Blastfrog's (probably not so) amazing pie-in-the-sky ideas emporium thread

[Blastfrog]

I was informed by a Portuguese smoked sausage that it was probably in my best interests to confine my nonsense to one big thread.

 

So, here, have a wall of text!

 

Spoiler

Kaboom: a Doom source port idea by Blastfrog

 

Kaboom is a fork of Chocolate Doom, with the aim of remaining faithful to the key behaviors and general feel of id's original DOS engine (as well as taking ideas from other versions of Doom either developed or licensed by id), while removing static limits, fixing bugs and providing select enhancements.

 

This port is meant to mostly consist of what I consider to be logical extensions of id's original feature set, to some extent or another. There is the occasional feature idea in this document that doesn't quite fit within this purview. It's my port, so if I feel like adding anything I want, I'm at liberty to do so.

 

At its core, it is a conservative port, despite all of the advanced features. Conservative in that it conserves what was already there, not making drastic changes to core behavior ala GZDoom. Doesn't mean that I can't go crazy in adding new periphery things.

Of course, credit to Xaser for the name, as he came up with it. Cool name, it is. Not worth seeing it go to waste! Also has the advantage of not having "Doom" in the name (fuck you zenimax)

 

I think "Toffee Doom" should be the nickname for the prototype before Boom/MBF support is added, to reflect that it's more of a souped-up Chocolate Doom at that stage than what I intend it to eventually become.

 

One idea is to merge ZDoom Launcher 3.x with the Chocolate Doom setup program, give it a brand new front-end made from scratch, and call it "Detonator". Perhaps a generic version could be made to work with more than just Kaboom, call it "Aardvark".

 

Major (not minor) bugs (medusa, tutti-frutti, etc) would be permanently fixed/not reimplemented, whether they're present or future Chocolate Doom features. Other than any changes specified in this document, the rest of the engine shall be kept in sync with mainline Chocolate Doom.

 

Features desired for 0.x:

* Restore random sound pitch feature (slider to adjust how big the range is, 1.0 being the original range. 0.5 ought to be a good default, compromise between having it on at full blast or being turned completely off, also less likely to annoy people as full random pitch range tends to)
* Static limits lifted (option to use vanilla limits or doom+ limits, default is no limits)
* Sprite flipping does not break alignment
* Wiggle fix on sector boundaries
* Non-power of two texture support ala Jag or Boom (at least vertically)
* Gamesim bug fixes (See PrBoom+ and its compat flags)
-----
Below are permanent changes, above features are all optional via config
-----
* Support for No Rest for the Living, PS3 Master Levels and original Master Levels (take a page from Eternity in how to handle Master Levels)
* Cut any implementation of major bugs that Chocolate Doom has (no medusa, tutti-frutti, etc)
* -file parameter uses PrBoom+ behavior, vanilla behavior -file is now done via "-oldfile"
* Load WADs from zip files (no, not gzdoom/eternity style wad format replacement, it simply finds all the wads in all the directories and loads them all at once with some kind of priority system in place) (perhaps ".pkb" would be a nice filename convention, standing for "pack for kaboom")

Features desired for 1.0 and later
Any and all feature ideas below are long-term goals and not necessarily final. I know that much of this is very non-trivial!

 

Misc:

* Mass palette translation (I made a thread on DWF but it never went anywhere and it got derailed into a true color discussion, still want to push for this to eventually happen) Also translates hardcoded engine-side color indices like player translation and automap colors

* Texture conversion between Doom 1/2/TNT/Plutonia in a way similar to Eternity when those textures are missing
* Do not crash on missing textures or flats, just use checkerboard placeholder ala Eternity and GZDoom

* Better netcode (wait until Edward850 works his magic on Eternity in this regard, then I take it and port it to Kaboom)

* Chocorenderlimits emulation (perhaps call the parameter "-renderstats") (even if i have to partially render but not draw the game separately from the user's view just to make sure the right stats are shown)

 

* "map game" mode. This one is a silly novelty, but it would be very cool IMO. Can use standard input, robotron style twin stick, or m+kb like the game abuse or the flash game thing-thing. automap is always up (cannot close), but visible lines always update like in gzdoom,
and actors are visible ala IDDT only visible when they are in a 360 degree view of the player's position (does not take height into account as long as there is an opening, even if you can't really see it in 3d view)

Idea: make retro style vector art as frames in place of sprites (like a vectrex console game), from the top down view.
no rotation sprites are shown from the front view instead of top down and are always forced to be aligned the same on automap regardless of actor angle
obviously, sprites that do have rotation would rotate on the automap. this would mean decorations, pickups, corpses would all be front view while live monsters and players are top down rotating vector images

Actually, maybe take that feature and expand it in another Chocolate Doom fork called "Vector Doom" with a hi-res vector renderer with antialiasing, a subtle glow behind the lines, CRT monitor bezel border graphics that even have a subtle additive blended reflection of the screen contents on the bezel sides.
All art would be redone as vector. Internal resolution of renderer could be 1600x1200.

 

 

Rendering:

 

* Have some kind of tonemap that emulates how the colors and brightness would have been seen on (pro quality, not consumer grade) VGA/SVGA CRT monitors of 1992-1995

* Non power of two walls horizontally
* Flats on walls and textures on planes
* Planes can handle non power of two textures
* Colorspace mode emulation (12-bit, 15-bit, 16-bit, 18-bit, and 24-bit)

* Quake 1 style LOD mipmaps (option to define how close/far they switch to lower detail levels, 1.0 would act like Quake where it does not allow to skip any pixels, 0.5 would allow for twice as much distance until the switch, meaning that it could skip 1 pixel but not 2 or more)
    Separate on/off and intensity setting between sprites and the world (Quake 1 didn't have LOD on models or model skins, but it'd be nice to allow objects here to have LOD and to allow you to configure it separately)
    Default should be 0.5 on world and sprites

 

* Optional Jaguar style lighting mode

* Optional Wolf 3D/ROTT/Shadow Caster/Doom alpha style sprite rotation. Perhaps a slider to average the angle between this method and the standard method?

