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

Askadar

Using Transparency in DDraw with software

15 posts in this topic

Hi! I''ve been reading about transparency in direct draw and know that I have to implement it in software. I read the articles here, so I basically know how to implement it, but there''s one question that I''ve got: I read that getting pixels from VRAM is really slow, because the video cards are built for blitting, not getting data. So all the tuning in the world won''t help if you''re trying to blit something transparent onto the primary surface, right? Or is this a wrong assumption and it doesn''t matter? In case I''m right, that would mean that one would have to prepare the frame in system memory and one would loose all the advantages of the blitter and surface flipping. Right? Or again wrong? Thanks for you help!
0

Share this post


Link to post
Share on other sites
Yes reading to/from video memory is very slow.

If you plan to use a lot of alphablending it is best to blit to an offscreen system surface and when you are done blit it to your backbuffer and then flip.
This means that all your surfaces should be kept in system memory even though you don''t plan on using them all for alhablending.

0

Share this post


Link to post
Share on other sites
Isn''t there a way to get around this, or this there no difference (for the framerate, say I lock it to 30 fps anyway) on modern computers whether the frame is created in VRAM or system memory anyway?
0

Share this post


Link to post
Share on other sites
The VRAM will blt your images much faster than in the system memory, since this is what is VRAM was meant for. Also, copying the memory into the VRAM will be slightly costly.

Though even with that in mind, as mentioned before, it is much quicker than retreiving pixel information from the VRAM.

Gamedev''s AI Auto-Reply bot.
0

Share this post


Link to post
Share on other sites
Now if I prepare the frame in system memory and do a whole lot of alpha blending at 32 bpp, what kind of processor requirements should I expect?

If I have only one 800x600 surface, that I want to fade in and out, will that be doable for old 400Mhz AMDs?
0

Share this post


Link to post
Share on other sites
nope. unless you use 8bit color with mmx asm, even then you are streching it. your ram is just not fast enough to handle that. if you want to do fullscreen alphablending or a lot of alphablending at high resolution, use d3d or opengl. you still do the game in 2d, but use textured quads instead of sprites. now you get bilinearing zooming, alpha blending, depth buffering, all for virtually no cost (well the video card has limitaions to, but 3d accelerators have much more bandwidth/better designed to handle this stuff). the only true way to know is to actually see for yourself. you may surprise yourself and find the framerate accpetable. but dont expect anything north of 15frames per second (and thats being optimistic).
0

Share this post


Link to post
Share on other sites
no, i'm pretty sure you can use transparency in directdraw...
look up "color key" in the docs (or search gamedev.net forums)...
--- krez (krezisback@aol.com)

Edited by - krez on December 14, 2001 7:23:21 PM
0

Share this post


Link to post
Share on other sites
Yep, I meant translucency.

So If I just want to fade my background in and out, it might me a better way to just prefade it in Photoshop and load all the frames for a 2 second fade in/fade out. That would of course eat up a whole lot of memory, but at least I would get it to run smoothly.

I''m just learning these things now, so I''m a little bit scared about D3D8, because it looks, well, very complex at least....

Thanks a lot guys for your help!
0

Share this post


Link to post
Share on other sites
Ups. Just did a little calculation, it would eat a lot more than just a few megs.... Well, maybe I have to look at D3D anyway...
0

Share this post


Link to post
Share on other sites
Look up "gamma"-something in the DDraw docs.

It lets you fade fast if the hardware supports it.
0

Share this post


Link to post
Share on other sites
well the other idea is do what we did back in the day (and still do), use a lower resolution and color bit depth. for instance doing 640x480 at 16bit color depth is possible for fading (if optimized in mmx, there was an example of this on this site). using the gamma control is a bad hack, since you are effectivly messing with someones video settings without permission and if some one alt tabs out your game or it crashes the person will be quite pissed. (since gamma settings wont be set back on a crash which is why desktops are bright (or dark) when quake crashes and other games crash). though in those games the user is telling the game while its running to use increased or decreased gamma settings.

also 640x480 is quite a decent resolution for a 2d game. dont expect look up tables or storing all the frames help yoru cause. it will merely make things worse. i think though even at 32bit color depth you could get realtime fade at 640x480 on 400mhz, just make sure you use mmx (or at least fixed point math) and ABSOLUTLY NO FLOATING POINT MATH AT ALL! (it will kill yoru framerate to the point of absurdity). i was able to get decent speed when crossfading images using 32bit color at varing resolutions. though my code was in mmx and purly for crossfading of images.

i am guessing you can get about 10 frames per second at 800x600, maybe even a bit less. but only if you mmx optimize your code. i really suggest if you want to go the directdraw route, go for 640x480 as your resolution, you will fare much better with fullscreen effects.
0

Share this post


Link to post
Share on other sites
ello
on my duron 600 pc133 with an TNT/agp card I get:
in 640x480x32bpp res
120screens (185mb) sysmem->sysmem copy
90screens sysmem->vidmem copy
therefore doing a fullscreen fade is possible (if you do it while copying info to vidmem it should be pretty cheap if done right(asm..))
you should expect similar results in 800x600x16bpp mode (as they use quite the same amount of memory...)
It might work much worser on systems with 66mhz bus/sdram modules (pentiums, p2 <350mhz and celerons<800mhz) as their sysmem->sysmem transfer is much much worse. (on my bro cel400 I could get much better results transfering sysmem->vidmem then sysmem->sysmem!)

With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/
0

Share this post


Link to post
Share on other sites
MirekCz, are you just copy the data to its destination? if so your numbers will be very skewed and optimistic (since you are going one way only). you must realize that read and writing can screw the cache especially when dealing with multiple buffers. \

on the other hand now if its for purly fade, then your numbers are pretty good (fades are almost free when using mmx even in 32bit color). just remeber Askadar, this type of fullscreen effect is very dependent on bandwidth. my numbers were for an alpha blit function so mine are skewed lower then if you are doing just a pure fade.

good luck, and remeber. no floating point. no reading from vram. you will then get decent framerates. (you can go old school and just subtracting (faster and pretty cool looking) or the proper way of multipling (slower but accurate, may be more of wait you want)
0

Share this post


Link to post
Share on other sites
a person:yeah, I only copy the data, what''s wrong with that?
I do HAVE it in registers.
I get this results by either using 64bit mmx transfer or all 4 32bit registers at once (with rep movsd you get lower mem transfer, not very much lower thru)

With best regards,
Mirek Czerwiñski
http://kris.top.pl/~kherin/
0

Share this post


Link to post
Share on other sites