[WIP] Flash quake/descent style renderer.

[Cortana]

I MUST see it in motion!!!

[rachil0]

Is it a problem that I can't see lasers when I fire them (but the bullet hole does appear)? That is to say, I have to strafe to one side if I want to be able to see it.

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.

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.

[rachil0]

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.



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 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.

[mr_malee]

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.

[ImprisonedPride]

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?

[renderhjs]

very nice update,
I had a play with the textures (because your engine can do more than just 8bit looks)


on a quadcore here average FPS 60-70 but on less face intense areas sometimes 125 fps

[rachil0]

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

[.hooligan]

Always wanted to do one of those smileys for something

[samvillian]

[rachil0]

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:


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.

[renderhjs]

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.

[dVyper]

I love all of the different weapons. It's kinda weird having a sort of a mine spewing machine gun though lol. Brilliant work!

[realMakc]

it's v10 isnt it... cant enjoy this

[dVyper]

All you need to do is download the standalone player and watch it with that...

[mr_malee]

insane in the membrane

[rachil0]

Thanks for trying it guys!

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?

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.

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.

it's v10 isnt it... cant enjoy this

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:
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.

[realMakc]

thanks, sa player is great idea.

[fuzoid]

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?

[rachil0]

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.

[fuzoid]

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!