Adventure Game Studio | Forums

AGS Support => Modules, Plugins & Tools => Topic started by: Scorpiorus on Mon 03/02/2003 18:43:02

Title: PLUGIN: Snow/Rain 2.02
Post by: Scorpiorus on Mon 03/02/2003 18:43:02
AGS Snow/Rain plugin 2.02 (original version):

http://americangirlscouts.org/agsresources/AGS%20resources/plugins/ags_snowrain202.zip (supports AGS 3.4.1 - Beta 6 and above; also supports AGS 2.71 and AGS 2.72)

Many thanks to http://americangirlscouts.org/agsresources/ for hosting!



AGS Snow/Rain plugin 3.0.0 ALPHAs (work in progress):

Snow/Rain 3.0.0-ALPHA-2: unavailable at the moment, use v2.02 for now (ONLY supports AGS 3.4.0 - Patch 4, running in Direct3D 9 graphics mode!)

Size: ~2.1 MiB




ORIGINAL VERSION:

Snow/Rain plugin (version 2.02) released.

Update: The version 2.02 has been released. It should solve the problem with the plugin not working with AGS v2.71. This also means it requires AGS v2.71 or above in order to run properly.

I totally rebuilt it so all function names have been changed (sorry). What's new?
- Added rain;
- Improved snow/rain control;
- Added ability to animate snowflakes/raindrops;
- Added ability to set snow/rain transparency (HiColor only);

Note: Since version 2.02 the plugin does NOT require the alleg40.dll library anymore, so you can safely remove it from your game COMPILED folder in case you have upgraded to the latest version.

Some other notes:
You can set the wind speed for the rain but keep in mind that it doesn't rotate raindrop sprites (currently that's not supported), and you then have to change them manually with the srSetRainView() function.
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Vel on Mon 03/02/2003 18:53:15
GREAT!!!!!!!!!!!!!
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: AJA on Mon 03/02/2003 18:56:24
Wow... Finally! :D

I can't wait to test it... I'll give you some feedback once I've tested it... :)

-EDIT-

That's great!! Wow, I love it!! :D
I'll definately use this in my game! :D
Great job!!!
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: canavan on Tue 06/05/2003 12:50:52
Hi

First, I love the snow rain plugin... very nice looking. Question: When you distribute a finished game (and include the dlls with it,) do you have to specify to the user to put the dlls in his windows folder?

Also, I am interesed in checking out your parallex scrolling plugin also... but the link on the plugins page wont allow me to download it. Do you have another source for the zip?
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: on Tue 06/05/2003 13:48:03
thats bloody brilliant, and i've got just the spot for it!

woodz ;D
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Pumaman on Tue 06/05/2003 21:39:20
Quote from: canavan on Tue 06/05/2003 12:50:52
First, I love the snow rain plugin... very nice looking. Question: When you distribute a finished game (and include the dlls with it,) do you have to specify to the user to put the dlls in his windows folder?

No, the DLLs just need to be in the game folder.
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: canavan on Mon 12/05/2003 13:28:56
Does this only work with high color games, or 256 color also?
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Scorpiorus on Tue 13/05/2003 17:20:30
Quote
QuoteFirst, I love the snow rain plugin... very nice looking. Question: When you distribute a finished game (and include the dlls with it,) do you have to specify to the user to put the dlls in his windows folder?


No, the DLLs just need to be in the game folder.
Yep, the rule is simple enough: just keep both dlls in the same folder where the game .exe is.


QuoteDoes this only work with high color games, or 256 color also?
Well, it works for 256 colors game as well. However you wouldn't be able to use transparency effects.

-Cheers
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Archangel (aka SoupDragon) on Thu 15/05/2003 20:33:20
Wow, this is perfect! And now I get a chance to use that 1337 rain sound effect I've been saving >:)
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Pet Terry on Sun 18/05/2003 09:10:14
Hey great plug-in! One question:

I have this background
(http://invis.free.anonymizer.com/http://yks_kaks.tripod.com/bridge.png)
and I would like to have raindrops appear only inside the white rectangle. How can I do that? Maybe setting rain baseline?
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Scorpiorus on Sun 18/05/2003 14:37:36
I am afraid setting baselines do not help. If you set a low baseline just on the bottom white line it'll help a bit. But for left, right and upper lines it won't. The plugin dosn't support walkbehindes because of perfomance reasons. The only way to do what you what is to make four always-on GUIs representing each side of the border as the GUI is the only thing that is drawen over the rain/snow sprites.

-Cheers
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: on Sun 18/05/2003 23:00:59
Amazing Plug-in ! Scorpiorus, any chance this plug-in of yours will be updated to support 800x600 ?
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Scorpiorus on Mon 19/05/2003 09:53:01
Possibly, but keep in mind it could slow down a game a *LOT* (especially with transparencies turned on) so I would recommend you to use 640x480 instead.
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Scorpiorus on Tue 20/05/2003 16:08:49
Quote from: Synthetique on Tue 20/05/2003 15:05:19
can i use it only to be seen in a window..
Actually I think of adding a function allowing resizing and positioning of a window, the snow/rain runs in.
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: SSH on Tue 05/08/2003 16:50:03
I was trying to use the plugin to get a snowstorm effect. The trouble is, that for a snowstorm flakes need to start from one side rather than along the top. As it is, I get a snow storm in the top 100 pixels and the stuff underneath is clear...  :(

Unless I've missed something... any chance of adding an option like this?
Title: Re:AGS: SnowRain PlugIn [v2.01] fixed to work with AGS 2.6
Post by: Rui 'Trovatore' Pires on Sat 10/01/2004 07:44:13
Petteri already asked for this, but he could work around it better than I will be able to, since I need it for more complex layering.

Could we have it so we can change whether the rain is displayed on top of other things, whether they are GUIs or not? And even if we want the rain to fall over the GUI?
Title: Re:AGS: SnowRain PlugIn [v2.01] fixed to work with AGS 2.6
Post by: Scorpiorus on Sat 10/01/2004 14:00:37
I see what you are asking for and I'll implement that layer thingy for the next major release. Thank for the suggestion.
Title: Re: PLUGIN: SnowRain plugin
Post by: Hobbes on Sun 27/03/2005 22:00:36
I can't get this plugin to work.

In the past I was able to use this without a problem, but now my AGS does some very weird things...

The raindrops fall, but leave behind a transparant trail which does not disappear.

So, within thirty seconds my entire screen is one big whiteness.

Did this happen to anybody else?
Title: Re: PLUGIN: SnowRain plugin
Post by: Rui 'Trovatore' Pires on Tue 29/03/2005 11:41:47
That'll happen, methinks, unless you're using the most recent version of the plugin.
Title: Re: PLUGIN: SnowRain plugin
Post by: GarageGothic on Fri 01/04/2005 09:01:36
Now that this thread has been dug up again...

I've been playing around with the plugin, and I was wondering if it would be possible to add a "center of gravity" to the plugin. So that raindrops/snowflakes would fall towards a coordinate (on or off screen), instead of straight down, and then disappear when they reached it?
Title: Re: PLUGIN: SnowRain plugin
Post by: Scorpiorus on Sat 28/05/2005 15:46:26
I see what you're asking for. Currently, drops/flakes are seen through the standart camera. It's usually enough as most background images for AGS games are drawn in a similar perspective but there are exceptions (like a top-down view) or a free camera view (like in Alone in the Dark).
So, I thought about having a way to change the camera position/orientation for a future version.

EDIT:

p.s. Are you after some starfield simulation or what? :)
Title: Re: PLUGIN: SnowRain plugin
Post by: skw on Sat 11/06/2005 17:12:22
Hi, great plugin I must say!

Does it always works with both snow and rain, or can you choose between rain and snow? Let's say I want only the rain, but have foggiest idea about scripting. What should I do? ;)
Title: Re: PLUGIN: SnowRain plugin
Post by: Cyberion on Sun 12/06/2005 00:27:57
well you have script commands, which need to be run. Plugin has two seperate commands for snow and rain effect. Just check with the readme file.

And ya, Scorpiorus is an amazing coder ;)
Title: Re: PLUGIN: SnowRain plugin
Post by: GarageGothic on Mon 20/06/2005 12:15:24
Quote from: Scorpiorus on Sat 28/05/2005 15:46:26
I see what you're asking for. Currently, drops/flakes are seen through the standart camera. It's usually enough as most background images for AGS games are drawn in a similar perspective but there are exceptions (like a top-down view) or a free camera view (like in Alone in the Dark).
So, I thought about having a way to change the camera position/orientation for a future version.

EDIT:

p.s. Are you after some starfield simulation or what? :)

Sorry, I didn't notice this before now. Thanks for the reply Scorpiorus. Well, yeah, technically I suppose it would work like a starfield simulation :) except that scaling/rotation of raindrops would be a bitch, so I'm not really asking for that. In my case, I'd probably put the center of gravity well below the screen area itself, just to make it fit the perspective and avoid the "curtain" look that it sometime has now, falling straight down.
Title: Re: PLUGIN: SnowRain plugin
Post by: Jade on Wed 06/07/2005 09:10:22
Ehmmm...this plugin seems very interesting....but i've difficulties making it work in my game....

I've read the attached file with the instructions...but i dont know how to do the script in a certain room. :-[ Sorry if my question is banal...but i really need to put every rain/snow setting in the room script or what?

For examble...if i want to see begin to rain in a certain room....what main function i've to use?

EDIT: ignore the message above...i solved the problem myself...i've only another question:

If i put this script...

srChangeRainAmount(100); wait(50);
srChangeRainAmount(200); wait(50);
srChangeRainAmount(300); wait(50);


...inside the "if" where timer is expired, every time that rain change amount my game goes in cutscene mode for few seconds...why?

Oh...btw...this plugin is really awesome!  ;D
Title: Re:AGS: SnowRain PlugIn [v2.0]
Post by: Jade on Thu 07/07/2005 09:02:48
Quote from: Scorpiorus on Fri 16/05/2003 22:04:36
No, not for everyone drop. :) Actually if you would play a sound for every drop you don't hear much because of limited number of sound channels. But having a function that returns is there specified amount of drops have fallen could help to organize sounds. Like srIsDropsFallen(int amount) returns 1 if there is 'amount' of drops or less have fallen right now. So you could check it repeatedly to change the sound to play:

repreatedly_execute() {

if (srIsDropsFallen(30) )
Ã,  Ã, PlaySound(1); // for about 30 drops
}
else if (srIsDropsFallen(200) )
Ã,  Ã, PlaySound(2); // for about 200 drops
}
etc.

or maybe using an interval as usual: srIsDropsFallen(int min_amount, int max_amount). :P yep, that's probably better.


Hey Scopiorus....i was thinking to arrange the sounds effect testing the rain amount...

for example:

in my case i set rain amount randomly...so...i've this script:

int ran=random(400);
if (isTimerExpired(i)){
srChangeRainAmount(ran);
if (ran > 100) {
PlayAmbientSound(1, 6, 50,0,0);
}
if (ran > 200){
PlayAmbientSound(1,6,100,0,0);
}
if (ran > 300){
PlayAmbietSound(1,6,200,0,0);
}
settimer(1,1000);
}


In this way i got a nice and credible sound effect that only increase volume with the rain amount.Ã,  :)
Title: Re: PLUGIN: SnowRain plugin
Post by: Scorpiorus on Sun 11/09/2005 18:35:30
Quote from: Xarkh on Sat 11/06/2005 17:12:22Does it always works with both snow and rain, or can you choose between rain and snow? Let's say I want only the rain, but have foggiest idea about scripting. What should I do? ;)

You can have it only rain, snow or both at the same time -- there is different functions for rain and snow, look them up in the plugin reference file.

As for an example, the plugin demo game provides with some basic script code to make it work. You can comment out (remove) parts of it responsible for the snow, such as srSetSnowAmount(...) or srChangeSnowAmount(...).


Quote from: Jade on Wed 06/07/2005 09:10:22Sorry if my question is banal...but i really need to put every rain/snow setting in the room script or what?

For examble...if i want to see begin to rain in a certain room....what main function i've to use?
QuoteEDIT: ignore the message above...i solved the problem myself...

I'm glad you solved it; still to mention for anyone may having the same question: typically, you should invoke the initialization functions (such as srSetSnowView, srSetSnowTransparency, srSetSnowFallSpeed etc...) when game starts, that is within the body of the game_start() script function;
and whenever you are going to actually start snow/rain just call srSetSnowAmount or srChangeSnowAmount. You can of course change weather properties at anytime of game's running -- just invoke the init functions again whenever you need.


QuoteIf i put this script...

srChangeRainAmount(100); wait(50);
srChangeRainAmount(200); wait(50);
srChangeRainAmount(300); wait(50);


...inside the "if" where timer is expired, every time that rain change amount my game goes in cutscene mode for few seconds...why?

That's due to how Wait() works -- it actually blocks the script from executing further for the specified amount of time.

What you need is to restrain from using Wait() in that particular case, for example:

at the top of room (or global) script:
int weatherTimer = 15; // any number available within 1..20
int rainAmount = 0; // amount to begin with


room (or global) repeatedly execute:

if (IsTimerExpired(weatherTimer))
{
Ã,  Ã,  if (rainAmount < 300)
Ã,  Ã, {
Ã,  Ã,  Ã,  Ã,  rainAmount = rainAmount + 100;
Ã,  Ã,  Ã,  Ã,  srChangeRainAmount(rainAmount);
Ã,  Ã,  Ã,  Ã,  SetTimer(weatherTimer, 200);
Ã,  Ã, }
}


some event function (to start the timer ticking for the first time):
SetTimer(weatherTimer, 200);


Quotei was thinking to arrange the sounds effect testing the rain amount
Yeah, that should make it. :)
Title: Snow/Rain plugin not working
Post by: Trisk on Mon 21/11/2005 03:26:23
Does the Snow/Rain plugin no longer work with AGS 2.71 RC3? It looked great in 2.7, but now that I've ported up I can't see my rain anymore...?

Has anyone else had this problem?
Title: Re: Rain/Snow plugin does not work with AGS 2.71
Post by: SSH on Wed 18/01/2006 14:42:38
Yes, this is known. Scorpiorus will have to fix this and he's not aroudn at the moment. However, there is the SimpleSnow moudle by me (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24001) and Akumayos' weather module (http://www.adventuregamestudio.co.uk/yabb/index.php?topic=24419.msg304237#msg304237)
Title: Re: PLUGIN: SnowRain plugin v2.01
Post by: Scorpiorus on Sun 29/01/2006 00:04:20
Oops, seems like the plugin has some sort of a conflict with the new version of allegro that comes along with AGS 2.71, as I see. It's probably some special functionality I used that hadn't been available via the plugin API at the time I wrote it.

Sorry about that, I'll get it fixed (will probably manage to reduce its size a lot as well).
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Klytos on Thu 02/02/2006 23:54:06
Seems to work great now, well done. Thanks.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Sat 04/02/2006 06:29:12
No problem, thanks for letting me know that it works now.

Just want to point it out once more that the last version of plugin doesn't require the "alleg40.dll" file so you may safely remove it from your game's folder *unless*, of course, there is another plugin using that library.
Title: Rain & Snow plugin with latest beta
Post by: Radiant on Sun 19/03/2006 12:53:28
Using the R&S plugin with the current v2.72 beta produces a lot of warning messages like this one:

(in room 42): RawDrawImage: Sprite 155 colour depth 16-bit not same as background depth 32-bit

(where the background color depth is in fact 16-bit, just like everything else in the game).
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Sun 16/04/2006 18:49:33
I just tried the plugin's demo game (it uses 16bit sprites on a 16bit background) with the currently latest AGS v2.72 beta7 and it works fine.

Are you sure it is plugin-related? Because this kind of warning message is usually common for the RawDrawImage() ags script function. The plugin doesn't produce any warnings explicitly. It may be a result of calling into some plugin API function but I'm not quite sure it's the reason.

Don't you have a RawDrawImage call in your room 42 by any chance, do you?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Goldmund on Tue 06/06/2006 13:32:15
Are you still working on this?

I'd like to use this great plugin in my game, but are you planning to make it possible to set horizontal boundaries like you can do with vertical? It would be perfect, because using guis to cover "dry" areas makes it impossible for other animations to display correctly (they get covered with guis as well).
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Tue 13/06/2006 18:06:33
You mean some sort of a viewport functionality? Yeah, that definitely would be possible, and handy. I made a special version of the plugin for someone in the past to support that. It's kind of an unofficial one though, I doubt it's compatible with the latest version of AGS and I don't have the source code for that branched out version anymore.

I'll see about adding it into the official version, as time permits.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: tiagocorreia on Wed 14/06/2006 09:50:01
I've tried the plugin, and then I open the demo game included, but I got this error and testing the game. I thought the alegro.dll has not needed.

Before I got this illegal exception, I got an error saying that alleg40.dll has not found.

---------------------------
Illegal exception
---------------------------
An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x004341A6 ; program pointer is +9016, ACI version 2.72.915, gtags (0,0)

AGS cannot continue, this exception was fatal. Please note down the numbers above, remember what you were doing at the time and notify CJ on the Tech forum.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Gilbert on Wed 14/06/2006 10:12:22
Quote from: Scorpiorus on Mon 03/02/2003 18:43:02
A word about installation:
The plugin uses Allegro library which I included to zip file. To use the plugin you have to copy file alleg40.dll to your Windows folder. However I strongly recommened copy this file to the COMPILED folder of every game that uses SnowRain plugin because it must be included in the final game pack!

Did you read this?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: SSH on Wed 14/06/2006 10:44:03
Gilbert, did you read this:  ;) ::) :P

Quote from: Scorpiorus on Sat 04/02/2006 06:29:12
Just want to point it out once more that the last version of plugin doesn't require the "alleg40.dll" file so you may safely remove it from your game's folder *unless*, of course, there is another plugin using that library.

Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Gilbert on Wed 14/06/2006 10:51:41
Maybe he's still using V2.0 then?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: SSH on Wed 14/06/2006 11:41:22
Well since v2.0 doesnt work with 2.71 or later (and he's using the 2.72 beta) then he's buggered anyway
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: tiagocorreia on Wed 14/06/2006 14:10:35
I'm using version 2.72 latest beta. I've downloaded the plugin, yesterday, so I guess I'm using the latest version.

It must be a bug.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: SSH on Wed 14/06/2006 15:56:30
There are links to two different versions of the plugin in the top post, are you sure you got the newest one?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: tiagocorreia on Wed 14/06/2006 16:34:04
I've the latest version 2.02.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Wed 14/06/2006 19:58:28
Quote from: tiagocorreia on Wed 14/06/2006 09:50:01
Before I got this illegal exception, I got an error saying that alleg40.dll has not found.

An exception 0xC0000005 occured in ACWIN.EXE at EIP = 0x004341A6 ; program pointer is +9016, ACI version 2.72.915, gtags (0,0)

I believe you're using v2.0 then. The latest version of the plugin (v2.02) doesn't even have a link to "alleg40.dll" within its code.

I just tried both versions of the plugin (v2.0 and v.2.02) and I got exactly the same error message with plugin v2.0 running with AGS v2.72 RC1; because that won't work.

So make sure you have the version [2.02] ticked in the Plugin Manager dialog.

The version you need: http://www.geocities.com/scorpiorus82/ags_snowrain202.zip


Quote from: Scorpiorus on Mon 03/02/2003 18:43:02
A word about installation:
The plugin uses Allegro library which I included to zip file. To use the plugin you have to copy file alleg40.dll to your Windows folder. However I strongly recommened copy this file to the COMPILED folder of every game that uses SnowRain plugin because it must be included in the final game pack!

Gilbot, SSH:
I've just realized that may seem rather confusing as of AGS v2.71 (which is now official) and higher; so yeah I'll better remove it.

I also removed the second link to previous version, again to avoid any ambiguity. Still, if anyone needed it, the link is: http://www.geocities.com/scorpiorus82/ags_snowrain201.zip
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: tiagocorreia on Fri 16/06/2006 15:16:13
It works now.

I didn't realized that it didn't work on 800x600. So I'm not able to use it.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: SSH on Fri 16/06/2006 15:27:48
There are various modules for rain/snow effects that do work at 800x600, but they will be sloooow
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Janik on Fri 15/09/2006 05:08:38
May I ask why 800x600 is not supported by your plugin? On my computer, at 640x480 I get framerates > 200, so I would guess that even at 800x600 it would not significantly slow the game down.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Wed 15/11/2006 09:37:59
That's because 800x600 resolution was recently added in AGS at the time I was writting the plugin. I had Celeron 300A running at 375Mhz and it appeared to be rather slow back then. A mid system was 500-1000Mhz, I think, but still it was a bit too much to require a fast enough computer to play an adventure game using the plugin that otherwise would perfectly run on a 200Mhz system at decent speed.

Anyway, it's not much of a problem for now; may still require to address some issues regarding different room/viewport resolutions at different screen ones, though.
Title: Rain Plugin
Post by: Calin Leafshade on Wed 07/10/2009 15:29:22
Ive been playing around with the rain plugin and when a room loads the rain always starts to fall after the screen is loaded and so it always looks like its just started to rain.

Is there anyway of making the rain already coming down before the screen fades in?
Title: Re: Rain Plugin
Post by: Crimson Wizard on Wed 07/10/2009 15:40:28
Quote from: Calin Leafshade on Wed 07/10/2009 15:29:22
Ive been playing around with the rain plugin and when a room loads the rain always starts to fall after the screen is loaded and so it always looks like its just started to rain.

Is there anyway of making the rain already coming down before the screen fades in?

What about making instant room change and control fade out/in manually, giving rain a moment to "reach the ground"?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Calin Leafshade on Wed 07/10/2009 18:35:10
It seems the best way to do it is to start the rain at the very start of the game so its always falling and then alter the transparancey of it. Not sure if this makes much of a difference resource wise.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: abstauber on Thu 08/10/2009 08:19:45
Just in case you're using AGS 3, why not using this module:
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=36706.0
?

That way your game would also work with the linux port.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Calin Leafshade on Thu 08/10/2009 11:20:55
While i do like the way that module looks, the character is always on top of the particles.. which looks very odd for rain.

It does have an overlay feature but then transparancy isnt supported.

Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: abstauber on Thu 08/10/2009 13:44:49
Good point :)

Although the transparency limitation is sort AGS's fault  ::)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: TheJBurger on Sat 31/10/2009 21:27:07
Sorry to dig this up but does anyone have a mirror of version 2.02? The original link is broken.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Calin Leafshade on Sun 01/11/2009 09:26:06
check americangirlscouts.com

EDIT: sorry.. .org

http://www.americangirlscouts.org/agsresources/
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Romeo on Wed 16/06/2010 22:43:47

Hi, I really needed a snow plugin...so thanks for your great work

Cheers
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Icey on Sat 31/07/2010 13:30:16
can someone send me this plug-in please
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Calin Leafshade on Sat 31/07/2010 13:36:16
there is a link to a site which hosts the plugin 2 posts up
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: on Sun 31/10/2010 16:39:35
Great module, quick question - I'd like my rain to start about 100 pixels down from the top of the screen. How do I set that? Is it the SetBaseline part because I have only been able to block off where it falls too, not dictate where it falls from. Unless there's a way to make it fall behind a room object that is covering the top 100 pixels of the screen. Cheers.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: on Thu 04/11/2010 21:01:09
I'd still like my rain to fall 100 pixels from the top.

