Home       About Me       Contact       Downloads       Part 59    Part 61   

Part 60: Our Story So Far

August 16, 2012

There were some miscellaneous items of work that got done this week.


Someone commented last part that the code did not run on Fedora Linux because it couldn't find the fonts. I have suspected there was a bug in the font search path. I'm using the XLib call XGetFontPath, which you would think would return the font directories. And under Ubuntu, after I install the MS Core Fonts, I can find them in this path, but in a very weirdly named directory.

I installed Fedora on one of my machines, but couldn't get the MS fonts installed. The font path there just didn't seem right either. After Googling, I found one reference to /etc/fonts/fonts.conf which is an XML file that lists the real font directories. Even there, it seems I have to traverse the tree and find all the directories that contain TrueType fonts.

I discovered a bug in my code (it doesn't actually use the default font when it can't find the requested font), and added the code to parse fonts.conf. I've also added a default to the "Liberation" fonts, since these seem to be present on both Ubuntu and Fedora by default. Unfortunately, they don't seem to be rendering correctly. I'm not sure where the bug is, but the text is definitely a bit mangled.

If you've tried the demos on some other distro of Linux and gotten "font not found", try Part 60 from the downloads page. Let me know if it works, since I never did get good display drivers installed under Fedora.

Debug Console

One reader requested the old scrolling messages that Crafty used to have, so he could write debug output there. The new way to do that is with the GUI code, as in the GuiTestAll program. I've added a debug console, which opens on F2 in all the demos. Any of you messing with the code can look at the TestCube demo source for examples of using it.

The only fun thing to do with the console is in SeaOfMemes. Open the console, type "list" to list the variables. The only ones implemented so far control the rotation and orbital speed of the planet, moon and ring. So if you type lines like:

you can speed up the rotations. The numbers are the time in seconds for a full rotation or orbit. Case is not significant on variable names.


I've continued to fool with the statistics page, trying to make it more useful. I was reporting the OpenGL "device renderer" string, which is the display card name. Unfortunately, we've hardly had two machines with the same display card so far. I tried grouping them by serial number (all GeForce 8xxx machines counted together), but that doesn't really tell me anything.

I then realized what I wanted was performance numbers, and found a 3DMark database on the net. I parsed that (310 different displays) and now look up the display string and show a histogram of 3DMark scores.

Unfortunately, the OpenGL renderer does not name the devices the same as the names in the database. I fooled with sloppy lookups for a bit until I realized that Windows can return a device name as well, and this is probably what was used to create the database. I've changed the demos to report the Windows display name, and I'm now looking that up.

Under Linux, I can also get a display name from "lspci", but I have no idea if its the same as the Windows name for the same card. Under Mac, I guess I have to use "ioreg", but the output is such a mess that I'm not sure what to look for. If anyone knows how to query the display card on a Mac, let me know.

It will take awhile for new logs to come in and fill out the 3DMark histogram. I'll be interested to see how that goes. Since the log server seems stable, I'm going to put the Log Statistics link on the front page.

Twenty-One Months!

Back at the beginning of this project, after I had a really basic block world working, I listed some possible directions in Part 5:

  1. Imitate Minecraft
  2. A Peer to Peer World
  3. A More Interesting World
  4. An Avatar Editor
  5. A Programming Environment

In the end, I chose #3, and worked on graphics and world design. I reasoned that no one would play a game with slow, ugly graphics. But as I mentioned in the pros and cons of each choice, the argument against doing this was

I don't know much about 3D graphics, and these rendering issues are endless. I could spend a long time working on a nice looking world, and not get anywhere on the overall project.

Although I've done some nice work on the demos and the Minecraft viewer, I'd have to say this is the way the project has gone, and I'm not very happy about it.


