Mastering SFML Game Development (n-th SFML book?)

[OrderNexus]

Hello again, SFML community! Although it has been quite a while since its actual release, I'm still happy (although late) to announce that the newest (to my knowledge) SFML book is finally published and available in a myriad of formats and locations now:



https://www.amazon.com/Mastering-SFML-Development-Raimondas-Pupius/dp/178646988X/
https://www.packtpub.com/game-development/mastering-sfml-game-development

The logical question, I suppose, is what does this one actually offer in comparison to everything else out there. Aside from picking up right where my first book (SFML Game Development by Example) left off, it teaches and demonstrates more advanced rendering techniques to improve your games. Everything from using sf::Shaders to actually going raw OpenGL is covered, and the results range from simply manipulating the rendered image on screen to actually implementing ambient, normal and specular lighting, as well as fully three-dimensional shadows in a 2D game. It also goes over the creation of your own custom tools for building game assets such as maps, using various profiling tools and actually optimizing your game code, and building a particle system that emulates 3D particles in a 2D world.

This is what the shadows look like in the game: (I know the ground looks a bit tiled, and that's simply because auto-generating normal and specular textures for tile-maps is a bit painful, and usually leads to hard edges. I did my best to combat that, but the software I had access to didn't deal with that right, and I have no artistic skills to draw my own material-maps)

There's also a video of this in action, showcasing how raising and lowering the light affects the shadows being displayed on tiles with greater elevation:
http://ordernexusdev.tumblr.com/post/155511575788/making-a-2d-rpg-project-look-snazzy-with-bump
A couple of different angles showcasing the specular lighting:

A glimpse at some of the game asset editing tools built from scratch:

Some multi-state particles being used in different ways:



A lot of concerns from previous input I've received have been addressed and taken into account, such as using smart pointers, relying on C++11/14 a lot more, following certain general guidelines etc. In the end, I did want to make this book seem like something I myself would want to purchase and use to get better, so that was my primary objective. I think I have accomplished that, and I can't wait to hear some feedback from the community.

If you do decide this is a book you might enjoy and end up reading it, please feel free to contact me at any time to let me know whether it was acceptable or not. If any problems arise, I'm available (within reason) here through the PM system, or you could just directly shoot me an email at order.nexus.dev@gmail.com. Love it, hate it, bash it or praise it, I'd just be happy to hear from you and potentially help you out.

Hope you all enjoy it, and thanks for reading!

[GameBear]

I just got the book today.
I'm looking forward to go through it...

All in all I'm glad, my c++ library is growing well

[OrderNexus]

Hope you enjoy it. Let me know if you have any questions or concerns!

[Mario]

I know the ground looks a bit tiled, and that's simply because auto-generating normal and specular textures for tile-maps is a bit painful, and usually leads to hard edges.

While haven't tried it, create a new texture using the tiles in a 3x3 tiled pattern. Generate your normals, then just copy the central piece and use that one.

[OrderNexus]

It's a great idea, actually. I had the same thought as well, except I couldn't quite get it to work just the way I wanted. The results you saw already had that technique applied. Chances are if it wasn't crunch time and I had a bit more room to work the magic, I would've perfected it. Thanks though, I appreciate the feedback!

[SeriousITGuy]

As Packt was kind enough to give me a 70% Discount code for their developer survey, I picked this up. First look is promising, and if the pain Points of the first book have been reworked I look Forward to the rest.

[OrderNexus]

As Packt was kind enough to give me a 70% Discount code for their developer survey, I picked this up. First look is promising, and if the pain Points of the first book have been reworked I look Forward to the rest.

Glad to hear you picked it up! The pain points have been re-worked, I assure you. Perhaps there might be some new pain points though, so feel free to let me know if you find something like that.

[_Imperial_]

Hi OrderNexus. I was thinking the other day about animated tiles. To make that happen in a easy and convenient way, what would be your suggestion (and why):
- Create a new component that attaches to Tile objects and use SpriteSheet_Animation System itself?
- Or... Modify the Tile and Tile_Info structs and have them had the abilitity to hold an Animation options (such as isTileAnimated() and addSpriteSheetAnim() to Tile).

I have a couple ideas here.... hahaha  . But I just can't decide on what would be a better approach: both for maintaining the existing code-base as intact as possible while still trying to have this new functionality easily tweakable.

[OrderNexus]

The smart thing would probably be re-using the existing system, but it was specifically designed to work with sprite-sheets. Depending on how you actually store the animated tiles, it may not work exactly as you want. Some re-designs might be in order. You could generalize the existing animation class enough to apply to your situation.

[_Imperial_]

OrderNexus, I have some questions.

I'm in chapter 7, but since the beginning I have noticed that you serialize lots of parameters into different .txt files and also have built numerous de-serialization functions into most of your data structures. Is there a specific reason why you engineered the engine like that.
I would like you to give me an insight on some reasons that made you decide to plan the engine like your did. Why not storing those data in the code-base itself? For example, some objects such as entity (name, health, id, position, etc..), sound properties (attenuation, volume) and even particles (lifespan, colorRange, etc..) could be initialized to some desired values inside the body of their respective constructors and just ReadFromMemory(...) instead of ReadFromFile(...).
I'm novice in engine programming, but I am just trying to understand the "whys" of these decisions. Do most engines employ these serializations when their objects are initialized and need to read their parameters from a file? I think you wanted to be able to tweak properties in the .txt file without the need to recompile everytime. Is that one of the objectives?

Well, if it's possible, just shed some light on these topic for me and help me understand more about these engine architecture decisions.

I'm looking forward to hearing your ideas!! (and also some other alternative ideas that you might have thought about but decided to not to implement)

Thanks 

