Doooooom

[webgeek]

Arcade machines are great. I've got one I built based on Groovy Game Gear hardware. Totally dodges the whole keyboard problem in the first place. I run some Flash on mine too and its been fine.

[mr_malee]

rachil0 - if you were talking to me, sorry but i didn't do the engine, just spreading it around. I might add that yours does look very good.

And as to the thread, i really hope this isn't just another "demo" which i see all the time. But you can't be sure i guess.

[ImprisonedPride]

I don't understand all I see in rachels 2 demos is a gray/blue screen?

[renderhjs]

@ ImprisonedPride: perhaps you dont own a copy of the standalone Flash Player 9 ? - drag it into the browser instead.
The grey/green color shows the default Flex background color (seems someone doesn´t care about that color )

[ImprisonedPride]

(seems someone doesn´t care about that color )

Hmmm?

[renderhjs]

I just dont like the default flex color,- one of the first things I searched for AS3 was how to change the background color, guess I´m picky in such cases

[Ray Beez]

Impressive tech demo.
(Unfortunately, his frame rate will tank once he:

- Adds wall collision
- Sprite object rendering
- Sprite collision
- Monster behaviours
- etc
)

[ImprisonedPride]

As far as doom is concerned, the biggest hit on performance will be the sprite collision, wall collision is pretty static, the rendering, if following the same method shouldn't be to bad (since in doom they were 2d sprites), and all the monsters habits were 1) Move towards player 2) shoot at player.

[mr_malee]

wouldn't you just run sprite collision like collision in a tilebased world? what i basically mean is use a data structure so you only check a collision with things next to you rather than everywhere in the same room, and bullet collision would be very much the same. I'd say the rendering of additional objects is what will kill it, and I reckon there's still some CPU left in there.

[ImprisonedPride]

Well that's why I said what I did, I don't think anything will really "kill" it as you said, but simply that they will take up more if he uses per/pixel rendering on the objects like he did on the level.

[yow]

He's got collision detection on the floor, anyway...

BTW: why doesn't Flash use the video card? That would be fast.
A security issue or something?

[renderhjs]

He's got collision detection on the floor, anyway...

BTW: why doesn't Flash use the video card? That would be fast.
A security issue or something?

excluding users for not beeing able to run either openGL (vista in aero) or DX (Linux, OSX,...) + the fact that it wont be compatible anymore with all those different devices flash already performs well (wii, ps3, mobile, psp,...)

[xMCNUGGETx]

this one had sprites and collision detection (although doom looks much nicer )

http://www.glenrhodes.com/wolf/myRay.html

[yow]

excluding users for not beeing able to run either openGL (vista in aero) or DX (Linux, OSX,...) + the fact that it wont be compatible anymore with all those different devices flash already performs well (wii, ps3, mobile, psp,...)

All of those (except mobile) have fast graphics capability... but I guess unifying access to all of them would be a big ask!

[mikel83]

this one had sprites and collision detection (although doom looks much nicer )

http://www.glenrhodes.com/wolf/myRay.html

That one's pretty good, shame i ran out of ammo & had no ILM to fall back on

[Ray Beez]

He's got collision detection on the floor, anyway...

The way Doom achieved their "heights" is through a trick. You NEVER have a floor go over another floor (like a bridge or room above a room). Each area of the 2D floor map has a "height value". So the floor "collision" again is just a trick, since you know based on the map data how high each zone of floor is supposed to be already. They might be able to use a grid system for sprites, assuming WAD maps support that information to begin with, and he wants to stick to faithfully "emulating" the WAD data.

Regarding your question: Flash doesn't use hardware because it doesn't conform to the strict limits of what video hardware can calculate: triangles, blitted surfaces (basically 2 triangles that form a rectangle with a bitmap texture mapped to it) and 3d lighting. Bitmap textures are best stored in video memory, and for many cards also must conform to a power of 2 in size (ie: 8, 16, 32, 64, etc). Flash can draw pretty much anything and everything on the fly with too much flexibility. This is Flash's greatest strength, yet also its achilles heel when it comes to direct hardware accelleration. The second you have to load textures on the fly into video memory, your performance suffers (true even of 3D PC games if you try to manage more graphics data than there is RAM available on the graphics card). With Flash, essentially, each frame gets rendered to a window via "dirty rectangles" method, then the window is sent over to the video card for display via the PCI, or AGP bus. This is much slower than 3D hardware grabbing data from its own video RAM and blitting it straight to display memory. (I'm grossly simplifying how this all works, but that's the basic gist of the performance hurdles).

There IS an implementation of Flash player called ScaleForm gFX which uses 3D hardware. It was built from the ground up, implementing only core basic features that are needed and possible to translate to the hardware. It breaks down vector drawings on the fly into triangles, MovieClips into 2D "surfaces" (look that up in DirectX SDK help files if you don't know what that means) and can even render Flash animation to a texture which can then be mapped onto a 3D object!. However, artists must watch their "triangle" counts when designing the vector graphics (much like 3D game artists must do with 3D models), and the actionscript support is incomplete. The SDK is meant for use in 3D games (PC, PS2, PS3, Wii, Xbox 360, etc) primarily as a tool for creating complex, animated GUIs, HUDs, and animated textures.

[mr_malee]

^

ScaleForm gFX - well well, this could be interesting, i didn't know about that. Thanks for sharing.

[yow]

Wow, thanks for that Ray Beez.

Flash again sacrificing performance for ease-of-use. It seems AS3.0 is pushing the balance back the other way a bit now.

[tiny_legoman]

If this engine uses the same techniques as the original doom, it is in fact fake 3d. But yeah, that's just semantics and I do get your point. However, if 3d becomes truely available to flash developers, I can only welcome that. Not that I'm some 3d junky, but if it means more possibilities, I'm up for it.

looks pretty 3d to me. surely there is no such thing as true 3d on an inherantly 2d environment, such as a computer screen...

[tomsamson]

what fall x and i meant when we said doom was fake 3d was how its implemented rather than the look and we said that because when someone talks about a (not fake 3d) realtime 3d game nowadays that means you have a game world made up of polygon 3d models (and generally objects/particles all with real 3d coordinate spacing/positioning) which allows much more freedom in actual 3d geometry of the game world,shape of objects and placement and movement of the game camera (though even modern realtime 3d games use faking attempts to save rendering time such as skyboxes etc to fake large distant horizons etc).
doom in comparison wasn´t fully real 3d in the modern sense as it faked the look in a way which was awesome for its time but brought up many restrictions (like said before you shouldn´t have rooms above each other or if you did (like duke nukem did,which had a similar but more advanced system than doom) it would lead to bugs where the player could by a glitch jump between different room/area geometries (as the engine couldn´t cope with it well). you were also restricted way more in the shapes of the level geometry and next up the moving objects in the game world (such as enemies etc) were sprites so you needed their animations premade in several angles and either you´d have to export them in many angles (and by that bump up filesize a lot) or they would look weird in certain angles and have noticable "jumps" when "easing" from one angle to another.