Jump to content

  • Log In with Google      Sign In   
  • Create Account


Memory problem...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Zen42   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 September 1999 - 09:05 AM

Hi to all of you!

I have a problem with my ISO-based strategy game. Since I began coding it a week or so ago, it is far from complete. But I encountered a real big problem at this stage.

The problem is MEMORY. When I call IDirectDraw::GetAvailableVidMem() it tells me, that I have used aproximately 4 Megs of VideoRAM. In the times of 32 Megabyte Graphiccards this should not be a problem, but I consider my game (at this point) very simple and even at this stage (I have just drawn the floor-tiles and four objects) it rips 4 Megs out of my VideoRAM. This is realistic, because I use...

... 1 Fontbuffer, 1 Backbuffer, 1 Offscreenplain for the tiles,
1 Offscreenplain for the interface elements and 1 Offscreenplain for drawings like the map and so. All that surfaces are 800x600x16bit, except the drawing-plain, which is 210x450x16bit.

So, here is the point: As I implemented softscrolling, I need to have all of my surfaces in VideoRAM (or don't I?). Because, if I put them in systemmemory, The Blitting is horribly slow. I tried to use some of the tricks to increase blitting speed I found on GameDev.net, but they didn't work for me (slower than with hardware accelerated IDirectDrawSurface4::Blt).

I then went over to my girlfriend's computer (Matrox Mystique 2Megabyte) and tested my game there. Since there are only 2 Megs of VidMem available it did just as I expected. SLOOOOOOWWW!!! So my fears were justified. But I want gamers to play my game even if they don't have a TNT card or the like.

So, if anyone could give me some advise I would be very thankfull.

btw: I have never before come so far with a game, so even I am not new to programming, I am quite new to DirectDraw and stuff, so please take that into account, when replying

Thanks in advance...

A screenshot of the game can be found at:
http://www.rzuser.uni-heidelberg.de/~tpastuch/screenshots/screenshot.html

I know the graphics are poor, but this is the first time ever, I tried to do real graphics in a game (Not just lines and dots) and I am NOT a good graphic designer (Used photoshop the first time ever).


Sponsor:

#2 Niels   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 September 1999 - 04:08 AM

First of all, you need to realize that there's no way all you gfx will ever fit in video memory (unless you are targeting 32MB video cards) (I have 9MB of animations + tiles, buffers etc., and I'm probably half done with the gfx: http://www.image.dk/~noshit/scrshots.html)

So now the question is: What do we keep in video memory and what goes in system memory? There's no clean cut answer, but here is a few guidelines:

1) Tiles cover the whole playfield, I.e. you are gonna blit a lot of those. Also, they don't require any special processing (alphablending f.ex.). So they're an obvious candidate for videomemory (Also you can have a tileset per map removing the need to store tiles that are not used with that particular map)

2) You don't wanna copy too many little pieces from system to video memory - a few larger chunks are preferred. So if possible, consider pre-rendering stuf that don't change often and copy it to video memory with a single blit (UI, radar etc.).

3) ASM ASM ASM - I know there is a tendency to believe that C++ compilers genereate awesome code - this is, however, simply not true. For the processing where you can't use HW blitting you should definately go for inner loops written in asm.

Hope it helps (I was in the exact same situation 6 months ago )

/NJ


#3 TANSTAAFL   Moderators   -  Reputation: 1152

Like
Likes
Like

Posted 24 September 1999 - 07:39 AM

blitting to and from sysmem is not necessarily as slow as everyone makes it out to be, as long as you know what you are doing.

vidmem to vidmem is fast

sysmem to sysmem is fast

vidmem to sysmem or sysmem to vidmem is not fast

so, if you have to use sysmem for things, dont do 100 blits from sysmem to vidmem. do 100 blits (or however many you have to do) sysmem to sysmem then do ONE blit from sysmem to vidmem.


#4 mutex   Members   -  Reputation: 1109

Like
Likes
Like

Posted 24 September 1999 - 01:34 PM

first of all, i have to say that your graphics skills are better than i ever hope mine will be. mine are so horrible i have to use textures from the directx 6 sdk samples =)

anyway, with the video memory problem. you could check how much video memory there is, and if it's too little, force the creation of all buffers in system memory. that way, you're do all the blitting from system to system memory, and then at the last step it gets blitted to the video card. you only need to add one flag in CreateSurface to place it in system memory also, but i can't remember it


#5 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 24 September 1999 - 02:27 PM

Hi!

Thanks for all the help an suggestions. Everything was very helpful and made me totally rewrite my graphic functions. Okay, not totally, but much of it.

I had to give up softscrolling at the moment, but I will reintegrate it, when my ASM-knowlege is better. The display routines suffered a slowdown, but not as much as I thought (The hint concerning speed issues for blitting (SYS->SYS, SYS->VID, VID->VID) where very helpful at this.

I am now going to optimize everything in the next days or so.

btw: 2 new questions

1) Has anyone tried which one is faster to copy a whole screen in system memory to a backbuffer in video memory, "memcpy()" or "Blt" ?? I can't see any difference, but if someone timed it exactly, I would like to know.

2) Would it be a good technique to move the "old" contents of the screen if the player srolls the map and just redoing the portions of the screens that are invalid then? I mean, I have to make a "backup" of the whole screen without the UI everytime the player scrolls, hm?

Again, thanks for the all the help!

Bye...


#6 Queasy   Members   -  Reputation: 157

Like
Likes
Like

Posted 24 September 1999 - 04:45 PM

I have tried this technique that you described but have found an almost nill speed increase (though i thought it'll speed it up lots). Also, with that technique, when scrolling diagonally, i found the code to be quite messy.

maybe it's just me?
**********
2) Would it be a good technique to move the "old" contents of the screen if the player srolls the map and just redoing the portions of the screens that are invalid then? I mean, I have to make a "backup" of the whole screen without the UI everytime the player scrolls, hm?
**********


#7 TANSTAAFL   Moderators   -  Reputation: 1152

Like
Likes
Like

Posted 24 September 1999 - 07:21 PM

i have found that doing a single blit to scroll the entire playing area, then filling in the newly uncovered areas to be a good way of minimizing the number of blits you have to do.

however, if you are going to do it with a same surface blit (i.e. a surface blitting to itself with overlapping rectangles), i have had mixed results. sometimes it works, and sometimes it doesnt, and i dont know why... i think it depends on the video card.

so, you may want to have an additional surface handy for the big scrolling blit.


#8 Zen42   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 September 1999 - 09:05 AM

Hi!

I have now done some optimizations and implemented a form of blitting the whole screen in response to movement and then renewing the portions of the screen which are then invalid. I used another surface in SYSMEM to hold the image of the landscape without the UI.

That speeded up the scrolling much, so I like to thank you for the advice of having another surface for the "screen-backup".

btw: This is a really cool message board with really cool people





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS