A Flash Developer Resource Site

Results 1 to 10 of 10

Thread: [AS3] Fast, full-screen, touch-every-pixel updating.

Threaded View

  1. #8
    Senior Member rachil0's Avatar
    Join Date
    Jul 2007
    Location
    Columbus, OH.
    Posts
    465
    After some more work on this doom-clone, I'd like to share more progress... this thread seemed like as good of a place as any.

    Although 256 color palette images that the last code generated looked pretty good, I found a decent way to extend this into "almost true-color" quality. The trick is to add an additional layer that acts as a lighting map. It's another 8-bit (0-255) byteArray image that is generated alongside the regular framebuffer. Every time a pixel is written an (x,y) position in the framebuffer, a lightmap-pixel is written into the lighting map at the same location(x,y) There's basically no work spent computing a new offset, it's always adjacent to the framebuffer pixel.

    Furthermore, the doom rasterization algorithm always writes a bunch of pixels with the same projection distance (z-value?) at the same time. That is, columns of consecutive pixels are filled with wall texture are inside a single function call, and rows of consecutive pixels are filled floor texture are drawn inside a single function call. In both of these cases, these pixels are all at the same projection distance from the camera. So if you make your lighting model only depend upon projection distance, you don't need per-pixel recomputation of lighting level, because it's constant for the whole span. This is how doom does it's "darkening" or "black-fogging" lighting model. I think a lot of other 1993-1998 era FPS games worked like this too - far away objects are black shifted, as if the player himself is the source of the light. The only expense to this model is one additional byteArray[] write per pixel, which hurts performance, but you're getting a lot of visual appeal for that smallish cost.

    Now, promoting palette images to true colors images is more complicated, but it's still the same idea:
    1a. Write palette indices into the blue channel of a byteArray.
    1b. Write darkness indices (255 = near and bright, 0 = far and dark) into the green channel of the same byteArray.
    These two rendering steps (1a/1b) occur concurrently. Every pixel write into the blue channel is accompanied by a lightmap write into green channel - 1 byte away, right next door.
    2. Like last time, write into a bitmapData using setPixels. This copies both channels concurrently - so we now have some funky blue/green image (note the byteArray should have it's alpha channel seeded with 255's when it is created - otherwise the alpha-multiplication semantics built into bitmapData will zero out your precious green/blue data as soon as your write it in).
    3. Now a paletteMap operation takes place:
    Use the blueArray argument to assign the red/green/blue channels of the output image (this is exactly what we did before, except we were using the alpha channel as the source). The greenArray should be used to generate a new alpha channel. Each 32 bit entry of the greenArray has 8-bits of alpha data following by 24 bits of zeros - so it doesn't modulate color, just alpha. Note this can be all be done in one call! The redArray and alphaArray arguments are zero.

    And finally, some flash-specific cleverness..
    4. Place the finished image on top of a black backdrop (setting the stage default color to black will do just fine). Our completed image is partially transparent, so some pixels are see-through to the black behind them, and get mixed together with it. Closeup pixels are nearly opaque so they don't get much black mixed into them and appear brighter. Further pixels are almost completely transparent and are heavily fogged/blacked. Voila! - distance based lighting model.

    For a sample, here's a downloadable (zipped) .swf that demos these features and the current state of the game. Some artwork has been pulled to keep the filesize low. There are also some other features added in here and there:

    * Better clipping of things against map geometry (last submission was pretty wonky although you might not have noticed)
    * Crude particle system for wall and player shrapnel. Sort of like the blood droplets from doom - but the target audience for this game is not into blood so... it's shrapnel! Yeah, that's the ticket. shrapnel.
    * Beam weapons (lasers) - work like dooms hitscan weapons but they leave a tracer for 1 frame.
    * Sector based lighting - similar to dooms lighting abilities.
    * Player avatar artwork- finally some stuff that wasn't just jacked from other games! (That's why's it's uglies)

    Walk around with arrow keys, + shoot with spacebar. (you can walk the big green dude around with ASDF+G - but his guns don't pop out of the right spots yet).

    Feedback welcome! A lot of gameplay is still up in the air, but I am shooting (har) for a game that plays mostly like 4-player coop doom (run, shoot enemies, open doors, ride elevators, snatch repair item) but has some additional sim-like elements (power management between weapons/shields/engines like X-Wing, damage taken affects mech performance like Privateer 1, and a garage or upgrade system where you can repair, purchase new weapons, or mech chassis between maps).
    Last edited by rachil0; 01-07-2008 at 04:51 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center