SFML community forums

General => General discussions => Topic started by: OrderNexus on May 04, 2017, 06:43:46 am

Title: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 04, 2017, 06:43:46 am
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://d255esdrn735hr.cloudfront.net/sites/default/files/imagecache/ppv4_main_book_cover/9885OS_B05590_Mastering%20SFML%20Game%20Development.jpg)

https://www.amazon.com/Mastering-SFML-Development-Raimondas-Pupius/dp/178646988X/ (https://www.amazon.com/Mastering-SFML-Development-Raimondas-Pupius/dp/178646988X/)
https://www.packtpub.com/game-development/mastering-sfml-game-development (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)
(http://i.imgur.com/hKTGZSS.png)
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 (http://ordernexusdev.tumblr.com/post/155511575788/making-a-2d-rpg-project-look-snazzy-with-bump)
A couple of different angles showcasing the specular lighting:
(http://i.imgur.com/g94aFqJ.png)
A glimpse at some of the game asset editing tools built from scratch:
(http://i.imgur.com/dfa7g8s.png)
Some multi-state particles being used in different ways:
(http://i.imgur.com/XFjkr5j.png)
(http://i.imgur.com/hATqand.png)

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!
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: GameBear on May 06, 2017, 08:31:41 pm
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 :)
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 07, 2017, 04:30:32 am
Hope you enjoy it. Let me know if you have any questions or concerns!
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: Mario on May 07, 2017, 09:15:38 am
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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 07, 2017, 12:52:17 pm
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!
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: SeriousITGuy on May 10, 2017, 10:08:37 am
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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 10, 2017, 03:10:46 pm
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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: _Imperial_ on May 12, 2017, 10:00:41 pm
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  8). 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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 18, 2017, 04:52:33 am
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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: _Imperial_ on May 24, 2017, 04:55:54 am
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  ;) ;D

BTW... look what I did to help me visualize better the whole engine. A diagram!  8)
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: eXpl0it3r on May 24, 2017, 11:41:39 am
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).
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 26, 2017, 05:15:43 am
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!
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: _Imperial_ on May 28, 2017, 06:47:54 pm
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. =)
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on May 31, 2017, 03:35:25 am
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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: _Imperial_ on May 31, 2017, 03:47:17 pm
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 8). 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.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on June 13, 2017, 05:13:19 am
Hi _Imperial_,

Sorry about the late response. I've been incredibly busy for the past couple of days. The first problem does seem strange. Are you experiencing any other types of lag? Can you debug your code and spit out some basic information about the update loop while the problem persists, such as the delta time during the update? I'd have to know more details to really draw any useful conclusions.

Second problem might be happening in cases where you don't have your OpenGL context created yet, but you're trying to call a gl function. Make sure the context is actually created beforehand, again, probably by just stepping through code while debugging and making sure. You will want to take a look at the Window::Create method and see if the context has been established. Also make sure that the sf::ContextSettings variable in there actually reflects the GL context your machine supports. By default, I believe, it's v4.5. Try to downgrade it to 3.0 and see if it works. Chances are your graphics card may not support the latest GL versions.

Let me know if it works, and give me some more details on both issues if at all possible. Preferably, the type of exception you're getting, driver versions, glew version, GL version, etc.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: _Imperial_ on June 14, 2017, 05:15:37 am
Hi OrderNexus, thank you for the reply.

About your questions:
1. No, there was no other types of lag: just the player movement. I tried using your version of chapter 9 files, just compiled and run and I experience the same issue. This issue started happening after chapter 5 (when we cut off SFML and started using openGL).

1.1. My delta time during the update? Let me know exactly what you want me to create so I can log something for you to see.

2. GLEW version I use is the latest on their website (v 2.0.0) which supports opennGL up to 4.5. My graphics card is simple, it only supports up to 4.4, but that didn't seemed to be the problem, because I use 4.4 in the context setting inside Window::Create() and I was able to follow the entire chapter 6 (when you create a rotating 3D cube on the screen as an introduction to openGL) and it compiled and ran just fine. As a comparisson, here is the setting I am using:
void Window::Create() {
        sf::Uint32 style = sf::Style::Default;
        if (m_isFullscreen) { style = sf::Style::Fullscreen; }

        sf::ContextSettings settings;
        settings.depthBits = 24;
        settings.stencilBits = 8;
        settings.antialiasingLevel = 0;
        settings.majorVersion = 4;
        settings.minorVersion = 4;

        m_window.create(
                sf::VideoMode(m_windowSize.x, m_windowSize.y, 32), m_windowTitle, style, settings);
        ...
}
Actually, the engine with those context settings compiled every time until chapter 9. It only started throwing an exception when we created that class called "GenericFBO" and used it to create the framebuffer m_FBO. The exception is thrown in this line:
void GenericFBO::Create() {
        if (!m_FBO) { glCreateFramebuffers(1, &m_FBO); } // <-- exception throws right here!
        ...
}
and the exception message is attached to the attachments below my post, followed by my graphics card settings. Let me know what you would like me to do in order to solve this. I'm really into game programming. I love it and I don't want small stones in the path to break my motivation to keep going. I want to start the debugging tool for the engine. I also bought another C++ book to further my knowledge! (https://www.amazon.com/How-Program-10th-Paul-Deitel/dp/0134448235/ref=sr_1_1?ie=UTF8&qid=1497409561&sr=8-1&keywords=deitel+deitel+c%2B%2B) 8) Supposedly a very good one.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on August 11, 2017, 07:41:57 pm
Hi _Imperial_,

Sorry I wasn't able to reply sooner, I was actually away for quite a while and was unable to really be of any assistance. Let me know if you have figured out your problem, or if it still persists and I will do my best to aid you in resolving it.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: Sidious78 on August 30, 2017, 10:17:51 am
I am well underway with designing an mmo, having spent most of the time writing the server code, and setting up the interface on the client-side.

About the map editior: Selecting a map size that exceeds 1000x1000 seems to cause all types of problems. Certainly, memory should not be an issue.

Anyone else having this problem? I canĀ“t seem to find any size limits in the map system itself.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: OrderNexus on August 30, 2017, 04:12:04 pm
That would probably have to fall under the issues of optimization, given the type of project you're working with. I would go with switching back to rendering individual tiles into a buffer texture that's the size of the screen to eliminate the need of having a large texture that may not be available on certain platforms. Without any more details I can't provide a better answer.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: Schorsch on April 08, 2018, 10:15:30 pm
I have some problems with the code. I started to fix some bugs in it but it is much work. So i started to fix the code of the first book, SFML Game Development By Example, because there i don't need to fixall problems in one step. The engine is build slowly over the chapters. Currently i fixed the code for chapter 1 to 9 and the others will follow. After that, i will try to get the code for this book running. If some of you guys have already fixed some of the problems, please contact me :)
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: JermaineD on April 10, 2018, 05:11:36 pm
I have some problems with the code. I started to fix some bugs in it but it is much work. So i started to fix the code of the first book, SFML Game Development By Example, because there i don't need to fixall problems in one step. The engine is build slowly over the chapters. Currently i fixed the code for chapter 1 to 9 and the others will follow. After that, i will try to get the code for this book running. If some of you guys have already fixed some of the problems, please contact me :)

Are there big problems with the code or are the problems only minor things, Schorsch? I'm just curious.
Title: Re: Mastering SFML Game Development (n-th SFML book?)
Post by: Schorsch on April 11, 2018, 02:40:26 pm
Are there big problems with the code or are the problems only minor things, Schorsch? I'm just curious.
Most of the problems are minor. I started to fix the code from his first book, because he uses this code in the new book as a base. I am almoust done with that part.
The problems vary from "void main(int argc, void** argv[])" like stuff to missing methods or codefiles. There are even some logical mistakes, malformed configuration files the game wants to read and so on. So it is much work to solve those problems. If someone wants to have the code, you can get it here (https://github.com/sschellhoff/SFMLGameDevelopmentByExample). Currently, i fixed chapter 1 to 11. So there are three more chapters left. After that, i will make the same for the current book. If someone wants to help, feel free. :)