Leaderboard

Unmapping is unnecessary with persistent buffers. That's their whole spiel - they are persistently mapped As for flushing - if you created and mapped the buffer with the GL_MAP_COHERENT_BIT, then you don't need to flush explicitly, as it's taken care of automatically. If you don't, you have to flush so that OpenGL knows parts of the buffer were touched and need to be synchronized before the next GL read from that area. See here: https://www.khronos.org/opengl/wiki/Buffer_Object#Persistent_mapping

Thanks for your detailed comments - I'm glad you liked it. For the two items mentioned, the readables could be more explicit. Specifically, and As for that turns out to be

Fanatastic mission, joebarnin, I enjoyed it alot! There were few thing at the end that baffled me: And I must say your mission is well optimized - throughout the whole time I had stable frame rate of 120FPS, maybe even more, but that´s the maximum my monitor can draw.

Problem: crash on x64 after map load inside nVidia driver. x86 just works. Puzzle: qglFlushMappedBufferRange does not seem to be doing anything. x86 works great without it. x64 still crashes after map load. No crash on Intel. Edit: NM, driver bug. Went away after driver update. As for flushing, should we not unmap the buffer every frame?

Did this in svn. The persistent mapping path only for now. Will add fallback for incompatible drivers later. The extension seems to be supported for all GL4 drivers, even though it was only cored in 4.4.

Well, I just think that this was the intent. It maybe did not work out as intended, but it is too late to change that...

But the way it is, creating skins is easier for people with little to no experience in creating textures. You can simply create a skin by exchanging one material with another. No need to create a texture from scratch. That (I belive) is the versatility Springheel meant: The easy possibility to create new skins.

A little necromancy here, but I tested the things in the package and couldn't get any of them to work. Although there were no errors, none of the animations would play (when the AI was supposed to run it just walked, no pain was played when damaged, etc) and the ik didn't appear to do anything (AI bounced up steps as before). I don't know what to make of that, but I've uploaded them to SVN in case anyone else wants to have a look. When opening up the animations that work vs the ones that don't, I see the two have different numerical values for each bone. I suspect that's a problem, but don't know exactly what those values mean. Working animation: "origin" -1 0 0 // "Bone001" 0 5 0 // "Bone002" 1 32 2 // "Bone003" 2 56 3 // "Bone004" 3 56 6 // "HeadBone" 4 56 9 // Non-working animation: "origin" -1 63 0 // "Bone001" 0 63 6 // "Bone002" 1 63 12 // "Bone003" 2 63 18 // "Bone004" 3 63 24 // "HeadBone" 4 63 30 //

One last sneak peak from Shadows of Northdale Act 3. Lord Edgar's estate!

This week Epic Games is giving away 6 free games. Batman Arkham Collection https://www.epicgames.com/store/en-US/bundles/batman-arkham-collection LEGO Batman Trilogy https://www.epicgames.com/store/en-US/bundles/lego-batman-trilogy I don't think these need any explanation. If you haven't played the Arkham games yet, then I highly recommend them as they do an awesome job of giving you a badass Batman feeling.