real-time 2d lighting

[Draco9898]

Hi, I have a new annoying question here :blink: I was wanting to implement a real-time 2-d lighting system...but I've only seen it done in C++ or Visual basic and they do it with per pixel calculations :blink: Is there a lightning fast way to do this inside PB? Or is it one of those things you'd have to access the buffer for? If so that'd be a neat feature

[kevin]

Well, I guess that depends on what you call lighting?.. Can you show us an example of what your referring to ?..

  Lighting/Shading will be possible,  in a ways, but i'm not sure how useful (if at all ) it would be form a serious real time perspective.

At this point, i don't want to let the cat out of the bag as to what rendering modes i've been thinking about (for a LONG LONG time), with the  coming changes to FX buffers you could handle large segments of  alpha/shading real time.  The more the CPU grunt the more you could do.

  While most things will be oriented towards images, I hope to include 'strip' versions also.   So you can pretty much blit all sort of crazy stuff yourself.

[Draco9898]

Hmmm you ever played diablo/ Diablo 2? something like that...then make light objects in the level that could produce different types of light, or have the player have a minimum light "circle" or radious around him....or you could do something like a light on,  lights gradually fade away and turn back on with a level object thing...the possiblities are very broad...

I found a good example that was made in game maker with buffers, I dunno how it works but:

http://ee.1asphost.com/Draco9898/dynamic.txt

Rename it to zip...and well you know..extract it and run it

[kevin]

Yeah nice example, but that's obviously 3D though.   Anyway, what I think their doing  is rendering the scene, then blending a light map over it.  

To simulate this, we'd need a gfx function to blend two images together and dump the pixels to the destination buffer..  The function would take pixels from the source buffer then alpha blend them with the second buffer and dump them out.

Of course, that means the user has to render the light maps themselves.   For example you'd have to render the flash/spots lights to the light map..   While it's doable, i wouldn't get your hopes up !.

[Draco9898]

Then there is of course my underwater speed problem :) I'd probably even want to make it so the water has lumonsity areas/pixels

or various other effects I see all the time done on (which by todays standards) are pretty much JUNK hardware..Such as heat-shimmers and stuff like that :)

[kevin]

Well, i'd say that most effects are a by product alpha .  Which is fine if your depending upon video hardware to do the processing.   But PB doesn't..    Ironically though CPU's are  fast enough to do some serious rendering in  system memory though and then blit it to video memory.   But you do loose some nice things like filtering..

 For effects like water, or any overlay.  We probably need some composite style blitting commands.  Where you can specify the sources and destination buffer and perhaps a mode.  You see this type of thing in modern (software render) demo's all the time  .

 How much you can blit is totally up to the system running it obviously.   Should be able to handle full screen masking at 640*480 and perhaps 800*600 in 32bit at a decent speed, even on low end PC's ..

[Draco9898]

let's see it then :) Just kidding...I know we dont have buffer commands yet :)

Now, a person couldn't write a DLL to do all this stuff could he/she?

[kevin]

Yeah, eventually we'll probably expose pointers to the image buffers so 3rd parties can write their own renderers in C/Asm or whatever floats their boat.   Obviously we can't do this until all the back end is finalized.