|
|
>Places where (static) objects are standing, houses, trees, high
>mountains (evth with a certain angle) and thinks like that.
>Let's say I'd increase the grid-resolution by 4 (so 512x512 with 1 byte
>per grid-entry, I'd need 256kb/sector, which gives >1Gb in total...
But it sounds like you only need 1 bit per entry. (go/no-go) So 512x512 of that information is only 32KB. x5000 = 160 MB in total. Better but still a lot.
>I also though about using the detail of the terrain - but we are
>trying to seperate logic from rendering (so a gameserver - running
>on a different computer - can have a relatively small logic
>representation of the world, compared to the huge render-representation).
Then how about those running the game and have all the renderdetail handy, to generate most of it as the gamer goes along. (If he has all details, it doesn't sound like a good idea to store that information extra.)
But then for that gameserver, storing 160MB of bitmaps would probably not be much of a problem. And with 32KB per sector it can load a whole lot of surrounding sectors for hundreds of players in memory at a same time.
Generating such a map is probably really fast for the type of objects you mentioned. You can loop through all the 512x512, but everytime you hit an object of a certain shape, you can eliminate a lot more bits, so you could have a temporary 512x512 bitmap aside that keeps track of what bits and places you already had. And I'm sure you can find other ways to eliminate larger areas at once.
Also to make it seamless you could generate line by line as the player moves of comming-near sectors, instead of all 512x512 at once. (but you also need to load sectors i guess, then you can do at the same time.)
What will the game be about?
Stan
|
