Jump to content

  • Log In with Google      Sign In   
  • Create Account


Using Transparency in DDraw with software


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
15 replies to this topic

#1 Askadar   Members   -  Reputation: 122

Like
Likes
Like

Posted 14 December 2001 - 02:44 AM

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!

Sponsor:

#2 granat   Members   -  Reputation: 122

Like
Likes
Like

Posted 14 December 2001 - 03:05 AM

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.



#3 Askadar   Members   -  Reputation: 122

Like
Likes
Like

Posted 14 December 2001 - 04:03 AM

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?

#4 kurifu   Members   -  Reputation: 122

Like
Likes
Like

Posted 14 December 2001 - 04:19 AM

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.

#5 Askadar   Members   -  Reputation: 122

Like
Likes
Like

Posted 14 December 2001 - 05:29 AM

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?

#6 a person   Members   -  Reputation: 118

Like
Likes
Like

Posted 14 December 2001 - 09:24 AM

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

#7 krez   GDNet+   -  Reputation: 443

Like
Likes
Like

Posted 14 December 2001 - 12:15 PM

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

#8 Big Sassy   Members   -  Reputation: 310

Like
Likes
Like

Posted 14 December 2001 - 07:08 PM

I think they are talking about translucency, krez.

#9 Askadar   Members   -  Reputation: 122

Like
Likes
Like

Posted 15 December 2001 - 01:04 AM

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!

#10 Askadar   Members   -  Reputation: 122

Like
Likes
Like

Posted 15 December 2001 - 01:08 AM

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

#11 granat   Members   -  Reputation: 122

Like
Likes
Like

Posted 15 December 2001 - 07:04 AM

Look up "gamma"-something in the DDraw docs.

It lets you fade fast if the hardware supports it.

#12 a person   Members   -  Reputation: 118

Like
Likes
Like

Posted 15 December 2001 - 01:02 PM

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.

#13 Askadar   Members   -  Reputation: 122

Like
Likes
Like

Posted 16 December 2001 - 06:14 AM

Thank you all!

#14 MirekCz   Members   -  Reputation: 132

Like
Likes
Like

Posted 16 December 2001 - 06:30 AM

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/

#15 a person   Members   -  Reputation: 118

Like
Likes
Like

Posted 16 December 2001 - 09:47 AM

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)

#16 MirekCz   Members   -  Reputation: 132

Like
Likes
Like

Posted 16 December 2001 - 09:53 AM

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/




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