Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Re:creation - a top down action adventure about undeads [hiatus]  (Read 485331 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re:creation - a top down action adventure about undeads
« Reply #600 on: May 27, 2016, 09:12:09 am »
Quote
Should I use both pragma once and include guards?
I'd say include guards. According to wikipedia, at least gcc and clang are able to detect and optimize them the same way as #pragma once.

Quote
I have no idea for the namespace yet, any suggestions?
I'm not an expert in finding names ;D

Quote
I've changed getMembers from being a class member function to Meta struct templated function.
Much better :)

Quote
1) I'm thinking about renaming MemberPtr to just Member. Is this reasonable?
Sure. Here you're abstracting things, there's no such concept of "pointer" at this level.

Quote
3) What should library do in exceptional cases?
Why are you asking? Any problem with exceptions?
Laurent Gomila - SFML developer

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #601 on: May 27, 2016, 09:30:53 am »
I'd say include guards. According to wikipedia, at least gcc and clang are able to detect and optimize them the same way as #pragma once.
Will do :)

I'm not an expert in finding names ;D
SFML is a good name. ;D

Much better :)
Neat

Sure. Here you're abstracting things, there's no such concept of "pointer" at this level.
Agreed, I'll rename it to just Member.

Why are you asking? Any problem with exceptions?
Just isn't used to writing them and I don't see them often in code, to be honest. Any good libraries or examples of doing exceptions good way? :D

Btw, I was trying to implement something like this:
template <typename Class, typename F>
inline void Meta::doForMember(const std::string& name, F&& f)
{
    for_tuple([&](const auto& memberPtr) {
        if (memberPtr.getName() == name) {
            f(memberPtr);
        }
    }, getMembers<Class>());
}

...

// can get age like this!
int age;
Meta::doForMember<Person>("age",
     [&age, &person](const auto& memberPtr) { age = memberPtr.get(person); });
 

But this didn't work, because lambda which is passed to doForMember is instantiated for each MemberPtr and so line "age = memberPtr.get(person);" fails for all non-int types. Any tips about what I can do? (This looks like conditional compilation, he-he).
« Last Edit: May 27, 2016, 01:50:26 pm by Elias Daler »
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re:creation - a top down action adventure about undeads
« Reply #602 on: May 27, 2016, 10:05:58 am »
Quote
Any good libraries or examples of doing exceptions good way?
I don't know, but it's pretty easy:
- create your own exception class(es)
- throw on exceptional case
- catch where it makes sense to handle the exceptional case

But in your example (function which returns a non-const reference to member), this is a programer error, not a runtime error, so I'd say you should treat this one with an assert -- maybe you could even static_assert with some tricks, as everything is known at compile time?

Quote
But this didn't work, because lambda which is passed to doForMember is instantiated for each MemberPtr and so line "age = memberPtr.get(person);" fails for all non-int types. Any tips about what I can do?
This is the kind of problems you'll run into with such a strongly-typed generic approach.
However I guess this one could easily be solved with a visitor:

class Visitor
{
    template <typename T>
    void visit(const Member<T>&)
    {
    }

    void visit(const Member<int>& member)
    {
        do_something_with(member.get());
    }
};

Visitor visitor;
visit(Meta<Person>::getMembers(), visitor); // for_each(member) visitor.visit(member)
 

This is the typical way to dispatch an heterogeneous container in a strongly-typed context.

This is just the idea, you'll now have to try to wrap this stuff so that it can carry all the needed context (age and person variables), and is more friendly on user-side (so you can use a simple lambda instead of writing a full visitor everytime).

The other typical approach is to introduce an intermediate weakly-typed layer (with a variant class for values, and abstract base classes on top of anything that depends on the underlying member type). But that's a different story.
« Last Edit: May 27, 2016, 10:11:55 am by Laurent »
Laurent Gomila - SFML developer

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #603 on: May 28, 2016, 12:37:27 am »
Thanks for ideas, Laurent. I actually came up with a neat solution to the problem with some inspiration from your example.
I used SFINAE to create function call_if_same_types<T, U> which calls (and instantiates) lambda with given args if types T and U are the same (and does nothing otherwise).
It's used here. The coolest thing about this function is that it won't instantiate the lambda with wrong MemberPtr type! So, the user only gets const MemberPtr<T, Class>& member in lambda. The user needs to pass correct member type to doForMember function but that's pretty basic and I don't see any way to deduce member's type without user passing it explicitly.
doForMember allowed me to create two useful functions: getMemberValue and setMemberValue which can be used like this:
int age = Meta::getMemberValue<int>(person, "age");
Meta::setMemberValue<int>(person, "age", 30);

Unfortunately there's very little that my library can do at the compile time, because I can't get access to a given member by it's name, because all Member instances are created during runtime. I'm okay with doing all stuff during runtime, though. :) (It would be cool to be able to use static_assert a lot, but it's hard in my implementation)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #604 on: June 01, 2016, 12:48:29 am »
Here's how my animation editor looks now:

Animation properties part is generated with Meta stuff and directly maps widgets to C++ variables, which is pretty cool and shows that spending some time on all this template stuff was useful. :)
I also wrote the tutorial about how to use ImGui with SFML which some of you may find useful. :)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Lin

  • Newbie
  • *
  • Posts: 6
  • Just another game developer.
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #605 on: June 03, 2016, 03:05:11 am »
That looks really nice. The interface is clean, the system is flexible, and overall it's very powerful. I like it a lot!

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #606 on: June 04, 2016, 12:00:15 am »
That looks really nice. The interface is clean, the system is flexible, and overall it's very powerful. I like it a lot!
Thanks a lot! :D
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Ethan.Calabria

  • Newbie
  • *
  • Posts: 16
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #607 on: June 04, 2016, 08:50:59 pm »
Hey Elias, thanks for the ImGui tutorial, it was great!  I'm looking forward to the second part.  Out of curiosity, do you have a Youtube channel for you or for Re:creation?
----
Follow me on twitter: here

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #608 on: June 06, 2016, 12:16:40 am »
Hey Elias, thanks for the ImGui tutorial, it was great!  I'm looking forward to the second part.  Out of curiosity, do you have a Youtube channel for you or for Re:creation?
You're welcome! :)

I have a youtube channel, but it has just some old covers, ha-ha. Some day it'll be used for Re:creation trailers and dev log updates, though. But I can't say when because I like writing more than speaking. :)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #609 on: July 04, 2016, 11:12:56 pm »
Hi, everyone, I'm back!
I recently finished my bachelor's degree and now I'm free for some time so I'll work on the game as hard as I can!



I've published new dev log about what I did in the recent months. There's some new stuff that I didn't write before (especially Action Lists) so be sure to check it out.

Today I've also made some awesome changes to input handling. Input was previously hard coded in C++ and this wasn't very good. But I've moved all input handling in Lua and finally separated input from game logic which is awesome:

playerCallbacks = {
    usePrimaryItem = {
        action = ButtonPressedAction(self.buttons.PrimaryAction),
        f = function()
            playerEntity:usePrimaryItem()
        end
    }
}

...

inputManager:setCallback("Press_Primary", playerCallbacks.usePrimaryItem)
 
So, I register callbacks and bind them to different actions. Suppose that I entered the menu and now pressing Primary Action button does some another thing.

It's pretty easy to change, I just do this:
inputManager:setCallback("Press_Primary", menuCallbacks.select)

Very easy and clean. Btw, ButtonPressedAction calls sf::Keyboard::isPressed and so input handling is very fast.

 Still, it may not be perfect, so feel free to advice some stuff I may do better. :)
« Last Edit: July 04, 2016, 11:38:48 pm by Elias Daler »
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Mortal

  • Sr. Member
  • ****
  • Posts: 284
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #610 on: July 05, 2016, 01:29:43 am »
Hi, everyone, I'm back!
I recently finished my bachelor's degree and now I'm free for some time so I'll work on the game as hard as I can!


congratulation for bachelor's degree Elias.  :)

Today I've also made some awesome changes to input handling. Input was previously hard coded in C++ and this wasn't very good. But I've moved all input handling in Lua and finally separated input from game logic which is awesome:
i'm totally agree with you regarding separation of game logic and input that makes sense for game design. but  why do you thing that implementing input functionality with C++ is bad idea?

Glocke

  • Sr. Member
  • ****
  • Posts: 289
  • Hobby Dev/GameDev
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #611 on: July 05, 2016, 08:13:44 am »
Hi, everyone, I'm back!
I recently finished my bachelor's degree and now I'm free for some time so I'll work on the game as hard as I can!

Gratz! And nice to have you back :-)

I've published new dev log about what I did in the recent months. There's some new stuff that I didn't write before (especially Action Lists) so be sure to check it out.

Nice :) Keep on coding and posting :-)
Current project: Racod's Lair - Rogue-inspired Coop Action RPG

Elias Daler

  • Hero Member
  • *****
  • Posts: 599
    • View Profile
    • Blog
    • Email
Re:creation - a top down action adventure about undeads
« Reply #612 on: July 05, 2016, 09:37:52 am »
congratulation for bachelor's degree Elias.  :)
Thanks

i'm totally agree with you regarding separation of game logic and input that makes sense for game design. but  why do you thing that implementing input functionality with C++ is bad idea?
It's not a bad idea, it's just not as flexible as I want. I want to be able to change input in scripts (not just bindings!) so that I don't have to recompile C++. And if I set up callbacks, they'll probably be Lua functions and calling Lua for each keypress will be inefficient and calling simple update() function in each frame seems to be much faster.

Gratz! And nice to have you back :-)

Thanks!

Nice :) Keep on coding and posting :-)

I will. :)
Tomb Painter, Re:creation dev (abandoned, doing other things) | edw.is | @EliasDaler

Ungod

  • Newbie
  • *
  • Posts: 44
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #613 on: July 05, 2016, 07:50:29 pm »
Decent work so far!

So what you basically do is store a callback function together with a button/key and invoke that callback when the appropriate inputEvent is catched? What if you want multiple callbacks to be invoked on the same keypress?

Btw I think I saw you posting at Sol2 on GitHub (the world is small), is that right? I recently started using it and I think its pretty decent. Do you use it?

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re:creation - a top down action adventure about undeads
« Reply #614 on: July 05, 2016, 11:14:05 pm »
What if you want multiple callbacks to be invoked on the same keypress?

Use something capable of storing multiple entries, such as a vector? :)