Messages

1

General discussions / Re: Mastering SFML Game Development (n-th SFML book?)

« 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) Supposedly a very good one.

2

General discussions / Re: Mastering SFML Game Development (n-th SFML book?)

« 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 . 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.

3

General discussions / Re: Mastering SFML Game Development (n-th SFML book?)

« 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. =)

4

General discussions / Re: Mastering SFML Game Development (n-th SFML book?)

« 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 

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

5

General discussions / Re: Mastering SFML Game Development (n-th SFML book?)

« 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  . 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.

6

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: May 09, 2017, 04:49:00 am »

void StateManager::update(const sf::Time& time) {
   if (statesContainer.empty()) { return; }
   if (statesContainer.back().second->isTranscendent() && statesContainer.size() > 1) {
      bool reversing = true;
      for (auto statesItr = statesContainer.end() - 1; statesItr != statesContainer.end(); (reversing ? --statesItr : ++statesItr)) {
         if (!statesItr->second->isTranscendent() || statesItr == statesContainer.begin()) {
            reversing = false;
            if (!statesItr->second->isTranscendent()) { continue; }
         }
         if (!reversing) {
            statesItr->second->update(time);
         }
      }
   }
   else { statesContainer.back().second->update(time); }
}

void StateManager::draw() {
   if (statesContainer.empty()) { return; }
   if (statesContainer.back().second->isTransparent() && statesContainer.size() > 1) {
      bool reversing = true;
      for (auto statesItr = statesContainer.end() - 1; statesItr != statesContainer.end(); (reversing ? --statesItr : ++statesItr)) {
         if (!statesItr->second->isTransparent() || statesItr == statesContainer.begin()) {
            reversing = false;
            if (!statesItr->second->isTransparent()) { continue; }
         }
         if (!reversing) {
            locator->window->getRenderWindow()->setView(statesItr->second->getView());
            statesItr->second->draw();
         }
      }
   }
   else {
      locator->window->getRenderWindow()->setView(statesContainer.back().second->getView());
      statesContainer.back().second->draw();
   }
}

Yes OrderNexus, you are right. The previous approach wasn't doing any work inside the first loop. Sorry for the delay to reply. I wasn't able to dive into the engine code for a couple days, too busy. Anyway, after returning to it, I took my time to understand what needed to be accomplished there and I believe I got it right this time. Actually it uses only one for loop now.

7

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: May 03, 2017, 07:09:26 pm »

Hi, OrderNexus. I bought the Mastering SFML book. Big fan of your work. I want to dive deeper into openGL. Looks promising. Btw, I just thought you might like this small change on the codebase (that is, if you didn't do this yet in this specific part of the code). Anyways, on the StateManager.cpp file, consider using reverse_iterators, they are good for what you wanted to accomplish in the update and draw methods, but with less hastle.  Here is what I did. It has less lines of code and does the exact same thing and also uses the STL facilities "rbegin" and "rend". Thanks!! 

void StateManager::update(const sf::Time& time) {
   if (statesContainer.empty()) { return; }
   if (statesContainer.back().second->isTranscendent() && statesContainer.size() > 1) {
      for (auto statesItr = statesContainer.rbegin(); statesItr != statesContainer.rend(); ++statesItr) {
         if (!statesItr->second->isTranscendent()) { break; }
      }
      for (auto statesItr = statesContainer.begin(); statesItr != statesContainer.end(); ++statesItr) {
         statesItr->second->update(time);
      }
   }
   else { statesContainer.back().second->update(time); }
}

void StateManager::draw() {
   if (statesContainer.empty()) { return; }
   if (statesContainer.back().second->isTransparent() && statesContainer.size() > 1) {
      for (auto statesItr = statesContainer.rbegin(); statesItr != statesContainer.rend(); ++statesItr) {
         if (!statesItr->second->isTransparent()) { break; }
      }
      for (auto statesItr = statesContainer.begin(); statesItr != statesContainer.end(); ++statesItr) {
         locator->window->getRenderWindow()->setView(statesItr->second->getView());
         statesItr->second->draw();
      }
   }
   else {
      locator->window->getRenderWindow()->setView(statesContainer.back().second->getView());
      statesContainer.back().second->getView();
   }
}

8

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: January 26, 2017, 02:15:45 am »

Does anyone had this compiling problem? All other C_(something) are fed into the template just fine, just the SoundListener component that can't be instantiated. It says it's abstract.

9

General discussions / Re: SFML Game Development by Example - 4th SFML book

« on: January 23, 2017, 03:25:16 pm »

Hi OrderNexus. It's been a while I got your book, but only 2 weeks ago I could start going through it. It's an amazing work. Good job! I'm also looking forward to reading the Mastering SFML Game Development.
Anyway, my question is: I'm in chapter 11 (in the end). Just finished and compiled and ready to go to chapter 12 when...... BOOM! I don't have a GUI 
I don't understand what I did wrong. I am very careful to follow all the code and understand all that I am doing. It compiles without any errors (I use VS Community 2015).

Basically, it loads the Intro and when we go to MainMenu it doesn't show any GUI. I tried to bypass to see it the problem is in the Main Menu, so what I did was testing it by simply jumping from Intro_continue to Game. And nope, nothing wrong with the states. The game runs ok, the map loads.... but also no GUI in the game mode.

Summarizing: No GUI elements show anywhere, but the GUI_(something).h and GUI_(something).cpp look all fine. (I also ajusted the SharedContext, Satte_MainMenu and EventManager per your instructions).
I don't know what else to do.

Btw, there is also a minor bug that's been anoying me for a while (but it's no big deal). So, when you close the game using the 'X' button in the window, it purges all resources, all goes well, but the last second it displays a message saying (see attachment). That bug doesn't make the game unplayable or anything... it's just there since chapter 7 and I can't find the reason why.