Back to General and Gameplay Programming

Memory problem...

General and Gameplay Programming Programming

Started by Zen42 September 26, 1999 03:05 PM

6 comments, last by Zen42 24 years, 7 months ago

122

September 24, 1999 10: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

TANSTAAFL

1,160

September 24, 1999 01:39 PM

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.

Get off my lawn!

mutex

1,111

September 24, 1999 07: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

Anonymous

September 24, 1999 08: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...

Queasy

157

September 24, 1999 10: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?
**********

Jonathan Makqueasy games gate 88[email=jon.mak@utoronto.ca]email[/email]

TANSTAAFL

1,160

September 25, 1999 01:21 AM

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.

Get off my lawn!

Zen42

122

Author

September 26, 1999 03:05 PM

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).

Zen42

122

Author

September 26, 1999 03:05 PM

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

Memory problem...

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Memory problem...

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines