PLUGIN: Snow/Rain 2.02

Started by Scorpiorus, Mon 03/02/2003 18:43:02

Previous topic - Next topic

Mehrdad

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 ?
My official site: http://www.pershaland.com/

Scorpiorus

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

Slasher

Anything that can be done to update this add-on would be great..

Weather .dll or module we are all waiting ;)

cheers

slasher


Mehrdad

It's will be great Scorpiorus if you can improve it for D3D . Another alternatives is nice but I love this one  ;)
My official site: http://www.pershaland.com/

Two Tales

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.

Scorpiorus

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

Crimson Wizard

#106
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 (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?

Crimson Wizard

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

Scorpiorus

#108
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

Code: ags

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

Crimson Wizard

#109
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?

Crimson Wizard

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

Scorpiorus

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...
Code: ags

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.

bx83

Scorpiorus, are you still working on this plugin? I would be happy to see it working in my game :P

Mehrdad

My official site: http://www.pershaland.com/

Scorpiorus

#114
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!

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.

Slasher

Hi

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

This is really 'what' we need and i hope you succeed (nod)

Crimson Wizard

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?

Mehrdad

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
My official site: http://www.pershaland.com/

Scorpiorus

#118
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!

Crimson Wizard

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

SMF spam blocked by CleanTalk