1 - I''m trying to find a way to dynamically page the map data off the disk as to avoid any real loading times or map switching. Does anyone have an idea how this could be performed efficiently?
2 - I need to find a way to limit the view of the map like most isometric engines currently do - eg: so you don''t see the borders of the map; any ideas on this one?
Any feedback, suggestions, etc would be awesome!
Thanks!
Nate S.
Isometric questions..
Author
I''m toying with the idea of creating an 2D isometric rendering engine in OpenGL but I have a few things I can''t sort out - so I figured I''d see what the masters on this forum have to say
1 - I''m trying to find a way to dynamically page the map data off the disk as to avoid any real loading times or map switching. Does anyone have an idea how this could be performed efficiently?
2 - I need to find a way to limit the view of the map like most isometric engines currently do - eg: so you don''t see the borders of the map; any ideas on this one?
Any feedback, suggestions, etc would be awesome!
Thanks!
Nate S.
1 - I''m trying to find a way to dynamically page the map data off the disk as to avoid any real loading times or map switching. Does anyone have an idea how this could be performed efficiently?
2 - I need to find a way to limit the view of the map like most isometric engines currently do - eg: so you don''t see the borders of the map; any ideas on this one?
Any feedback, suggestions, etc would be awesome!
Thanks!
Nate S.
#2 is pretty easy...if you can see X squares in every direction then you just make a border x squares wide where you are not allowed to walk on. That way they see the border but cant walk on it and thus move the screen exposing the edges of the map.
For a tile game the data for each map is tiny, while the textures themselves can be many times larger than the map. So as for the map load it all in memory, and work on a dynamically loading textures.
Author
I just thought up another interesting question that I can't seem to place the answer to..
Does anyone have a solid idea as to how dynamic map paging could work for 2D game such as diablo II? I would like to have a very vast game world but I can not seem to wrap my mind around the logic behind data paging :|
Any suggestions / web links would be great
-Nate S.
[EDIT] I just noticed that I did ask a similar question in my first post; my excuse is that I just woke up and I'm tired =)
But any more ideas would be interesting too!
[edited by - nstrg on May 25, 2004 1:39:37 PM]
Does anyone have a solid idea as to how dynamic map paging could work for 2D game such as diablo II? I would like to have a very vast game world but I can not seem to wrap my mind around the logic behind data paging :|
Any suggestions / web links would be great
-Nate S.
[EDIT] I just noticed that I did ask a similar question in my first post; my excuse is that I just woke up and I'm tired =)
But any more ideas would be interesting too!
[edited by - nstrg on May 25, 2004 1:39:37 PM]
I''ve just implemented a system like this in my iso project.
It can theoretically load maps of unlimited size(well practically you''re having the file size limitation)
I''m in a hurry right now so i can''t post more details.
Maybe later tonight i''ll post details on implementation.
Here these words vilifiers and pretenders, please let me die in solitude...
It can theoretically load maps of unlimited size(well practically you''re having the file size limitation)
I''m in a hurry right now so i can''t post more details.
Maybe later tonight i''ll post details on implementation.
Here these words vilifiers and pretenders, please let me die in solitude...
Author
That would be great Voodoo4 - if you want you can email me (or just post on this forum) nstrg AT dyaustech DOT com
Thanks!
Nate S.
Thanks!
Nate S.
I''ve done something similar in the past using a 3x3 cell system (could be larger if you have memory spare for caching - see below), where the player is always considered to be in the ''central cell'' of the grid. As the player moves towards one of the 8 outer cells, the game loads in the next 3(up to 5 for a diagonal) cells in that direction, and flags them to the system. Maps are stored in a cache and ages according to distance from the player.
Tile sets for the maps are designed to be layered and work together, so you never get a cell with 100% new graphics, always an intermediate overlapping the old with the new. These are again stored in a cache, and rated by distance etc.
The only major problem comes with the 100% new, from teleporting, going into a special area, or new zone (eg an underground city). For these you normally have to live with a brief pause - normally just a few secs black screen, or a cut-scene. Of course if there is enough memory to hand you could partially or completely load these as well.
The system I wrote also had flags on the ''global map'' for when a cell would never be seen (so no map to load), or when the cell was all one (eg water effect).
One obvious point to remember is to load the central cell (and tile-map) first on the player''s arrival, so people can see their surroundings as the other 8 cells load - even if they don''t have control yet. With a bit of animation to the place (fires/torches burning or whatever), the player starts to feel they are there - in the game, ready for anything - even while the last details of the other 8 cells are loading. Obviously, one ''cell'' is several times the width/height of a screen.
Unfortunately the system was only a test-bed, so I don''t know if I still have the files to hand. If I do, I''ll dig them out. I moved on to applying the same system to a 3D world (the struggle against ''Zones'' a la EQ).
As an addendum, its also possible to break this down further, depending on memory etc, so a cell may itself have a 3x3 sub-grid, and you load the sub-cells nearest the approaching player before the others, and so on.
Hope this helps,
Ann-Marie
Tile sets for the maps are designed to be layered and work together, so you never get a cell with 100% new graphics, always an intermediate overlapping the old with the new. These are again stored in a cache, and rated by distance etc.
The only major problem comes with the 100% new, from teleporting, going into a special area, or new zone (eg an underground city). For these you normally have to live with a brief pause - normally just a few secs black screen, or a cut-scene. Of course if there is enough memory to hand you could partially or completely load these as well.
The system I wrote also had flags on the ''global map'' for when a cell would never be seen (so no map to load), or when the cell was all one (eg water effect).
One obvious point to remember is to load the central cell (and tile-map) first on the player''s arrival, so people can see their surroundings as the other 8 cells load - even if they don''t have control yet. With a bit of animation to the place (fires/torches burning or whatever), the player starts to feel they are there - in the game, ready for anything - even while the last details of the other 8 cells are loading. Obviously, one ''cell'' is several times the width/height of a screen.
Unfortunately the system was only a test-bed, so I don''t know if I still have the files to hand. If I do, I''ll dig them out. I moved on to applying the same system to a 3D world (the struggle against ''Zones'' a la EQ).
As an addendum, its also possible to break this down further, depending on memory etc, so a cell may itself have a 3x3 sub-grid, and you load the sub-cells nearest the approaching player before the others, and so on.
Hope this helps,
Ann-Marie
Author
@Archimage - Sounds like a very impressive system (even if it was only for a test bed). If I recall, even in Diablo II there was a slight pause when you entered a new area (Not sure if that was caused by actual loading or something else..)
-Nate S.
-Nate S.
I''ve sent you an e-mail but in case anyone else is interested
i''ll just post it here too:
---------------------------------------------------------------
OK, here''s a description of my implementation:
What i basically do is to cut the map into sectors and load each time the sectors i need.
It''s not as fast as loading the whole map in memory,but it is fast enough and certainly
much more efficient for huge maps.
Let''s say we have a 4000x4000 tiles map.
What we need is to seperate this into sectors.
Let''s make the sector size 200x200 tiles.So the map will be seperated into 400 sectors(20x20 sectors).
Each time we "enter" a sector,we''ll load this sector and its "neighbour" sectors.
Take a look at the following example:
We start a game at sector 0(the first sector).Its "neighbour" sectors are 1 to the east,
20 to the south and 21 to south-east, so we will load them too.
0 1 2 3 4 ... 19
20 21 22 23 24 ... 39
40 41 42 43 44 ... 59
It is good to keep a list of the "active" sectors(the loaded sectors), in which you will add and remove sectors.
So currently our active sector list contains sectors 0,1,20,21.
If sometime later we enter sector 1 then we have to load this sector and its neighbours:
0 to the west, 2 to the east, 20 to the south-west,21 to the south and 22 to the south-east.
However some of them are already in the active list so there''s no need to load them.
Thus we only load the new sectors: 2 and 22.
Our active list now contains sectors: 0,1,2,20,21,22
Moving to sector 22 we need to load it and it''s neighbours.
The only new sectors are 3,23,41,42,43.However some old sectors have gone out of scope(0,20) so there''s no need keeping them and thus it is better to remove them.
The active list now contains sectors: 1,2,3,21,22,23,41,42,43
The maximum sectors you will have to load is 9 since 9=sector + maximum number of neighbours,which are 8:
NW N NE
W O E
SW S SE
Well that''s the general idea.
Implementing it though is more tricky and requires some effort.
I could send you source code but there are little chances you''ll figure out what''s going on
since it''s not very well commented.
I''ll give you some tips though:
I keep my list of active sectors in an std:: container which makes it easy to
add and remove sectors by key rather than index.
I add the sector and pass it''s sector number as its key.
Then if you want to check if the sector is already in the list,or if you want to remove it,
you just do it by just refering to each sector number.
Just BE CAREFUL! In a container never store the actual object, but instead a pointer to that object.Storing objects in std containers can kill your performance!
The size of the sector is also vital.
Using small sectors will decrease memory allocation but the cost is more disk access which generally is much slower than RAM access.
Using large sectors will decrase disk access but it will increase memory usage.
Another problem with large sectors is transition-delay.This is the time needed to load the new sectors when you pass from one sector to another.The larger the sectors, the bigger the delay.
As with most things, balance between the two is the ideal.
Just play with the numbers and see for yourself.
I currently use 100x100 tile sectors and i get constant 119 fps(just base tiles - no objects,no characters,no AI).And transition is smooth enough(just a small noticeable delay - but there''s always room for optimization
)
Anyway if you have any questions on implementation just ask me.
Also if you need source code i can send you,but as i said it won''t be very easy to read it.
Here these words vilifiers and pretenders, please let me die in solitude...
i''ll just post it here too:
---------------------------------------------------------------
OK, here''s a description of my implementation:
What i basically do is to cut the map into sectors and load each time the sectors i need.
It''s not as fast as loading the whole map in memory,but it is fast enough and certainly
much more efficient for huge maps.
Let''s say we have a 4000x4000 tiles map.
What we need is to seperate this into sectors.
Let''s make the sector size 200x200 tiles.So the map will be seperated into 400 sectors(20x20 sectors).
Each time we "enter" a sector,we''ll load this sector and its "neighbour" sectors.
Take a look at the following example:
We start a game at sector 0(the first sector).Its "neighbour" sectors are 1 to the east,
20 to the south and 21 to south-east, so we will load them too.
0 1 2 3 4 ... 19
20 21 22 23 24 ... 39
40 41 42 43 44 ... 59
It is good to keep a list of the "active" sectors(the loaded sectors), in which you will add and remove sectors.
So currently our active sector list contains sectors 0,1,20,21.
If sometime later we enter sector 1 then we have to load this sector and its neighbours:
0 to the west, 2 to the east, 20 to the south-west,21 to the south and 22 to the south-east.
However some of them are already in the active list so there''s no need to load them.
Thus we only load the new sectors: 2 and 22.
Our active list now contains sectors: 0,1,2,20,21,22
Moving to sector 22 we need to load it and it''s neighbours.
The only new sectors are 3,23,41,42,43.However some old sectors have gone out of scope(0,20) so there''s no need keeping them and thus it is better to remove them.
The active list now contains sectors: 1,2,3,21,22,23,41,42,43
The maximum sectors you will have to load is 9 since 9=sector + maximum number of neighbours,which are 8:
NW N NE
W O E
SW S SE
Well that''s the general idea.
Implementing it though is more tricky and requires some effort.
I could send you source code but there are little chances you''ll figure out what''s going on
since it''s not very well commented.
I''ll give you some tips though:
I keep my list of active sectors in an std:: container which makes it easy to
add and remove sectors by key rather than index.
I add the sector and pass it''s sector number as its key.
Then if you want to check if the sector is already in the list,or if you want to remove it,
you just do it by just refering to each sector number.
Just BE CAREFUL! In a container never store the actual object, but instead a pointer to that object.Storing objects in std containers can kill your performance!
The size of the sector is also vital.
Using small sectors will decrease memory allocation but the cost is more disk access which generally is much slower than RAM access.
Using large sectors will decrase disk access but it will increase memory usage.
Another problem with large sectors is transition-delay.This is the time needed to load the new sectors when you pass from one sector to another.The larger the sectors, the bigger the delay.
As with most things, balance between the two is the ideal.
Just play with the numbers and see for yourself.
I currently use 100x100 tile sectors and i get constant 119 fps(just base tiles - no objects,no characters,no AI).And transition is smooth enough(just a small noticeable delay - but there''s always room for optimization
)Anyway if you have any questions on implementation just ask me.
Also if you need source code i can send you,but as i said it won''t be very easy to read it.
Here these words vilifiers and pretenders, please let me die in solitude...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
