Not really on topic for this post, but I haven't checked out your journal in ages...

Are you using texture atlases for you app? I just noticed that my engine is very similar to yours - almost everything is a sprite (quad), and that gets shoved into a dynamic VB once per frame and rendered. Texture atlases (texture sheets as they're know in my engine) let me render (usually) all sprites in a single DrawPrimitive call.

Also, using the GDI fonts aren't that difficult to do either, my engine draws glyphs to a DIB section, then copies that to a texture, and uses vertex alpha to render coloured quads as a text string.
It saves having the fonts pre-generated, and lets you use unicode easily (If that's any use). But it means textured fonts are a bit limited...

Pictures and Pictures + some code

Hey Steve. Nice to see you in my journal [smile].

I'm not suprised my engine is similar to yours since yours was a source of great inspiration. Thanks again for that.

Basically how sprites working is that I have a small console application that reads in lists of bitmaps and spits out my custom sprite files. These are very simple files that just start (binary) with the number of sprites, then for each sprite have the height, then width, then the pixel data in rgba format. The console program can either generate all 255 alpha, 0 alpha for any pixel of a specific colour or a complete alphamap from a red-black bitmap. You write a little script for it that specifies the images and run the console program on the script.

I have a CTextureMap class that you create as a local variable when loading sprites into one big texture. You specify the width and height of the texture plus the minimum cell size that the texture map uses to search. This is just a big array of bools that are initially set to false. As each sprite is loaded, the texture map searches right and down until it finds an area on the texture big enough to fit the sprite, then it marks that block as used in the array and returns the co-ordinates. I then just copy the pixel data into the texture at that position using D3DCOLOR_ARGB() to convert it.

Not the most efficient system in the world but I haven't noticed any particularly long load times so I'm happy to continue with that until I do. I know you can get quite clever and create and update a binary tree of rectangles to speed up finding free space, but I haven't bothered with that yet.

Fonts are actually externally generated by a little C++ Builder app I wrote, detailed a bit lower in the journal. It generates a file like the sprite file, but prefixed by an array of 256 ints, each of which contains the index into the sprite array of the letter whose ASCII corresponds to the image in the array. There is then a CTextureFont class that looks after loading these files, providing like TextWidth methods and also adding letters into a quad buffer.

So the fonts and sprites can all co-exist quite happily on the same texture, reducing the number of DrawIndexedPrimitive() calls.

Obviously it is not as flexible as your font system in some ways since it will only support ASCII and it requires me to decide which characters I include in the font file. However it does mean that a given font does not need to be installed on an end-users system - I like this since I've found some excellent freeware fonts an AEnigma Fonts that I can use and don't really want to need to ship them with my game. My font generator only requires that the font is installed on my computer and as long as the font is freeware, I can do what I want with my generated font files.

Anyway, thanks for the interest. I'm keeping a close eye on DruinkScript as this is another area of programming that very much interests me. I'm glad to see that you are progressing well with the code generation at the moment.