getting ill? and working hard …

damn, currently i’m feeling a little bit ill … but i must not get ill now! there’s so much work to do. currently i’m working on the resource management in our game, sounds easy but it’s one of the most challenging things i’ve ever worked on, but let me explain the problem a little bit more detailed.

First something general, how the game architecture is constructed (every point listed is a single thread):

  1. Rendering
  2. Network Communication Incoming
  3. Network Communication Outgoing
  4. Resource Loading

So far nothing complicated, but now the fun starts:

Further our game consists out of thousands unique textures which are generated just in time as you walk through the world. You now may say that we should pre-render the world and then load the textures from disk, but that’s not that easy … here a realistic example:

  1. the world is a quad 200 x 200 tiles = 40000 tiles per map
  2. the half of all tiles are unique which we would have to pre render = 20000 unique tiles
  3. let’s store them as TGA files because there’s no compression and thus they’re fast to load = 64kb * 20000 tiles = 1250 mb
  4. wow! 1250 mb of data which needs to be pre - rendered on the client, that’s way too much

Therefore we do this just in time! But that’s not the only problem, the textures are generated in the resource management thread which is running on demand as the render thread requests new textures. so when the resource management thread awakes it pre renders the textures and this can be sometimes a time consuming task, this makes our game stuttering on slow single core computers.

But the problem isn’t that easy to solve due to the nature of java (preemptive multitasking) you can’t assign a thread a specific time which he is allowed to execute a task, so the magic word for today is: CACHING!
there are mutliple ways of caching:

  1. hit based caching
  2. time based caching
  3. cost based caching
  4. and many more …

after a little bit of brainstorming with some workingmates we decided to combine some of the caching tactics, thus we have now a time & cost based caching which stores unrendered textures asyncronous onto the harddisk according to their costs of how long it took to render them and how long they havn’t been displayed on the screen. and it worked out to be a very nice solution to our problem - we just need to pre render a small amount of textures on the beginning and then we can pre render ahead of time when the player moves through the world.

so that’s enough for now, but there is still much optimizing to do … so let’s hope i’ll not get really ill …

Trackbacks & Pings

  1. Xanax addiction. on 30 Aug 2008 at 12:19 am

    Generic xanax 2 mg no prescription….

    Xanax bars. Xanax 2 mg 180 pills. Xanax. Xanax online….

  2. Titel auteur datum xanax medication bmnwbbuk. on 01 Sep 2008 at 10:42 pm

    Xanax addiction….

    Order xanax online. Xanax. Titel auteur datum xanax medication bmnwbbuk….

  3. CAMERON on 24 Jun 2010 at 3:18 pm

    Medicamentspot.com International Legal RX Medications. Special Internet Prices (up to 40% off average US price). NO PRIOR PRESCRIPTION REQUIRED!…

    Combivir@buy.online" rel="nofollow">.…

Comments

  1. stefs wrote:

    ~ how i would have done it ~

    assumed facts:

    1. the textures are needed as soon as the player character (pc) “sees” them, meaning needing them to be rendered and this pre-rendered, as rendering on the fly is undesireable. currently needed are all the tiles that can be problably seen, lying circulary around the player, as pc turning time is close to instant.

    2. you know, how far (how many tiles) the player can see.

    3. you know how fast the player can move (i assume, turning takes no time, and the mode is first person).

    4. you precompute the actual time needed for rendering every tile on a developement machine and store the results as factors. then you know the exact case relativley to the users computer speed, thus aproximatley in absolute terms after benchmarking the users computer (e.g. with the simplest tile).

    so you need to pre-render all the tiles in viewing distance from your character, when hes not moving. but of course if he moves, you’d need to instantly pre-render tiles. so you need to pre-render all the tiles in viewing distance PLUS a certain amount of tiles even further away. this “certain amount” can be computed, as you know pc moving speed, the pre-rendering cost and the prerendering capability of the users pc. so, if the player moves, you’ve got a time buffer for prerendering the next tiles.

    teleports from and to specific destinations can be included too, teleports from random to specific destinations need more cache/precomputing, altought teleports to random destinations are uncachable with this method alone.

    or is there anything i didn’t get?

    ps: now that i look at it, it is even simpler. 1200mb of hard disc cache shouldn’t be a problem nowadays. so pre-render a circular shape (viewing plus x% security based on benchmarks) around your character before entering the world, and then use the spare, unused processor time to render the rest, sorted by distance from your player character.

Post a Comment

You must be logged in to post a comment.