No? Is that not possible with this plugin?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Dualnames on Thu 04/11/2010 21:09:23
From the readme:

srSetRainBaseline(int top, int bottom);

Sets rain baselines (top and bottom ones). These baselines
determine the edges the rain falls between. Range [0..200].

EDIT:
srSetRainBaseline(100,System.ScreenHeight);


EDIT2: Sorry m0ds, didn't read your initial post. Stupid me. ::)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: cianty on Thu 04/11/2010 22:19:33
No, I don't think it's possible to do what Mods wants.

The function Dualnames mentions only defines the area in which the rain lands, i.e. it comes from the top and falls down to.. e.g. 180 and 200, thus defining an area of 20px height in which the rain falls.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: on Fri 05/11/2010 20:04:49
Bugger.

Thanks anyway  :=
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mati256 on Fri 31/12/2010 22:27:51
Does anyone have a working link for this?
Or can pint me to an easy rain module/plugin?
I tried to use SimpleRain and SnowRainPS but couldn´t work with them, maybe Im just stupid.  :-\
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Icey on Fri 31/12/2010 22:37:40
Click here (http://americangirlscouts.org/agsresources/AGS%20resources/plugins/ags_snowrain202.zip)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mati256 on Fri 31/12/2010 23:33:07
Thanks Icey, works like a charm.  ;D
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Icey on Sat 01/01/2011 00:22:48
no prob :)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Mon 27/02/2012 16:04:12
Hi

Sorry for coming up old topic

Isn't any way for using Snow/Rain plugin for D3D  or any another suggestion?

Mehrdad

Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Icey on Mon 27/02/2012 21:21:14
Can't really understand your question, Are you asking if it'll work with D3D or not? If so then I think it will work.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Tue 28/02/2012 06:41:06
Quote from: Icey games on Mon 27/02/2012 21:21:14
Are you asking if it'll work with D3D or not?

Yes
I read in forum this plugin doesnt work with D3D.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Icey on Tue 28/02/2012 10:46:47
Oh so it doesn't work, well I guess there's not much to say :/

Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Dualnames on Wed 29/02/2012 10:57:55
It doesn't work. If you want a rain/snow that's always in front of the player and supports individual transparency per flake/drop, then you really have to sacrifice stuff. I prefer to put the rain in a gui that simply plays an animation of frames/sprites and use particle effects for the rains falling on surfaces (ground, dripping) ecc.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Fri 25/05/2012 17:05:28
Ok

Good point.thanks a lot.although i think game goes to slow with use animation gui.correct?

edit: (combined double post)
Sorry again

But i need to this useful module on D3D.for Rain and dust.Is it possible to re-writing for Direct3D9? I tried GUI instead .As result wasnt any good at all.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: paolo on Sat 09/06/2012 17:01:00
A few questions about this module...

1. Does it work with AGS3.x? It's fine in 2.71 and 2.72 but when I ported my game to 3.0, AGS complained that the dll doesn't work. Does anyone have a version of the dll that works with 3.0, or is there something I need to do to get it to work?

2. Scorpiorus mentions that to change the rain view you need to use srSetRainView, but this is not discussed in his documentation nor does he say on here how to use it. It takes four integers as parameters - that's as much as I know. Does anyone know how to use this? Using srSetRainDefaultView sets the view once only and doesn't seem to allow you to change it.

3. Scorpiorus apparently hasn't been active here since 2009. Is anyone in contact with him in case I need to ask him directly?

Thanks everyone!
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: EchosofNezhyt on Sat 09/06/2012 19:48:51
Quote from: paolo on Sat 09/06/2012 17:01:00
A few questions about this module...

1. Does it work with AGS3.x? It's fine in 2.71 and 2.72 but when I ported my game to 3.0, AGS complained that the dll doesn't work. Does anyone have a version of the dll that works with 3.0, or is there something I need to do to get it to work?

2. Scorpiorus mentions that to change the rain view you need to use srSetRainView, but this is not discussed in his documentation nor does he say on here how to use it. It takes four integers as parameters - that's as much as I know. Does anyone know how to use this? Using srSetRainDefaultView sets the view once only and doesn't seem to allow you to change it.

3. Scorpiorus apparently hasn't been active here since 2009. Is anyone in contact with him in case I need to ask him directly?

Thanks everyone!


I got newest ags.

Works fine for me.

I just use
srSetRainFallSpeed(200, 300);
srChangeRainAmount(1500);
srSetRainBaseline(20, 200);
srSetRainTransparency(50, 90);
srSetRainDefaultView(9, 0); //view=3; loop=0;
srSetRainWindSpeed(0);


Title: Does Rain/Snow Plugin 2.02 allow Anti-Aliased Snow Sprite?
Post by: GMD1984 on Thu 06/02/2014 13:18:10
Hi, I've been testing around with a famous RainSnow plugin this morning.
And have using it in my game. Everything is pretty much controllable.

But I have one question about the snow sprite.
(https://pbs.twimg.com/media/Bfw3709CcAAX2gu.png)
It's quite jagged and lost its softness from alpha its channel.

I have checked the sprite, re-imported them with Alpha on. But, still. It's won't display properly with it own alpha.

Is there any option that I can config for this?

Thank you very much!

Edited by mod: Merged with appropriate topic
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Monsieur OUXX on Sat 08/02/2014 14:36:37
If I recall, this is a rather old plugin, and unless I'm mistaken (there are several rain and particles plugins/modules so it's easy to cinfuse them) this one is a bit outdated -- and does not handle alpha blending (except full transparency, of course).

You might want to look for a more recent particles plugin/module (e.g. akumayo's particles, or others...), and test to see if it manages alpha channel.
Unfortunately, I've done that research myself recently -- but since then, I completely forgot the outcome of my research.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Calin Leafshade on Sat 08/02/2014 15:04:11
The most recent version of the engine has alpha blending built in so the plugin is totally unneeded now.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Sat 08/02/2014 15:10:12
I recall there's a Snow/Rain module now (Wadjet Eye used it for Gemini Rue ports)?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Monsieur OUXX on Sat 08/02/2014 15:41:54
Quote from: Calin Leafshade on Sat 08/02/2014 15:04:11
The most recent version of the engine has alpha blending built in so the plugin is totally unneeded now.
Yes, that's what I thought. Yet, a module to tie all that together would be nice.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Silent Bob on Fri 16/05/2014 00:22:02
Hey, does anyone have a working Gemini-Rue-like Rain plugin for AGS 3.0 or higher? I spent hours on looking for something, but if there's still any working hyperlink with packed plugin - then the plugin doesn't work on AGS 3.3. ;/. I can't figure out how to implement this into a newest AGS version :cry:

Thanks in advance.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Fri 16/05/2014 12:22:19
Did you run game on Direct3D? It only work on direct draw
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: monkey0506 on Fri 16/05/2014 14:39:35
Quote from: Crimson Wizard on Sat 08/02/2014 15:10:12
I recall there's a Snow/Rain module now (Wadjet Eye used it for Gemini Rue ports)?

Sort of. I'll take a look and see if I still have it.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Silent Bob on Thu 29/05/2014 18:21:05
Does anyone have a working Snow/Rain module on AGS 3.3?

Thanks.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Priabudiman on Mon 09/03/2015 13:50:12
The given link are dead,

Anyone can help me with the latest version of this? or alternative for 3.3.3 ?

Thank you
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Mon 09/03/2015 14:10:11
Unfortunately this plugin doesn't work with direct 3D. It's only a alert for use it.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Priabudiman on Mon 09/03/2015 16:18:23
Quote from: Mehrdad on Mon 09/03/2015 14:10:11
Unfortunately this plugin doesn't work with direct 3D. It's only a alert for use it.

thank you so much for the answer, do you probably know an alternative way to create snow animations?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Tue 10/03/2015 08:20:43
Your welcome

You can make a large animation as GUI or object with alpha transparency and use it on room.This way is good but it's go to slow down for high resolutions

Also see this link:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=41448.msg547989#msg547989
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Dualnames on Tue 10/03/2015 10:31:04
Personally, for snow I'm using still frames, it looks pretty good.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Monsieur OUXX on Wed 18/03/2015 17:06:16
There's also this one that doesn't work too badly if I recall. http://www.adventuregamestudio.co.uk/forums/index.php?topic=26379.msg445079#msg445079
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: StillInThe90s on Wed 18/03/2015 20:08:15
Quote from: Mehrdad on Tue 10/03/2015 08:20:43
Also see this link:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=41448.msg547989#msg547989
I'm using this one with v3.2. It works in both DD & D3D.
Spoiler
It may lag a bit when skipping cutscenes but this seems to get rid of it:
Code (ags) Select
function repeatedly_execute_always()
{
    if (!Game.SkippingCutscene){ps.RenderParticles();}
}
[close]
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Monsieur OUXX on Thu 19/03/2015 09:07:26
Quote from: StillInThe90s on Wed 18/03/2015 20:08:15
Quote from: Mehrdad on Tue 10/03/2015 08:20:43
I'm using this one with v3.2. It works in both DD & D3D.
It may lag a bit when skipping cutscenes but this seems to get rid of it:
Code (ags) Select
function repeatedly_execute_always()
{
    if (!Game.SkippingCutscene){ps.RenderParticles();}
}

If you're talking about  SnowRainPS v0.5, then maybe you should post your tips into the thread of that module. ;)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: StillInThe90s on Thu 19/03/2015 16:28:03
I think I was talking about SnowRainPS v1.0, but I figured recommending it without mentioning the lag issue would be a bad idea.
Edit: There. Hidden. :-D
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Monsieur OUXX on Fri 20/03/2015 13:44:33
I meant SnowRainPS 1.0, not 0.5. My comment is still valid :) Share the SnowRainPS tricks in the SnowRainPS thread! :D
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: m0rph84 on Tue 17/01/2017 16:44:39
Hello,
anyone knows if this plugin still works with the last AGS release?

Thank you.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Mon 23/01/2017 06:18:04
It have to work . But only direct draw mode no Direct 3D.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Sun 05/02/2017 23:39:51
Alright, I keep mentioning this everywhere recently, but I guess here is a better place.

There is a portable version of plugin written by JJS several years ago. The code is open source:
https://github.com/adventuregamestudio/ags/tree/master/Plugins/ags_snowrain
It also fully compatible with original plugin in the terms of script commands, meaning it should be safe to replace plugin in your existing game.

I believe there is a chance it works with Direct3D and OpenGL. But this should be tested out.


EDIT: But I keep wondering, do you really need this functionality to be in a form of plugin, and not script module, for example? That should not be that hard to script falling sprites/particles around the screen. Or is it speed that is still an issue?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Nixxon on Wed 08/02/2017 06:15:11
Damn, looking for a working link of either Snow/Rain plugin or ParticleSystemPlugin.

Not sure what to do with the above link Crimson. Aren't all plugins dll files?

Cheers.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Wed 08/02/2017 07:29:20
Unfortunately I haven't knowledge programming for this link too and I can't make it as dll for test . I appreciate for any help ?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Mon 27/02/2017 19:21:09
Hello and...

Blimey! It's been 14 years now since the release of the snow/rain plugin version 2.0...

Can't believe people are still interested in using it in their new projects!

I am sure there is a lot of alternatives right now in a form of script modules or something.

And yep, DLL-plugins are known to have portability issues, effectively binding the game that uses them to "Windows-only".

One funny thing about the snow/rain plugin though, is that it had portability concerns from the very first day of its appearance but over a decade ago it was about not being able to build a DOS-version of the game, lol! Not even a Linux port of AGS was in question those days. Time flies by!

Now having said that I'm actually somewhat interested as to whether people do want a reincarnation of the plugin to support more recent versions of AGS?

Not sure if I still have the source codes of the original version (need to check my backups) but if I do, I could probably mock up a new version as a script module as time permits, unless there are serious technical difficulties to make it work in AGS script fast enough.


