Explosions Glitchy

[DivFord]

Having a problem with explosive barrels. The explosions don't destroy things, but sometimes cause a segfault. I can't seem to reproduce it now, but the crash log suggested it was something wrong with time::clamp.

Just wondering if anyone else gets this error. I've been changing the level loading code in World, but I don't think that should affect it. Could it have happened during one of your changes, Iain?

EDIT: Segfault happened again. In a different place this time:

Application Specific Information: objc[2394]: garbage collection is OFF *\ error for object 0xbf800000: pointer being freed was not allocated

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff91935ce2 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff89ef87d2 pthread_kill + 95 2 libsystem_c.dylib 0x00007fff89ee9a7a abort + 143 3 libsystem_c.dylib 0x00007fff89f4884c free + 389 4 com.apple.driver.AppleIntelHD3000GraphicsGLDriver 0x000000010bcd3807 GHAL3D::CSurfaceState::~CSurfaceState() + 149 5 com.apple.driver.AppleIntelHD3000GraphicsGLDriver 0x000000010bcd3730 GHAL3D::CVertexBufferState::~CVertexBufferState() + 30 6 com.apple.driver.AppleIntelHD3000GraphicsGLDriver 0x000000010bf27527 _ZL23CreateGHALVertexSurfaceP13GLDContextRecP12VertexBufferj + 157 7 com.apple.driver.AppleIntelHD3000GraphicsGLDriver 0x000000010bc4fb04 g575GetVertexBuffer + 258 8 com.apple.driver.AppleIntelHD3000GraphicsGLDriver 0x000000010bca078a g575PrefetchPrimitiveBuffer + 51 9 com.apple.driver.AppleIntelHD3000GraphicsGLDriver 0x000000010bca0670 glrBeginPrimitiveBufferUseDataBuffer + 151 10 GLEngine 0x000000010b9d59a2 gleBeginPrimitiveTCLFunc + 78 11 game 0x00000001076ec25a Window::draw(unsigned int, Vector, Vector, Vector, Vector, Vector, Vector, Vector, Vector, Colour) + 90 (Window.cpp:81) 12 game 0x000000010762c144 Window::draw(unsigned int, Vector, Vector, Vector, Vector, Colour) + 436 (Window.hpp:88) 13 game 0x000000010761a9a5 Screen::draw() + 213 (Window.hpp:85) 14 game 0x000000010760bdc1 Game::draw() + 49 (Game.cpp:178) 15 game 0x000000010760ba5f Game::run() + 1711 (Game.cpp:66) 16 game 0x0000000107645a8e main + 2926 (main.cpp:74) 17 game 0x00000001075b1234 start + 52

[DivFord]

Beam weapons are also glitchy. Related?

[DivFord]

I've found a few more glitches, so I'll list them here to keep things contained. Essentially, I don't want to push my code until I know whether these were a pre-existing condition.

1) Blocks surrounded by others of the same type randomly form single block groups. It seems to be consistent within a level, so you may not be able to reproduce this without the levels I'm using.

2) Entrance blocks are more viscous than air. Related: Spaces where dirt blocks used to be are more viscous than air. Actually, jumping in the centre of these regions works fine, so it may be a problem with friction rather than viscosity.

3) Explosions don't destroy crates (see above).

4) Beams don't extend properly (see above).

[Fyll]

O.o I'm away for one day and the game apparently explodes (well, except the bits that are supposed to).

Explosions not destroying crates is something I've noticed every now and then, but then promptly forgotten about when it comes to trying to fix things. It's added to my todo list now though, so that should get it done eventually.

Everything else sounds like it might just be a consequence of a level not being something I'd accounted for. As an important point, the BlockGroup building has no way to handle holes inside BlockGroups, so just pretends that the holes are filled in. This would mean that if you've got a ring of stone blocks surrounding the level, the game will think that there's a stone block on each tile (I think).

You technically being inside some stone would explain why Beams don't extend, why things are more viscous or there's inexplicable friction, and possibly why BlockGroup forming is messing up.

I can't seem to reproduce these problems, so can't say much at the moment. Are you sure you're up to date? A few of the older pushes had some BlockGroup bugs lying around.

As for your segfault, a Googling around suggests that that might be caused by GL_QUADS being deprecated (odd that it'd only happen sometimes, but worth a shot). I've pushed a version with this changed.

[DivFord]

I suspect, as you say, the problems were already there, we just weren't seeing them in the test level. Linking up the level editor has meant loading a bunch of different levels, so that's why I found them all today.

I think I'm up to date, but I'll merge once I've implemented Hole patterns, see if that fixes anything.

None of my levels are completely surrounded, so I don't think it's that in this case, but it certainly would be worth fixing at some point.

Just realized I didn't upload my screenshot.

The block group I'm standing in was all dirt when I started. As you can see, after digging down this far, the bottom block no longer collides.

[Fyll]

Actually, that might be being caused by the replaceObject() function in Room. I've tried avoiding it (and pushed), so see if that's any better.

Although yeah, that is very wierd that it's still drawing the Dirt....

EDIT: Explosions explode things again. The circle collision code had a bug in it that I hadn't noticed due to only checking it with Bullets (which are tiny).

[DivFord]

After a long and glorious struggle with vim, I have merged the changes and pushed my level loading stuff. You seem to have fixed beams, and I haven't segfaulted in a while, but the rest is still screwy.

EDIT: Explosions seem to be destroying crates again. Good job.

[Fyll]

Hmm. I can very much see the problem now. I'll have a play around and see if I can spot anything.

[Fyll]

I've fixed the problem in your picture (I think. It stopped happening for me, but it was never all that consistent). It turns out that there was a bit of the BlockGroup building code that was forgetting chunks of the hitbox under very specific circumstances, with that being one of them.

The dodgy BlockGroup building will probably take a while to fix, but the dodgy dropping/rising prop collisions shouldn't be too hard (although that'll be for tomorrow or the weekend).

EDIT: Oh, and I should mention that a line of code has been added (I was using it for debugging, and left it in because it was pretty useful) such that when you right click, the console will tell you what BlockGroups the mouse is hovering over.

[DivFord]

The problem is gone for me too, and it was happening every time before, so I believe you have fixed it.

This one is still around though:

[DivFord]

I've been having a look at blocks, and have discovered why some areas feel sticky (I think). Because of the problems with block groups (see previous post), we sometimes get a small air region inside a larger one. Since the block groups are never concave, that means you get the drag from both while in the smaller one. This tends to happen in patterns at the moment, because of the way they load after normal blocks, should you wish to try it for yourselves.

The block group investigation function you added was really helpful for discovering this. Good job!

[Fyll]

I should've fixed the problem causing the BlockGroups to chunk like that. I can very much see why it was messing up for patterns (it wasn't accounting for bits being put inside of hitboxes), but that random chunk in the picture does rather confuse me (although it's gone now, so that's good, I guess?).

[DivFord]

The editor wasn't necessarily exporting the block coordinates in left-to-right top-to-bottom order, so that may be where the bit in the picture came from. In any case, it's definitely fixed. The platforming sections feel so much nicer now!