I am planning on making an RPG game with a similar iso engine to Ultima Online. What I will have is, a whole big world as an array of tiles. I also plan on doing this with 32bit. I would like to know how the engine in UO works (how it loads/draws the whole world without taking much time) and see if it will be possible with 32bit graphics. Thanks for your help!

Compression and on the fly decompression is the key to fast loading.

32 is no different than 16 or 8. Except 32 bit is going to kill your framerate. You''re also going to double or more your memory requirements instantly.

Ben

Thanks for your reply.
So the UO engine does compression/decompression so load the whole world super fast when it loads up the game?
Or is there a way to load the graphics that are only in the screen?
(And the engine knows automatically to load the graphics out side the screen when the player moves?)

Well, the engine doesn''t "know automatically" It does whatever you program it to. The idea is to have a caching layer inbetween the tile rendering code and the graphics storage. Instead of tiles storing a pointer to a graphic, they store a reference number (or unique name - it doesn''t matter how you do it really). And when the renderer wants to display a tile, it asks the graphics storage to give it the pointer to the graphic it requires. The graphics storage may only have, for instance, half the game''s tiles in memory at any one time. If the desired tile is in memory, it returns a pointer to it. If the desired tile is not in memory, it deletes a tile in memory that it hasn''t needed for a while to make space, and loads the requested tile in its place, before returning a pointer to it. This system allows you to economise on memory usage, with the small tradeoff that you will occasionally get loading times as the system swaps graphics from disk to ram. You can optimise it further by loading images before you need them, rather than as you need them, and perhaps by putting such ''preloading'' in a separate thread.

I believe DDraw does all of that automatically. The system I''m developing on is a p5-200 with 48MB of ram. There''s a 150+ Megs of stuff that needs to go into memory. That amount will go up much more. However it still runs.

When I hit an area with different tiles there''s a pause and the harddrive begins reading for a few seconds then the game continues smoothly. Systems with more ram do that less.

You could probably do your own routine but I''ve left it up to DirectX and have never worried about it.

Ben

KalvinB, that''s probably DirectX taking the item out of the Virtual Memory (HD space that pretends it is RAM) and placing it into the RAM or Video Memory. In other words, it was loading and was taking up space in memory, you just weren''t noticing it.

If you were using Win2K (are you? I got the impression you weren''t) I''d show you how to check how much RAM/Virtual Memory is in use. I don''t know how to do it in Win 9x without a second party program.

---

http://www.gdarchive.net/druidgames/

Too bad that my game is for the Mac. Any Mac programmers?
I guess I would have to do those stuff in QuickDraw.

I am not a Mac programmer per se but I am writing
a cross platform engine and have deciced to go
for memory mapped files. The Mac has this capability
go to Apple.com and have a look at this feature.

First, I don''t believe UO uses tiles for the ground - rather voxels or polys (can''t remember which). That save on a lot of tiles there. As for storage, yes - a cache system is best to use.

Merely keep the most used tiles in memory, while throwing out older ones as new ones come along.

Jim Adams

Hmm...now im confused as to what is meant by tile! First its a tile, then maybe a voxel, but its still worded as a tile?! My point is that 2 defs of "tile" used, 1 as the graphics bitmap at that mappoint and then the other as the actual mappoint data structure.

If, as jim says they use voxels, does that mean they are using a BSP tree? If yes and yes, are the trees created using x,y,z(z not sure if needed but included here)?

aka John M.
Never give up. Never surrender!