• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

Zen42

Memory problem...

7 posts in this topic

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

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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...

0

Share this post


Link to post
Share on other sites
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?
**********

0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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).

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites