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

Author Topic: How do I deal with abstraction when it comes to SFML? [SOLVED]  (Read 1267 times)

0 Members and 1 Guest are viewing this topic.

Riser

  • Newbie
  • *
  • Posts: 33
    • View Profile
Hello,I've been working on this simple shoot 'em up for a while,and I've finished most of the main gameplay loop now,I have a looping background,a character that you can move and shoot with,enemies to shoot,a working healthbar,dying/respawning mechanic...

Objects like enemies,player,and background already have their own respective header and source files,where I declared their classes and defined their related methods,but all of the objects and their related variables are declared in the main.cpp file,along with most of the game logic, like, collision, dying/respwaning, shooting, spawning/destroying enemies and projectiles,etc...

And now I want to work on other aspects of the game,such as adding other scenes (Main menu,level selection),so what I want to do is move  all of the objects I've declared into a header file (Let's call it "Game.h" ) and move all of the game loop logic into a method that I can call inside the main loop (Declared inside a class in "Game.h" and defined in "Game.cpp" ) ,but I kept getting strange errors when I tried to compile,such as a linker error in main.obj telling me that the "objects are already defined in game.obj ",even though I already commented them out in main.cpp (Note here that I only moved the objects,not what's inside the game loop),among other things,everytime I try something that I think would work I end up with another error.

TL;DR how do i move everything in the main.cpp file to another file without messing up the whole project? Preferably while also keeping the general structure of the main.cpp file intact: Event handling,game loop, and then displaying everything,which now that I think about is part of the game loop so I'm not sure...
« Last Edit: July 10, 2020, 05:53:47 am by Riser »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11032
    • View Profile
    • development blog
    • Email
Re: How do I deal with abstraction when it comes to SFML?
« Reply #1 on: July 07, 2020, 10:00:58 pm »
Are you using header guards for your files? Those should prevent double symbol issues.
If you have a cyclic dependency you may also make use of forward declaration.

Finally, you may consider moving all the logic from main() to a dedicated class, that way you can also use scoped member variables.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Riser

  • Newbie
  • *
  • Posts: 33
    • View Profile
Re: How do I deal with abstraction when it comes to SFML?
« Reply #2 on: July 08, 2020, 09:28:44 pm »
So, the weirdest thing happened, it turns out I did forget to add header guards,after adding them I was able to successfully move all the objects to the "Game.h" file, and the game did work as intended, but only once, because I wasn't able to get it to work again after I tried to copy the logic to a method(s) in "Game.h" and ended up with the same "objects are already defined in game.obj " and "Multiply defined symbols" errors (Even though I DID add header guards this time), So I tried reverting those changes but I still always ended up with those errors no matter what I did, even if I comment out almost everything in the main.cpp file, the error log still complains about objects in main.obj being already defined in game.obj, unless I put everything back into the main.cpp file, I've been messing with it for hours and still no luck...


And to answer your other questions: I don't have cyclic dependency,but I'm already using both forward declarations AND a dedicated class,I created a class in "Game.h" containing the declarations of the logic method(s), which are defined in "Game.cpp".

I don't know what to do.

EDIT: Sigh It turns out I may have actually created a cyclic dependency after all,I'm not exactly what it was but the problem was the #include structure,after changing a couple of inclusion lines here and there to make it more like the other header files,everything now works as intended.
« Last Edit: July 10, 2020, 05:53:26 am by Riser »

 

anything