next »

[kabbotta]

Solution: The Camera class was not initializing its position variables, so when the Manager class was constructed it caused garbage to be used for the x and y position and moved the Camera way off target. Builtin member variables do not have useful default values assigned to them!

I'm in the process of setting up a basic framework in SDL and I've encountered a very strange problem. I'm building and displaying a tile map made up of chunks, and everything was displaying just fine. Then I added a GameManager class, and all of the sudden nothing displays on the screen anymore. First, I started pulling things out of the class to see when the display came back, but it never did. I got down to just a bare class with a single empty constructor and no dependencies being included. The display still didn't come back. The input still works fine, and the render methods are all still being called, but nothing shows up on the screen anymore. I got frustrated enough, that I actually just deleted the GameManager class and recreated a blank class from scratch to see if it caused the same problem and it did. The second I instantiate an object of the class, I suddenly lose the display. The weirdest part is that it still occurs even if the instantiation is put off until after the whole game loop runs.

In my main.cpp:

Code:

Game game;

game.init();

while (game.is_running())
{
    game.update();
}

game.cleanup(); 

// Problem class
Manager mgr;

As you can see, I've moved the Manager instantiation to after the entire game loop runs, quits, and cleans up. But it still causes the display to disappear. There used to be a bunch of code in Manager that I took out looking for the problem, but this is all that is left:

Code:

#ifndef MANAGER_H
#define MANAGER_H

class Manager
{
public:
    Manager() {}
};


#endif /* MANAGER_H */

And the problem remains...

Here is the full project: https://github.com/kabbotta/last-ditch-cpp

[nox]

So, even if you remove the intantiation entirely, right now, your display works properly?

[kabbotta]

Yep. Just commenting out the instantiation causes the display to come back. I can even still include the file and it doesn't cause any problems, but if I add the instantiation, the display disappears. No matter where I add it, and no matter how stripped down the class is. I even deleted the class and created a new one with a different name. No errors or interupption to the rendering or input calls, but the display just remains black.

Maybe I'll throw the project up on github so that someone can see if it gives the same problem.

[happymonster]

Can you post all your code so we can see?

[kabbotta]

Sure. I just put it in this repo. https://github.com/kabbotta/last-ditch-cpp

I moved the Manager class back into the Game class body where the problem originally occurred. I just tested it again and all I have to do is comment the "Manager mgr_;" line and the display comes back.

[Average Software]

I don't know how to fix your problem, but I noticed this:

Code:

const std::vector<Chunk*> get_chunks() { return chunks_; }

Don't return things by const value.  It prevents return-by-move optimization, and that's a really big deal.  Drop the const.

[kabbotta]

Interesting, Average. Do you have a reference for what you are referring to? I'm a bit new to c++, and I thought you were supposed to return a const reference whenever you expected the data would not need to be changed to help document intention in the code.

[Average Software]

Interesting, Average. Do you have a reference for what you are referring to? I'm a bit new to c++, and I thought you were supposed to return a const reference whenever you expected the data would not need to be changed to help document intention in the code.

You aren't returning a reference, you're returning a copy.  if you mean to return a reference, you need to put a & after the type.  In that case, the const is fine.

[Cheezmeister]

Uh, well CMake gets confused* in OSX and I have to fiddle with flags to get everything kosher. Then I get a black screen and a crash and this

Assertion failed: (p_tileset_), function init, file /Users/cheezmeister/stuff/hax/last-ditch-cpp/src/systems/RenderSystem.cpp, line 23.

I don't think that's your problem, though

* Looks like it doesn't ship with a FindSDL2.cmake. Are you providing your own?

[jgrams]

This is a random thought, but...have you tried dynamically allocating the Game instead of making it a local variable in the main function? I've run into compiler bugs where you can't stack-allocate structures over a certain size without it causing bizarre problems...

[kabbotta]

Oh, good point, Cheez. I've just updated the repo so it includes the cmake modules and the resource images so that everyone should be able to run the project. Cmake does not come with a FindSDL2.cmake.

Thanks for the suggestion, jgrams, but it didn't seem to bring back the display. The weird thing is that I'm not getting any errors at all, and all of the render calls are still happening just like they should be - just no picture on the screen unless I comment out the Manager.

[Pit]

In the Camera class you never initialize the x and y value, thus you render with a crazy offset completely outside of the screen. Initializing those values fixed it for me.

[happymonster]

Well done Pit!

[jgrams]

Heh. I was just writing that.

So it's not surprising that it changes when you add the Manager: it's just taking whatever trash is on the stack, so when you call another constructor or add another thing to the class...there's different trash there...

Actually that's a good rule of thumb: if you make innocuous changes to your structures (add an element, change the order of fields) and something breaks, it's likely a failure to initialize something. Or a buffer overflow, but failure to initialize is easier to find, so check for that first.

[kabbotta]

Awesome! Thanks, guys, and nice catch, Pit. I had convinced myself that the default constructor was zeroing out those ints. I completely forgot that c++ doesn't promise that. Gotta get Java out of my head...

It seems so strange that the other three classes being initialized in Game had no effect on the zeroes that just happened to be in x_ and y_, but adding the Manager class finally caused them to have wild values.

[nox]

I've got this strong sense of pride in the forum for solving this problem. It could have been a really tough one...but boom, collaboration, and solution.

Praise Pit.