I MUST see it in motion!!!
Printable View
I MUST see it in motion!!!
It is a problem but it is temporary. If you looked close, you probably noticed that beams are drawn as little trapezoids, that taper from the near end to the far end.vRight now, new beams are spawned at the focus of the camera and cast out along the look direction. When you view a line end-on and project it to screen space, it's start and end point and coincident. This throws all kinds of NaN's when it's time to build the trapezoid and compute texture coordinates.Quote:
Originally Posted by VENGEANCE MX
This problem will go away when beams are launched from the correct initial spot (tips of the arms) - they'll appear correctly and converge inwards from the sides, instead of passing right trough the eye.
Love the screenie render. A HUD by Christmas sounds about right ;)
I'll get an interactive demo up once a few more features are inplace (buttons, player proximity checks and shootable triggers). Right now doors are just opening/closing on a timer, which causes some unpleasantness (and graphical garbage) when you stand in the door jamb and the door closes you.
Implemented new features over the weekend, mostly focused on new types of weapons. Everybody likes guns! Right now there are:
Hitscan - Invisible, travels with unlimited speed along a straight line.
Beam - Hitscan weapon and renders as a 3D line with textured cross section.
Pixel gun - Fast moving particle (zero volume) that is integrated using swept collision tests.
Wedge - Shoots fast moving texture mapped triangles. Similar to the quake nailgun.
Stoke - Shoots line segments, like the autocannon weapon from Earthsiege/Battledrome.
Bitmap - Emits a fast moving billboard sprite, like the imps fireballs from doom.
Grenade - A polygonal canister which arcs to the ground and then starts tumbling. Explodes after a delay. Quake nostalgia to the max!
Sticky Mine - A polygonal hex-frustum that sticks to the wall, blinks, explodes. Will be refactored into a proxy & remote mines like Goldeneye 64.
Rocket - A polygonal missile that spins as it travels, like a rifled bullet. Just placeholder artwork for now. Will be subclassed into a limited homing missile later.
Here's some screenies. Clockwise, from upper left: Bitmap, Stroke, Wedge, Mine, Rocket, Beam. Grenade in the middle. Pixel gun not shown.
http://esl.eng.ohio-state.edu/~rac/quake/weapons.jpg
The transformation pipeline for polygonal things has been implemented (the grenade, rocket and mine were the test suite). Before, things were just pasted into the map and could not move around. Also started to implement some physics and particle effects. Grenade, rockets and proximity mines explode into sparks, and the small arms emit chips off the wall when they hit. The particles bounce off of obstacles and respond to gravity/friction forces. The polygonal weapons don't interact with the enemy yet, polyhedron-to-polyhedron collision is going to be refactored and simplified in the near future. The hitscan and particle-like weapons are all working properly though.
A demo is located here. (434K)
If you haven't updated it recently, you'll probably need a new version of the debug player. Arrays in the code have all been promoted to template Vector.<>'s for greater type safety. However, revision 2510 of the debug player was choking while constructing vectors from some of my types. The problem seems to have been corrected by revision 3178, you can get a more recent debug (standalone) player here. If you have problems with a recent player please let me know and I will report it to the developers. ( link, link)
Next features to come:
* Implement thing-to-thing collision more robustly. There is some weird assymetry right now, when thing A tries to move into thing B, A is treated like a sphere and B is treated as a union of polyhedra. When B tries to move into A, the opposite is true. If A and B are very different shapes/sizes, A says A&B collide, but B says A&B don't collide. So I need to sort that out in a self-consistent way. I think all things are going to collide as capsule shapes.
* Program the walk cycle for the enemy.
* Damage and destroy the enemy. Make some kind of destruction sequence. I think just removing the joints between the polyhedra and letting them tumble and explode randomly will look pretty good.
* Embed the weapon hardpoints from the robots xml file. They are just hard coded now.
* Embed the lighting source points in the map xml - they are also hard-code. Sector based lighting is also back. It can vary in time, but is not softly shadowed. Just draws transparent black uniformly over a sector, in screen space.
* Get the doors worked into this map.
* Support for animated textures. They will not be shadowed at runtime because I think it will be too expensive. I am thinking this will be used mostly for things like computer readouts, which are already mostly black and are really their own light sources. So they wouldn't be really in shadow anyway.
Still grinding it, one feature at a time :) There's enough of a surrounding application now that it's getting into the fun phase, where you can think about gameplay and design ideas instead of just struggling to get the damn thing working at all. I :lovers: grenades.
EDIT: Thanks Mr. M! Forgot to mention the controls - arrow rotates the view, space scoots forward, CTRL shoots weapons, SHIFT switches through the weapons.
what can I say.
A fine good job ol chap, I say stick it to those papervision bastards, right up the duffa, jolly good show.
The rest of us should probably reset our keyboards to the upright and locked position. Honestly, is there any reason to keep developing after something like this? :p
very nice update,
I had a play with the textures (because your engine can do more than just 8bit looks)
http://www.renderhjs.net/bbs/flashki...d_textures.jpg
on a quadcore here average FPS 60-70 but on less face intense areas sometimes 125 fps
Thanks guys for the positive feedback. I hope you all tried the grenades, I think they're the best added feature.
Very very cool screenshot :) - I especially like the floor texture and the "||=" pattern on the walls. You can drop in any 24 bit textures you want, almost all the assets are loaded at runtime and customizable on your end. Only the beam and wedge textures are embedded and immutable. (Well the bitmap weapon is also embedded, but eventually it won't be). I think you could also use different texture resolutions and it will still work - internally all the texture coordinates are normalized to the texture size - if a 64x64 texture is tiled 3x3 times to cover a wall, a 128x128 texture will be tiled 3x3 times, too, packing more detail into the same geometrical space.
Although not shown in this demo, all the polygonal Things can be textured, too. There's a medikit thing which tests this pipeline, clobber grenade.xml with the contents of medikit.xml if you want to see it on your end. (Medikit launcher?)
Of course with the rest of the scene looking so great, now the mech needs a skin too! I like the camo design very much. I think WW2 style markings or a steampunk skin would also be interesting twists.
More to come, sooner or later :)
:yikes:
Always wanted to do one of those smileys for something
:yikes: :hubba:
More updates, mostly related to animation.
* Animated textures are now supported. The fan is the only animated asset I have. More computer screens to come.
* In addition to the small bulletholes, Surfaces can be scorched by explosions. Scorches are just black polygonal blooms alpha-composited over the base texture. The exploding weapons (grenade, missle, stickybomb) also spawn explosion sprites upon their demise.
* Walk cycle for the robot - legs pitch about the hip joint, the torso & head bob up and down, and the arms translate back and forth in a vaguely humanoid way.
* Death cycle for the robot - all joints between polyhedra are removed, the pieces tumble to the ground and explode randomly. As the damage dealing process is refined, it will be possible to blow off parts of the robot (arms/legs) with surgical shooting.
* Another enemy robot with a little different designed - pronounced hip joints, larger weapons, and an more underslung cockpit. Also has a walk cycle/death animation. Geometry is close to final version but needs a polish and definition. (Legs are uniform thickness and somewhat bland, this will be fleshed out and more articulated when it gets revised)
* Although this cannot be screenshotted, the file formats for things and maps have been redone in a binary (non human readable) format. The model editor still uses a pure XML representation, but this will reduce filesize significantly if/when this game ever gets deployed to the web. The binary format is still pretty extensible, because the user defined tags are still embedded as UTF8 strings. Hopefully, any unforeseen extensions that are needed can be globbed into the tags. For comparision, the map file was 130KB as xml, and is 7KB as an ascii hexadecimal stream. It will be 3.5KB when stored as a real binary file. (Hexadecimal is only used here because the string has to be copy/pasted from a dialog box in order to be exported from the editor to a local file - extended characters foul this up so 2 hexademical ascii chars are used to store each single byte)
Some screenies:
http://esl.eng.ohio-state.edu/~rac/quake/animation.jpg
Demo still available here.
(Controls: arrows=look camera, space=move camera, shift=cycle weapons, ctrl=file weapon, enter=spawn/destroy opponent)
Full source coming soon - spent some time refactoring and it's almost ready. I don't know how useful source will be - it's growing too large to be an effective teaching tool IMO.
again very very nice.
The thing with the binary files is a smart move because usually you can also faster parse or read in the data compared to string operations like DAE, XML, OBJ and alike.
What would interest me how the engine handles larger maps,- not necessary more complex maps but lets say this same room placed like over 20 - 50 times next to each other and one could walk along a corner (so you dont see the rest ahead at once) to the next room and so on.
Like how is the initializing time,- does it need to build up alot of things. Does performance still runs fine just like now?
If it would work out well this might be a very interesting approach for FPS games and applications in Flash.
I love all of the different weapons. It's kinda weird having a sort of a mine spewing machine gun though lol. Brilliant work!
it's v10 isnt it... cant enjoy this :(
All you need to do is download the standalone player and watch it with that...
insane in the membrane
Thanks for trying it guys!
I plan to do a larger map soon, which will be a testbed for more scripts and gameplay elements (buttons, doors, keys, traps, etc). I expect that the game will scale very well with map size - testing on the descent maps it what convinced me. If none of a sectors geometry is visible then it has zero rendering impact - there's no overdraw waste, and its vertices are not even transformed! I/O and initialization time will always be linear in the size of the map, and the lazy evaluation of shadowed surfaces tends to spread out the highish cost of the lighting routines - shadows aren't computed until the surface is visible for the first time.Quote:
Originally Posted by renderhjs
The editor is a different story. It doesn't have any of the occlusion tricks so it draws the whole map on every frame. It will become a real bottleneck as mapsize grows. There might be a need to cull the map to just a short distance in front of the camera in order to make the editor more responsive. Exporting a map is also quadratic in the number of polygons it contains, this is a known issue which will be resolved in the future.
If you don't have the 10 player installed in your browser (I don't either), then you can fetch the standalone debug player from:Quote:
Originally Posted by makc
http://opensource.adobe.com/svn/open.../in/player/10/
That's the same environment I debug and test with, so you'll see what I see.
thanks, sa player is great idea.
this is really incredible work, great to have a good 3d game engine for browsers that isn't massive like shockwave 3d!
I've been making a lot of models and music recently for a game inspired by alone in the dark (original) and realms of the haunting so I'm really looking to forward to seeing where this goes.
My idea was to have creepy low-polygon (no textures, AITD style) origami people moving around in textured rooms, using a haunted 1930s house as the main area and as a hub to other worlds lol.
The double pixel size rendering actually makes it look really cool imo! Will I have to upgrade to CS4 to use the engine in a project?
Thank you for your interest in the project :)
I am not very familiar with realms of the haunting but alone in the dark was a nice classic. Graphically the engine is well suited for indoor, densely occluded maze environments. As long only a small portion of the mansion is visible at once performance should be fine. Gameplay wise, it's an action engine more than a puzzling engine so a lot of the projectile physics will be overkill. So there would be more for you to modify on that front.
You don't have to use CS4 to work with the engine or the editor tool (I don't have any of these tools, no CS4, no CS3, no nothing). You just need the mxmlc compiler, which is available free in abobe's flex SDK.
I have not had much time to update this project lately but I certainly haven't forgotten about it. Recent features include corrections and improvements to the shadow casting code, a crude sound model with stereo and fading effects (via SoundTransform), creating sounds for all the events currently in the game, laser traps, and fleshing out a design for how things/entities can respond to stimuli in a generic and extensible way. I still intend to give away the source. I keep thinking there will be some perfect milestone where the code will be ready, but this is a pretty unrealistic view of things. The renderer is stable but the physics and entity hierarchy is still WIP. PM if you just can't wait but I'd rather let it incubate a little more. :)
I was planning to put time into making something in about 6 months from now anyway, just wondering what the current status was :)
I haven't actually played Realms of the Haunting either (lol), it just came to mind as an example of a similar engine used to create an adventure game.
Really i'd love to do any style of game with it, it'll look cool!
The projectile physics would still be good for any game anyway, I was planning to have objects that you could throw and falling objects etc..
I love the skybox implementation!
Had some time to work on this again over xmas/new years break so thought I would share a new demo :]
Added or revised features include:
* More robust shadowing - actually doing shadow volumes now instead of a flat projection. This makes some boundary cases render correctly that were failing before. The effect is still not perfect - there is a smoothing step that takes place in texture space that really should be done in world space (ie the code blurs/blends shadows using an 8 texels stencil, when it should blend using an 0.2 meter stencil). But most textures are at the same sampling density so you don't really notice that approximation. You can still only shadow by 1 light at a time - this will never change because shadowing is expensive enough already (note the drop in frame rate upon entering a new area). Screenie:
http://esl.eng.ohio-state.edu/~rac/q.../demo-jan0.jpg
* Support for masked textures (like chain link fence). This is not really tough to do by itself, but it is tricky to get them to zbuffer correctly. It's not really a polygonal gradient fill anymore, it's a polygonal gradient fill with holes. The example fence is not very impressive, the real reason for adding this feature is to make thin doors.
* Underwater and under-lava graphical effects. Loved these in doom-a-like, just had to get them back. When viewed from above, water and lava are just standard animated textures that sorta ripple back and forth through a sequence of pngs. But when you jump underwater, a displacement map filter in screen space is applied to the entire framebuffer, so even the geometry looks like it's rippling too. A tint (blue or orange) is also applied. The displacement map filter was also used to generate the png sequence in the first place. Screenie:
http://esl.eng.ohio-state.edu/~rac/q.../demo-jan1.jpg
* Sound effects for weapons, explosions and environmental events, courtesy of SFXR. I especially like the grenade tumbling sounds - 100% quake nostalgia. There are also stereo panning and distance fading effects. The fading is a little wonky - gets to quiet too soon - but the panning feels ok. Sound can't propagate beyond closed doors, and you can also tag sectors as soundproof. Eventually there will be gameplay consequences of sounds too, like player-triggered noises will alert nearby enemies.
* It's finally more than a camera in a box simulation - there is a player avatar with more interesting physical characteristics. The player can jump, slide down ramps, respond to friction and falls due to gravity. This screenie was made by toggling to 3rd person view and then walking your avatar around to face the static camera:
http://esl.eng.ohio-state.edu/~rac/q.../demo-jan2.jpg
* There's a few interactive environment elements. There are timed laser traps, moving brushes for making elevators and bridges, and doors respond to player as they approach and retreat. Screenies of an interactive bridge and laser traps:
http://esl.eng.ohio-state.edu/~rac/q.../demo-jan3.jpg
http://esl.eng.ohio-state.edu/~rac/q.../demo-jan4.jpg
* Last but not least, there is a larger map to explore - 1K vertices, 1600 triangles, 32 sectors. I eventually expect real playable maps to be on the order of 3-4 times this size. There's also the first gameplay entities - find all 3 keys! However the locked (colored) doors are kinda on the honor system right now. You can walk through them without the keys, and you can't really pickup the keys anyway. Screenie in-editor:
http://esl.eng.ohio-state.edu/~rac/q.../demo-jan5.gif
Controls:
Left/Right/Page-Up/Page-Down to look around.
Up/Down to walk forwards and backwards.
Shift to jump, control to shoot, tab to cycle through weapons.
Home to toggle between 1st and 3rd person views.
Link to playable demo (1.5 MB, requires flash 10): here (Copy to your computer, unzip all contents to same directory).
EDIT: Glad you guys like it! :D Ideas for what gameplay features would be cool on a map would be greatly appreciated.
sooooooooooooo seeeeeeeeeeexy will have an in depth look at it :D
:eek: That's amazing
Just played through, was quite sweet. Nice job! (An actual usable 3d experience, quite rare!)
Mouse controlled view would be useful. :)
Runs real nice!
Better than all of the PV3D etc demos if you ask me. This is more relevant to programming games than those painfully slow APIs. Well I say that from what I observe, I may be wrong...since I haven't tried to spend my time learning and using them.
I always enjoy seeing the updates you add to this project. Pretty cool stuff. Keep it up.
the best.
If you want something done, do it yourself.
I agree with the others, its a great achievment and i think with where the flash player is at right now something like this makes a way better impression and way more sense than all those pv3D etc demos which usually choke around at less than 15 fps without much interactivity.
This ran really great on my machine, i could even play it pretty smooth with anti aliasing turned on, really nice.
Since you asked for suggestions:
-mouselook aim and mouse button shoot option
yeah, not like in the classic games but man, i´d like it so much more with this :)
-not using shift key (pressing shift key several times triggers a windows message)
-show minimap (maybe gameplaywise only of already explored areas)
yeah, i get easily confused regarding where i´ve already been :)
ah, you tricked me into thinking those beams actually do any damage, had to run like crazy through them :) my suggestion, make shadows stronger, they are barely visible here.
Word can't describe just how blown away I am with this update so I'm not even going to try...
Just keep it up!
...
WOW
I can't believe I have missed this for this long!!! First I must ask, is the whole engine a Z-Buffer? I've been working away at a Z-Buffer for a long time now (in theory), but I haven't gotten a lot of time, and only now am I starting to write my custom rasterization classes...but I read that the best way to go is with using GradientFill...my original plan, until I saw how slow BitmapData.draw() method is, or would be...And man have I ever imagined up millions of optimization techniques, but I've never had the guts to start something so big...in fact, I must admit, I don't even know exactly where to start...
I think that Render will recall me mentioning some weird secret 3d engine idea I had...well, this was pretty much it. I mean, I think I have a few tricks up my sleeve still, but of course, I need to actually show them and quit simply talking about them...
So yeah...this is the best 3d Engine yet! Delivers amazing FPS rate with very good graphical quality! I'm astounded when I see all those shadows and everything, and how you have a z-buffer!
A few details under the good: How exactly how are you doing everything? I mean, what are you doing in Vector, and what are you doing in Raster?
Second, what are the limitations of level design in it? Can you do absolutely anything, or are there some guidelines? (I think this was previously answered, but I'll have forgotten about it (*PHEW*...read through the whole thread in just about 40 minutes or so, to suck it in...) )...
Hell, this is my new favourite thread! And can you post the links to the demo's? Other people seem to be finding them, but I...well, you finish the sentence...
AMAZING
All my respect to you! Though I almost feel like giving up on Flash... :( Never knew someone else was thinking about doing a Z-buffer until know...
Keep up the work!
P.
Quote:
Originally Posted by Pazil
the link is mine.Quote:
Originally Posted by rachil0
Ah ok...it just looked like there were some z-buffer screen shots...Post #77, second screeny. The way he combines the two and how he's using depth as the pixel shade is exactly like a z-buffer...
I never knew that a Portal engine can be the whole concept. From what I've read on Portals, is that they're just an optimization of sorts...to speed the rendering of things, and also solve fairly minor cases of visibility...
In the demo's (I'm sorry...I was too excited to really notice the links you HAD put up) you can throw objects like grenades.
How are they sorted with the other objects, like columns and stuff?
P.
Thank you for all the interest :D I'll try to explain how it works in broad strokes:
It uses three different algorithms (portal rendering, binary space partitioning, Z-buffering) together to solve different aspects of the visible surface problem. The map is first and foremost a portal renderer like realMakc's link. The editor builds geometry from convex polyhedra ("sectors") where all the faces point into the roamable volume. If a map contained a single sector, it's easy to draw - because it's convex none of its faces can occlude any other. We just need to do a backface cull, project them to screen space, and draw them using the 400x300 screen rectangle as a clipping region. To support multple rooms, sector polygons can be tagged with hole ("portal") information. If a hole/portal subpolygon is present on a sector polygon, it the sector that is visible through the hole is drawn recursively. The holes projection in screen space is used as a clipping region - much like the 400x300 window was used before. Ultimately the renderer looks very much like a depth-first-search - the map structure builds a graph where nodes are the sectors to be drawn, and the arcs are the portals which connect them.
The renderer described thus far is basically the descent engine. With it you can model any geometry you like - just keep on carving out roamable regions with additional sectors. For greater geometric flexibility, you can partially fill a sector back in with outwardly oriented polyhedra ("brushes"). The reasoning is that sometimes it's easier to describe/discretize what is filled/unroamable rather than describing what is empty/roamable.
Consider the red door screenie: the laser trap emitters, ramp, and catwalk structures all all brushes, the green wall is the sector boundary. It's easy to say this room is "mostly empty with these specific areas solid", than to say "this area is made up on the following voids: ...". The catwalk in particular makes a weird 3 handle torus topology that would be tedious to describe in terms of the voids it leaves behind. Another way to put it, is that it's easy to build the catwalk structure out of blocks of marble, but hard to carve it out of a single piece of marble.
So there's also solid bits of map ("brushes") that fill back in a void ("sector"). However, when we have multiple brushes all existing in the same sector, we have to establish a drawing order so that they occlude each other correctly. This is where the BSP comes in. Each sector it's own local BSP which is used to sort the brushes. With just a local handful of brushes to consider, the BSP is easier to build. The editor does it automatically at export-time. To prevent faraway sectors from occluding nearby brushes, the brushes are drawn on the "tail side" of the recursion. So sectors are drawn as the recursion goes down, brushes are drawn as the recusion winds back up.
Moving on, the monsters are also self-sorted using BSP's. This makes sure that the arms of the monster correctly occlude the feet (for example). Monsters are sorted against other monsters using basic sort-on-z-centroid. Particles and billboards are also thrown into that step and sorted by z. Billboards currently include explosions and the green fireball weapon - the only raster entities in the game.
The tricky part is sorting these moving entities into the static map. I use a z-buffer with very limited functionality. Basically, the routine will let you feed it two screens, each with a pixel buffer and zbuffer plane, and will composite the two together in one pass. So the renderer makes 1 scene with just the map, another scene with just the monsters, and then composites them into the result. The z-buffer can be filled efficiently on a polygon-by-polyogn basis using linear gradient fills, because 1/z is linear in screen space.
There is no support for setting or testing single pixels - this cannot IMO be done efficiently in flash. However an entire-pass composition can be done efficiently using blendmode subtract and a bitmapData.threshold. Because of the finicky way flash does gradient fills and channel subtract, the zbuffer only has about 9 bits of resolution. This is an area I would like to improve, but it's not that bad because we have robust sorting schemes for every possibility except monster vs. map.
That ought to cover most of the basics (regarding your specific question, grenades are treated monsters so they are zbuffered to occlude correctly against columns).
Wow. A wow for the engine itself, and wow for how well you explained it!
I never understood what you meant by brushes before now. So the only rule is you always need a big polyhedra encompassing the camera? If that's so, then I really need to get down and learn your engine's API!
A question on the z-buffer then...So you first draw a monster by doing the centroid z-sort. How do you draw the gradient shapes of it? And last but not least, how do you draw the final image? I understand the z-buffer combination well enough (I think), but how do you then translate the buffer info into the actual pixel values?
A question on the blendMode option also...why subract, and not lighten/darken? And then what does bitmapData.threshold do (In regard to the engine)?
How often are you using BitmapData.draw()? I'm sorry if some of these questions are quite obvious, since I'm used to using the as2.0 BitmapData, so I don't know how they've changed the operations (in fact, I'll look at it now).
Sorry for overloading with questions...I still only half believe this!
P.
Yes the camera must always lie inside of a polyhedra - a home sector from which the recursive rendering begins.
Just like you compure u,v coordinates for polygon vertices, you compute a camera z-depth for each vertex too. If you look at the function 1/z (or K/z for any constant K) across a flat polygon, it's actually linear in screen space after the perspective transform. So instead of rolling your own rasterization where you compute and poke z into a bitmapdata one pixel at a time, you can write 1/z for a whole polygon at once with a linear gradient fill (graphics.beginGradientFill). It's been a while since I touched this part of the code, but I think the actual mapping from z to color is:
Basically this takes a z value and maps it into a fill value between 0 and 765 (=255*3), and that gets mapped into a real color between (0x01,0xFF) or (0x01FF,0xFFFF) or (0x01FFFF, 0xFFFFFF). That is a continuous spectrum of 765 unique colors that can be filled with a gradient fill without introducing any gaps that could confuse the linear interpolation routine internal to graphics.beginGradientFill.Code:function zbuffer_value(z : Number) : color
arg = 256/z;
if (arg > 765)
return 0xFFFFFF;
if (arg > 510)
return 0x00FFFF + ( (arg-510) << 16 );
if (arg > 255)
return 0x0000FF + ( (arg-255) << 8 );
return arg;
The blendmode subtract and thresholding operators are how the z-buffer write/test pass is implemented. Subtract ... erm subtracts the two zbuffers pixelwise, then threshold is used to find where the monster zbuffer was further than the map zbuffer. Where that happens, threshold writes a transparent pixel. Then this masked monster layer is composited above the map layer using bitmapData.draw.
It's obscure and the resolution sucks but I spent a lot of time trying to figure out a good way to fill and composite z-buffers and this is the best solution I could come up with. I would eventually like to rewrite those routines...perhaps in C++. I tried pixelbender but was not pleased with the speed.
All in all there are 3 draw calls. The map layer is rendered into an offscreen sprite using graphics.beginBitmapFills and graphics.drawTriangles, and ditto for the monster layer. Two draw calls are used to drop those graphics contexts into honest-to-god bitmapdatas. The third draw call is used during z-composition (as described above).
Awesome!
I'm still not quite sure why you don't just merge the monster and map using BlendMode.LIGHTEN though. Also, you mention it filling in transparent pixels. Is this process done by looping through each pixel? Ah...waaait a second. I might have had a click right here. You do the subtract and threshold, because that's where you draw on the actual bitmaps of the projections instead of the z-buffer projection?
But then is the actual drawing done face by face basis, or the whole monster at once? Because if you do monster at once, then you must be doing 2 projections of it at first, no? One for the z-buffer with gradients, and one of the actual image? And same with the map?
I hope I don't seem to be nagging at you with questions or anything...This is all so fascinating! Also, how are you doing the gradients through drawTriangles? Do you need to give it a matrix, or can it interpolate values?
Thanks for being so open! And you seem to respond very quickly, but don't let me keep you from doing more! Keep it up!
P.
You might be able to get it working with lighten - replaces with minimum z right? But then it wouldn't be obvious to me which layer that minimum z came from. With blendmode subtract, you get a zero where the map pixel should be used and a nonzero where the monster pixel should be used.
The transparent filling is done with threshold. It is a totally bizarre method if you peruse the livedocs, it edits the contents of the map pixelbuffer, but with a conditional check in the map z-buffer.
The drawing for monsters is done face by face, into two seperate graphics contents (a pixel buffer and a zbuffer). The map is the same - so ultimately there's 4 bitmapdatas in play (mapz, monsterz, mappixel, monsterpixel). This burns up fill rate but I have found that to be a plentiful resource compared to polycount.
The gradient fill is done with drawTriangles. There is some math magic behind the scenes to setup the beginGradientFill arguments. (bGF has very strange semantics too - internal units are 20'ths of pixels). The helper function, matrix.createGradientBox, is invaluable for getting this calc correct. But it doesn't do the whole job for you, because it only works for axis aligned gradients. You have to rotate and translate it around after you set it up, to get the gradient aligned with the proper screen direction and get the zero-z point in the right spot. Not a ton of math, but you have to be pretty careful with over/underflow when your z value is not inside (0,765).
Just happy to help :) Been working on 4k games so I've been trolling flashkit to see what the other guys are up to.
if you do drawTriangles you could use UV(T)s as well and replace beginGradientFill with beginBitmapFill. but that may be slower too.
That's a good idea! It could be slower, but if the GradientFill is really using 20'ths of pixels...then it wouldn't hurt to try it out!
P.
Actually, nevermind. It seems that rastering lines may be faster, but it seems as though rastering triangles can't compare with drawTriangles()...
I was wondering about the FPS your engine's giving right now...How much of it is the overhead, and how much is the amount of poly's you want to render? Meaning, I notice that in the other 3d engines out there start out with quite low frame rate, but after you get over that, you can add quite a few triangles and poly's in there without worrying too much about the frame rate really shaking down...
P.