Graphic Storage

02-21-2002, 03:47 AM
I am makeing an RPG that has a lot of graphics.
Does anyone have any suggestions of what the best way to store them is?
Should I put them all into a Resource File?
Should I leave them as jpg files?
Or is there a better way of storing them?

02-21-2002, 07:18 AM
A resource file would not be the best idea. They are not supposed to hold large amounts of data, certainly not all the images for a whole game. You could use zip or some other compression and then unpack at the start of the program. If you're also worried about security then you could just concatenate all the files into one big file with a suitable delimiter and extract them at the start of the program. If you are worried about theft, you might want to look at this article ( However, if theft is not your concern then leaving them as a collection of plain separate jpg files in a subfolder off the main program folder would be fine. This is easy to do if you make a proper installation using P&DW or Inno (


02-21-2002, 07:19 AM
I think it depends on what you want.

Resource files are great if you want to hide all your graphical work from the average pleb, but if you are planning on shifting your game by floppy then you may want to keep the size and quantity of the graphics down a bit.

I personally am doing a game with a large number of graphical tiles, which will be free standing files. This is partly because the user will possibly only wish to use some of them, or may wish to import thier own graphics.

A word of warning about Jpegs... in VB they tend to load up stupidly slow. I tried loading 13 48x48 jpegs and it took over 1.5 seconds. That may not sound like much, but it can really add up, particularly if you are having to load pics frequently (like every time the player moves) BitMaps, although bigger, allow much faster loads. I can do 143 48x48 bitmaps in a negligable amount of time. Guess which I am using?

02-21-2002, 01:18 PM
Thanks for the information.
I have changed my files to Bitmaps.
And I am going to stick all of the pictures into one file.

02-21-2002, 03:09 PM
Loading every time the player moves? Sounds very inefficient to me......

02-21-2002, 06:36 PM
Ha! Take a look at some of the things around here... it is inefficency city.

A good example is BillSoo's TileMap demo in the code samples. Have a good look... it re-plots the entire screen every 0.1 seconds or so. Don't get me wrong... it works, and it is a good example for people who want to learn, but you can't pretend that it's efficent.

If a player moves, revealing new terrain, it is easiest to load the new squares. (well actually it is easiest to load the whole thing) You could have all the tiles preloaded, but that is not always feasible. In my project I will ultimately have about 1000 possible terrain tiles, with the possibility of user additions. It would be bloody stupid to preload all that, just to speed up the display by a negligable amount.

The other prob with .JPG files is that they go fuzzy. That's fine when it's a large pic, but small tiles require a sharper image. This means .BMP or .GIF. GIFs load slow .BMPs do not. I think that the extra size of the .BMPs more than makes up for the increase in speed. Furthermore there is very little difference in size between a zipped BMP, and a zipped GIF or JPG, so internet transport is not really an issue.

02-21-2002, 07:13 PM
BillSoo's example map still preloads the images.
Every commercial game you've ever played updates the screen faster than every 0.1 seconds. And you'd call them inefficient? However, this wasnt the issue, Im talking about LOADING images, not DISPLAYING them...
Most games preload graphics at the start of the level, loading ONLY the graphics that will be needed for that level. Hence loading screens.
Although commercial games DO load graphics during play, it happens infrequently, images are preserved in memory and are only unloaded if they arent used for a specific length of time.
You are correct, commercial games would use BMP or similar, but my point was about the frequency of loading of the images, not their format.
You mention 'small tiles', in which that case 1000 images isnt an amazingly large amount, and I doubt you need even half of them on each level.
One (wrong) example hardly makes anything 'inefficiency city'

Okay, so commercial games arent written in VB, but in this context it makes no difference.