BTW... look what I did to help me visualize better the whole engine. A diagram! 

[eXpl0it3r]

I'm novice in engine programming, but I am just trying to understand the "whys" of these decisions. Do most engines employ these serializations when their objects are initialized and need to read their parameters from a file? I think you wanted to be able to tweak properties in the .txt file without the need to recompile everytime. Is that one of the objectives?

I'm not the author, but that's pretty much the main reason why "magic" values aren't hard-coded but made easily changeable. Imagine you had to balance some health and attack values, which can easily go to like 100 edits and tests, having to recompile the whole game for every change, would take up a lot of time, while saving the text file and restarting the game or having a built-in function to on-the-fly reload the data, will save you hours.

I can't speak for the engine in the book, but some engine designs go along the way of letting the user build a game without ever touching the engine code. So you write all the game logic within scripts that get loaded at runtime (see Unity, UE4, etc).

[OrderNexus]

OrderNexus, I have some questions.
...

eXpl0it3r is actually right on the money about that. Building in certain values can be useful, but most of your game data will be subject to change, whether through tweaking, updates, or simply adding new content. Serialization separates that part of development from actual code so that:
a) Changing the values at any time is easily maintainable and relatively fast.
b) Tools can be built to speed up that process even more by manipulating an established format. (Editors)

Regarding the ideas I haven't had time to implement, I have a whole list, actually. Let me know in PM if you want me to share that, and I'll send you some stuff. By the way, the diagram is actually really useful! Did you do it by hand, or use some sort of software to generate that? Let me know!

[_Imperial_]

I believe I found a bug in the Map Editor.
Please, can someone try to reproduce this steps?
Go in MapEditor mode -> Click "Selection" -> click "Toggle" (to change solidity).
Do this without selecting a tile in the map and also without being in brush mode. I believe that, if replicated correctly, it freezes the game. LOL

Anyway, I also found a fix for that. The problem was that, when in SelectionMode, if no tile is selected in the map, when it loops over this section: "for (auto x = start.x; x <= finish.x; ++x) { ..... y.... layer... }" it never finds the tile. So it freezes.
So, to fix this is actually very simple: improve the check made right in the beginning of the toggle function. It will enter the function and do its thing only if mode is "Brush", or mode is "Selection" and if "m_selectedRangeX.x != -1" (this means that if it is indeed -1, the coordinates were never initialized, remaining at (-1,-1)). Summarizing, the old code and the new code would be:

old code:
if (m_mapControls->GetMode() != ControlMode::Brush && mode != ControlMode::Select) { return; }

new code:
if ((m_mapControls->GetMode() != ControlMode::Brush && mode != ControlMode::Select) || m_selectRangeX.x == -1) { return; }

Now, after this fix, if you hit toggle and happen to not have selected a tile on the screen (which I did when trying to make a new map in the editor), the ToggleSolid() command gets ignored and the game doesn't freeze. =)

[OrderNexus]

I vaguely remember testing that just before finalizing, and it not crashing at all. Weird. While it's possible some other small but crucial bit of code got left out as you were building the editor, I'm not sure. Either way, since solidity toggling only applies to selection mode, I'd stick to modifying that branch down the line inside the SolidToggle method:

void GUI_SelectionOptions::SolidToggle(EventDetails* l_details) {
  auto mode = m_mapControls->GetMode();
  ...
  if (mode == ControlMode::Brush) {
    ...
  } else if (mode == ControlMode::Select) {
    ... // Modify/verify the selection range here.
  }
  ...
}

Doing it up top like that completely ignores the fact that brush mode doesn't even deal with selection range. At least modify your check up top to something like this:

if (m_mapControls->GetMode() != ControlMode::Brush && (mode != ControlMode::Select || m_selectRangeX.x == -1)) { return; }

Goes to show how missing something simple like that can result in a crash.

[_Imperial_]

Yes, the editor crashed every time if you replicated those steps. Also, it makes sense to use my suggested check, but moving it into the specific portion of the code that matters to it: the selection mode (as you suggested!) -> BUG FIXED! 

Now, not related to the map editor anymore (and jumping from chapter 4 to chapter . One wierd thing started to happen and before posting it here I double check with the source code from PacktLib instead of just trusting my own version of the code (because it could have been my fault if I missed something). So the results described below are after compiling and runing the original source code available with the book purchase by PacktLib.

PROBLEM 1 (minor):Prior to chapter 8 you could move your guy in the town, so all movement was working fine. After the modifications in chapter 8, we can only move the guy for about 1 or 2 seconds before it starts to decelerate and then completely stops. No matter how you keep pressing any directional key, it doesn't move anymore. You have to hit ESCAPE to return to main menu and get back to the game state so it can move a little bit more if you press the key, only to stop again after 1 or 2 seconds. It's like something is slowing him down like a car applying the brakes. It's very wierd, specially because we didn't change anything in the S_Movement or C_Controller files. I can't wrap my head around why chapter 7 (implementing openGL camera, transforms, etc..) and chapter 8 (implementing basic light) has to do/can influence the character movement.

PROBLEM 2 (critical): After chapter 9, following the implementations of the 3d dynamic shadows, we are forced to move to openGL completely when using our rendering engine and the shaders. With that, we are instructed to create a GenericFBO class, so far so good. After compiling the Packtlib version of chapter 9 (to see if I still encounter the error), I still do, and hit an exception at the following line :

void GenericFBO::Create() {
        if (!m_FBO) { glCreateFramebuffers(1, &m_FBO); }

Observation: My graphics card can run OpenGL fine and its drivers are updated.

Well, those are the two main problems: character movement (wierd, wierd!) and the openGL exception that doesn't let me run the game anymore.