too many surfaces!!!!
My 2d directx platform game is crashing at load time!
I'm beginning to construct a level around 8000 * 2100
The screen res is 1024 * 768
It is tiled with 16bit 100 * 100 tiles (well I want it to be)
But it crashes if I try to load less than half that area.
I'm loading one 100 * 100 surface for each tiled area of around 1000 * 1000
The RECT info along with the surfaces is kept in vectors and called from there for blitting to the screen
Should I be able to blit more surfaces than this?! I hope so or my levels have to be pretty small.
An added note:
Tested on 2 different computers and it crashes at the same point on both.
Is it too many surfaces, full vectors or something else entirely?
Hi (been a while ;)).
How about some code of yours.We may be able to help you better if we knew how you were loading the level, the memory allotment etc.
Best put the code on a site a paste a link here ;)
How about some code of yours.We may be able to help you better if we knew how you were loading the level, the memory allotment etc.
Best put the code on a site a paste a link here ;)
It is really hard to say what the problem is without a better description of the problem. What are the return values you get from your DX calls? When your program 'crashes', how exactly does it 'crash'? Have you tried stepping through the code with the debugger?
You have way way too many surfaces.
You don't make a surface for each tile on the map. You make a surface for the screen and a surface for each tile artwork. Then blit the tile surfaces onto the screen (multiple times) where you need them. You should not have 1000*1000 surfaces unless you have that much artwork.
You don't make a surface for each tile on the map. You make a surface for the screen and a surface for each tile artwork. Then blit the tile surfaces onto the screen (multiple times) where you need them. You should not have 1000*1000 surfaces unless you have that much artwork.
Don't load one image per tile. Load all of your images and re-use them for all tiles that look the same.
I don't know if that's your problem; sorry to repeat, but you should post some code.
I don't know if that's your problem; sorry to repeat, but you should post some code.
Sorry I probably didn't explain it very clearly.
I'm actually only loading in about 30 or so surfaces, 100*100 and then blitting each single surface several times into 1000 * 1000 area. I generate the rect positions for the blits with an algorithm that works out how many rects(surface size ( in this case 100*100)) can fit into the area rect(1000 * 1000 in this case). These rects are stored in a vector and recalled at blitting time (if they are within the screen boundaries).
Don't know if i'm running out of vector space or something.
I'm even thinking there may be some restriction like a MAX_SURFACES value or something that is in the ddutil.h helper file I'm using?? I'll be checking that out tommorrow.
How many surfaces should I be able to load up (NO BLIT) at one time? I thought direct draw started allocating memory outside of video memory if it ran out. Maybe I'm totally mislead there? Shouldn't it only mean it starts running slower?
I'm gonna setup a site tommorow so I can post some code on it, I'll let you know when it's up.
I'm actually only loading in about 30 or so surfaces, 100*100 and then blitting each single surface several times into 1000 * 1000 area. I generate the rect positions for the blits with an algorithm that works out how many rects(surface size ( in this case 100*100)) can fit into the area rect(1000 * 1000 in this case). These rects are stored in a vector and recalled at blitting time (if they are within the screen boundaries).
Don't know if i'm running out of vector space or something.
I'm even thinking there may be some restriction like a MAX_SURFACES value or something that is in the ddutil.h helper file I'm using?? I'll be checking that out tommorrow.
How many surfaces should I be able to load up (NO BLIT) at one time? I thought direct draw started allocating memory outside of video memory if it ran out. Maybe I'm totally mislead there? Shouldn't it only mean it starts running slower?
I'm gonna setup a site tommorow so I can post some code on it, I'll let you know when it's up.
30 surfaces? Wow.
Make an offscreen surface that contains a BMP of your tileset. Not one surface per tile, but one surface with the tileSET that you're currently using.
From that surface blit the tiles, using their x,y,w,h values, to your backbuffer surface, then flip the back and display surfaces.
In other words, you aren't forced to blit the entire surface. That's why you see stuff like this:
http://www.artreality.com/gamesite/big/u6tiles.gif
You are more than welcome to post your code as long as it's between source tags. [ source ] //Code here [ /source ], without the spaces.
Make an offscreen surface that contains a BMP of your tileset. Not one surface per tile, but one surface with the tileSET that you're currently using.
From that surface blit the tiles, using their x,y,w,h values, to your backbuffer surface, then flip the back and display surfaces.
In other words, you aren't forced to blit the entire surface. That's why you see stuff like this:
http://www.artreality.com/gamesite/big/u6tiles.gif
You are more than welcome to post your code as long as it's between source tags. [ source ] //Code here [ /source ], without the spaces.
It doesn't sound to me like the number of surfaces is the issue. I've programmed apps which have used many more surfaces than 30. Give us some clues as to what is happening when the code crashes...
BTW, 8000 x 2100 is a large level. Do not try to render the entire level. Just render what is on the screen and a couple of tiles extra in each direction. When the player moves UP, delete the bottom row and render the next top row, etc...
tadobie,
This probably isnt your problem, but I thought I'd throw it out anyways. Most compilers have a limit to the amount of memory you can allocate on the stack in a function. By default this is 1 page. If you're allocating your 8000 * 21000 level as some kind of fixed size or 2d array, it may be that you're reaching that limit and getting a page fault.
Without seeing your code it's hard to say. I'd suggest moving the 8000 * 21000 allocation outside of any function (global) and testing it. There is no such cap on global allocation. Also, if this does turn out to be the problem, the allocation cap is a configurable flag on most compilers, so you can set it higher as necessary.
This probably isnt your problem, but I thought I'd throw it out anyways. Most compilers have a limit to the amount of memory you can allocate on the stack in a function. By default this is 1 page. If you're allocating your 8000 * 21000 level as some kind of fixed size or 2d array, it may be that you're reaching that limit and getting a page fault.
Without seeing your code it's hard to say. I'd suggest moving the 8000 * 21000 allocation outside of any function (global) and testing it. There is no such cap on global allocation. Also, if this does turn out to be the problem, the allocation cap is a configurable flag on most compilers, so you can set it higher as necessary.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement