RawDrawFrameTransparent issues (SOLVED)

Started by LeChuck, Mon 14/04/2008 14:47:13

Previous topic - Next topic

LeChuck

Code: ags
   
// script for Room: Player enters room (before fadein)
SetBackgroundFrame(0); // frame 0 is the normal background
RawSaveScreen();
   


Code: ags
   
 // script for Hotspot 6 (Hotspot 6): Use hotspot
RawRestoreScreen();
SetBackgroundFrame(1); // frame 1 is a totally blank frame, indicating a strong flash

int trans = 99;

while (trans > 0) {
	RawDrawFrameTransparent(0, trans); //fade in the normal background
	trans--;
	Wait(1);
}

SetBackgroundFrame(0); // go back to normal frame
RawSaveScreen(); // save current frame (don't know if this is necessary after already saving it in the before fadein script - either way it won't work the second time)



This code is supposed to be a quick flash of white that will fade into the normal screen. However, the fading script will only work the first time, and not the following times. Any ideas why?

naltimari

Hmm...  Why do you do RawRestoreScreen() if you do SetBackgroundFrame(1) right after? The RawRestoreScreen() seems pointless to me... maybe you should comment it and see what happens.

Anyway, I guess you shold also place the Wait(1) before RawDrawFrameTransparent(0, trans), so SetBackgroundFrame(1) is guaranteed to repaint the screen.

SSH

Why not have a fullscreen GUI on top of everything with your all-white BG and then change the GUI's transparency?
12

LeChuck

#3
Quote from: naltimari on Mon 14/04/2008 15:42:58
Hmm...  Why do you do RawRestoreScreen() if you do SetBackgroundFrame(1) right after? The RawRestoreScreen() seems pointless to me... maybe you should comment it and see what happens.

The manual says you should throw that function in there before the calling RawDrawFrameTransparent... Either way, if I comment it there's no change...

Quote from: naltimari on Mon 14/04/2008 15:42:58Anyway, I guess you shold also place the Wait(1) before RawDrawFrameTransparent(0, trans), so SetBackgroundFrame(1) is guaranteed to repaint the screen.

Tried this too, nothing new happens. It still does not fade the background the second time.


Quote from: SSH on Mon 14/04/2008 16:26:04
Why not have a fullscreen GUI on top of everything with your all-white BG and then change the GUI's transparency?

I've tried this with both an object and a GUI but it totally butchers a 2.4 ghz PC. The game's in 640x480 24 bit.

naltimari

#4
Be aware that mixing RawDraw's and SetBackgroundFrame's can be tricky. When you do SetBackgroundFrame(), you're actually changing the 'target' of the subsequent RawDraw's. I guess this is why it's working the first time.

Also, when you RawDraw something with an increasing transparency, like you did, you should restore the background to the original state in the next iteration, otherwise you'll be adding to the previous transparency.

Example:

The 1st iteration will draw the frame 0 with 99 transparency over background 1;
The 2nd iteration will draw the frame 0 with 98 transparency, right above the 99 transparency that was drawn on the last iteration;
The 3rd iteration will draw the frame 0 with 97 transparency, right above the 98 transparency, with was drawn above the 99 transparency;

and so on...

LeChuck

Quote from: naltimari on Mon 14/04/2008 19:32:14
Be aware that mixing RawDraw's and SetBackgroundFrame's can be tricky. When you do SetBackgroundFrame(), you're actually changing the 'target' of the subsequent RawDraw's. I guess this is why it's working the first time.

Also, when you RawDraw something with an increasing transparency, like you did, you should restore the background to the original state in the next iteration, otherwise you'll be adding to the previous transparency.

Example:

The 1st iteration will draw the frame 0 with 99 transparency over background 1;
The 2nd iteration will draw the frame 0 with 98 transparency, right above the 99 transparency that was drawed on the last iteration;
The 3rd iteration will draw the frame 0 with 97 transparency, right above the 98 transparency, with was drawn above the 99 transparency;

and so on...

How do I manually set the image in the background frame back to a spesific sprite? This is the problem, right? That the game is actually changing the original (white) background image?

naltimari

Quote from: LeChuck on Mon 14/04/2008 20:40:50
How do I manually set the image in the background frame back to a spesific sprite? This is the problem, right? That the game is actually changing the original (white) background image?

Maybe... There are lots of ways to restore the original frame back to its original state.

I would advise you to completely erase the 'flash' background, thus leaving only the original room background. Then, create a 10x10 white sprite, and import it into the sprite library. This tiny sprite can fill the whole screen, thanks to DynamicSprite's Resize() method, and can be drawn transparently, thanks to RawDrawImageTransparent().

I'm writing this without testing, so you may need to adjust it, but you should be able to understand the principle:

Code: ags


// script for Hotspot 6 (Hotspot 6): Use hotspot

// replace 'X' with the 10x10 sprite index from your sprite library
short tiny_white_sprite = X;

// create on-the-fly sprite from the 10x10 one
DynamicSprite* flash = DynamicSprite.CreateFromExistingSprite(tiny_white_sprite);

// resize sprite to fill the screen - you may need to adjust the size
flash.Resize(320,240);

// save the current screen in memory
RawSaveScreen();

int transp = 99;

while (transp > 0) {

  // paint the white sprite with transparency
  RawDrawImageTransparent(0, 0, flash, transp);

  Wait(1);

  // restore screen for the next iteration, or for the final step
  RawRestoreScreen();

  transp--;
}

flash.Delete();



The advantage in this approach is that you can use this effect in other rooms too, without need to replicate the background sprite, thus saving space in your final game.

Hope this helps,

LeChuck

#7
Quote from: naltimari on Mon 14/04/2008 21:34:44
Maybe... There are lots of ways to restore the original frame back to its original state.

I would advise you to completely erase the 'flash' background, thus leaving only the original room background. Then, create a 10x10 white sprite, and import it into the sprite library. This tiny sprite can fill the whole screen, thanks to DynamicSprite's Resize() method, and can be drawn transparently, thanks to RawDrawImageTransparent().

I'm writing this without testing, so you may need to adjust it, but you should be able to understand the principle:

Code: ags


// script for Hotspot 6 (Hotspot 6): Use hotspot



The advantage in this approach is that you can use this effect in other rooms too, without need to replicate the background sprite, thus saving space in your final game.

Hope this helps,

Well, yes and no. Yes it worked, and no I can't use it. It put too much strain on the CPU to do it. Thanks for all the help guys, I guess I'm gonna have to ditch the flashy thing and come up with something else. Consider this thread solved.

GarageGothic

#8
It sounds very strange that a full-screen GUI will slow down your computer. I have a 2.4 GHz P4 and experience absolutely no slowdown with such an effect. You should try updating your graphics drivers and DirectX.

However, as an alternate solution, have you tried using AGS's built-in fade function?

Code: ags
SetFadeColor(255, 255, 255);
FadeOut(64);
FadeIn(20);
SetFadeColor(0, 0, 0); //to return to default black fades


naltimari

Quote from: LeChuck on Wed 16/04/2008 04:36:06
Well, yes and no. Yes it worked, and no I can't use it. It put too much strain on the CPU to do it.

I remember that, not so long ago, I tried to see how the transparency effects were handled in 8-bit and 16-bit, compared to 24-bit, and I found that the performance was very different between the modes (8, 16 and 24).

Maybe you should also try to change the colour depth in your game, just to see if it affects the performance.

Also, please trim the quotes in your replies... remember this is a forum, not a mailing list, so we can always see the previous messages if we need to... :)

LeChuck

#10
Quote from: naltimari on Wed 16/04/2008 20:29:25

I remember that, not so long ago, I tried to see how the transparency effects were handled in 8-bit and 16-bit, compared to 24-bit, and I found that the performance was very different between the modes (8, 16 and 24).

Maybe you should also try to change the colour depth in your game, just to see if it affects the performance.

Also, please trim the quotes in your replies... remember this is a forum, not a mailing list, so we can always see the previous messages if we need to... :)

Seeing as how I converted from 16 bit to 32-bit by mistake somewhere along the road, a lot of my sprites are imported in the highest colour mode. If I try to run my game in 16 bit it will run, but a lot of sprites have a nasty tendency of just disappearing randomly from the screen (and never reappearing) when playing. Does this make sense at all?

naltimari

I guess this is (unfortunately) the way it is. I started at 16bit myself, and had to move up to 32bit because of alpha masking (only 32bit supports it), so I have sprites at 8, 16 and 32 bits... :P But as long as I run my game in 32bits, it seems everything is fine.

This would be less of a hassle if AGS had a 're-import sprites at game colour depth' feature. I guess it's on the near future, since the XML file keeps the path to every single sprite.

Well, it's up to you to decide if it's worth the trouble, but you could do some transparency tests on a fresh new game, since your CPU is relatively modern. Maybe it's an issue with your graphics driver.

SMF spam blocked by CleanTalk