As for plugin's not supporting the Direct3D mode, well... if memory serves me right, the last time I checked it (but that was many years ago, I have to say) I remember I had a feeling it was something in AGS itself that prevented the plugin to work in Direct3D out of the box. I think I removed all the direct calls into Allegro library and only relied on the AGS Engine Plugin API instead.

Oh, and about the recreation of the snow/rain plugin by JJS. I'm really sorry that I didn't give him the sources of the original plugin. Could have saved tons of work. He actually asked me if I can share it, but by the time I read his message he had already coded the whole thing on his own...

Anyways, I can probably look into the Direct3D issue again if I can dig up the sources out of tons of backups I have... Of course if anyone is really interested.


~Cheers
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Slasher on Mon 27/02/2017 20:44:45
Anything that can be done to update this add-on would be great..

Weather .dll or module we are all waiting ;)

cheers

slasher

Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Tue 28/02/2017 06:16:10
It's will be great Scorpiorus if you can improve it for D3D . Another alternatives is nice but I love this one  ;)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Two Tales on Tue 28/02/2017 07:23:52
Quote from: slasher on Mon 27/02/2017 20:44:45
Anything that can be done to update this add-on would be great..

I agree.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Wed 01/03/2017 21:50:39
Ok guys, so I did some research on this and have semi-good news at the moment.

I've managed to find the plugin sources but only version 2.00 that requires Allegro DLL.

That's not a big deal to remove the dependency on the external Allegro DLL again. Apart from that the logical behavior of 2.00 vs 2.02 seems almost bit-by-bit identical to each other. That's important as I wanted to support previously released AGS games as well (say AGS engine version 2.72).

And I think Snow/Rain v2.01 was actually a fix to support AGS 2.60 (where some drawing optimizations were introduced aka Dirty Regions)

And 2.02 was a fix to work with AGS 2.71 where I think the internal AGS Allegro library was updated (but I'm not sure) and got in conflict with the external one used by the plugin. At that point the external dll was removed in the original 2.02 version of the plugin.

All in all, now I have the sources and can build a new version of the plugin to be very compatible with the old one! That's good.



Now to the Direct3D problem...

It looks like at the moment there is no support in the AGS Engine Plugin API for drawing operations by means of AGS Direct3D Driver.

So there is no a simple fix...

However... it is possible to use Direct3D directly :) calling low-level Direct3D9 functions from within the plugin to try and draw particles onto the screen.
But such an approach rises a number of serious concerns regarding cooperative use of the Direct3D device by the plugin and AGS.

Also, the AGS Direct3D Driver actually does quite a lot of stuff like checking video hardware capabilities and trying to adapt to specific setups any user may have.
The plugin then have to reproduce that behaviour to be consistent with what AGS D3D Driver already does.

A really fast and dirty trick I could try is just grab the AGS D3D Driver source code and put it inside the plugin to replicate the behavior.
This is not a good solution and may theoretically break the plugin again at any moment in the future versions of AGS.
Also if other video driver modes like OpenGL are introduced the plugin won't work with them and will need a new fix.

Oh well, little we can do as the AGS Engine API is rather old and was build around Allegro (DirectDraw) support from the beginning.
I believe CJ had no plans adding Direct3D support in that times, but the computer industry had its own visions and good-old Direct2D support or whatever started to break when newer kewl video cards and chipsets appeared on the market...



And as for the script module version of the plugin - that's a possibility but I tested the performance of drawing in AGS script and it is unfortunately much lower compared to the plugin. But maybe it's possible to optimize it a bit with prerendering or something. I'll see what I can do...



Ok, I think I'll try fixing the plugin to work in the Direct3D mode and than let you know how it goes.


~Cheers
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Wed 01/03/2017 22:11:09
Quote from: Scorpiorus on Wed 01/03/2017 21:50:39
Also if other video driver modes like OpenGL are introduced the plugin won't work with them and will need a new fix.
There already is OpenGL mode, just not officially supported for Windows engine yet.

But, perhaps I do not understand something, why do you need a direct access to the driver at all? What does this plugin do with it?
For example, plugin rewrite made by JJS (https://github.com/adventuregamestudio/ags/tree/master/Plugins/ags_snowrain) (we have its code in our repository) uses BlitSpriteTranslucent function from plugin API to draw particles on screen, regardless of driver type. Won't same thing work for you?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Wed 01/03/2017 22:29:07
Here, I uploaded a compiled plugin made by JJS:
http://www.mediafire.com/file/z3eiktzdjyulr31/ags_snowrain.dll

I tested it with Ben Jordan 8, which has rain in its main menu and some of the starting rooms, and it works with both DirectDraw and Direct3D.
EDIT: also tested OpenGL mode too just in case, and it works, so this function is really generic.

Not sure if it is completely identical by functionality and performance, but tbh I did not notice any difference.


Probably these rooms do not use plugin's rain, I need to do more tests.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Wed 01/03/2017 22:33:48
Ah, I tried BlitSpriteTranslucent() but it didn't work in Direct3D for some reason (nothing was drawn).

That would be ideal solution... I'll look into it further and let you know then, thanks!

EDIT:

Ok, unfortunately I can't download from mediafire but I've just compiled it from: https://github.com/adventuregamestudio/ags/tree/master/Plugins/ags_snowrain
But it didn't work in Direct3D here -- again no particles drawn (setting a quick test game and trying with ACI 3.4.0.14). DirectDraw mode works fine. That's rather odd...

EDIT:

Also, I've just found some strange lines in the master source regarding BlitSpriteTranslucent().

https://github.com/adventuregamestudio/ags/blob/master/Engine/plugin/agsplugin.cpp#L330


void IAGSEngine::BlitSpriteTranslucent(int32 x, int32 y, BITMAP *bmp, int32 trans) {
    set_trans_blender(0, 0, 0, trans);
    Common::Bitmap *ds = ::GetVirtualScreen();
    // FIXME: call corresponding Graphics Blit
draw_trans_sprite(ds->GetAllegroBitmap(), bmp, x, y);
}


At first glance it seems like it calls some allegro functions at the moment?






EDIT:
btw that's totally ridiculous but I've just found out that I definitely used BlitSpriteTranslucent() even in the original 2.02 version as well! ))))

https://www.adventuregamestudio.co.uk/forums/index.php?topic=10392.msg126247#msg126247
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Thu 02/03/2017 08:40:05
Maybe I did not use the proper test... I will check that again today.

Yes, you are right, this won't work with hardware-accelerated renderer like Direct3D or OpenGL, because they use different approach when drawing sprites on screen.
The rain I was seeing was probably made using different ways.

Alot of things in AGS still use allegro drawing when preparing bitmaps, even though later these bitmaps may be transformed into Direct3D/OpenGL textures.

I was thinking that maybe there could be a way to similarily create a drawing chain entry for Direct3D/OpenGL mode instead of using draw_trans_sprite directly in the BlitSpriteTranslucent. But I need to make sure I am using correct test first. Can you upload your test game somewhere?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Thu 02/03/2017 09:57:21
So, yes, it was rather engine's defect all this time, that it cannot process plugin commands properly in Direct3D mode.

Looking from the engine's viewpoint, I can see two solutions, or rather two ways to improve that may be complementary:

1) Make functions like BlitSpriteTranslucent (and all of their variants) work in Direct3D mode. Plugin can call them from any of its callbacks, which means engine would require a viewport-sized bitmap for each such callback, that would then be transformed into driver-dependent drawing chain entries and inserted into the render chain at corresponding z-orders.

This will work a lot slower than sprite drawing normally would with Direct3D, but at least ensure certain level of compatibility between renderers.

2) Add new plugin API for managing custom "screen sprite entities", that are created by passing bitmap, but internally converted into driver-dependant bitmaps, and could be told to be drawn at certain z-order (sprite layer) in the chain. In such case the transformation of raw bitmap into D3D texture will occur only at sprite creation, and therefore whole process will be much faster.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Thu 02/03/2017 21:10:42
Ah ok, I see. Thanks for looking into it and clarifying the problem.

Ironically, the snow/rain plugin, for instance, wouldn't work, even if BlitSpriteTranslucent() supported D3D drawing because it calls IAGSEngine::GetVirtualScreen() for no apparent reason (probably a leftover from the original "ags_template.cpp" example file), which triggers the "plugin doesn't support Direct3D driver" error message.

QuoteI was thinking that maybe there could be a way to similarily create a drawing chain entry for Direct3D/OpenGL mode instead of using draw_trans_sprite directly in the BlitSpriteTranslucent. But I need to make sure I am using correct test first. Can you upload your test game somewhere?
Unfortunately, I haven't saved that quick test game. I have a habit deleting them ASAP, otherwise I end up cluttering my AGS folder with "asdasdasds"-kind of projects.
But basically it was a simple AGS 3.4.0 Patch 2 "Default Game" template game with whatever version of the snow/rain plugin and the following code...

srSetSnowDefaultView(int view, int loop); // some roger walking view/loop or whatever
srSetSnowTransparency(50, 50); // ~50% opacity/transparency
srSetSnowAmount(1000); // set max number of flakes

... in room's "after fadein" event.

I actually use snow/rain's SnowDemo bundled with the plugin but that's only for AGS 2.72 tests (http://americangirlscouts.org/agsresources/AGS%20resources/plugins/ags_snowrain202.zip).

QuoteLooking from the engine's viewpoint, I can see two solutions, or rather two ways to improve that may be complementary:
Quote1) Make functions like BlitSpriteTranslucent (and all of their variants) work in Direct3D mode. Plugin can call them from any of its callbacks, which means engine would require a viewport-sized bitmap for each such callback, that would then be transformed into driver-dependent drawing chain entries and inserted into the render chain at corresponding z-orders.
This means, if I get it right, updating D3D texture buffer on-the-fly by uploading large bitmaps with already-"flattened" sprites on them for each callback every game loop into the video hardware?
We have several drawing callbacks, I don't really know how much slower that would be in terms of resulting Frames Per Second, since, yeah, video hardware likes having its resources nearby to perform at its best.

But the good thing with this is that it's a constant number of bitmaps no matter how many sprites/particles we draw and so, we won't hit the drawing-list/scene-graph limits on the max number of entries. This is a specific problem of particle system plugins that draw tons of little images. The snow/rain plugin, for instance, can draw up to 2000 sprites but that is an arbitrary limit.

So if it's not *too* slow, I think that would be the best compromise/compatibility solution for particle system (and other similar effects) plugins for the current moment.

Quote2) Add new plugin API for managing custom "screen sprite entities", that are created by passing bitmap, but internally converted into driver-dependant bitmaps, and could be told to be drawn at certain z-order (sprite layer) in the chain. In such case the transformation of raw bitmap into D3D texture will occur only at sprite creation, and therefore whole process will be much faster.
Yeah, that's more video hardware-friendly but also seems more envolved to implement as it requires some new special entities to add and new engine API functionality to expose and support in the future. TBH I'm not really sure about expanding the current version (AGS_PluginV2) of the engine API at all. And again for particle system plugins it should then support large amounts of objects (though probably sharing most of the graphics).



Ideally, it would be cool to draw and blit inside the video hardware with some special shader program (if possible/supported by HW) where even AGS script raw draw commands (not only for blitting images but also for drawing lines/rectangles/etc) could be passed to the shader program to perform. That's of course a lot of work and testing - I understand - and it's out of the question for the near future.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: bx83 on Sat 15/04/2017 12:35:02
Scorpiorus, are you still working on this plugin? I would be happy to see it working in my game :P
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Sat 15/04/2017 14:43:46
I want it too. Any news?
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-1
Post by: Scorpiorus on Sun 23/04/2017 03:06:43
Sorry guys, so here is the first ***very-ALPHA*** version of the Snow/Rain plugin to hopefully support Direct3D 9 mode to certain extent:

