Levels gone craaaaaazy!

[mspraggs]

I don't really know what's happened, but something has gone wrong somewhere and, well... see attached...

Is this just a problem with my build? Is there a file missing from the latest revision or something?

[Fyll]

I wouldn't go through the top exit, who knows what'd happen!

Ahem. Is it happening all the time? It hasn't happened for me, but if it's occasional I just may not have seen it yet.

[mspraggs]

It happens every time for me, and the results seem fairly random, as in a different "level" for each room. Are you sure you don't have any uncommitted changes? Maybe our compiler flags are different in some way? I checked out revision cdf32c8 and recompiled, and that worked well, so it must be a fairly recent change.

[Fyll]

Well, seeing as I just pushed a build, I think it must be something you've done to your code.

I do recall having a similar problem a while ago, but I can't remember how I got past it. I'll have a nose around on my end for any potential weaknesses like that.

[mspraggs]

I don't see how it can be something I've done, as I haven't done anything since March 11th. If I do git checkout cdf32f8 then rerun make, I get exactly what we had before the recent collision stuff.

It's weird, as according to the git logs, World.cpp, where the level loading stuff is defined, hasn't changed.

[DivFord]

I guess it could be coming from my changes to tiling, but that was March 11th as well.

[Fyll]

My guess is then that something hasn't been initialised. That was a problem that came up before that was different for different people. Is there anything you've forgotten to initialise in World.cpp?

[DivFord]

I just pulled and tested it, and I'm getting the same problem. It can't be a tiling problem though, because we don't get collisions either.

[mspraggs]

@DivFord That occured before the commit I checked out to, so it can't be that.

This is the output of my git status:

On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    CMakeCache.txt.old
    build/
    cmake/readme.md
    cmake_install.cmake
    debug.sh
    game
    leaks.log
    levels/active_levels.txt.orig
    output.cpp
    output.hpp
    temp
    test.cpp

nothing added to commit but untracked files present (use "git add" to track)

@Fyll could you run the same command and see what you get?

[DivFord]

@Fyll I think you might be onto something with the initialization failure:

[Fyll]

Very long printout ahead:

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   CMakeLists.txt~
#   Makefile
#   audio/bullet2.wav
#   audio/bullet3.wav
#   cmake_install.cmake
#   game
#   gfx/WeaponSpritesheets/Test.png
#   levels/Menu.txt~
#   levels/Retry.txt~
#   levels/active_levels.txt~
#   levels/middles.txt~
#   levels/test_level.txt~
#   lib/AI.hpp~
#   lib/Block.hpp~
#   lib/BlockList.hpp~
#   lib/Bullet.hpp~
#   lib/Constants.hpp~
#   lib/FilePaths.hpp~
#   lib/Fire.hpp~
#   lib/Game.cpp~
#   lib/Game.hpp~
#   lib/GraphicPool.hpp~
#   lib/Gun.cpp~
#   lib/Gun.hpp~
#   lib/GunList.hpp~
#   lib/Input.hpp~
#   lib/Levels.cpp~
#   lib/Object.cpp~
#   lib/Object.hpp~
#   lib/ParticleEffect.hpp~
#   lib/ParticleSystem.hpp~
#   lib/Pickup.hpp~
#   lib/PickupList.hpp~
#   lib/Player.cpp~
#   lib/Player.hpp~
#   lib/Position.cpp~
#   lib/Position.hpp~
#   lib/Prop.hpp~
#   lib/PropList.hpp~
#   lib/Room.cpp~
#   lib/Room.hpp~
#   lib/Screen.hpp~
#   lib/Sound.hpp~
#   lib/Sprite.hpp~
#   lib/Time.hpp~
#   lib/Unit.hpp~
#   lib/UnitList.hpp~
#   lib/Vector.hpp~
#   lib/Window.cpp~
#   lib/Window.hpp~
#   lib/World.cpp~
#   lib/World.hpp~
#   lib/block.hpp~
#   lib/levels.cpp~
#   lib/main.cpp~
#   lib/room.cpp~
#   lib/room.hpp~
#   lib/world.cpp~
#   lib/world.hpp~
nothing added to commit but untracked files present (use "git add" to track)

EDIT: Mines all fine:

[DivFord]

Isn't that the entire library?

[mspraggs]

Those look like temporary/backup files created by your editor.

[Fyll]

Oh yeah. However, everything has a ~ after it, which means it's the deleted version of it.

I really should clean those out one of these days. The bit that isn't just backups is:

# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   Makefile
#   audio/bullet2.wav
#   audio/bullet3.wav
#   cmake_install.cmake
#   game
#   gfx/WeaponSpritesheets/Test.png
nothing added to commit but untracked files present (use "git add" to track)

[mspraggs]

I suppose the acid test would also be to run git diff. This should tell us if there's anything that's being tracked that's been changed.

I can fix the *~ files... just a second.

[Fyll]

Nothing came up when I typed it in.

[mspraggs]

Ok I just added those files to the gitignore

[DivFord]

@Fyll Are you definitely not getting this bug? You haven't forgotten to make, or something silly like that?

[Fyll]

100% certainly definitely not happening over here. Especially if it's every time for you two. Pics or it didn't happen:

This is why I say it's initialisation. Can someone who understands World::registerCharCodeHandlers() check it, as it's all very scary and confusing to me, so I'm naturally suspicious of it.

@mspraggs: As an aside, I've deleted the *~ files and told gedit to stop making them, so everythings a lot tidier over here.

[mspraggs]

World.cpp hasn't changed though since the last "good" commit. The only thing I can think is that something has changed in another header file upon which World.cpp depends.

EDIT: With regards to registerCharCodeHandlers, all it's doing is adding to charHanlders_. The mapping is between a string, in this case a two-character code corresponding to the pair of characters in the level data, and a function with the following signature (Room& room, const std::string&, const int, const int, const int, const int). The std::bind stuff is just to bind particular codes to generic functions so that the same code can be reused.

[Fyll]

This is strange... Valgrind couldn't find any leaks or uninitialised variables (after cutting out all of the graphics and sound). It could have missed one, or I cold have commented it out with the gfx/sound accidentally, but it's still odd... (Also, nice to know there's apparently nothing wrong with the rest of the code).

@mspraggs: The bit that's confusing me is the std::placeholders.

[mspraggs]

std::bind returns a function, with certain variables bound to the input arguments of that function. If the function you're binding too takes more parameters than you want to bind, you use _1, _2, etc. to tell std::bind that you're leaving those arguments unbound. _1, _2 etc. are in the namespace std::placeholders, so we state at the start of the function that we're using stuff from that namespace, to prevent having to write out std::placeholders::_1 and so forth.

Has anything in Room.hpp changed that could affect the way blocks are initialised?

[Fyll]

Not that I can see. The only thing I've tweaked in there is applyFDG().

I've tried changing World::registerCharCodes() a bit (I know you said it wasn't the problem point, but I figured it'd probably be a good idea to get my head around it). Does the change change anything? If so, there's some sort of memory leak....

[mspraggs]

What you've done shouldn't change the behaviour, no. Indeed, it's probably better because as we add more stuff to blockList, it'll automatically be added to charHandlers_. One thing might be good is to change auto for auto&, as then there won't be the overhead of copying an instance of BlockData each time you go round the loop.

[Fyll]

If you go into Object::update() in Object.cpp and comment out the pos_ += vel_; line, does that stop the problem (it should stop everything from moving, but it'll tell me if the problem is caused by the update or by the initialisation)?

EDIT: Also, what happens if you build the menu level out of floating blocks instead of stone? That'll say whether or not the problem is in the Blocks.

[mspraggs]

I'll give that a go in a moment and see what happens.

I'm still totally bewildered as to why we are getting different results, despite having the same code. If the code is indeed identical, then the behaviour should be the same too.

[mspraggs]

Ok, that made the the blocks appear correctly on the screen. I've stepped through the addition of each block in a debugger, and the blocks are added correctly to the Room instance. It must either be the update code or the way the blocks are drawn to the screen that causing the problem.

Ok what the hell... I uncommented the line you mentioned in order to debug, and now it's working again. And when I run git diff it shows there are no changes. This is very weird...

[DivFord]

Huh. I did have one occasion where the level loaded and a couple of squares shot across the screen. It was too fast to make out properly, but they may have been stone blocks. Are we accidentally giving blocks velocity?

[Fyll]

The velocity is 0 initially, and the acceleration is also 0-ed in the constructor (although that's a recent thing), so that's not the problem. Thinking about it now, the second to last push didn't initialise the acceleration, but this last one does, so that might have been it.

[DivFord]

Just pulled. Works for me now. I guess that was the problem?

[mspraggs]

Ah that would probably be why. Unitialised floats would play havoc with the physics I expect.

EDIT: Though it still doesn't explain why it worked for Iain. Maybe clang sets unitialised variables to 0 by default?

[DivFord]

I almost miss the challenge of the broken levels...