Ask me about my source port
Graf, that's bullshit and you know it - that's not what DaniJ means, and I *know* you're smarter than that. Yeah, DaniJ's post makes sense to me, and I'm sure it makes sense to lots of people - it's straight-forward, spelled correctly, uses good grammar, and summarized nicely. But most of all, he's right.
Graf Zahl said:
In other words: the first thing ZDoom ever did (implementing support for Hexen maps) was wrong.
Even Boom made significant changes to the way WADs are handled and WADs made with Boom in mind won't work on non-compliant engines.
The original WAD format was so broken that sticking to it would have meant not being able to advance the engine much.
Sorry, but you don't make any sense at all. With that attitude no progress would be possible.
"The original WAD format was so broken"??? What?
Yes, Boom did make significant changes, and, yes, non-Boom engines will fail on Boom stuff. But the Boom approach is way different than the ZDoom approach:
* Original DOS editors practically already support Boom enhancements out of the box (a notable exception: SWITCHES/ANIMATED lumps - why they decided on these strange formats, I'll never know).
* Untested Boom support is added to a source port in a day.
* No external libraries are required to be linked, dynamically linked, etc for Boom support.
* Boom *did* "advance the engine much", and did it using the original WAD format.
And, one of my personal favorites, most Boom engines play original demos! Not only that, but they also play advanced Boom demos. Hell, PrBoom+ can play most all flavors of original Doom, Boom, MBF, etc. But, not ZDoom. Heh, ZDoom cannot even play most ZDoom demos...
Don't get me wrong, I understand that ZDoom's philosophy is different - basic support for most "easy-to-support" game formats, with a slant for improvement, bug-elimination, and advanced editing. Noble causes. That's all well and good.
But, can you take a guess as to why the "easy-to-support" formats are easy-to-support? That's right, it's because those authors gave a shit about compatibility, and shared features, and easy implementation, and openness, and humbleness, and adding features without sacrificing compatibility, at least to some degree. Here's the two mindsets. You guess which mindset goes with which port:
#1. "Let's add this cool new feature."
#2. "Let's think about how we could possibly add this cool new feature, it a way where it can either be seamlessly added to existing structures, using existing code. If that's not possible, let's do some research: Probably there are some other ports in existance that also want to add features. Maybe we can collaborate, and devise a solution that can be considered a standard, so that eventually all ports can be improved. If we can, great - let's publish that standard. If we cannot, we will try again. We will repeat this cycle until there's no chance for agreement. When we have exhausted all efforts in collaboration, we will create the new standard ourselves, but we will make damn sure that our new standard would allow the other ports to easily use our standard. Because we are considerate and believe in compatibility, we will use the most simple structures and code possible."
Somewhere in this thread, DaniJ, Quasar, and others state this point much more eloquently than I do - DaniJ: "...inconsiderate design" and Quasar: "...the one-sided nature of ZDoom driving the standards".
What I want to know is: Why would anyone, especially an accomplished programmer, defend this lazy disregard for map editors, port authors, tool authors, documentation writers, and to a lesser extent, players? It's utterly ridiculous, and it's self-perpetuating.
So, how do you improve on these points? First you have to want to. And that's what I think Quasar was doing when he created this thread.
Back to the original topic, if possible
With all the new talk these days about 32-bit rendering, I would love to see an image format that handled 8-bit as well as 32-bit images. It would be *really* nice if said method could optionally capture both the 8-bit and 32-bit versions of a patch/texture/flat/whatever, without the need for per-pixel closest-color matching, etc. That may not be what you were envisioning - so be it. But, I *do* worry that, when many ports start to adopt the 32-bit rendering stuff, we will have umpteen image formats to handle. Ironically, I'd almost be tempted to endorse PNGs, for the simple fact that, if we've all got to use *something*, I'd hate to hypocritically add another format for everyone to support :(