Snow/Rain 3.0.0-ALPHA-1: See first post for DOWNLOAD links! (https://www.adventuregamestudio.co.uk/forums/index.php?topic=25665.msg46317#msg46317)

For now, it runs only with AGS version 3.4.0 - Patch 4 and only in Direct3D 9 mode.
That's deliberate, to focus on testing the EXTREMELY hackish way of accessing the AGS D3D9 Driver.

I only tried running it on Windows 7 SP1 64-bit, so see if it works with other OS versions.

And if the plugin crashes, please let me know your Windows OS version and if it's 32 or 64-bit.

Good-old Snow/Rain Demo included to assist testing.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Slasher on Sun 23/04/2017 10:54:56
Hi

I'll give a try on win7 32-bit.

This is really 'what' we need and i hope you succeed (nod)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Sun 23/04/2017 13:40:59
Quote from: Scorpiorus on Sun 23/04/2017 03:06:43
Sorry guys, so here is the first ***very-ALPHA*** version of the Snow/Rain plugin to hopefully support Direct3D 9 mode to certain extent:

https://files.fm/u/fdtrv4tf (Snow/Rain plugin version 3.0.0-ALPHA-1), Size: ~2.1 MiB

For now, it runs only with AGS version 3.4.0 - Patch 4 and only in Direct3D 9 mode.
That's deliberate to focus on testing the EXTREMELY hackish way of accessing the AGS D3D9 Driver.

Does it still make sense to implement any of the engine solutions I've mentioned above?
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Mehrdad on Sun 23/04/2017 14:53:27
Quote from: Scorpiorus on Sun 23/04/2017 03:06:43
Sorry guys, so here is the first ***very-ALPHA*** version of the Snow/Rain plugin to hopefully support Direct3D 9 mode to certain extent:

https://files.fm/u/fdtrv4tf (Snow/Rain plugin version 3.0.0-ALPHA-1), Size: ~2.1 MiB

For now, it runs only with AGS version 3.4.0 - Patch 4 and only in Direct3D 9 mode.
That's deliberate to focus on testing the EXTREMELY hackish way of accessing the AGS D3D9 Driver.

I only tried running it on Windows 7 SP1 64-bit, so see if it works with other OS versions.

And if the plugin crashes, please let me know your Windows OS version and if it's 32 or 64-bit.

Good-old Snow/Rain Demo included to assist testing.

Thanks a lot . I have Win 10 and seems work perfect
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Sun 23/04/2017 16:17:18
Quote from: Crimson Wizard on Sun 23/04/2017 13:40:59
Does it still make sense to implement any of the engine solutions I've mentioned above?
Definitely! The current solution I used is rather tricky and is more meant for previous versions of AGS, but for future AGS versions it would be very important to switch to something native.
To be honest, I'm not even sure how the plugin would work with the upcoming AGS 3.4.1 since there is a lot of graphics handling changes in there. Not to count that the OpenGL mode may become officially supported in the future.

I'd also like to release the plugin source codes, but before I do that, I have to remove all the dirty hacks I used to get to the AGS engine graphics driver!

Quote from: Mehrdad on Sun 23/04/2017 14:53:27
Thanks a lot . I have Win 10 and seems work perfect
Good to know, thanks for testing it out!
I tried running it on Windows XP SP3 32-bit and it seems to work fine there too.


Meanwhile, I've made a couple of small fixes to the current ALPHA. But mainly changed the SnowRainDemo game to run in D3D9 mode by default:
Snow/Rain 3.0.0-ALPHA-2: See first post for DOWNLOAD links! (https://www.adventuregamestudio.co.uk/forums/index.php?topic=25665.msg46317#msg46317)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Sun 23/04/2017 16:25:56
Quote from: Scorpiorus on Sun 23/04/2017 16:17:18
To be honest, I'm not even sure how the plugin would work with the upcoming AGS 3.4.1 since there is a lot of graphics handling changes in there. Not to count that the OpenGL mode may become officially supported in the future.

My current plans on finilizing AGS 3.4.1 include:
- Implement a variant of plugin API's Blit* functions that will formally work with hardware accelerated renderers (something I mentioned above). (Not sure how fast that will work though)
- Possibly add OpenGL support to Windows. This is practically working, only needed polishing.

I cannot answer on your question about graphics handling, because I do not know what exactly your plugin does. The changes in 3.4.1 are not so about drawing, but rather about modifying mode at runtime.

TBH I have not thought whether plugins will be able to detect such events. It could be that we need to add plugin hooks for them.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Sun 23/04/2017 19:59:28
The plugin basically starts from the engine API instance and browses through engine internals, like objects' vtables and code, to try and find all the required functions and data needed to perform drawing.
It can stand minor code changes or EXE-image re-basing (like ASLR - Address Space Layout Randomization) to a certain degree but of course will eventually fail as more and more code changes are made.
Again, its main purpose was to support previous set of AGS versions so that I wouldn't have to hardcode it for every single version of the engine that has been released.
My original idea was to only unlock plugin support for each new AGS version after I've thoroughly tested that plugin works with it correctly, and use standard AGS engine API Blit-family functions as a fallback (meaning nothing will actually be drawn until it's fixed).

So, while technically it is possible to keep the plugin working with even newer versions of AGS and still using such tricks, I'd better switch to something officially supported as soon as possible, and I'm really glad you are considering fixing Blit functions for 3.4.1 -- and to be honest that's what I was hopping for, since, yeah, changing graphic modes at run-time is a significant change and I'm sharing your concerns regarding the need to notify plugins somehow (as they may have their own resources allocated separately from the AGS graphics lists/caches, etc).


Oh, and I always wanted to say that before...

Crimson Wizard, I'd like to thank you for all the hard work, time and effort you dedicate to support AGS Community! And of course all other AGS developers contributing to it to keep AGS a wonderful game creation system! You've been doing a great work! Thanks!
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Tue 02/05/2017 15:44:38
Quote from: Scorpiorus on Sun 23/04/2017 19:59:28
The plugin basically starts from the engine API instance and browses through engine internals, like objects' vtables and code, to try and find all the required functions and data needed to perform drawing.

I found that when the plugin's onEvent callback is called for rendering stage, the first parameter is the event type, and the second parameter is a pointer to IDirect3DDevice9 interface.

Unfortunately, the callback argument is 32-bit integer, so that won't work if engine is compiled as 64-bit program.

EDIT: regarding the solution I am doing. I researched this a bit more, and plugin callbacks are already structured better than I initially thought.
When AGS creates a drawing list it pushes special items there, which indicate a plugin event. When it does all the rendering, and meets such item, it calls plugin callback instead.

Therefore, there seem to be no need to keep and manage bitmaps for every possible stage, but only one bitmap of a size of virtual screen. Interestingly, D3D and OpenGL renderers also have a dummy bitmap called "virtual screen", but I could not find yet what is it for (probably to make sure game don't crash).

Anyway, I am now trying to let plugins draw upon this "virtual screen" bitmap even if that's Direct3D running. Then, after callback, I am creating D3D texture from this bitmap and render it right away.
I've got results, but messy results, because apparently there is no direct way to know whether plugin has drawn anything on it. I guess we could try to set a flag whenever one of the drawing API functions is called (like GetVirtualScreen, BlitSpriteTranslucent, and so on).

As for the speed, it seems okay. I do not think this will be slower than software drawing anyway.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Tue 02/05/2017 20:51:06
Quote from: Crimson Wizard on Tue 02/05/2017 15:44:38
I found that when the plugin's onEvent callback is called for rendering stage, the first parameter is the event type, and the second parameter is a pointer to IDirect3DDevice9 interface. Unfortunately, the callback argument is 32-bit integer, so that won't work if engine is compiled as 64-bit program.
And another practical issue with using the IDirect3DDevice9 interface directly by plugins is that plugins then may have to create their own texture resources. And since AGS introduces an abstract concept/layer of DriverDependantBitmap where with Direct3D9, for instance, it may actually be represented by several tiled textures of specific format (current internal implementation and hence is always a subject to change), plugins should carefully manage their own textures to be consistent with the engine's strategy and method of drawing. At the very least repeating engine's work on checking video hardware capabilities (like texture size, format, etc...) and, probably, even applying similar workarounds if necessary.
Otherwise, a game may fail to run on certain video hardware because of some Direct3D plugin, but would work perfectly in Direct3D mode without that plugin.
Also, things like AGS FlipScreen()-enabled rendering etc... may be a problem to support at such a low level.

QuoteI researched this a bit more, and plugin callbacks are already structured better than I initially thought.
When AGS creates a drawing list it pushes special items there, which indicate a plugin event. When it does all the rendering, and meets such item, it calls plugin callback instead.
Yeah, and I actually abused that NullSpriteCallback entry from within the plugin as a point from which to make a bunch of extra calls into private D3DGraphicsDriver::_renderSprite() to draw particles.

QuoteI've got results, but messy results, because apparently there is no direct way to know whether plugin has drawn anything on it. I guess we could try to set a flag whenever one of the drawing API functions is called (like GetVirtualScreen, BlitSpriteTranslucent, and so on).

As for the speed, it seems okay. I do not think this will be slower than software drawing anyway.
Would be really great if the speed is acceptable, and yeah some sort of a flag to optimize things seems like a good idea.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Fri 05/05/2017 18:12:16
So, this is a build I was testing with your snowy/rainy room game: http://www.mediafire.com/file/hu8qntvzm0ofzod/acwin--d3dplugindrawing.zip
Branch: https://github.com/ivan-mogilko/ags-refactoring/tree/improv--d3dpluginblit

Traditionally, two news, good and bad one:
1) It works.
2) Software renderer draws everything to the same bitmap, composing a "flattened" image, therefore translucent sprites are blending with actual scene behind them.
But D3D has to pass separate bitmap to plugin. I could not figure what to do with that fact yet.
If I simply zero the bitmap, it will be opaque black with correct snow/rain on top, but room cannot be seen.
If I mark it as having alpha layer, room is seen, but rain will be completely invisible too, because plugin draws 16-bit sprites without alpha (I guess?).
So for now, to at least see the effect, I was filling bitmap with magic pink. This makes it transparent to see the room behind it, but caused those translucent sprites to blend with pink...

Any ideas?
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Sat 06/05/2017 19:36:33
Hmm... It seems like by painting sprites onto that transparent intermediate helper bitmap we would lose translucency levels of sprites (trans param) specified when calling several IAGSEngine::BlitSpriteTranslucent() for a single screen frame anyway.
And to save translucency info for each painted sprite (fur further blitting by GPU) we'd have to embed translucency (on a per-pixel-basis) into that intermediate bitmap data as alpha values?...
...because getting an alpha channel info from the original sprites won't help much, since it's a static translucency but IAGSEngine::BlitSpriteTranslucent() can be used to draw the same sprite multiple times with different trans values?

I'd like to look into it but I don't have the AGS Engine 3.4.1 build ready at the moment (simple build command doesn't work anymore since the external libs were separated from the AGS branch and I'd have to add them back to build the engine). I'll see if I can do it.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Sat 06/05/2017 19:57:12
Quote from: Scorpiorus on Sat 06/05/2017 19:36:33
Hmm... It seems like by painting sprites onto that transparent intermediate helper bitmap we would lose translucency levels of sprites (trans param) specified when calling several IAGSEngine::BlitSpriteTranslucent() for a single screen frame anyway.
Not sure if I understand what you are saying correctly. To elaborate, multiple BlitSpriteTranslucent calls done during same event callback will draw upon same bitmap. But that bitmap will be cleared before each next callback.

I was thinking that maybe plugin could detect bitmap format, and draw alpha sprites if its 32-bit (or detect hardware-accelerated renderer, if there is such method). On engine side it will just mark this surface as having alpha layer, which would blend over rest of the room correctly.
Could not it be solved that way?