* Hi res support (only multiples of original res, I don't wanna deal with arbitrary sizes) (1x reflects vanilla, 2x reflects Crispy Doom, 3x reflects Doom Classic 1.11)
* Hi color support (inspired by Mocha Doom's method, brute force replace colormap and playpal with true color colormap/playpal hybrid)
* Widescreen support, see notes on how to handle the base resolution
* Framerate interpolation via delta time (use PrBoom+'s code, also check to see if GZDoom does anything better)
* Doomsday or GZDoom style monster movement interpolation. (former would be default)
* Smooth palette fading via interpolation (still, ignore last level as it's unused, even if that was a bug)
* PSX style palette fading (applies to world assets, not screen space)

* Not sure if this is how light diminishing actually works, but if the fades don't use all 32 colormap levels, have an option to do so! (on that note, maybe support 64, 128 and 256 levels in hi color mode) That being said, unique SECTOR light levels must remain at 16 (OR, at least quantize when loading map, even if more levels supported during play, such as light fade in/out).

* Doom retro style shadows, also expand to do glows when the actor's bright flag is on in their state (my justification is that Wolf 3D has this as a feature, even though it was just baked into the sprite with an assumed solid color background)

* 16 angle support (why not?)
* 4 angle support (heh, why not?)
* When in hi-res, thicken the automap lines
* Option to correct aspect ratio of automap projection (on by default)
* Option to prevent line "quivering" when scrolling in automap (forced to scroll on a per-pixel level instead of a sub-pixel level, didn't Jag do this?)

* Selectively make pixels fullbright and/or transparent via loaded sprite masks (like how GZDoom handles brightmaps), similar to Doom Legacy's selective transparency or Doom Retro's selective fullbright (Bungie's Marathon games have this 1-bit brightmap feature as well)
    On that note, have the option to use a special brightmap for when the sprite has the bright flag (forces the sprite to act like bright flag isn't on, with only manually selected pixels turned bright) (GZDoom ought to have this too, methinks)
    Make sure there is an intercompatible brightmap standard with GZDoom, quantized to 1-bit when used in Kaboom, GZDoom can use the full range
    Perhaps GZDoom should have alpha masks too

* New transparency mode that uses overlay blend mode to show whatever's behind it with a low contrast grayscale mask (the intent is to be more faithful to vanilla appearance while still having some form of transparency)

* Proper perspective on skies (scales up vertically toward the edges of the screen, would match how it looks when turning in GZDoom)
* Doomsday style sprites face camera (off by default, simply there for anyone who might prefer it, I don't prefer it myself)
* Do not cull sprites too early around corners (afaik the engine assumes the object isn't visible if the bounding box itself isn't)

* Try to figure something out to have better behavior when sprites are close to sector boundaries (like the torches in the four corners of that room in e1m8 on raised platforms, usually you see the base of the sprite rendered atop the lower line texture of the platform) (I may not be able to come up with a satisfactory alternate behavior, but it's worth looking into)

* stereoscopy mode? simple HMD support perhaps?
* Overbright light levels?

 

Cosmetic stuff:

* Adjustable base resolution with 2D screen element upscaler. The upscaler would be similar to XBR, and would then downscale (linear) and quantize (palettized and no partial trapsarency). Movement of 2D screen elements should be adjusted via delta for refresh rates For my own purposes, this would be to make the game run in 320x220 instead of 320x200, so that I may play it on a CRT TV in the same way as the console versions of Doom in the 90s.

* Automap can be seen without status bar

* Heavily revised alpha style helmet hud? ofc, remember to use the 2nd from the highest screen size in terms of scale (was the detail level of vanilla by default, also makes it closer to 90 degrees inside that tiny screen)

* Doom 64 style floating HUD
* Doom 64 style view kickback when firing certain weapons
* Textured automap (possibly allow to disable flat animation, also darkens to maybe like 25% or 33% brightness anyway)
* Boom style combined key icons (perhaps make my own graphics for them? eh, team TNT's are probably good enough)
* Jaguar style key icon hud blinking when using a locked item and failing to have the correct key
* Jaguar gib death status bar face (YOUR HEAD ASPLODE)

* Jaguar style big text story screens (only when the number and length of lines are short enough to reasonably fit it on one screen) (really, Doom 2's secret map messages look dumb by taking up like 5% of the screen)

* Viewbob and weaponbob scalars (1.0 is standard vanilla range, 0.75 viewbob reflects Doom Classic 1.11 behavior, 0.0 viewbob reflects SNES Doom behavior)
* Smooth weapon bobbing on low framerate (state-rate? :P) weapons like chainsaw (Strife Veteran Edition has this feature)

* Randomly flipped enemy deaths (take from Crispy, my justification for including this would be that id themselves did it in Jag Wolf 3D) (possibly except any boss monsters if there is only one of them on the map)

* Doom 3 BFG edition style head/neck model view positioning
* Lower the menus by 16 pixels when the status bar is off

* Marathon style weapon vertical sprite positioning when mouselooking (similar to Quake 1, just in 2D instead) (makes use of unused bottom portion of sprite, 1.0 scale is moving 32 pixels up/down, default is 0.5)

* Doom 3 style weapon sway when turning (1.0 is full intensity, 0.5 is default)

 

Sound stuff:

* Marathon 2 style ambient sounds assigned to sectors! Sectors get new property: ambient preset. Each preset is a list of ambient sound loops and the volumes they individually play at. Depends on which sector you're in.

* Allow for more sound channels
* SFX preprocessing to be 11025hz and 8-bit, turn interpolation off, 
* Support for WAV, FLAC and OGG for sfx
* Support for FLAC, OGG, MP3 and common module formats for music

* have optional "quick fade out" instead of actually cutting off sounds when they are to be interrupted (similar to PSX, but reflects PC behavior, a good default would be 2 tics fadeout duration) (alternately, have yet another option to go full-on PSX and not interrupt sounds at all)

* option to split voice and attack into their own channels rather than just one actor one channel. (your mouth and your gun are two different things, grunts/screams and gunshots should not interrupt each other even if coming from the same actor)

* vertical sound attenuation (takes 5:6 ratio into account, default scale is 1.0)
* PSX style reverb (on when indoors, off when in sky sector) (should have intensity scalar, 0.5 by default, 1.0 is PSX intensity)
* Post-processing filter for OPL, so that it sounds like an actual Soundblaster instead of just raw OPL output.
* Soundfont support with internal softsynth (err, I think Chocolate already has this, still, it's a feature I want)
* GUS patch support??

* True 3D sound positioning. Remember the "barbershop" video that you're supposed to listen to with headphones? That's the idea, it's not just stereo, it actually simulates the way sound distorts from different positions due to the shape of the human ear.

* OPL/GUS and/or OPL/SF2 hybrid mode, inspired by Sega Megadrive/Genesis games that used the SMPS driver such as Sonic. Some percussion (including snare, bass, etc, excluding hihat, cymbal, etc) (or optionally all percussion) would be substituted with samples while the rest remains as FM synth. Have various preprocessing and playback options for the samples such as quantization and no interpolation so that it "fits in". Samples are subject to the OPL post-processing filter in the mix by default, though this can be disabled

* Optional post-processing on sfx that emulates how GZDoom sounded back when it was still using FMOD (I may have said it was an "adulteration of the proper sound" in a post on DWF, but whatever, it does kinda sound nice and I know there are people who even prefer it) (hell, maybe even have a slider for the FMOD filter, and set it to 1.5 by default just to give it that extra bassy "oomph" to it)

* Optional subtle reverb and surround post-processing on music (not sfx, it already has 3D sound and PSX style reverb) (this would be the final step, being done after any other post-processing like Soundblaster and/or FMOD filters for SFX and/or music)

 

Game definition support:

* BEX support
* Doom Retro extended DEH/BEX support
* ANIMDEFS support
* UMAPINFO support
* Decorate-lite support (I insist that it be named "DECOLITE" :P)

 

Input:

 

* "Live" mouse input (meaning that it continues to update independent of ticrate, ala GZDoom)
* Digital (i.e. keyboard) turning simulated via virtual mouse input (helps with responsiveness issues when using uncapped framerate)
* Option for smooth accelerating/decelerating keyboard/joystick turning in the same way as SNES Wolf 3D
* Option for 1:1 turning like PC Wolf 3D and prerelease Doom (they must've added the slowtics feature very late, not even press release has it)
* Option for Doom 4 style turning and Doom 3 BFG style aim assist
* Joystick turning takes "slowtics" fake aim acceleration into account (take the code from my own fork of Eternity that only did just that) (consider reducing the slowtics time when using joystick, since it takes longer to move your thumb across a thumbstick than it does to press a dpad, button or key)
* Autouse taken from iPhone version (off by default, obviously)

* Maybe vertical looking ala Heretic?

 

It would be nice to eventually support Boom/MBF map spec (official id spec is the only supported map spec at first). Depending on where this "post-MBF map spec, designed by committee" thing ends up heading, support the new standard as well.
If it ends up remaining vaporware, well then, there's nothing to support beyond MBF. Actually, I lied; UDMF already exists, worth looking into eventual support for that, too.

 

 

The way widescreen res is handled: First, calculate the width of the picture in 1x resolution (assuming 5:6 pixels with a fixed 200 line height). Then, always round the result UP (even if fraction after decimal point is less than half).
Then, if necessary, round it UP again to the nearest multiple of 2. Lastly, we multiply it by the hi-res factor (fixed multiples of base resolution). This would mean that we'd be using 428x200 when targeting a 16:9 screen.

 

This ensures that the pixel aspect ratio remains as consistent with 5:6 as possible, without leaving a single pixel on the user's screen blank. Better to have wasted area cut off in the same manner as overscan than to have vertical borders (if we were okay with ANY pillarboxing, why would we even have widescreen support anyway?)

For all of these advanced things, I'd need the port to have its own data pack like Eternity and GZDoom do (hell, even plain TNT Boom has one). Licensing is likely an issue though, the data pack should be under Doom source license instead (if in any way applicable to the content). It would be its own git repository.

Perhaps I could include a version of the SC-55 soundfont that makes it closer to (but still better than) the way Microsoft GM sounded. Include a slightly tweaked and enhanced version of the GUS patchset as an SF2 as well.

 

 

Include the Doom enhancement pack I want to make. Expose as much as possible as normal, but have encrypted archives that require having the original IWADs to "unlock" for the stuff I can't really just give away like levels. Ultimate Doom is lazily included in Chex Quest, and Romero leaked a shitload of stuff like map sources, but I can't risk just letting the maps out there as-is... can I? It's less of an issue if I include anything else like sprites, sounds, textures. It's not legal, still, but id never really cared that much in later years, and Zenimax hasn't really said shit. The maps (for the most part) the only thing that make the IWADs unique and still have purchase value.

 

 

IDGAF (i dont give a fuck) should be a cheat, just for the sake of making use of that name. no idea what the cheat itself would actually be or do, heh (actually, how about max out armor (200), armor class (2), health (200), all six keys, give backpack, max ammo and all weapons, iddt twice, god mode, Zed's Quest style air control, infinite use distance (manual only, autouse still acts only at 64 units), infinite melee range, )
while we're on the subject of needless profanity in the game, have a command line option called "-suckitdown" that reenables the silly devmode quit messages that Romero wrote

 

while we're on the subject of quit messages in general, perhaps have a config option to show both doom 1 and 2 messages in either game (and if the sounds are available, the sounds when you confirm as well, separate option than the text itself though)

 

another idea: have a config option to disable cheats. why not? would be off by default anyway

 

Feature idea: HICOLOR lump. Basically like a PLAYPAL, but serves the role of a COLORMAP.

 

The purpose is so modders can customize the screen/light fades and such by hand for stylistic purposes. Were a project like BTSX to use it, they could ensure that the fades are still stylized by hand to preserve artistic intent when the renderer is in high color mode.

Otherwise, the engine generates one from the currently used colormap and playpal lumps

 

HICOLOR lump specification:
32 light levels from fullbright to darkest (1/32 brightness) (256 palette entries x 32)
1 level for invulnerability effect (256 palette entries x 1)
Repeat 3 more times, but with the max color fade applied for each effect (pain/berserk, item, and radsuit) (note that when I say max fade, I mean the max that is USED, the unused ones from PLAYPAL are ignored)
This should result in a raw truecolor image that is exactly 99kb with a size of 256 x 132.

 

Note to self, Marcaek said this on DWF: "Boom/MBF introduced their own bugs which should be fixed, also fuck monsters being knocked off of ledges while alive so much". So, keep that in mind when I'm trying to port PrBoom+'s altered behaviors, be careful not to make the same mistakes that Team TNT or others made.

Given this port's id (and not Boom) centric philosophy, unless there's really good reason to (compatibility with existing Boom/MBF mods that rely on the broken behavior to function as intended), don't even include the option to use these additional non-id bugs. Why should I? Screw bugs.

 

 

THE DIRECTORY OF INSANE IDEAS (I do not take these even remotely seriously, even though I'd like to have them)

* Primitive stencil shadows. only affected by map geometry, sprites do not cast shadows. infinite distance, does not decay. should seamlessly replace player light casting from gunfire, then monsters get to do it too (but it would fade quickly in distance, only if you're close to the monster do you see their casted light)
* Kill off y-shearing, even if this requires a totally new renderer (hmm, QZDoom's code could be useful).
* Doom 64 gradients! :D
* 3D floors as capable as GZDoom's
* Portals as capable as Eternity's
* Slopes! How does Odamex handle collision? GZDoom's method is terrible, and Eternity's is nonexistant.
* ACS, with at least some reasonable level of ZDoom extension support (I guess just go with whatever Eternity does)
* mouselook, ala heretic, although if ROTT used a taller range by any chance, go with that instead of Heretic's range, because Tom Hall is more officially Doom related than the guys who did Heretic.
* jump
* crouch

 

Edited May 26, 2017 by Blastfrog : FUCK YOU FORUM SOFTWARE STOP EATING MY LINE BREAKS

[Lollie]

God, that was a hell of a spoiler to read. (And I read it before you had a chance to fix the line breaks. ;__; ) How long have you been sitting on this grab-bag of port feature ideas?

 

5 hours ago, Blastfrog said:

* "map game" mode. This one is a silly novelty, but it would be very cool IMO. Can use standard input, robotron style twin stick, or m+kb like the game abuse or the flash game thing-thing. automap is always up (cannot close), but visible lines always update like in gzdoom,
and actors are visible ala IDDT only visible when they are in a 360 degree view of the player's position (does not take height into account as long as there is an opening, even if you can't really see it in 3d view)

Can I just say, an always-on map view as a spectator mode would be great on its own. Little feature that worked really nicely in some DS/3DS portable Doom ports. Otherwise I dig all the automap ideas you had in here. HUD-less, thicker lines, all good shit. Don't know how you'd handle height in map-game mode, unless you used a top-down camera with the actual level (instead of the flat 2D automap).

 

Edit: Hell, has anyone attempted a Top-Down Doom? Stuff like Nuclear Throne, Hotline Miami, PS1's Loaded, etc. Sounds like a huge no-brainer.

 

5 hours ago, Blastfrog said:

Actually, maybe take that feature and expand it in another Chocolate Doom fork called "Vector Doom" with a hi-res vector renderer with antialiasing, a subtle glow behind the lines, CRT monitor bezel border graphics that even have a subtle additive blended reflection of the screen contents on the bezel sides.

Shader support, perhaps?

 

5 hours ago, Blastfrog said:

IDGAF (i dont give a fuck) should be a cheat, just for the sake of making use of that name. no idea what the cheat itself would actually be or do, heh

Health, armor and ammo always at max + all keys always available, as opposed to IDFA/IDKFA's ammo refills and keys only sticking around for one level.

 

Alternatively, the Doom equivalent of Google's "I'm Feeling Lucky" button. Randomize everything: Level (and music), starting health, armor, weapons and ammo. Good luck, player!

Edited May 26, 2017 by Lollie

[Blastfrog]

22 minutes ago, Lollie said:

God, that was a hell of a spoiler to read. (And I read it before you had a chance to fix the line breaks. ;__; ) How long have you been sitting on this grab-bag of port feature ideas?

Heh. I've been sitting on a lot of these ideas for years, but I started the text document that I pasted in (that the forum software so kindly removed all of the line breaks for me) about a week or two ago.

 

I find it funny that at the end there's a "directory of insane ideas". To myself: err, don't you mean pretty much the entire document?

 

It's not really a serious document, it's just every single idea that I think would be cool to have in a Doom port, for whatever that's worth.

 

As usual, I've stayed up all night and am too tired to think straight now, I'll comment on the other things you said when I'm rested.

[Blastfrog]

Being the irresponsible bastard that I am, I opted to drink some coffee rather than give my body the rest it needs. Heh. Well, I feel more alert now, so here are my responses:

 

By "always-on map view as a spectator mode", are you referring to a small automap as part of the HUD during normal gameplay? If so, that is certainly something that I'd like as well. If the helmet HUD idea is done, it's a no-brainer where to put it on the screen. Otherwise, I guess you could configure its size, transparency and position when using any other HUD.

 

CRT shaders would be cool, yes. Should have some options to customize it so that it can be a less intrusive effect (no curvature distortion or grille mask, but still having some subtle scanlines, blurring and glow on dark pixels next to bright ones).

 

I guess if IDGAF is to be some kind of "ultimate cheat", then infinite ammo, no health/armor/ammo limit, and keeping keys between levels is good.

[Voros]

Heh, I kinda halfway-implemented that in Chocolate Doom once. Never got to test it out though. 

 

Frankly, I can't figure exactly what IDGAF should do. Here's a thread I made on the subject: https://www.doomworld.com/forum/topic/92736-if-idgaf-was-a-cheat-code/

[Blastfrog]

I was just about to edit my previous post to note that I didn't come up with the name, but couldn't remember who did.

 

That answers that question. Thanks for your creativity and sense of humor! I stuck it in the document because it randomly popped back up in my head and I didn't want to forget it again.

[Lollie]

1 hour ago, Blastfrog said:

By "always-on map view as a spectator mode", are you referring to a small automap as part of the HUD during normal gameplay? If so, that is certainly something that I'd like as well. If the helmet HUD idea is done, it's a no-brainer where to put it on the screen. Otherwise, I guess you could configure its size, transparency and position when using any other HUD.

I'm thinking more along the lines of Chocolate Doom's three screen mode, where the left and right windows act as "observers" in a solo multiplayer game. I've played around with using the -left client for a second-screen automap. It requires the automap to be opened at the start of each level, and the automap only reveals what the observer can see (the map is constantly revealing everything at your left side, instead of in front), but it still feels nice to have!

 

The thought mostly comes from this PrBoom 3DS port. The automap was always present on the bottom screen, really convenient. It made more sense on the 3DS of course, not everyone's going to have a second monitor on their PC.

 

All that said, I have seen a ZDoom/GZDoom mod that adds a small automap to the hud: Doom Delta (Doomworld, ZDoom Forums), it looks like it works rather nicely.

[Olroda]

Having read this almost a year ago, I found the recent developments amusing.
For the record, though; I don't find them "shitty".

[Blastfrog]

I really regret the tone I had when talking on the Pfhorums. I still think that their refusal to even address the abysmal, poorly aged, speed-capped, low resolution and velocity-based mouse control holds Marathon back from being enjoyed by more people.

 

And, what recent developments do you refer to? Did I miss something?

 

EDIT: That reminds me, I ought to update my avatar here to my pixel art Gooseman avatar I used there. I've had the blinking cat long enough, cool as it is. Also, due to my HDD crash last year, I don't have my original hi-res source anymore, it doesn't look so hot being scaled in the new forum software with bigger avatars.

Edited May 26, 2017 by Blastfrog

[Olroda]

39 minutes ago, Blastfrog said:

And, what recent developments do you refer to? Did I miss something?

Nah, just that you were "confined" to a single thread there also.

The port ideas sure sound interesting. Is the port on the concept stage, or have you implemented anything as of yet?

[Voros]

The only reason I don't like Marathon, Duke Nukem 3D and Blood (not sure if the new gdxBlood fixes it) is because mouselook on a software renderer is fucking terrible. Last I played Marathon, it seemed to run on OpenGL, but fuck that limited mouselook. No. Fuck the terrible controls too.

 

If mouselook doesn't work like mouselook, don't put it in at all. Doom could only look left and right, and it worked. Quake was completely free and it worked, given that it's a 3D engine with hardware rendering. 

 

Maybe sometime in the future (when I get rad coding skills, hopefully), I could have a look at Aleph One and see if I can implement some basic changes, and hopefully, if the talented community here and elsewhere give positive reception,the more advanced stuff will come from others bit by bit, or something like that.

 

[Blastfrog]

1 hour ago, Olroda said:

Nah, just that you were "confined" to a single thread there also.

Yeahhh, I have a tendency to overdo things. :P

 

1 hour ago, Olroda said:

Is the port on the concept stage, or have you implemented anything as of yet?

Oh, good lord, no. I wish!

 

Literally the only thing in that entire document that I have actually written and completed a feature is adapting gamepad turning to use the keyboard turning style false aim acceleration (that, and the ZQ code changes I already made there for air control, but like all my code, it's bad). It's pretty old though, and I'm terrible at organization. I'll dig around and see if I can find it in my files, and I'll post the code here if I do find it.

 

It's not the prettiest code either and was sort of just grafted on top of the existing behavior. A better way to do it would be to have an option, but I was more concerned with just getting it working.

 

EDIT: Seems to be gone. I did find my old Eternity based Zed's Quest source code* before I moved that project to GZDoom, however, which has a completely original implementation of aim acceleration that is entirely unlike Doom's.

 

*(not my other Eternity fork that was only made for personal use that had just the aim acceleration)

 

Not quite relevant to this hypothetical "Kaboom" source port, but here it is, nevertheless:

Spoiler

	  double joyacc; // -Blastfrog
	  bool sameside;
	  double inputX;
	  double increment;
	  double joyacc2;
	  bool sameside2;
	  double inputY;
	  double increment2;

------

void G_BuildTiccmd(ticcmd_t *cmd)
{
   bool sendcenterview = false;
   int speed;
   int tspeed;
   int forward;
   int side;
   int newweapon;            // phares
   int look = 0; 
   int mlook = 0;
   int flyheight = 0;
   static int prevmlook = 0;
   ticcmd_t *base;
   double tmousex, tmousey;     // local mousex, mousey
   playerclass_t *pc = players[consoleplayer].pclass;

   base = I_BaseTiccmd();    // empty, or external driver
   memcpy(cmd, base, sizeof(*cmd));

   cmd->consistency = consistency[consoleplayer][maketic%BACKUPTICS];

   if(autorun)
      speed = !(runiswalk && gameactions[ka_speed]);
   else
      speed = gameactions[ka_speed];

   forward = side = 0;

   // use two stage accelerative turning on the keyboard and joystick
   if(gameactions[ka_right] || gameactions[ka_left])
      turnheld += ticdup;
   else
      turnheld = 0;

   if(turnheld < SLOWTURNTICS)
      tspeed = 2;             // slow turn
   else
      tspeed = speed;

   // turn 180 degrees in one keystroke? -- phares
   if(gameactions[ka_flip])
   {
      cmd->angleturn += (int16_t)QUICKREVERSE;
      gameactions[ka_flip] = false;
   }

   // let movement keys cancel each other out
   if(gameactions[ka_strafe])
   {
      if(gameactions[ka_right])
         side += pc->sidemove[speed];
      if(gameactions[ka_left])
         side -= pc->sidemove[speed];
      
      // analog axes: turn becomes stafe if strafe-on is held
      side += (int)(pc->sidemove[speed] * joyaxes[axis_turn]);
   }
   else
   {
      /*if(gameactions[ka_right])
         cmd->angleturn -= (int16_t)pc->angleturn[tspeed];
      if(gameactions[ka_left])
         cmd->angleturn += (int16_t)pc->angleturn[tspeed];

	  if(joyaxes[axis_turn] != 0)
         turnheldjoy += 1;
      else
         turnheldjoy = 0;

      if(turnheldjoy < 6)
	  {
		 if(joyaxes[axis_turn] < -0.5)
			 cmd->angleturn -= (int16_t)(pc->angleturn[speed] * -0.5);
		 else if(joyaxes[axis_turn] > 0.5)
			 cmd->angleturn -= (int16_t)(pc->angleturn[speed] * 0.5);
		 else
			 cmd->angleturn -= (int16_t)(pc->angleturn[speed] * joyaxes[axis_turn]);
	  }
	  else
	  {
		 cmd->angleturn -= (int16_t)(pc->angleturn[speed] * joyaxes[axis_turn]);
	  }*/

	// Thanks to BrainMuncher for some assistance with the aim acceleration code! -Blastfrog

	  if(gameactions[ka_right])
		inputX = 1.0;
	  else if(gameactions[ka_left])
		inputX = -1.0;
	  else
		inputX = joyaxes[axis_turn];

	  double incrementBase = 0.066;

	  //if input is further from the center of axis than current speed,
	  // and both are on the same side of center, use acceleration rate
	  if((joyacc > 0 && inputX > 0) || (joyacc < 0 && inputX < 0))
		sameside = true;
	  else
		sameside = false;
	
	  if(((abs(inputX) > abs(joyacc) && abs(inputX) > 0) || (abs(inputX) < abs(joyacc) && abs(inputX) < 0)) && sameside == 1) // Same side, accelerate
		  increment = incrementBase;
	  else if(((abs(inputX) > abs(joyacc) && abs(inputX) > 0) || (abs(inputX) < abs(joyacc) && abs(inputX) < 0)) && sameside == 0) // Opposite side, decelerate faster
		  increment = incrementBase * 5; // * 5
	  else
		  increment = incrementBase * 4; // * 4 // Same side, decelerate

	  //How far from current rate is the input?
	  double delta = 0;
	  delta = inputX - joyacc;

	  //Limit adjustment to +/- 0.065 or 0.13
	  if(delta > increment)
		  delta = increment;
	  else if(delta < -increment)
		  delta = -increment;

	  joyacc += delta;
	  
	  cmd->angleturn -= (int16_t)(pc->angleturn[speed] * joyacc);
   }

   // gamepad dedicated analog strafe axis applies regardless
   side += (int)(pc->sidemove[speed] * joyaxes[axis_strafe]);

   if(gameactions[ka_forward])
      forward += pc->forwardmove[speed];
   if(gameactions[ka_backward])
      forward -= pc->forwardmove[speed];

   // analog movement axis
   forward += (int)(pc->forwardmove[speed] * joyaxes[axis_move]);

   if(gameactions[ka_moveright])
      side += pc->sidemove[speed];
   if(gameactions[ka_moveleft])
      side -= pc->sidemove[speed];
   
   if(gameactions[ka_jump])                // -- joek 12/22/07
      cmd->actions |= AC_JUMP;
   
   mlook = allowmlook && (gameactions[ka_mlook] || automlook);

   // console commands
   cmd->chatchar = C_dequeueChatChar();

   if(gameactions[ka_attack])
      cmd->buttons |= BT_ATTACK;

   if(gameactions[ka_use])
      cmd->buttons |= BT_USE;

   // phares:
   // Toggle between the top 2 favorite weapons.
   // If not currently aiming one of these, switch to
   // the favorite. Only switch if you possess the weapon.
   
   // killough 3/22/98:
   //
   // Perform automatic weapons switch here rather than in p_pspr.c,
   // except in demo_compatibility mode.
   //
   // killough 3/26/98, 4/2/98: fix autoswitch when no weapons are left

   //
   // NETCODE_FIXME -- WEAPON_FIXME -- G_BuildTiccmd
   //
   // In order to later support dynamic weapons, the way weapon
   // changes are handled is going to have to be different from
   // either of the old systems. Packing weapon changes into the ticcmd
   // isn't going to be sufficient any more, there's not enough space
   // to support more than 16 weapons.
   //
 
   if((!demo_compatibility && players[consoleplayer].attackdown &&
       !P_CheckAmmo(&players[consoleplayer])) || gameactions[ka_nextweapon])
   {
      newweapon = P_SwitchWeapon(&players[consoleplayer]); // phares
   }
   else
   {                                 // phares 02/26/98: Added gamemode checks
      newweapon =
        gameactions[ka_weapon1] ? wp_fist :    // killough 5/2/98: reformatted
        gameactions[ka_weapon2] ? wp_pistol :
        gameactions[ka_weapon3] ? wp_shotgun :
        gameactions[ka_weapon4] ? wp_chaingun :
        gameactions[ka_weapon5] ? wp_missile :
        gameactions[ka_weapon6] && GameModeInfo->id != shareware ? wp_plasma :
        gameactions[ka_weapon7] && GameModeInfo->id != shareware ? wp_bfg :
        gameactions[ka_weapon8] ? wp_chainsaw :
        gameactions[ka_weapon9] && enable_ssg ? wp_supershotgun :
        wp_nochange;

      // killough 3/22/98: For network and demo consistency with the
      // new weapons preferences, we must do the weapons switches here
      // instead of in p_user.c. But for old demos we must do it in
      // p_user.c according to the old rules. Therefore demo_compatibility
      // determines where the weapons switch is made.

      // killough 2/8/98:
      // Allow user to switch to fist even if they have chainsaw.
      // Switch to fist or chainsaw based on preferences.
      // Switch to shotgun or SSG based on preferences.
      //
      // killough 10/98: make SG/SSG and Fist/Chainsaw
      // weapon toggles optional
      
      if(!demo_compatibility && doom_weapon_toggles)
      {
         const player_t *player = &players[consoleplayer];

         // only select chainsaw from '1' if it's owned, it's
         // not already in use, and the player prefers it or
         // the fist is already in use, or the player does not
         // have the berserker strength.

         if(newweapon==wp_fist && player->weaponowned[wp_chainsaw] &&
            player->readyweapon!=wp_chainsaw &&
            (player->readyweapon==wp_fist ||
             !player->powers[pw_strength] ||
             P_WeaponPreferred(wp_chainsaw, wp_fist)))
         {
            newweapon = wp_chainsaw;
         }

         // Select SSG from '3' only if it's owned and the player
         // does not have a shotgun, or if the shotgun is already
         // in use, or if the SSG is not already in use and the
         // player prefers it.

         if(newweapon == wp_shotgun && enable_ssg &&
            player->weaponowned[wp_supershotgun] &&
            (!player->weaponowned[wp_shotgun] ||
             player->readyweapon == wp_shotgun ||
             (player->readyweapon != wp_supershotgun &&
              P_WeaponPreferred(wp_supershotgun, wp_shotgun))))
         {
            newweapon = wp_supershotgun;
         }
      }
      // killough 2/8/98, 3/22/98 -- end of weapon selection changes
   }

   // haleyjd 03/06/09: next/prev weapon actions
   if(gameactions[ka_weaponup])
      newweapon = P_NextWeapon(&players[consoleplayer]);
   else if(gameactions[ka_weapondown])
      newweapon = P_PrevWeapon(&players[consoleplayer]);

   if(newweapon != wp_nochange)
   {
      cmd->buttons |= BT_CHANGE;
      cmd->buttons |= newweapon << BT_WEAPONSHIFT;
   }

   // mouse
  
   // forward double click -- haleyjd: still allow double clicks
   if(mouseb_dblc2 >= 0 && mousebuttons[mouseb_dblc2] != dclickstate && dclicktime > 1)
   {
      dclickstate = mousebuttons[mouseb_dblc2];
      
      if(dclickstate)
         dclicks++;

      if(dclicks == 2)
      {
         cmd->buttons |= BT_USE;
         dclicks = 0;
      }
      else
         dclicktime = 0;
   }
   else if((dclicktime += ticdup) > 20)
   {
      dclicks = 0;
      dclickstate = false;
   }

   // strafe double click

   if(mouseb_dblc1 >= 0 && mousebuttons[mouseb_dblc1] != dclickstate2 && dclicktime2 > 1 )
   {
      dclickstate2 = mousebuttons[mouseb_dblc1];

      if(dclickstate2)
         dclicks2++;
      
      if(dclicks2 == 2)
      {
         cmd->buttons |= BT_USE;
         dclicks2 = 0;
      }
      else
         dclicktime2 = 0;
   }
   else if((dclicktime2 += ticdup) > 20)
   {
      dclicks2 = 0;
      dclickstate2 = false;
   }

   // sf: smooth out the mouse movement
   // change to use tmousex, y   

   tmousex = mousex;
   tmousey = mousey;

   // we average the mouse movement as well
   // this is most important in smoothing movement
   if(smooth_turning)
   {
      static double oldmousex=0.0, mousex2;
      static double oldmousey=0.0, mousey2;

      mousex2 = tmousex; mousey2 = tmousey;
      tmousex = (tmousex + oldmousex) / 2.0;        // average
      oldmousex = mousex2;
      tmousey = (tmousey + oldmousey) / 2.0;        // average
      oldmousey = mousey2;
   }

   // YSHEAR_FIXME: add arrow keylook?

   if(mlook)
   {
      // YSHEAR_FIXME: provide separate mlook speed setting?
      int lookval = (int)(tmousey * 16.0 / ((double)ticdup));
      if(invert_mouse)
         look -= lookval;
      else
         look += lookval;
   }
   else
   {                // just stopped mlooking?
      // YSHEAR_FIXME: make lookspring configurable
      if(prevmlook)
         sendcenterview = true;

      // haleyjd 10/24/08: novert support
      if(!novert)
         forward += (int)tmousey;
   }
   prevmlook = mlook;
/*
   // analog gamepad look
   look += (int)(pc->lookspeed[1] * joyaxes[axis_look] * (invert_padlook ? -1.0 : 1.0));
   
   if(gameactions[ka_lookup])
      look += pc->lookspeed[speed];
   if(gameactions[ka_lookdown])
      look -= pc->lookspeed[speed];
   if(gameactions[ka_center])
      sendcenterview = true;
*/

	  if(gameactions[ka_lookup])
		inputY = 1.0;
	  else if(gameactions[ka_lookdown])
		inputY = -1.0;
	  else
		inputY = joyaxes[axis_look];

	  double incrementBase2 = 0.099;
	
	  //if input is further from the center of axis than current speed,
	  // and both are on the same side of center, use acceleration rate
	  if((joyacc2 > 0 && inputY > 0) || (joyacc2 < 0 && inputY < 0))
		sameside2 = true;
	  else
		sameside2 = false;
	
	  if(((abs(inputY) > abs(joyacc2) && abs(inputY) > 0) || (abs(inputY) < abs(joyacc2) && abs(inputY) < 0)) && sameside2 == 1) // Same side, accelerate
		  increment2 = incrementBase2;
	  else if(((abs(inputY) > abs(joyacc2) && abs(inputY) > 0) || (abs(inputY) < abs(joyacc2) && abs(inputY) < 0)) && sameside2 == 0) // Opposite side, decelerate faster
		  increment2 = incrementBase2 * 5;
	  else // Same side, decelerate
		  increment2 = incrementBase2 * 4;

	  //How far from current rate is the input?
	  double delta2 = 0;
	  delta2 = inputY - joyacc2;

	  //Limit adjustment to +/- 0.065 or 0.13
	  if(delta2 > increment2)
		  delta2 = increment2;
	  else if(delta2 < -increment2)
		  delta2 = -increment2;

	  joyacc2 += delta2;
	  
	  look += (int16_t)(pc->lookspeed[1] * joyacc2);

   // haleyjd: special value for view centering
   if(sendcenterview)
      look = -32768;
   else
   {
      if(look > 32767)
         look = 32767;
      else if(look < -32767)
         look = -32767;
   }

   // haleyjd 06/05/12: flight
   if(gameactions[ka_flyup])
      flyheight = FLIGHT_IMPULSE_AMT;
   if(gameactions[ka_flydown])
      flyheight = -FLIGHT_IMPULSE_AMT;

   // haleyjd 05/19/13: analog fly axis
   if(flyheight == 0)
      flyheight = (int)(joyaxes[axis_fly] * FLIGHT_IMPULSE_AMT);

   if(gameactions[ka_flycenter])
   {
      flyheight = FLIGHT_CENTER;
      look = -32768;
   }


   if(gameactions[ka_strafe])
      side += (int)(tmousex * 2.0);
   else
      cmd->angleturn -= (int)(tmousex * 8.0);

   if(forward > MAXPLMOVE)
      forward = MAXPLMOVE;
   else if(forward < -MAXPLMOVE)
      forward = -MAXPLMOVE;
   
   if(side > MAXPLMOVE)
      side = MAXPLMOVE;
   else if(side < -MAXPLMOVE)
      side = -MAXPLMOVE;

   cmd->forwardmove += forward;
   cmd->sidemove += side;
   cmd->look = look;
   cmd->fly = flyheight;

   // special buttons
   if(sendpause)
   {
      sendpause = false;
      cmd->buttons = BT_SPECIAL | BTS_PAUSE;
   }

   // killough 10/6/98: suppress savegames in demos
   if(sendsave && !demoplayback)
   {
      sendsave = false;
      cmd->buttons = BT_SPECIAL | BTS_SAVEGAME | (savegameslot << BTS_SAVESHIFT);
   }

   mousex = mousey = 0.0;
}

 

 

Worth noting that I copied the entire block of code, firstly because I didn't feel like bothering to isolate my changes, secondly so that you can see the context among Eternity's original code.

 

1 hour ago, Voros said:

The only reason I don't like Marathon, Duke Nukem 3D and Blood (not sure if the new gdxBlood fixes it) is because mouselook on a software renderer is fucking terrible.

Aleph One has three renderers; software, "classic" GL and "shader" GL. Unless your computer is powered by Casoline, you ought to pick the latter of the GL renderers. It has proper perspective (no y-shearing) and fully supports the features of the software renderer (such as fuzz effects and sprites drawing inside of floors).

 

1 hour ago, Voros said:

Fuck the terrible controls too.

Marathon didn't have proper mouse support, it literally emulated a joystick type input. I had a (hacky) solution that would've kept the internal workings identical*, but provide all of the benefits of real mouse input, but this was ignored. The idea was to add a layer of abstraction so that the translation to velocity would've properly reflected the player's input, rather than a crude approximation.

 

*(for purposes of demo sync, net play, and simply not having to make major changes to the core behavior)

 

1 hour ago, Voros said:

Quake was completely free and it worked, given that it's a 3D engine with hardware rendering.

It was actually a software rendered game, first and foremost. Looks better that way, too. Crisp textures, and overbright lighting. These days, that's not a problem with modern video cards, but back then, it wasn't able to be done so easily for reasons I don't know.

 

1 hour ago, Voros said:

Maybe sometime in the future (when I get rad coding skills, hopefully), I could have a look at Aleph One and see if I can implement some basic changes, and hopefully, if the talented community here and elsewhere give positive reception,the more advanced stuff will come from others bit by bit, or something like that.

This is something that a classic like Marathon deserves. It is such a good fucking game, and nobody knows it. I don't particularly care about the desires of the existing Marathon community, they're fine with the status-quo, and more power to them. I'm more concerned with trying to bring the game a new audience so that more people can appreciate the pure genius that is early Bungie's game design and storytelling. It was so far ahead of its time.

Edited May 26, 2017 by Blastfrog

[Voros]

20 minutes ago, Blastfrog said:

I'm more concerned with trying to bring the game a new audience so that more people can appreciate the pure genius that is early Bungie's game design and storytelling. It was so far ahead of its time.

Strife kinda suffers from this too. It's story telling elements, multiple endings, character progression, all in first person, was pretty much ahead of its time. At least there's proper support for it now and can be legally bought too. 

 

As for Quake, I think I remember it running in software mode via dosbox, but at least the mouselook was comfortable to use.

[Woolie Wool]

To be frank, this port idea of yours sounds massively bloated with unnecessary cosmetic froufrou (and I highly doubt the ability of any set of shaders to make a discrete pixel screen look like a CRT). I would rather go with a much more basic feature set:

 

Phase I:

* Limit removing (of course)

* Full Boom/MBF compatibility, including BEX

* Boom-style -file behavior, with -merge deprecated.

* Elimination of tutti-frutti, Medusa, moiré, and texture size limitations

* Demo compatibility with 1.9, Boom 2.02, MBF 2.03, and PrBoom+ -complevel 9

* Widescreen (still using the vertical resolution and pixel scaling of the standard 320x200, so 16:10 would be around 384x200)

* Crispy Doom's 400p high detail mode

* Mouselook and crosshair, with the option of a few custom crosshairs or the message font + character.

* Boom's compatibility flags plus flags to turn on/off various vanilla bugs like elastic collisions and ouch face behavior

* Revamped setup/launcher that can select any available midi device (just like GZDoom) and choose an iwad

* v1.9 style text startup screen (doesn't have to be identical to 1.9's) with customization via a special lump

* MAPINFO, either through UMAPINFO or a cut-down ZDoom MAPINFO parser that ignores ZDoom-specific stuff

* A few basic content hacks like colored blood and centered weapons. Must be deprecated/removed in Phase II.

 

Phase II:

* 44.1/48 KHz sound, ogg and flac support, non-MIDI music

* Optional FPS cap removal

* Many ZDoom special lumps like SNDINFO and SBARINFO, with a restricted feature set

* Basic DECORATE with enough functionality to recreate Dehacked patches and do Doom-style weapons and enemies. Crazy shit like modern gameplay mods would not be supported. DECORATE should be set up so maps and mods made for this port will also load and function properly in ZDoom, though they may not be 100% identical.

* Do not break demo compatibility

 

Phase III:

* Eternity compatibility, including scripting system and UDMF

* ZDoom's score system

* Basic ACS implementation

* ???

[Blastfrog]

I first thought to call it Toffee Doom and thought that it shouldn't support Boom, and it was to remain simple, but polished. Then I thought to have Boom support, and thought that Xaser's Kaboom name was good. Then I ruined the entire document by turning it into an insane every-idea-I've-ever-had dump. :P Hence why the description at the start contradicts the contents, minus the bits I added in later about "but if I want to go crazy why not lol."

 

But yeah, keeping it simple is better.

 

I made this thread less to talk about the idea for the port itself, and more about the, shall we say "unusual and esoteric" feature ideas. I'm fine with the thread heading in either direction, though.