Google C++ Style Guide

LKmalloc, the basis allocator for the allocator used at MS Internally at MS the LKmalloc library is referred to as ROCKALL, not part of the std C library distributed with visual studio. I haven’t used vc8 so that may have changed.

PTMalloc3 A DLmalloc based allocator that aims at reducing lock contention. Used in glibc.

JEMalloc A concurrent allocator used in FreeBSD.

Okay.. now honestly I’m done posting anything about heap allocators!

Object allocations now appear so:

Heap local; obj *p = new (local) obj();

And when deleting the memory you must ensure that you give it back to the heap:

operator delete(p, local);

That last part makes the system less friendly. You can however override the operator new and delete for ‘obj’ and give it knoledge of a local heap.

More references:

• Memory management in C++
• C++ in action book (overloading operator new)
• Using C++ Objects in a Handle-Based

Allocators (STL) @ Codeguru. A good article about writing a pool allocator replacement.

This article provides a good introduction to the subject with a sample replacement allocator. Things get a little more interesting when you have some state that is maintained per allocator. The implementation of the libstdc++ multithreaded allocator

This is a very interesting policy based allocator that is the default STL allocator on GNU/linux distributions. I assume it is very fast. I’m not actually trying to write a faster allocator.

Rogue Wave’s open source stdc++ implementation

I just came across this and it looks interesting. It’s supposed to be pretty fast and stable.

STLport cross platform STL implementation

At work we use STLport. If you have to use STL most people will refer you to STLport. Most STL implemenations are pretty solid but some such as the old vc6 dinkumware library are pretty bad.

Doug Lea’s malloc replacement

dlmalloc is a great replacement for the system malloc. In many cases it is the system implementation of malloc. The feature that I am using is the ‘mspaces’ private heap implementation which in combination with a custom STL allocator allows systems written using STL to use indepedent heaps. Using a private heap you can collect better statistics at runtime and also thread isolate heap access to reduce lock contention.

The C++ Programming Language Of course the best source of all details for the C++ language. This is the only place that I found that the rebind semantics were clearly explained. When state is maintained on the allocator it’s important to use some kind of reference maintainence for the allocator. The allocators may be copied, rebound to a different type and assigned to.

Someone may create a container with an allocator on their heap and you may store a reference to the container. If the caller’s allocator goes out of scope the heap needs to stay valid because you now have a container with a lot of objects allocated on it.

In my system there is a Heap class which acts as a wrapper around the mspace (private heap). The current design has the heaps reference linked together.

RubyCube is a ruby extension that gives a high level ruby API on top of GLUT and ODE currently. It abstracts away some stuff that doesn’t really belong in a graphics scripting environment but you tend to see people include anyways (like the render/update loop). I used it back in March of ’06 to write a game with my friend John in a matter of hours.

When I started I decided that I didn’t want the render loop to be bound to the performance of the ruby VM since it’s performance is pretty crap. Craps! score doesn’t really account for object lifetime management overhead which Ruby may have some issues with as well. Regardless of that I really like the language and I think it could make a good prototyping environment for game programming.

Most people when they create a language wrapper for something like OpenGL or DirectX write a direct 1-to-1 mapping (luasdl, rubysdl, rubygl, etc). This is probably due to simplicity of implementation and maybe lack of imagination . It may have something to do with not really understanding the problem domain very well, which is a huge barrier to successful software design in general.

So the way that I approached the problem is to create a seperate thread in the extension and use queues to communicate between the script interface and the extension. The render and object update loop is handled in C. This has a lot of benefits but is more complex to code. Overall, I have been very pleased with this design. Currently the interface is very simple, it’s intended as a prototyping environment. It’s not the kind of thing you would build a whole game on at this point. I’m going to try the approach of release early, release often and see how that goes. I was planning on including texture support in the first release but I think I’m just going to finish the docs and tests and release it as is.

It currently only supports vector based graphics, no lighting and only a few simple types of animations. Oh and it doesn’t yet compile on my Mac.

One nice benefit of using a background thread is that you watch the render window while you’re in irb.

irb -r rubycube

irb> RubyCube.startup(“My test application”, 800, 600) # create the window and thread irb> myshape = Shape.circle(100, 200, 50) # create a circle at 100,200 with radius 50 irb> myshape.move_to(300, 300, 2) # move to <300,300> in 2 seconds irb> myshape.color(1, 0, 0)

You can also create custom shapes that are lists of verts, normals, colors. You can create thousands of shapes and have them animate very easily without burdening the ruby interpreter.

For the first release I’m shooting for the following:

• All core methods documented
• Test cases for all animation types
• Test cases for ODE physics on shapes simulation
• Finish stress test
• Perspective transform mode working

• Mac OSX support
• Texture/Material support
• Sound support
• Shader support
• Implement changes from user feedback (if any)

Download Here

On the UI side I cleaned up the main menu so continue career only shows up when you have a save game. From the in game options menu when you cash out or save and quit it does a nice transition back to the game and then either fades out to career or play now or shows the currently slightly broken quit confirmation.

I would love to get one more art pass over all the menus and background stuff. I may just experiment with altering the existing menu background to make it more color blend friendly and change to a larger font. I want the UI to feel very tangible and inviting.

At least on a green background it looks semi-decent. It looked better in 32bit color. I think that dithering to 12bit makes the colors harder to pick out. I ‘skinnied’ (if that’s even a word) up the action menu which sacrificed the ‘best hand’ display and the bet ammount. That should make it more consistent with the other phone UI elements. The left action button is bound to the menu.

Career mode got some love. I fixed a bunch of character select bugs. But I think I’ll the last glyph in the font should be swapped with a RUB button. Probably just a back arrow would be fine. The hiphen glyph is serving this purpose now.

I also fixed the career continue mode a bit. All menu animations have been cleaned up and are sliding in and out nice and smooth.

Massimo says:

so what are you up to now? working on getting the animation running? Cuz I know what you’re not doing you’re not posting pictures of Hold’em running on your phone

The line that was crashing first was:

if(path.compare(rec->name, rec->namelen))

This looks totally innocent.. I’ll just say right away that it wasn’t any of the usual suspects. Keep in mind that this ran fine on other hardware architectures. The problem was actually memory alignment.

The records that are being referenced here are part of a block of index records stored in the resource file. I have a tool that transforms and packs files into a single file and creates one block of memory to be used as a searchable index. The structure in memory used to look like this:

struct RecordRef { uint32 offset; uint16 nextrec; uint16 namelen; // char name[namelen + 1] };

If I tried to access offset or nextrec and the field didn’t lay on a 4 or 2 byte boundary respectively my application would crash. This kind of problems are pretty hard to track down without a debugger. I used loglines traced to a text file on the phones internal memory through multiple builds to track this down.

The new structure looks like this:

struct RecordRef { uint32 offset; uint16 nextrec; uint16 namelen; uint16 padding; uint16 reserved; // char name[namelen + 1] };

I calculate the padding when the records are built in memory and before they are stored into the resource file. When they load from the file they are all nicely aligned and the code that searches the index just has to take into account padding when doing any pointer/index math.

Seeing the title screen on my phone makes me very happy!