Naively doing what this describes could be a costly operation.
#Gamemaker studio 2 room speed code
Taking this apart, here's the code to go with the conjecture.ĭraw_set_blend_mode_ext(bm_src_alpha_sat,bm_src_color) Shading and multiple lights are not demonstrated here. Support for multiple lights requires two more surfaces, ideally the size of the view. In addition to these meager mathematical requirements: two surfaces of arbitrary size (512 x 512 pixels in this demo), two models of arbitrary complexity (~2400 triangles each in this demo), the willingness to draw your shadow casting sprites once for any number of lights. For a single light with a radius 256 pixels, no more than 11 adds and 11 multiplies are required for a scene of any complexity. Virtually no calculations are made in the GML interpreter. It's primary advantages are its simplicity, its scalability, and the fact that it is almost entirely executed on GPU hardware. This is a proof-of-concept demonstration of technology that could be used to build a high-speed raster-based shadow system. For now I'll be happy just to color the sprites correctly. It still might be practical, but it might also be a bit complicated. I can get around the problem, but not without breaking most of the things that make this fast.
#Gamemaker studio 2 room speed how to
Unfortunately, I haven't figured out how to shadow the shadow-casting sprites themselves without self-shadowing (making all of them unlit because they're each standing in their own shadow). The other thing that still needs to be addressed is the shading. The equation is simple enough, but visualizing it in my mind gives me difficulty. Amazingly, it worked perfectly the first time. I've never used that blend factor before, I only tried it out of desperation. It solved some strange blending problems I was having (and I still don't understand what the problem is). Right now I'm using bm_src_alpha_sat as one of my blend factors.
There are a lot of interesting effects you can get with this basic technique. I'm also still trying to figure out some blending options. I think it will improve over quality as well. I need to construct the filter a little differently. That's actually a reflection of sorts caused by some faulty UV mapping on my part. You can see a weird glitch on the left side (a few black lines). I've got it up and running, I just need to iron out some wrinkles in the rectangular-to-polar warp. I'll follow-up soon with details about how it can be done in Game Maker, and most importantly, how it's done quickly. Once we've done that, we apply the inverse polar coordinate transform and Ka-Powza! there's our radial point light source shadows. We can construct shadows from the shadow casters if we imagine them being wet paint that we've smeared downward. The warped light rays are axis-aligned and parallel. Notice anything interesting about the light rays? In the next image, we see what happens when we warp the image using a polar coordinates filter similar to the one in Photoshop. The letters F and X will be our shadow casters. In the first image, we see a scene with a point light source in middle, and some arrows indicating light rays radiating out in all directions. I won't be going into the exact implementation details just yet, but I'll do my best to explain how it works in simple visual terms.įirst observe a marvelously exploitable feature of the polar-to-rectangular transform. The raster-transform technique depends on three things: UV map warping, surfaces, and blend modes. The germ of the idea popped into my head last night as I lay in bed and by this afternoon it had borne its first fruit. I've been calling this the "raster-transform" technique, but "raster-warp-feedback" might be closer to the mark. It's all on the GPU hardware which makes it literally 100 times faster than the clunky range_finder system. It was clearly not the answer and that was the end of the raster-based shadow project. Two lights and 30 on-screen instances ran at a crushing 15 fps on a 2GHz CPU. The problem was the range_finder script is costly, and to get any kind of remotely decent quality required at least 360 calls per light (1 degree of angular precision). The idea was to cast 2D shadow volumes from point light sources using the contours of shadow casting sprites. That was work that came out of the initial development of the range_finder script. I mentioned it in my first shadow engine topic. I've finally figured out a way to do raster-based shadows at practical speeds. I had a major brainstorm last night for an entirely new shadow engine.
Not Another Idiotic Light and Shadow prototype!
0 kommentar(er)
