Floor Demo
A tech demo of 3D moving floors. There's still some things that I want to do to it, but as a start this is pretty neat.
Filenames
floordmo.wad
Size
29.12 KB
MD5
0512fed8073d3eddf6d648535408abaa
SHA-1
d7a35ed4ec79d7c42970419b955250884eb60e85
SHA-256
f623b4b9fc3960def46e75be25273f306dc12feb1dc5cbbef363a74057d731f4
WAD Type
PWAD
IWAD
Doom II
Engines
GZDoom, ZDoom
Lumps
7
Maps
MAP01
Download
Read Me
=========================================================================== Advanced engine needed : ZDoom 2.6.1 or GZDoom 1.7.0 Primary purpose : Technical demo of 3D moving floors =========================================================================== Title : Floor Demo Filename : FLOORDMO.WAD Release date : January 21, 2013 Author : Ethan Watson aka GooberMan Email Address : [email protected] Other Files By Author : Doom - The Arcade Game Space Station Omega Misc. Author Info : But Goober!? Why are you making Doom maps again? Description : A tech demo of 3D moving floors. There's still some things that I want to do to it, but as a start this is pretty neat. Additional Credits to : The entire internet. You earned it. =========================================================================== * Play Information * Executable needed : ZDoom 2.6.1 or GZDoom 1.7.0 IWAD Needed : DOOM2.WAD Map # : MAP01 Single Player : Yes Cooperative 2-4 Player : Yes Deathmatch 2-4 Player : No, but no reason why not with some starts Other game styles : No Difficulty Settings : No New Graphics : No New Sounds : No New Demos : No DEH Patch : No * Construction * Base : From scratch. Build Time : Three hours. Tool(s) used : Doom Builder 2. Known Bugs : More like known limitations. Will Not Run With... : Alan Wake * General info * Has it really been 10 years since STARBOX.WAD? Earlier this morning, I got an idea on how I could implement moving 3D floors. Except they wouldn't be 3D floors as such. They'd be a use of polyobjects with walkable mid textures. A bit of experimenting (and finding a Doomworld thread from last year) soon showed me the futility of my idea - that being that impassable polyobjects will push you out of the way. However, since I'd also planned on implemting height variation effectively, I'd also been playing around with sector heights in my polygon control sector. This gave me an interesting discovery - if I set my texture offsets to *lower* than the control sector's floor height, I didn't need walkable mid textures. The polygon would spawn with that sector's height. Or, in other words, it was entirely possible to replicate oldschool 3D floors purely with polyobjects. So, the only line flags I set on my polyobject lines were doublesided, lower unpegged, and clip middle texture. This made my polyobject completely unblocking while moving. Combined with the texture offset and a control sector floor height set higher than the target sector floor height, I had a polyobject that would push me out of the way if I got in front of it but *not* if I stood on top of it. Now, some might call that mission success. But from the start, I was programming some scripts with friction in mind. Being on a moving floor that slides away from me isn't good enough. I have to move with the floor. And this is the tricky part. To know if you're on a floor, generally these days you'd use an "Actor Hits Floor" thing. But that doesn't work. So you need to refer to linedefs. The script expects all exterior linedefs of your polyobject to be facing out. The script that activates on crossing it then checks which side it was activated from before determining if the player is on or off. Next, you need to know if the player's Z value matches the floor's Z value. To do this, I check against a dummy thing inside the control sector. You could use GetSectorFloorZ in the same manner, but you still need a dummy thing inside that control sector for reference. If the Z height matches, the player is on the floor and thus friction should be applied. Using SetActorPosition was bad. It removed all freedom of moving on a platform. To implement friction, I needed to alter the player's velocity. Finding the correct velocity value was trial and error. I'm sure there's some mathematically correct way to find out the correct velocity to apply based on referring to the Doom movement code and plugging it in to an equation, but as it stands dividing the difference of the floor's previous position to it's current position by 10.7 gets something very close to the correct friction on the platform. All that remains is to set up your polyobject's move path. The path I've set up moves tri-directionally - it moves on X and Y as a polyobject does, and it moves along Z at the same time thanks to altering the control sector. Oh, and because I don't like showing off anywhere near enough, it is also multiplayer compatible. LIMITATIONS * You can't walk under the floor. * Things get screwy if your polyobject goes below the normal floor. * Rotational friction is not currently supported. There is no GetPolyobjAngle to compare against. * I'm disabling view bob when setting the velocity. I quite simply haven't checked if leaving it enabled will bob your view as the platform moves. THE WAY FORWARD FROM HERE * Removing the sector height modification and simply changing the texture offsets. * To account for the now-missing height, anchor some invisible bridge things to the poly object. * See if we can't get a flat rendering over that 3D floor. Transfer_Heights trickery? Non-solid 3D floor trickery? =========================================================================== * Copyright / Permissions * Authors MAY use the contents of this file as a base for modification or reuse as long as they give credit to me. You MAY distribute this file, provided you include this text file, with no modifications. You may distribute this file in any electronic format (BBS, Diskette, CD, etc) as long as you include this file intact.
Maps
