Having another look through the base code for the engine behind "Pierre and the Fish", I think there's a lot there I can reuse in my present project. The core engine itself is a modified version of Richard "superpig" Fine's Enginuity engine which I wrote while teaching myself the basics last year. While I'm planning on putting in a few more modifications, it's still basically going to be a big ol' game loop pumping tasks around, so I might as well use something I know works as the basis.

However I've got a couple more questions I'm sure a few of you can help me with. Most of these revolve around dealing with image resources, which is coming up soon on my checklist. For this game, I'd like to try using SVG as a base data type for images as they scale quite nicely for different resolutions and compress down to beautifully small sizes, but this requires a lot of new features that I haven't quite got the grasp on yet. I'm hoping if I describe what I'm presently planning on doing then hopefully you can pick apart the more stupid descision I've made and suggest better alternatives.

For reference, I'm using OpenGL with SDL for this project. I'd also like to use cross-platform libraries if possible.

SVG rendering to texture

My present plan is buld a texture manager to encapsulate the process of loading an SVG file, use a third party library to render it to an SDL/OpenGL texture and then rendering the texture as a 2D quad as per usual. The choice of third party library is uncertain though; I've downloaded a few a couple of weeks ago but I haven't yet had the chance to see which works best (in fact, somewhat embarrasingly I've forgotten what they are called now; I'll have to hunt around in my HD to find them).

While I'm happy blundering my way through figuring out a good process model myself, I was wondering though if any of you has had some success using SVG as a data format for game images, and could give me some recommendations on what to do?

Sprite sheets in SVG? Or keep the sprites single?

Another issue for the texture manager is to either accept sprite sheets - i.e. multiple sprites per texture, or to store each individual sprites per file. I know from my hacking around inside game's data formats that the sprite sheet method is very popular, but I don't know for sure if there's a risk in storing each individual sprite to a separate OpenGL texture.

Is there a potential problem looming ahead for me if I use a single OpenGL texture for every sprite? Will there be a problem with the driver's memory management?

Fonts, Fonts, Fonts

I don't know why, but there's something about fonts that's always bothered me. There's the problem of distribution; I've never found a font yet that I've liked that clearly stated I could legally distribute the font file with a game. For partly that reason I'm considering in the near future looking into designing my own typefaces (although it's more to ensure the font is in the same style as the rest of the artwork, plus most importantly because I think it would be cool).

More pertinently, there's the problem of rendering the fonts to screen and the associated problem of what file format to provide them in. Presently the only font system I've got working to my satisfaction was an old bitmap font library I wrote myself years ago, which used a big single texture for all the glyphs and because it wasn't monospace it took forever to write the data file that told the program where each individual glyph was in the file. However if I'm using SVG for the graphics I'd also like to use a vector based format for the fonts.

At the moment I am undecided between using SDL_TTF to render sentences to a single texture - which should be easier to implement but will require careful handling of the texture memory to ensure no leaks or performance hits, or to write my own font handler that renders each individual glyph as a separate sprite - which allows me to use custom font formats and effects but will require a lot of extra coding.

Eventually I'll probably gravitate to trying my hand at my own font system to provide my own funky effects, but is there any recommendations you can make based on your own experiences?

Virtual File Systems

I've only just thought of this today, so forgive me if I'm totally clueless on this issue. However given that I suspect that this project will require a lot of resource files (especially if I create an individual file per sprite!) then I really should think about providing a good way to keeping the resource directories tidy on the player's computer.

I know many games provide all art resources packed together in a single file. From what I know about them, I'm assuming they act like a virtual file directory that resources can be loaded off in a similar fashion as to if they were just sitting around in a plain ol' directory. However, I'm sure there must be some kind of middle process that converts the standard file access commands to read within the packed file.

I've done a quick search around on GameDev.Net to read more on such terms as "pack files" and "virtual file systems", and have read a bit about what some of you are doing, but I'm still in the dark about how to approach this. I've downloaded a copy of zlib to look at, but if any of you can suggest a good tutorial so I can read about the basics that would be great. It's possible I've just searched on the wrong terms and have missed something obvious. While I'm not sure when or whether I'll implement this feature in this particular project, I'd like to at least design and write the functions that access files in a way that would easily allow me to add the feature in the future.

Thanks for reading this far, and for any and all helpful replies!