Light source
BlitzMax Forums/BlitzMax Beginners Area/Light source
| ||
| Hi all, I have read a bit about being able to use light sources in BMax in your games, I was just wondering how many light sources you can have before the games performance is noticably affected. And would like this to be running at a reasonable resolution ie (1024 x 768+) Any thoughts! |
| ||
| Ive Managed to Have 4000 64*64 Png Sprites Drawing to the screen in a mixture of Alpha/Light/Shade Modes And Each one is Moving on the Screen and 88000 commands to update every loop and still running at 58 fps Athlon 2500xp Winxp Pro 1028 DDR Pc2700 128 mb Radeon 9800 pro Note For some Reason its Better for me to use Manual Tiling Than TileImage LightBending And ShadeBlending Large images could Slow it down a fair Bit Not Sure How long it Takes To Swap Between Alpha/Light/Shade But Adding SetTransform on top of this will slow things but if you carefull with programming Shouldnt Be a Problem |
| ||
| Thanks for that Duckstab. I would be interested to see a screenie of what u achieved!! Regards |
| ||
  Just Some Messing About Getting used to commands And Blending |
| ||
| That is amazing ! |
| ||
| I Just Did a quick Test First Drawing 4000 Masked images 54 fps Then a Test Drawing 1333 Alpha 1333 Light 1333 Shade Still 54 Fps Next test was as above but added the Settransform Command to each image 48 Fps |
| ||
| They look wicked Duckstab[o]! :-) |
| ||
| Im quite new to all this, but will this still be the same if u were lighting up other objects/ backgrounds, so you can have lighting effects in your platform game for example! |
| ||
| yes When i did the Test With Alpha/Light/Shade they were layed so they overlap The Buffer is additive So Some Form of blending Happens With The Four Blend Modes Mask/Alpha/Light/Shade but if it is SolidBlend Then it will overrite all underlying pixels |
| ||
| They are lots of examples in the Bmax Sample Which use Different Types of Light and Shade Blending Have a peek at LightImage FilmClip RadialBlur Shadowimage |
| ||
| Wasn't the original question about light SOURCES, as in, real lights, not light mapping? |
| ||
| yep but unless he is going into opengl there isnt any option in bmax plus if a level is stored in tile format can figure your position and light blend or shade blend the tiles in question in a 2d game there is not any point in having real lightsource as it would need the 3rd coord to work and for people learning from scratch it will be hard to duplicate maybe when the 3d module is released the will be a better way to mock 3d lighting on the 2d perspective or if a fast method of drawimagerect is created then it would posible now sorry for any confusion Grovesy@ |
| ||
| I agree you would have to use direct OpenGL. You could simply, though, add a lightsource in front of the plane on which the 2D graphics are drawn, and it could move around like a spotlight. |
| ||
| do you have any examples you could post would like a look at getting to grips with that Opengl concept |
| ||
| What about using buffer masking to create a sense of light? Render everything at full bright, masking out the areas where lights don't exist. I don't see why you would need a third dimension for that. |
| ||
| The Only Problem is the perspective light Bmax is a single Plane no 3d depth You Could Give every image a fake depth and calc its 3d distance from a fake light and setcolor to lighten/darken faces But to do that you might as well draw everything to depth layers changing the color each time or drawing a lightblend/shadeblend inbetween each layer |
| ||
| I understand your point. But its 2d. You don't have to worry about depth layers. Think of the Zelda 3 Dungeons with Link's lantern. |
| ||
| Well, the 2D shapes that you see on-screen are still technically in full 3D. I think you have to set up surface normals in order to use the lights in OpenGL. For 2D it should be easy, since all surfaces are facing straight forward down the Z axis. I haven't experimented with lights yet so I don't know all the commands you need. I think you have to switch context to the matrix mode of the light or something. Then position it, and translate it to orient, or use some kind of `look at` function etc. One way I've seen some people do lights is they have a sideways scrolling tilemap game but made of polygons, and they'll have a little bit of `overhang` or depth of the surroundings which is modelled by adding some extra polygons to give depth - ie extrude the scenery through the z axis, then lights are placed in amongst the scene so that they are blocked by solid walls etc. The thing about light is this: There is a very intimate relationship between light and shadow. They are not really two separate things. Shadow is just the places where the light is less strong, and ideally when there is no light there is total shadow. If you then add a light, it will illuminate some of the scene and the parts it doesn't illuminate you can call shadows - they remain dark, but really they don't change or have any special treatment. If you start off with dark, things can only get lighter. The problem in BlitzMax or other languages is people generate their graphics in full color as if already lit, then they have to figure out not only how to make them lighter but also how to make them darker, to implement the shadow system. You can't have light without a sense of shadow. If the scene started off dark and just got lighter that would make things a lot easier. But that'd mean your textures ordinarily have to have a high-dynamic range, which is a pretty recent feature on high-end gfx cards. If all your images could be represented with all their color variations within the range of $000000 to $010101 in RGB values, then adding light would be as simple as multiplying those values by the light amount. You'd automatically have shadows with no extra work. You could at least do that on most systems with a two-color image but not with lots of colors without making it floating-point data. So most of our focus on `lighting` things is just as much on `darkening` things as well. It's pretty difficult to model the idea that without any light at all, there would be total darkness - total shadow. That's because light that we see in the world is reflected from bouncing off of objects. When we draw a texture or image we kind of build-in to it the quality that it has its own light, it is self-illuminating. All of our textures/images act as if they are already lit all the time. To model a system where you can only see something if it reflects some light which was transmitted from somewhere else, that's pretty complicated. I'm not quite sure how OpenGL would handle that, if it even has the ability to draw `dark` or `nighttime` scenes which can be then made a lot brighter. I guess that's what they need high-dynamic-range (lots of floating point accuracy) for. For the rest of us..... wellll.... gotta get clever about it ;-) I'm not too sure what OpenGL's `ambient` light adjustment does, whether that allows things to be naturally darkened. If things were being raytraced it'd be a different matter since things are only visible then if they reflect some light. The question is, how to make reflective images/textures in BlitzMax which have an inherant color quality (ie what frequencies they reflect) but no inherant level of illumination of their own. I guess you could just have a normal pre-lit texture and then use something like ShadeBlend which multiplies by values from 0 to 1, to darken it. But again, as soon as you get into darkening, you get into having to code shadow routines. What you really need is a light source whose influence can be drawn on an existing scene, which can interact with the source texture of each surface to do a calculation on it and make it the appropriate brightness. But it has to happen at the time the light strikes. Maybe a shader or something? Maybe we need a different way of representing images, not as pre-drawn pre-lit, but as `potential color` and reflectivity? |
   |