02-22-2002, 09:53 AM
:( Like I said I wasn't trying to be harsh.

As you point out 1000 odd small bmps doesn't add up to a stupidly large amount of space, and I would not need all of them on a given map.

I could have the game scan through the map upon loading, and preload all the necessary images, but that would noticebly impact load times, where as my current method happens plenty fast enough, and doesn't use up surplus memory.

I could most likely load all the images into memory without particularly impacting on the game's performance during play, but it is an inefficent use of resources.

Likewise BillSoo's example doesn't need to rerender the whole map every 0.1 seconds. Just because it can without particularly effecting the game doesn't mean that it is an efficent method.

I actually like BillSoo's example, though it uses very very little of what I will be using. It is always nice to see different approaches to the same problem.

In my defence; when I used the term 'Inefficency City' I think that only a small percentage of commercial programmers would use a serious degree of efficency. The very fact that this board was setup to facilitate learning negates the possibility of it being largely populated with highly efficent programmers. I don't think my own coding is all that efficent, but I try to make it more so.

In terms of efficency I feel that doing something that makes a noticable positive impact, in exchange for any number of unnoticable impacts, is totally worth it. Likewise eliminating work that doesn't need to be done, even if the user will never notice the difference.

02-22-2002, 12:48 PM
I thought BillSoo's Tilemap was pretty efficient, because the only thing that was loaded in was the matrix of tiles, and the tileset, and the number of tiles on the screen, that's the only thing in the computer's memory, that is efficient, right?

02-23-2002, 08:25 AM
Sure those are the only things loaded, but that is all there is to the demo. There is nothing else to load.

My point again, is that it was unecessary to re-bitblt the whole map screen based solely on time. It was basically unoticeable in the example given, but what if the viewing area was considerably larger, and populated with items, and creatures, and you had to do line of sight calculations to determine visability? I think that you'd begin to notice some problems.

It is only necessary to bitblt the squares where animation is taking place, and the sprite upon them, based on time. Everything else would be more efficently handled in reaction to movement.

I think too many of us do things by one method because we can get away with it, and then much later try something much more tricky and wonder why it no longer works well.

Again, I liked BillSoo's demo. It is an excellent example of what you can achieve with very little code. I just think that for a larger project the timer thing would be the first thing to go.

02-23-2002, 09:00 AM
I really dont see your point here. You're saying that you should only redraw when really really necessary because if you are constantly redrawing it makes it slower which affects the game?

Id rather play a game that ran a little slower constantly than one that suddenly ran ultra-fast when nothing was apparent on screen (SimTower comes to mind). Plus, if the screen doesnt need redrawing, but the redraw is done anyway, then because its drawing over existing tiles it would make no difference.

Anyway, if you're going to get so picky about things like that you might as well scrap API altogether and move over to DirectX.

Lastly, I very much doubt any specific method was chosen (if we are talking about BillSoo's example) merely because it was 'easy'. If that were the case then why even bother with API at all, why not just shuffle a few image controls around a bit?

02-23-2002, 06:43 PM
It's not like the game would go bezerk while nothing was happening... it is turn based after all, and animation is controlled by a timer.

Plus, if the screen doesnt need redrawing, but the redraw is done anyway, then because its drawing over existing tiles it would make no difference.

This is my point. If it makes no difference, why do the extra processes? You can if you want at a small level, but if the process begins to take too long then you can end up with quite a bit of lag. The way BillSoo's demo was done this would be most noticable in missed key presses. The player would hit the button and release, and the game engine would never know, because it was busy rendering. Animation speeds would also suffer.

Lastly, I very much doubt any specific method was chosen (if we are talking about BillSoo's example) merely because it was 'easy'. If that were the case then why even bother with API at all, why not just shuffle a few image controls around a bit?

I never said that BillSoo's example was done the easy way. I imagine it was done to demonstrate how to use bitblt and tilesets to make a RPG map game. The code is very small for what it does, which is kinda cool to see also.

As for shuffling about Image Controls... if it can produce the desired effect quicker than, or on par with an API method then I'd say, 'Yes... why not use the Image Controls?'. Particularly seeing as thier implementation would be easier, and you wouldn't need to learn any APIs. I am not saying that Image Controls are faster, I haven't done a comparison. I am just saying 'if'.

BTW... in VB, is DirectX noticablely faster than API calls? I am considering a project after my current one, which will require one or the other (or a stupid amount of Image Control work ;) ) and I'm wondering if I should try API methods through out, or use it as an oppourtunity to get into DirectX.

02-23-2002, 11:16 PM
Hey, now that I think about it, BillSoo's example did refresh itself on a timer, but when the user released a key, the Direction=0, which wouldn't make anything move. Even though that probably doesn't require much, in my game I made it so that the timer enables when the user presses a key, just because I want games to use the least amount of resources. But, hey, with bitblt to make a 2-d map, you do get some nice results. Besides, even if some consider BillSoo's tilemap inefficient, it's only because he had a 200 X 200 map, which could take time to load, and that he has a large chipset, and relatively larger tiles. Other than that, he had a large character chipset, and used get/set pixel, and could have used a mask picturebox, but hey, it reached me, and helped me learn bitblt, so if it reached just one person, it was worth the time
there's my 2 cents

02-24-2002, 05:50 AM
DirectX is vastly superior than API in terms of speed, ease of coding, flexibility, and effects available. It was designed for gaming, and it works.

EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum