12-30-08 - More Technical Junk

SIMD Aware Raycasting is a really retarded name for this idea of using a polygon hull to accelerate volume ray casting. It's a good idea though. Basically you put a simple convservative outer hull around your octtree or whatever volume data. Then do your GPU raycast, you render the outer hull front & back and you rasterize out the ray start and end positions, then you read those to cast. This means casting many fewer pixels that just hit nothing, and means you don't have to march across empty space so much. It also is a good way to do the object-space transform. A lot of the volume rendering / GPU raytracing research is targetted to having one big giant rigid world that you just fly around in, which is silly. You at least need objects that can be rigid body transformed. This polygon hull method provides a good way to do that - when you generate the ray start/end points you can transform them into object space so that they are ready to go for the ray cast (you can also scale them to be inside the axial box of the object in object space so that they are ready to go as 3d texture coordinates).

I enjoyed the little "game" Reset by Roburky ; I use "game" in quotes because it's really an "experience". I don't really play many games any more, but I would enjoy playing little music-sync'ed experiences that have some interesting vision to them. (I'm also enjoying listening to the music of Trash80 as I work today). Sort of like the old Orisinal stuff in that it's really just an "interactive artistic moment". There's some interesting techniques in the Linger in Shadows demo; I'd love to see more creative and unusual render styles in video games.

I finally played a little Braid over the holidays. I didn't play enough to really feel like I have any opinion of it, but two things struck me : 1. I'm really going blind and need new glasses, because on a non-HD TV I was having trouble seeing WTF was going on (though my brother could see it just fine), and 2. it's really got a coherent artistic vision, and everything in the game, from the music to the render shaders to the art style, and the story and gameplay, all work together very well. It's something you almost never see any more. So many games these days are just a random hodgepodge of art and play elements and controls and GUIs that aren't coherent, don't match the universe, and don't contribute to an overall feeling.

I almost always write threaded code in a master/slave paradigm. That is, there is some master thread which is in charge of owning object lifetimes and creating slave threads and so on. I've never written anything significant which really does massively parallel cooperative multithreading, and I hope I never have to! Anyway, with almost all the Oodle stuff my threading paradigm is to make the library interfaces non thread safe, and then if you want to do things across threads you need to protect them for thread safety yourself; for example Files assume that only one thread is talking to them at a time. This is almost always the way I write threaded code - I don't like library calls that automatically do mutexes and such for me on every single call, I want to do it myself. I just realized today that I could actually use the single thread CRT in my multi threaded app. The MT CRT is really really really slow. For example, the MT CRT version of fgetc is 170 clocks instead of 10 clocks in the single threaded version. I can just use the single threaded CRT and protect it from bad threading manually. (I probably won't actually do this, instead I'll just avoid using the CRT altogether, but if for some reason you wanted to write a really high performance threaded app and still use the CRT, then I would recommend not using the MT CRT).


MH said...

Did you try http://www.playauditorium.com/ ?

Autodidactic Asphyxiation said...

Doing mutual exclusion in library calls is usually a bad idea since it is usually neither necessary nor sufficient. The original Java container libraries made this mistake. However, it is still important to think about what your interaction with the threaded world might be. A good choice (and the one you are implying) is the one most current implementations of STL now use -- basically, that concurrent const access to containers are safe across threads but non-const access requires mutual exclusion. If you start trying to get too clever (e.g. COW) then things get a bit more complicated.

cbloom said...

Yeah, Auditorium can be quite pretty, and I like the integration of the music with the puzzle play. It doesn't quite work as a "synergy" for me, you know, it just feels like a puzzle game that plays nice music. I played through all the demo levels and don't feel any desire to play more.

It would be cooler if it was more like you actually compose the music by your actions. I think we talked about this at the last Indie Sound Jam ? Or maybe it was somewhere else. Like the various actions affect the music settings, you have to do some actions rhythmically, and if you solve the puzzle right you also automatically made a cool song.

old rants