Positive ZDoom development

[Nash]

Maybe when the scripting stuff is finally in an official release, an effort to remove and clean up redundant/baggage/cruft features can be made so the source becomes lighter and easier to manage again? IDK

(although that would mean that future versions will not support old mods anymore, TBH that's not a bad thing in my opinion... GZDoom is slowly not supporting old hardware, as an example... development happens, things get unsupported... it happens)

[Graf Zahl]

Maybe when the scripting stuff is finally in an official release, an effort to remove and clean up redundant/baggage/cruft features can be made so the source becomes lighter and easier to manage again? IDK

Not going to happen. Such an attempt would kill ZDoom as a modding engine.

[Gez]

At best they could be exported to script form, like how actors have been moved out of the source code and shuffled away to DECORATE. For example, there's many redundant action functions that could be exported this way, like [wiki]A_SPosAttackUseAtkSound[/wiki]. As long as backward compatibility is kept, it'd be acceptable.

Then it's a question of balancing the potential gains of doing that (which ones?) against the "don't fix what ain't broke" factor.

[NeuralStunner]

[wiki]A_SPosAttackUseAtkSound[/wiki]

Best action function ever?

Nash, smells like a goal for a new fork. Such a clean codebase actually sounds really nice, but good luck keeping it maintained.

[Enjay]

Not going to happen. Such an attempt would kill ZDoom as a modding engine.

You are almost certainly correct in as much as the Doom community would probably walk away pretty quickly and ZDoom would just die through lack of interest. The irony being, of course, that a cleaner code base would actually be a better modding base for non-Doom work (not that anyone would be likely to take it up, at least not in numbers high enough to make it worthwhile).

Personally, I'd love a nice clean ZDoom based editing engine without all the Doom compatibility stuff required to make every HACKY'95.WAD, editing trick and engine exploit work but I'm realistic about the effort (loads) versus reward (almost zero) for whoever produced it.

[Edward-san]

I'd like to get rid of that decorate "Afrit" workaround. Who cares about those broken attacks!? I want to see half of the decorate issues (at that time) fixed!

[Graf Zahl]

Don't tell me. Sadly fixing the code will break more stuff than it'd solve.

That godforsaken Afrit, while being an impressive creation at its time surely messed up things quite thoroughly.

[Blzut3]

The code cruft in ZDoom actually isn't nearly as bad as people make it out to be. Extraneous action functions barely impact code readability and likewise for a lot of backwards compatibility bridges. (Although you might have a point about some of the compat flags.) About the only thing ZDoom would really gain from a clean slate is stricter parsing rules. When scripting is fully implemented perhaps there would be a argument for removing actor flags in a hypothetical code base though. But overall the ZDoom code is some of the best I've seen and I have no problems emulating the design in ECWolf. OK, there are some backwards compat wtfs in the script APIs, but most of those don't really impact maintainability or performance, just drives mod authors nuts. (OK it drives us nuts too, but I consider that more of an OCD thing.)

[ibm5155]

The only thing I miss is a proper map format where 3D floors would be a cave like tecnology, and a simple shadow system for some nice ilumination (At least, I think dynamic lights are just a colored sprite applied over a surface and not a real light source :S since there's a circle sprite over gzdoom.pk3)...

But I know I'll never get this, it's too much work and yada yada yada, but I'll still dreaming when at least one of this features came out (or maybe a dynamic light where it doesn't cross walls iluminating a floor where it shouldn't be iluminated ;--; )

The rest is rest, I'm enough with acs and decorate right now, if one is missing some tool, I can deal using like acs inside decorate to add extra stuff on it.

[Graf Zahl]

The only thing I miss is a proper map format where 3D floors would be a cave like tecnology, and a simple shadow system for some nice ilumination (At least, I think dynamic lights are just a colored sprite applied over a surface and not a real light source :S since there's a circle sprite over gzdoom.pk3)...

That's out of scope for the Doom map format. If you want a proper 3D format you have to use a proper 3D engine.

[ibm5155]

The only thing I miss is a proper map format where 3D floors would be a cave like tecnology, and a simple shadow system for some nice ilumination (At least, I think dynamic lights are just a colored sprite applied over a surface and not a real light source :S since there's a circle sprite over gzdoom.pk3)...

That's out of scope for the Doom map format. If you want a proper 3D format you have to use a proper 3D engine.

Indeed, Doom map format is way too 2D, for that it would require a 3D format support, or, a mixed map format where in the editor itself (like gzdoom builder) it would generate md3 models, I think it would be like this new engines does, where you have a flat BSP for the floor and the rest of the scenary would be just big 3D model...

At least, it would be easier than creating a new map format, the only thing on this case would be the colision detection , maybe people would require to add some invisible 3D floor for this case...

[VGA]

Would it be worth it to port the Odamex's 32-bit software renderer to replace Zdoom's? It looks way better because the transition between darkness levels is smoother, for example in MAP06 in Zdoom you can hardly distinguish the pillars from the starting position and moving towards them results in crappy changes in light. In Odamex it looks waaayyy better, clearer while using the proper light levels.

And I'd guess the code is cleaner, since GrafZahl hates the current software renderer and noone seems to want to touch it

[GooberMan]

Isn't there already a separate thread for that exact question?

[VGA]

Ah yes, I just found that thread and now I'm depressed ... it's sad that a multiplayer oriented fork has a better renderer, whoever worked on it might want his work to benefit the whole community and port it to Zdoom at some point.

[Graf Zahl]

it's sad that a multiplayer oriented fork has a better renderer

What makes you think that the renderer is 'better'?
Odamex is based on a very old version of ZDoom and thus is missing lots of stuff that ZDoom maps may take for granted.

For true color you need two things that currently don't exist:

- 32bit colormaps
- code that renders to a 32bit framebuffer

The first one is simple, I have done that myself a long time ago, and recreating such code should be no big deal. What this needs is a good colormap analyzer to get the correct values for fading. Of course if you want to have smooth fading things may get a bit more complicated because you need more than 32 brightness levels or use a different algorithm.

The second part is tricky. ZDoom uses lots of specialized assembly code for rendering, Odamex seems to rely on MMX/SSE2 extensions for this. So even if the feature is ported, the differences of the underlying code bases make it nearly impossible to use anything from Odamex, regardless of license.

So, asking them for permission is pointless either way. We'd have to redo this code to match ZDoom's current renderer.