Quote from: Scorpiorus on Sat 06/05/2017 19:36:33
I'd like to look into it but I don't have the AGS Engine 3.4.1 build ready at the moment (simple build command doesn't work anymore since the external libs were separated from the AGS branch and I'd have to add them back to build the engine). I'll see if I can do it.
I have the collection of prebuilt libraries, if that may help:
https://www.dropbox.com/s/4p6nw6waqwat6co/ags-prebuilt-libs.zip?dl=0
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Sat 06/05/2017 20:51:08
Quote from: Crimson Wizard on Sat 06/05/2017 19:57:12Not sure if I understand what you are saying correctly. To elaborate, multiple BlitSpriteTranslucent calls done during same event callback will draw upon same bitmap. But that bitmap will be cleared before each next callback.
Yeah, what I mean is that since we don't have the access to the current "background" screen image at the moment of calling into BlitSpriteTranslucent() and hence can't blend sprites with the "background" immediately, we should instead prepare and pass translucency info for the GPU to blend the entire intermediate bitmap later (when the control returns to the engine from the plugin draw event).
And because it's a single flattened bitmap holding all the drawn sprites on it (with *different*, still virtual, trans levels), the only possible way(?) to mark translucency for each of the bitmap's area where a sprite is located seems to be adjusting the alpha channel data of the entire bitmap accordingly?

QuoteI was thinking that maybe plugin could detect bitmap format, and draw alpha sprites if its 32-bit (or detect hardware-accelerated renderer, if there is such method). On engine side it will just mark this surface as having alpha layer, which would blend over rest of the room correctly.
Yep, but then it would use a predefined static translucency from the sprite. Where BlitSpriteTranslucent() allows to specify a different trans factor for each of its call on the same sprite.

QuoteI have the collection of prebuilt libraries, if that may help:
https://www.dropbox.com/s/4p6nw6waqwat6co/ags-prebuilt-libs.zip?dl=0
Should save me quite some time! Thanks a bunch!
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Mon 08/05/2017 21:08:29
Ok, I did some research on this and it seems that preparing a 32-bit alpha-translucent overlay bitmap (_stageVirtualScreen) is not as simple as I thought at first.
The main issue is that, indeed, unlike with Allegro/DX5 blending, we don't have the background scene image and because of that cannot do blending in an incremental additive way (i.e. starting from the background).
And if multiple overlapping sprites are blended with the overlay bitmap (_stageVirtualScreen), it is not clear how (if at all practically possible) to do it correctly.
It is possible to accumulate their blending with each other, but I am not quite sure how difficult (including performance concerns) it would be to calculate _stageVirtualScreen's alpha values to represent the "final" alpha-translucency that would consider trans contribution of each overlapping sprite, because:

B - background scene image color, [0..255]
S1,S2,S3 - colors of 3 overlapping sprites/pixels, [0..255]
a1,a2,a3 - alpha values of 3 overlapping sprites/pixels, [0..255]
A1 is a shortcut for (255 - a1)
A2 is a shortcut for (255 - a2)
A3 is a shortcut for (255 - a3)
Res - result scene color, [0..255]
ALPHA - what we'd need to write into _stageVirtualScreen

in a classic way it would be:

Res = (((B*A1 + S1*a1)/255 * A2 + S2*a2)/255 * A3 + S3*a3)/255;

but since 'B' is unknown, we'd have transformed it into:

Res = B*(A1*A2*A3)/(255^3) + SomeKnownColor(S1,S2,S3,a1,a2,a3);

Next (A1*A2*A3)/(255^3) is (255-ALPHA)/255 (aka background scene opacity factor) that the GPU would calculate from ALPHA, to blend _stageVirtualScreen with the background scene;

So, ALPHA = 255 - (A1*A2*A3) / (255^2), is what should go into _stageVirtualScreen alpha component... it seems :p

And then in general:
ALPHA = 255 - (A1*A2*A3*...*An) / (255^[n-1]), where n - total number of overlapping sprites for the current pixel.

I'm not sure how to do it in a single pass... And if it's at all the correct way of doing this...


And here is a simple custom Allegro blend function that DOESN'T follow anything from above, so it won't work correctly with overlapping translucent sprites:
Code (CPP) Select

unsigned long custom_blender_func_b32( unsigned long x, unsigned long y, unsigned long n )
{
    // From Allegro 4.4.2 manual:
    // x - blending modifier color;
    // y - base color to be modified;
    // n - (aka 'a') interpolation factor is in the range [0-255] and controls the solidity of the blending;

    // From Allegro 4.4.2 manual:
    // When a translucent drawing function is used (ex: draw_trans_sprite),
    // x is the color of the source,
    // y is the color of the bitmap being drawn onto,
    // n is the alpha level that was passed to the function that sets the blending mode
    // (the RGB triplet that was passed to that function is not taken into account).
   
    // TODO: revise implementation! Check Endianness!
    // using 'n' as a temporary to construct a new background pixel color
    n = n << 24;               // move Alpha to highest byte
    n = n | (x & 0x00FFFFFF);  // get sprite pixel color but don't use its Alpha component if any
    return n;                  // return new background pixel color
}

unsigned long custom_blender_func_STUB( unsigned long x, unsigned long y, unsigned long n )
{
    //return y;
    return 0xFFFFFFFF;
}


And adjusted IAGSEngine::BlitSpriteTranslucent():
Code (CPP) Select

void IAGSEngine::BlitSpriteTranslucent(int32 x, int32 y, BITMAP *bmp, int32 trans)
{
    Bitmap *ds = gfxDriver->GetMemoryBackBuffer();
   
    // Hardware-accelerated graphics driver:
    if (HARDWARE_ACCELERATED_GRAPHICS_DRIVER && ALL_BITMAPS_ARE_32BIT && _stageVirtualScreen_and_its_HW_BITMAP_SUPPORT_ALPHA_CHANNEL)
    //if (bitmap_color_depth(ds->GetAllegroBitmap())==32)
    {
        set_blender_mode_ex(
            custom_blender_func_STUB,  // 15-bit (same color depth)
            custom_blender_func_STUB,  // 16-bit (same color depth)
            custom_blender_func_STUB,  // 24-bit (same color depth)
            custom_blender_func_b32,   // 32-bit (same color depth)
            custom_blender_func_STUB,  // 15-bit (different color depth)
            custom_blender_func_STUB,  // 16-bit (different color depth)
            custom_blender_func_STUB,  // 24-bit (different color depth)
            0, 0, 0, trans);
       
        draw_trans_sprite(ds->GetAllegroBitmap(), bmp, x, y); // TODO: use other blit func?
    }
    else // Allegro/DX5 graphics driver:
    {
        set_trans_blender(0, 0, 0, trans);
        // FIXME: call corresponding Graphics Blit
        draw_trans_sprite(ds->GetAllegroBitmap(), bmp, x, y);
    }
}


So, the above code assumes that VideoMemoryGraphicsDriver::DoNullSpriteCallback() calls CreateDDBFromBitmap() and UpdateDDBFromBitmap() with hasAlpha = true.

Unfortunately, even such simple blend implementation is much slower compared to the Allegro/DX5 AGS graphics driver.
Ah well... that's what we get for not following GPU's pipeline. But still, as a compatibility solution it's not that bad.

I'll see if I can come up with something else regarding the issue...
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Mon 08/05/2017 23:21:32
I am afraid I cannot follow everything you say right now. But I can add a small note regarding allegro alpha blending. That is true that Allegro functions discard source alpha, and that is why AGS uses its own alpha blending functions. CJ started implementing them, and I improved this to introduce true alpha blending for GUIs and DrawingSurface.

You may find this function in blender.h/cpp files, it is called "_argb2argb_blender".

Ofc. it IS slower than Allegro's blender, also because it does more job.

Alternative variant to what we are currently doing is, perhaps inserting a new drawing entry every time something like BlitSpriteTranslucent is called (instead of flattening it to one big bitmap) and let driver do cumulative blending as it see fit.

But if we are to go that way, I'd rather introduce explicit plugin API for actual hardware-accelerated render support. Because there are still API functions that are practically impossible to simulate, like Get/SetVirtualScreen.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Tue 09/05/2017 01:00:36
To be honest, I wanted to suggest implementing plugin API blit functions compatibility mode to use driver's rendering functions instead. Because emulating flattened sprites with different translucencies by hacking them into _stageVirtualScreen's alpha channel seems too involved.

A specialized Engine API to manage drawing in a new way is a good idea too, since you removed the hard limit on the max number of drawing list entries in 3.4.1, but it would still be neat to support the original drawing functions such as DrawText(), DrawTextWrapped(), BlitBitmap(), BlitSpriteTranslucent() and BlitSpriteRotated() to work in hardware accelerated mode.
Maybe it's worth re-stating them to support only drawing to screen and if plugin tries to redirect drawing with SetVirtualScreen() just abort with error.

And even further, I don't know if there are any plugins working with allegro bitmaps in some specific way, but personally I always treated BITMAP* just like a pointer to pass around.
Doh! It even happened to me where I didn't notice to have it declared as Windows BITMAP* or something, and it worked and compiled since I didn't care of its internals but was passing pointer values :)
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Tue 09/05/2017 01:24:22
Quote from: Scorpiorus on Tue 09/05/2017 01:00:36
To be honest, I wanted to suggest implementing plugin API blit functions compatibility mode to use driver's rendering functions instead. Because emulating flattened sprites with different translucencies by hacking them into _stageVirtualScreen's alpha channel seems too involved.
Can you elaborate on how to do this?
OTOH you could even do pull request to my experiment branch, if you can figure how to make that work.

E: Or, do you mean same thing as I suggested as alternative?
Quote
Alternative variant to what we are currently doing is, perhaps inserting a new drawing entry every time something like BlitSpriteTranslucent is called (instead of flattening it to one big bitmap) and let driver do cumulative blending as it see fit.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Tue 09/05/2017 01:39:01
Quote from: Crimson Wizard on Tue 09/05/2017 01:24:22E: Or, do you mean same thing as I suggested as alternative?
Ah, yeah. Probably adding/inserting new entries to draw may be too late since we are in the rendering phase already but calling _renderSprite() just-in-time, like I do in the snow/rain plugin should work, I think.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Tue 09/05/2017 01:50:35
Quote from: Scorpiorus on Tue 09/05/2017 01:39:01
Quote from: Crimson Wizard on Tue 09/05/2017 01:24:22E: Or, do you mean same thing as I suggested as alternative?
Ah, yeah. Probably adding/inserting new entries to draw may be too late since we are in the rendering phase already but calling _renderSprite() just-in-time, like I do in the snow/rain plugin should work, I think.
I think either way might be possible with some work; currently I am substituting one bitmap right before _renderSprite get called, but I guess that would be possible to insert more, since there is a std::vector for draw entries now.

I guess the choice depends mostly on how that would be more convenient code wise. AFAIK _renderSprite is called after some variables are calculated, and these variables are local, thus calling it from external function may be problematic without larger code changes.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Scorpiorus on Tue 09/05/2017 02:12:45
I'm not sure what is a common implementation of std::vector. It seems like it could be a plain array. Then insertion may take some time. And I'm going to try and draw 10k particles as a test for the plugin since it will be HW-accelerated. But, I don't think it will be too much of a performance hit with even std::vector anyway...

Quote from: Crimson Wizard on Tue 09/05/2017 01:50:35AFAIK _renderSprite is called after some variables are calculated, and these variables are local, thus calling it from external function may be problematic without larger code changes.
Well, I'm just calling it with NullSpriteEntry substituted with my bitmap. Seems to work. But then again maybe it only seems so...
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Tue 09/05/2017 02:18:49
Quote from: Scorpiorus on Tue 09/05/2017 02:12:45
Well, I'm just calling it with NullSpriteEntry substituted with my bitmap. Seems to work. But then again maybe it only seems so...