I started out using DirectX and switched to OpenGL in Part 12. Although I still have no real preference for either library (I haven't done anything particularly ambitious with the 3D graphics), this decision did have consequences.

Since part of the appeal of OpenGL was supporting multiple platforms, I decided I had to really do that. That meant writing (and debugging!) Linux and MacOS versions of the code. It also meant supporting both OpenGL version 3.3 and the older version 2.1. I supported that for the Mac (which didn't implement 3.3 until Lion) and because tablets use OpenGL ES, which is very similar to version 2.1.

All of that extra debugging and fussing over multiple operating systems and OpenGL versions has cost me months. And despite all that work, I'm still getting comments like "How come my 1-year old laptop won't run your demos? It runs other games just fine!"

There are a lot of graphics cards out there, so perhaps DirectX would have been just as much of a nuisance. I suspect it would have been easier though. The problem is that every vendor is debugging their cards against games running DirectX and Windows. OpenGL is a second-class citizen. The OpenGL support actually isn't bad, and apparently it's better than it was, but the whole situation is still a pain in the neck.

In retrospect, it would have been better to continue with Windows-only DirectX code. If I wanted more portability, I could have used Java like Minecraft did. Or even held my nose and used Javascript and WebGL.

It's possible that I'll finish a really popular game, and one of the selling points will be "it runs everywhere!" Then all this work will pay off. Or, I could continue extending my platform, adding in tablet support and DirectX support. In that case, I'd basically be writing my own replacement for SDL. But that is a project in itself, not a side project of a larger game.


Learning 3D Graphics

Despite the amount of programming I've done on this, I really haven't even scratched the surface of 3D graphics. My math skills are very rusty, and most of the serious graphics algorithms would require a lot of study before I could even attempt an implementation. When I look at game engine ads, it's tempting to just throw up my hands and say "Oh, forget it!"

On the other hand, I'm pretty happy with the way McrView looks, and would be satisfied if the game looked like that. The bits of graphics I've done in SeaOfMemes and DontHitMe aren't terrible either. If you had shown me screenshots of those programs before I started, I would have said I wasn't up to that level of graphics.

Despite my frustration with graphics programming and framework, there are still things I know I need:

  • As mentioned in Part 54, I want to implement a modifiable polygon landscape, instead of cubes. That's been a requirement for me from the beginning. Without that, the whole thing just looks like Minecraft.

  • I need to do something about lighting and shadows. I've read about various algorithms, but so far, nothing jumps out at me as the one to implement.

  • I want a different algorithm for trees, and need to do the work to add leaves, light them correctly, and do forests. Without trees, the landscapes will look pretty barren.

I also have lower priority work that needs to get done at some point:

  • For the rings around the SeaOfMemes planet, I want some kind of dust that has cones of shadow behind the asteroids (they need to shadow each other as well, in the cases where they are close enough.) The whole ring needs to be shadowed correctly by the planet, and look good from space and from the ground.

  • I'd like to do rain, snow, wisps of fog, heat distortion and other atmospheric effects. I have no idea how this is done. I suppose water with ripples and reflections would be nice too.

  • Accurate skies would improve the look. I have research papers that explain that and code samples. It's just a matter of plowing through it.

  • I need to add more control types to the GUI, and make it look halfway decent.

Unfortunately, none of this has gotten done. As you all know, I haven't shown much evidence of a plan the last few months. This has mostly been due to health problems. When I'm short of sleep, the best I can do is nibble around the edges and knock the more trivial items off my huge "To Do" list.

What About "Don't Hit Me"?

I started on "Don't Hit Me" in January to put some fun back in the project. Then I dropped it, dismissing it as a distraction. I felt like I was just procrastinating on the main project.

In Part 56, I picked it up again. I rationalized that it was worth writing a complete small game, with every detail of game play, menus, sound, multiple platforms, etc. completed. Finishing something playable would be satisfying. I'd also have a feel for how much time it takes to produce a finished game.

The current version is in the demos, for anyone who wants to play with it. It has some odd rendering bug that only shows up on some of my machines (grrr!) If you get the cross cursor (hit ESC), then hit "F" (flying), you can detach the saucer from the track and go exploring. Use the mouse to steer, W/S for forward and back, and A/D to rotate the saucer. Or, use the cursor keys, which do the same thing on the right hand.

I could just finish off what I have with the asteroid and ship. It needs collision detection, menus, sound, a scoreboard and a more interesting path. The result would be playable enough, but I thought I could do better.

I was looking at the Part 26 tree branching algorithm again, wondering if I could come up with a better version. As mentioned above, I really want trees in Crafty and SeaOfMemes. If I had a better algorithm, I could use it to do vines and wrap the ship and asteroid with them. That was my next item of work to do.

Unfortunately, I'm having doubts again about all of this. I also have a couple of requests to "please, please, please do more work on Crafty!"

What Next?

I do feel guilty for letting Crafty sit in a semi-useless state all this time. I've been reluctant to work on it, because I know that if people start using it as a game engine, I'll have to add more and more features to it. I might never get around to the main project.

On the other hand, I'm not making much progress on SeaOfMemes. I have to figure out the landscape algorithm at least before I can do more on building the planet or asteroid surfaces. I haven't felt up to that level of algorithm implementation in months.

The good thing about working with Crafty again is that I know everything I need to know to finish it off. It's just a matter of doing the systems programming and checking things off my list. None of that work would be wasted either -- I want all the block-world features in SeaOfMemes too, just with a polygonal landscape. It's just a matter of doing it now or doing it later.

So I'm tempted to go in that direction for awhile. The project is coming up on the two-year mark. If I keep going the way I have been, I'll have nothing but a pile of disconnected demos.

I haven't decided what to do. Let me know what you think in the comments.

Home       About Me       Contact       Downloads       Part 59    Part 61   

blog comments powered by Disqus