Shared publicly  - 
 
I'll probably be posting a lot of updates over the next couple of weeks, but until the flood of stuff comes in, here's a quick look at screencaps I posted throughout the duration of Waveform's port, with some explanations as to what was going on...

http://www.flibitijibibo.com/images/NotMetroid.png

So this was the first thing I saw when I finally had the game start without segfaults, blank screens, etc. What the image doesn't show is the game moving as fast as it possibly can without a frame limit... this was because I had commented out the frame limiter due to some 'QueryPerformanceCounter vs. gettimeofday()' bugs that I hadn't figured out yet.

The two bugs you can see, however, are the font color and broken background. Both were caused by the transition from FreeImage to SDL_image... I would have stuck with FreeImage, but the OSX support was just lousy. Plus, as it turned out, SDL_image did a LOT of things that Waveform was doing manually with FreeImage. The font color was Waveform compensating for FreeImage not creating BGRA textures automatically. Removed that block of code and it worked like magic. The background was the result of me being silly and assuming that all textures were going to be RGBA, when the backgrounds are just RGB. So uh, that background is what happens when you try to make pixels 4 bytes at a time rather than 3.

http://www.flibitijibibo.com/images/NotDoom3.png

This one turned out not to be my fault! Waveform uses a multithreaded renderer, and the rendering is actually done in a thread separate from the main thread, which creates the window (though I think we're changing this to fix other bugs for the SDL port). This is normally fine, but as it turns out, nVidia's Linux drivers made GLX rendering contexts thread-local, and when you try to use framebuffers in another thread, the driver fails and returns GL_OUT_OF_MEMORY. This caused none of the drawing to occur where it needed to happen, resulting in a blank output. Created a new context in the rendering thread and it worked like a charm.

http://www.flibitijibibo.com/images/Not8Core.png

This one isn't really a visual bug; the explanation is actually in the file name. That screenshot was taken from my lappy, because my tower was actually too fast to run the game without segfaulting. Yes, really.

I spent quite a lot of time looking at threads trying to figure out what it was, but as it turns out it was just my SDL_image port making more poor assumptions about color channels. I still don't know why that would work on machines with less threads/speed, but it fixed the problem. Computers are weird.

http://www.flibitijibibo.com/images/NotGamebryo.png

This is the first screenshot of the game actually working, hence the file name. All of the bugs after this point were related to getting OSX up to par, which was far less interesting visually. There was one bug in the Mac version that involved the red and blue channels switching, causing most of the game to look yellow... had I not fixed it so quickly I probably would have posted a NotDeusEx.png. Oh well.

To end, here are some screenshots of Waveform Mac/Linux 1.0:

http://www.flibitijibibo.com/images/WaveformLinux.png
http://www.flibitijibibo.com/images/WaveformOSX.png

I think whenever I work on a game that's not covered in NDAs I'll do something like this. I've actually been doing it for Blueberry Garden, too... What do you think?
6
Josh Bush's profile photoVadim Peretokin's profile photo
 
Always keen to see updates :D
Add a comment...