• entries
    383
  • comments
    1075
  • views
    352710

Question Time II

Sign in to follow this  

161 views

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!
Sign in to follow this  


6 Comments


Recommended Comments

~Fonts: I prefer bitmaps fonts myself just because I like the control. What I ended up doing was using LMNOpc (it's not free for commercial use.) Tape_Worm has been working on one that has some nice features, it's just a matter of if and when he's going to release so the rest of us can get our grubby hands on it.

~VFS: I haven't actually done a virtual file system yet, but from what I've seen they're useful for portability and compression reasons. The only thing in my engine that could count as a VFS would be my GetAbsolutePath() function which takes in a filename and returns an absolute path.

Good luck!

Share this comment


Link to comment
Check out PhysFS for a virutal file system library. I haven't used it yet but it's something I'll be looking at soon.

Share this comment


Link to comment
I heard the Amanith framework has good support for SVG graphics and OpenGL; and from what I can see in some games it all looks rather nice. A plus is that you can create new SVG graphics from code, to make some funky interactive effects :)

http://www.amanith.org/blog/index.php

Share this comment


Link to comment
Quote:
Original post by Jotaf
I heard the Amanith framework has good support for SVG graphics and OpenGL; and from what I can see in some games it all looks rather nice. A plus is that you can create new SVG graphics from code, to make some funky interactive effects :)

http://www.amanith.org/blog/index.php


Anamith is one of the popular libaries I've seen around the 'net, however the huge downside with using it is that it appears to be using the QPL, which acts a bit like the GPL except it isn't compatible (meaning I couldn't use GPL code with Anamith). I'm not sure whether I want to be forced to release the source code of my game under some licence anyway, so I'm steering clear of any licences that force that issue.

At the moment I'm strongly considering Anti-Grain or Cairo, but I'm debating whether it's worth the effort to use them properly for this particular game.

Share this comment


Link to comment
Hey, I know this is a really late post, but just wanted to comment WRT the "one sprite per texture" thing. I suspect the biggest reason that people have for doing sprite sheets is that its actually pretty costly (in terms of rendering performance) to change textures. If, for example, you had a different frame of animation in every texture object, that would likely mean that almost every sprite onscreen would require you to change textures. This may not be an issue with a low number of sprites being onscreen at once, but it would certainly be one once you start ramping up the detail.

Cheers,
Lachlan.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now