Ok, I checked more, there seem to be just some global flip settings. I do not remember how they work, but they could be made class members for this purpose.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Tue 09/05/2017 02:28:22
Yeah, IIRC the flip params come from some global settings and I wanted to support them in the snow/rain plugin for AGS 3.4.0. But for now I just pass them as "no v/h flip".
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Tue 09/05/2017 03:26:13
Something that I am still wondering about, if you call _renderSprite 10k times, how do you manage 10k driver-dependent bitmap creations? Or are you reusing only one? or do something else?
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Tue 09/05/2017 13:43:27
Yep, like I mentioned before it is a very specific thing with particle systems, i.e. drawing tons of little images but in fact using just several (driver dependent) bitmaps as a source.
I don't allow drawing 10k instances of a particle in the plugin (only 2k max, at the moment), but I just thought that if it will be HW-accelerated I could probably increase the limit.

Using std::vector is perfectly fine if we are going to add elements to its end, but inserting them, especially one by one, would trigger copying the whole thing on the "right" each time we do it.
Another "bad" thing with std::vector is that it may well decide to reallocate its internal stuff to some other memory address (say, when we add new elements and it runs out of reserved space at its back), and then we can end up with dangling pointers if we had them pointing to vector's elements. I'm not sure maybe this is not a problem for us if we just pass element's addresses to _renderSprite() and don't resize the std::vector within that function.

EDIT:

So, it seems like flattening-bitmaps-to-scene-overlay approach has its own advantages here, where the engine doesn't have to care how to store/handle bitmaps passed via some plugin API Blit function.
The irony here, is that, practically, the bitmap passed to plugin Blit functions most likely was acquired with IAGSEngine::GetSpriteGraphic() and hence already loaded in sprite cache and may even have a device dependent representation ready to render. But since it's passed as an Allegro BITMAP all ties are lost and the engine has to deal with it as with some totally new entity (though, of course, this actually may very well be the case if it's some custom bitmap prepared by plugin).
And therefore there are, again, certain complexities of whether the engine should somehow try caching bitmaps passed via plugin blit functions, to use the same device dependent bitmaps and doesn't have to create new/destroy old DDB every single time...
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Wed 10/05/2017 18:35:32
Getting back to the flattened bitmaps idea... If it were possible to implement translucency more or less suitable, could we count on _stageVirtualScreen supporting 8-bit alpha channel (ARGB mode) with hardware accelerated drivers?

I noticed that the old snow/rain demo game (which is 16-bit color) runs in 32-bit color mode with the AGS Direct3D 9 driver.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Wed 10/05/2017 19:41:12
I made it so it sets 32-bit display mode by default, and converts game to that mode, otherwise 16-bit bitmaps were loosing 1 bit of green color (there is no suitable texture format for R5G6B5).
OpenGL driver did that since its created.

Direct3D and OpenGL can now run even 8-bit games, converting them to 32-bit ARGB, except it does support palette cycling.

I left "downgrade to 16-bit" option in the engine, but IDK if that is ever comes useful. That could be removed too. Guess it was mainly for software renderer.

I was thinking that maybe there is already a suitable blender function in the engine, because I remember writing few, for blitting opaque sprite without alpha on surface with alpha and vice versa.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Thu 11/05/2017 00:50:35
Ok, I see... Thanks for clarifying.

I will definitely look into your blender function implementations to grasp some ideas or even get ready-to-use code.
But I suspect, however, that we may still encounter certain specific issues and need to write some special code to handle them.

And this is because we "don't know" the background scene image!

What the engine must be able to do, to correctly process plugin's blitting/drawing commands for a single flattening stage:

- blit opaque sprites (with fully-transparent areas, aka pink color) onto stage bitmap
- draw translucent (i.e. semi-transparent) sprites onto stage bitmap
- draw translucent sprites over other opaque sprites onto stage bitmap (i.e. overlapping)
- draw translucent sprites over other translucent sprites onto the same stage bitmap
- blit opaque sprites over already drawn mix of opaque and translucent sprites onto the same stage bitmap
- etc...

~ each drawing operation of translucent sprite can have its very own translucency/opaqueness level (i.e. IAGSEngine::BlitSpriteTranslucent() 'trans' param)
~ all of this must be done without knowing background scene image colors


Relying on the ideas from all of my ramble before the currently planned implementation is as follows:

All the source sprites to draw onto the stage bitmap are considered without their alpha channel (if any). That's how, I believe, the original DX5 plugin draw functions behave. (This may be somehow reconsidered and we can even try adding at least rough alpha blend support? Though this seems out of the scope of providing Allegro/DX5-drawing-compatibility...)

Since we have a single stage bitmap that later will be rendered by GPU over the current background scene image in one step, we "pass" all the different values of 'trans' param into GPU by simply writing them into stage bitmap's alpha channel.

When flattening each new overlapping translucent sprite into the stage bitmap we blend its RGB components with the stage bitmap's ones according to 'trans' param, but also adjust stage bitmap's alpha area accordingly to specify how that new mix should blend with the unknown background scene image.

If we blit opaque sprite onto stage bitmap, that already have some alpha translucency (and colors) there, we must not only blit the sprite over it but also set stage bitmap's alpha values to 255 in that area (because blitted opaque sprite should not somehow get translucency of previously drawn and now overpainted sprites "under" it).


A common scenario of preparing a stage bitmap for further rendering by GPU is this:

- clear stage bitmap (ARGB: A8R8G8B8) to color 0xFFFF00FF (i.e. Fully-transparent Pink which has an additional special meaning of "stage bitmap here is empty"; and Alpha=255 as an initial trick to try support blitting fully-opaque sprites off-hand!)
- set a special flag to indicate that not a single translucent sprite has been drawn yet
- pass control to plugin
- plugin calls draw commands and blits fully-opaque sprites (they still may have fully-transparent pinks, that's ok)
- plugin draws first translucent sprite somewhere
- stage bitmap's alpha values in that area are adjusted accordingly
- a special flag now indicates that some translucent sprite has just been drawn, meaning that we can't simply blit opaque sprite around anymore, without filling stage bitmap Alpha areas, where we are going to blit the opaque sprite, with 255)
- when we draw some translucent sprite over the stage bitmap, the blender function that does this, specifically checks stage bitmap's color there...
- if it's Pink (i.e. stage bitmap is empty here), translucent sprite pixel color just overwrites the pink without blending with it, and Alpha value is simply set to 'trans' value of translucent sprite;
- if it's not Pink (something is already there), translucent sprite pixel color blends with that color according to 'trans' param and the new mix gets written back into stage bitmap pixel...
- ...but also, the current Alpha value is retrieved from the stage bitmap, gets remixed with 'trans' param, and new alpha gets written back into stage bitmap to define the new blending proportion between the mixed thing in the stage bitmap pixel and unknown background scene beneath it.
- eventually, plugin finishes with drawing its sprites and passes control back to the engine to render the stage bitmap!


I'll try to come up with some, at least partially, working code as time permits. Since I already did some tests before...
Unfortunelty, I'm not yet ready doing it via git, but since it's new stuff mostly, there shouldn't be a problem to just copy and paste it into experiment branch...

Also, I may have missed something... so any questions, suggestions, corrections or any other feedback is welcome!
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Thu 11/05/2017 01:33:42
I must apologize, because being very busy with other things I cannot dedicate myself to this task. So I could easily miss something from your explanations.

I was wondering if not knowing underlying pixels at this stage is such a big deal. There must be a way to draw translucent images on this stage bitmap, which should have alpha channel already. If that is achieved, then rest seems to be GPU's problem.

I just wanted to point you to the function called DrawSpriteBlend. It is used for GUI and DrawingSurface. This function gets custom alpha as a "translucency" parameter to whole operation, thus seems to be very similar to what plugin's Blit function does.
It also chooses blender from the list of AGS blenders suitable for this particular situation (both bitmaps has alpha, or only one of them).
Hopefully that may give implementation ideas.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Thu 11/05/2017 20:10:41
Ah, that's great! I didn't realize there is a blender ready to work with translucent destination surfaces that also supports external "trans" param...
Thanks for pointing me to it. Otherwise I would have spent my weekend reimplementing the wheel!

I didn't look into your blender's implementation details yet, but at first glance this, indeed, seems what we need. At least the dest alpha recalculation formula looks familiar.

As to why I keep emphasizing on unknown background image, because I think normally when we're composing a scene starting from the background image, we just blend and forget, so to say, i.e. calculating new color mix and flattening it into background. But with this approach (destination with alpha channel) we have to not only mix RGB values but also constantly retreive and recalculate the dest bitmap alpha values again and again on drawing each new trans sprite above. Which I believe may be unnecessary slower composing a screen scene with software rendering methods, especially, since we got image color components as some fixed 8-bit integers (and not floating points).

EDIT:

Ok, just did a quick test with the AGS engine, replacing BlitSpriteTranslucent's internals with the DrawSpriteBlend() function and the snow/rain plugin seems to work fine! Still needs proper testing though.

EDIT:

Also, I'm going to check the IAGSEngine::BlitSpriteRotated() func to see if it works in our compatibility mode and how hard it would be to fix it if it doesn't...
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Tue 16/05/2017 22:37:19
So, I was looking into how plugin compatibility drawing mode works with different plugin drawing functions and that's what I've got:

void DrawText(int x, int y, int font, int color, char *text);
void DrawTextWrapped(int x, int y, int width, int font, int color, const char *text);
void BlitSpriteRotated(int x, int y, BITMAP *spr, int angle);

These three functions seem to work with the Direct3D 9 Graphics Driver as well as with the Allegro/DX5 Graphics Driver.




void BlitBitmap(int x, int y, BITMAP *bmp, int masked);

Also works, but the "masked" flag has no effect in Direct3D 9 mode (transparent 0x00FF00FF pixels are always skipped).
With masked=0 sprites are blitted onto _stageVirtualScreen correctly, i.e. with PINKs included, but at a later moment stageVirtualScreen's texture gets PINKs replaced with ALPHA=0 anyway...
Not a big deal, but the behavior is different comparing to the Allegro/DX5 Graphics Driver.
And I'm not sure if there is an easy way to fix this without messing with hardware-accelerated driver implementations...




void BlitSpriteTranslucent(int x, int y, BITMAP *spr, int trans);

Seems to work with alpha-blending support enabled (i.e. VideoMemoryGraphicsDriver::DoNullSpriteCallback should pass hasAlpha=true when preparing DDB), and with the following implementation of BlitSpriteTranslucent (EDIT: doesn't work correctly with the Allegro/DX5 Graphics Driver in 32-bit color mode!):
Code (cpp) Select

#include "gfx/gfx_util.h" // GfxUtil::DrawSpriteBlend()

void IAGSEngine::BlitSpriteTranslucent(int32 x, int32 y, BITMAP *bmp, int32 trans)
{
    GfxUtil::DrawSpriteBlend(gfxDriver->GetMemoryBackBuffer(), Point(x,y), &Bitmap(bmp,true), kBlendMode_Alpha, true, false, trans);
}


With Allegro/DX5 graphics driver, however, it doesn't work as before when drawing 8-bit color sprites onto 16-bit color background. It draws opaque sprites regardless of "trans" (aka alpha) value.
DrawSpriteBlend() calls DrawSpriteWithTransparency() and 8-bit color sprite is promoted to 16-bit color there, to match background color format.
But after conversion is done, "ds->Blit(&hctemp, x, y, kBitmap_Transparency);" is invoked thus ignoring "alpha" param passed into DrawSpriteWithTransparency:

https://github.com/adventuregamestudio/ags/blob/release-3.4.0/Engine/gfx/gfx_util.cpp#L143

To fix it work as it used to be, the "ds->Blit(&hctemp, x, y, kBitmap_Transparency);" line could probably be replaced with something like:
Code (cpp) Select

        if (alpha < 0xFF && surface_depth > 8)
        {
            set_trans_blender(0, 0, 0, alpha);
            ds->TransBlendBlt(&hctemp, x, y);
        }
        else
        {
            ds->Blit(&hctemp, x, y, kBitmap_Transparency);
        }




And I'm sorry for posting code snippets here instead of committing/pull-requesting into experimental git branches. Still going to set up git at some point...
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Fri 26/05/2017 13:04:03
I believe I could add the base changes to 3.4.1 release, and someone (you or me, or other person) will be able to provide patches to it as time goes.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Fri 26/05/2017 23:42:51
Would you mind including the changes I proposed in my previous post?
That should cover most cases where compatibility drawing mode would work correctly, as far as I can say.

And kind of nitpicking, the thing I noticed with VideoMemoryGraphicsDriver's destructor -- which virtually overrides GraphicsDriverBase/IGraphicsDriver destructor -- it's not marked as "virtual" whereas in other places AGS code follows a common practice to mark all virtually overriding functions with "virtual" (i.e. with "overrides" meaning).

https://github.com/ivan-mogilko/ags-refactoring/blob/improv--d3dpluginblit/Engine/gfx/gfxdriverbase.h#L123
https://github.com/ivan-mogilko/ags-refactoring/blob/improv--d3dpluginblit/Engine/gfx/graphicsdriver.h#L124
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Fri 26/05/2017 23:46:32
Quote from: Scorpiorus on Fri 26/05/2017 23:42:51
Would you mind including the changes I proposed in my previous post?
That should cover most cases where compatibility drawing mode would work correctly, as far as I can say.

Yes, certainly.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Thu 08/06/2017 06:17:08
The discussed changes are in the new 3.4.1 beta: http://www.adventuregamestudio.co.uk/forums/index.php?topic=54681.msg636562780#msg636562780
Please check if I added your suggestions right.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Fri 09/06/2017 00:05:49
Yep, everything seems in place, thanks.

But I've given it a proper test now and just realized that translucent blitting doesn't work correctly in Allegro/Software mode at 32-bit color.
This is my omission where I only checked 16-bit color mode (because the Snow/Rain plugin demo game, which I was using, is 16-bit color).

The problem is that unlike the stage bitmap, the virtual screen (background) bitmap's alpha component must be 0xFF (not 0x00).
I don't know if it's worth the hassle to try forcing it to 0xFF, so that GfxUtil::DrawSpriteBlend (using _rgb2argb_blender) would be suitable for software graphics mode too.


And the alternative solution is this:

I really tried to avoid checking for graphic modes within IAGSEngine::BlitSpriteTranslucent and liked how it seemed to work with DrawSpriteBlend only, but looks like it may need a conditional there...

Code (cpp) Select

void IAGSEngine::BlitSpriteTranslucent(int32 x, int32 y, BITMAP *bmp, int32 trans) {
    Bitmap wrap(bmp, true);
    if (USING_SOFTWARE_RENDERER)
    // TODO: only works if string pooling is enabled; find a better way to check for Graphics Driver fast enough?
    //if (gfxDriver->GetDriverID()=="DX5") // pointer comparison
    //if (gfxDriver->GetDriverID()=="Software") // pointer comparison
        GfxUtil::DrawSpriteWithTransparency(gfxDriver->GetMemoryBackBuffer(), &wrap, x, y, trans);
    else
        GfxUtil::DrawSpriteBlend(gfxDriver->GetMemoryBackBuffer(), Point(x,y), &wrap, kBlendMode_Alpha, true, false, trans);
}


I don't know if we a have a fast and reliable way of checking for current graphics driver.
What I have noticed though, is that "DX5" changed to "Software" in AGS 3.4.1 Beta 5. Which looks neat but may theoretically break some plugins that already rely on the "DX5" ID name.


EDIT:

By the way, how feasible would it be to include the Snow/Rain plugin sources into the AGS Engine, provided I'm doing it myself?

I checked JJS's recreation and it now works with recent changes too. But it seems there are problems with certain screen resolutions where snow/rain covers only half of the screen (checked with the snow/rain demo game). And the overall behavior is a little bit different from the original version.
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Fri 09/06/2017 17:30:28
Quote from: Scorpiorus on Fri 09/06/2017 00:05:49
And the alternative solution is this:

I really tried to avoid checking for graphic modes within IAGSEngine::BlitSpriteTranslucent and liked how it seemed to work with DrawSpriteBlend only, but looks like it may need a conditional there...

I don't know if we a have a fast and reliable way of checking for current graphics driver.

You can use gfxDriver->UsesMemoryBackBuffer. This effectively means that the buffer you draw upon already has room drawn on it. If even that will be too slow, then cache its value in a boolean variable in plugin system (something like "DrawingSurfaceHasAlpha"). Graphics renderer is only created once during single engine run, so that could be done at startup.

BTW, this reminds me, I thought plugin drawing is very similar to the one of DrawingSurface. Perhaps they may be merged somehow.


Quote from: Scorpiorus on Fri 09/06/2017 00:05:49
By the way, how feasible would it be to include the Snow/Rain plugin sources into the AGS Engine, provided I'm doing it myself?
Do you mean include plugin sources into repository or in the engine itself as a feature?

There are several plugins there already, so I guess it won't be an issue if you swap JJS variant with yours.
Personally, I did not like it very much that we keep those plugins in same repository though. They were there mostly because we were statically linking them with engine for mobile ports. Perhaps there could be way to move them out and include as submodules... but that's not relevant to current situation.
Title: Re: PLUGIN: Snow/Rain 3.0.0-ALPHA-2
Post by: Scorpiorus on Mon 12/06/2017 20:02:39
Quote from: Crimson Wizard on Fri 09/06/2017 17:30:28You can use gfxDriver->UsesMemoryBackBuffer.

Ah, ok. So, hopefully, the final version of IAGSEngine::BlitSpriteTranslucent should look something like this:

Code (cpp) Select

void IAGSEngine::BlitSpriteTranslucent(int32 x, int32 y, BITMAP *bmp, int32 trans) {
    Bitmap wrap(bmp, true);
    if (gfxDriver->UsesMemoryBackBuffer())
        GfxUtil::DrawSpriteWithTransparency(gfxDriver->GetMemoryBackBuffer(), &wrap, x, y, trans);
    else
        GfxUtil::DrawSpriteBlend(gfxDriver->GetMemoryBackBuffer(), Point(x,y), &wrap, kBlendMode_Alpha, true, false, trans);
}



QuoteBTW, this reminds me, I thought plugin drawing is very similar to the one of DrawingSurface. Perhaps they may be merged somehow.
Very well may be. I haven't yet looked into it, though.
Many of the plugin API drawing functions need some refactoring anyway (such as BlitSpriteRotated calling Allegro's rotate_sprite directly, etc...). That should be addressed at some point I believe.

QuoteDo you mean include plugin sources into repository or in the engine itself as a feature?
I mean repository, yeah.
There is some code related to the plugins in the engine, though (for static linking or providing stubs, etc...). I'm not yet sure if it needs to be altered for including/replacing the snow/rain plugin.
And I thoroughly support the idea of moving plugin sources to their own place eventually.



So, what's about the "Software" graphics driver ID name replacing "DX5"? Should we change it to "Software" once and for all?
I'm checking for "DX5" in the current ALPHA version of the snow/rain plugin, but I can workaround it no problem and check for both depending on the version of AGS.
Still I don't known if there are other plugins relying on "DX5" ID...

EDIT: Also, "DX5" is mentioned multiple times on the AGS Engine Plugins page:
http://www.adventuregamestudio.co.uk/site/ags/plugins/engine/
Title: Re: PLUGIN: Snow/Rain plugin v2.02
Post by: Crimson Wizard on Mon 12/06/2017 20:47:18
Quote from: Scorpiorus on Mon 12/06/2017 20:02:39
So, what's about the "Software" graphics driver ID name replacing "DX5"? Should we change it to "Software" once and for all?
I'm checking for "DX5" in the current ALPHA version of the snow/rain plugin, but I can workaround it no problem and check for both depending on the version of AGS.
Still I don't known if there are other plugins replying on "DX5" ID...

TBH when I made decision to change it to "software" I did not think about plugins. But, to my knowledge only few plugins are actively used over years, and most popular are either open source or rewritten to make them portable.
Even if such incompatibility will be uncovered, it may be fixed with a config switch, similar to the fake "OS type" switch we made earlier for games & plugins that relied on OS id for some reason.
Title: Re: PLUGIN: Snow/Rain 2.02
Post by: rocifier on Sun 20/08/2017 02:00:04
Hi :) what's the status of this plugin with 3.4.1?
Title: Re: PLUGIN: Snow/Rain 2.02
Post by: Crimson Wizard on Sun 20/08/2017 03:55:51
Quote from: rocifier on Sun 20/08/2017 02:00:04
Hi :) what's the status of this plugin with 3.4.1?

The first link in the first post sais "supports AGS 2.71, AGS 2.72, AGS 3.4.1 - Beta 6 and above". I think that's the version I was testing, and it should be working with all 3 graphic renderers in 3.4.1.
There is a newer version of plugin which supports Direct3D in a hackish way, as Scorpiorus mentioned above, but I think it is not needed now that 3.4.1 engine is fixed to work with original plugin.
Title: Re: PLUGIN: Snow/Rain 2.02
Post by: on Sat 25/11/2017 14:16:57
Seems to be working well with 3.4.1 ......... in directX mode! Wonderful. Well done Scorpiorus, thank you! And CW for engine update to help it.
Title: Re: PLUGIN: Snow/Rain 2.02
Post by: Crimson Wizard on Mon 27/11/2017 15:28:32
I would like to clarify something: does this plugin check for display mode colour depth or game's native colour depth (in game structure parameters)?

I am asking, because I am currently considering forcing Software renderer to work in 32-bit mode in case of 16-bit game too, as one of options to solve the issue described here (http://www.adventuregamestudio.co.uk/forums/index.php?topic=54681.msg636575835#msg636575835). And also because 16-bit mode does not work well on modern systems / with modern gfx drivers (for example, with 16-bit games it does not refresh window on my computer anymore).
Title: Re: PLUGIN: Snow/Rain 2.02
Post by: Scorpiorus on Sat 02/12/2017 16:06:59
Quote from: MJL on Sat 25/11/2017 14:16:57Seems to be working well with 3.4.1 ......... in directX mode! Wonderful. Well done Scorpiorus, thank you! And CW for engine update to help it.
Good to know m0ds, thanks for testing it out!

Quote from: Crimson Wizard on Mon 27/11/2017 15:28:32I would like to clarify something: does this plugin check for display mode colour depth or game's native colour depth (in game structure parameters)?
The plugin reads the colour depth value, but it doesn't do anything with it, so it should be fine.

Anyway, feel free to do any adjustments to the engine necessary. In the end, I can always update the plugin to conform with them.
I'm still planning to release the plugin sources at some point :p



One thing that bugs me is that since AGS 3.0.0 the original plugin keeps moving particles when some deep-blocking function, such as Display(), is invoked.
The problem is that the plugin uses the rendering event to both MOVE and DRAW particles.
In pre-3.0 versions of AGS, the engine wasn't redrawing the screen when inside deep inner blocking loop (and hence it didn't call plugin render events).
The plugin uses the IsGamePaused() function to check if it needs to MOVE particles. But now that only works with game-pausing GUIs, etc.
One solution would be to make the AGS engine's IsGamePaused() return 1 when inside Display() and other similar functions. But I can see it's quite a hassle to implement.
From the plugin point of view, I'm not sure if we have a suitable plugin event, from where I could call the MOVE code only (I haven't yet checked it out though).