dpJudas wrote:My homing missile fix for Descent Rebirth was rejected (due to the maintainers there not being good at math and me not willing to fight for the bug fix by demonstrating why they were wrong).
I wouldn't bother with such projects either. If people show this blatantly that they are not up to the task, it's not worth the time.
dpJudas wrote:
There are a lot of small things that can cause a pull request to get rejected, including not knowing the contributor very well and not being sure if they will maintain what you accept. Once something is accepted into GZD it becomes the project's problem if it got problems. As a rule of thumb, the larger a change is and the less known the contributor is, the more likely the PR will be rejected unless it is 110% made exactly like the project maintainers imagine it should be. Developers are people too and sometimes it isn't worth the effort to get things merged upstream if your personal benefit isn't great enough.
Big PRs will always be scrutinized the most. Consider the two biggest external submissions ZDoom ever got aside from your true color renderer - that was the 3D floor submission for the software renderer and the portal submission.
The first 3D floor attempt was outright rejected because it was too broken, the second one was better but still required me to do some heavy fixing on it because it ran into countless edge cases with the overuse of global variables.
And the portal submission, while fully functional in the renderer required a total rewrite of the game-side code and a few feature restrictions to make it robust.
The only reason these two submissions were pushed through is that they added good value to the engine.
And now imagine the same scale but far less useful. Chances are high it won't be accepted.
dpJudas wrote:
Yes. That is often what happens. My initial true color renderer PR for ZDoom was rejected (can't remember anymore why, but it was). My homing missile fix for Descent Rebirth was rejected (due to the maintainers there not being good at math and me not willing to fight for the bug fix by demonstrating why they were wrong).
There are a lot of small things that can cause a pull request to get rejected, including not knowing the contributor very well and not being sure if they will maintain what you accept. Once something is accepted into GZD it becomes the project's problem if it got problems. As a rule of thumb, the larger a change is and the less known the contributor is, the more likely the PR will be rejected unless it is 110% made exactly like the project maintainers imagine it should be. Developers are people too and sometimes it isn't worth the effort to get things merged upstream if your personal benefit isn't great enough.
There could be any amount of reasons, i was just wondering if a perfectly functional implementation (as in, Graf would have no work to put into it in terms of fixing) would still meet a rejection. But this applies on a per usecase basis.
Thanks for the comment and everyone else involved into this discussion. It was enjoyable.
dpJudas wrote:My initial true color renderer PR for ZDoom was rejected
Well at least i merged it into a very late ZDoom (in ZDoom32) and ported later fixes, the main limitation was the lack of support for 32 bit sprites i think, it was pretty fast on really old hardware.
The rejected version wasn't that one - it was due to it using a define to control if it was targeting true color or palette. Or something like that.
About the speed, the early version had SSE2 drawers for the 4 column drawers randi had imported into Doom from Build. On old hardware this made a huge difference. It is a shame that my refactoring affected a lot of the speed improvements randi did.
Thanks for discussing the fate of Eternity. If you question why it has been slowing down lately or having bad PR, it's all for human reasons:
1. I may be the most active, but I don't have definite ownership. Quasar didn't come up and say "here's your port, do what you wish with it", though realistically I guess that whoever has the most contribution may as well have executive power. Anyway because of this, I've kept my role solely as a technical dev, who sometimes writes wiki documentation, without allocating more time for PR stuff such as the website (either inexistent, or a wiki with youfailit.net on top). If Eternity were purely my baby, I would more likely build a better presentation for it. I'm still thinking of forking off to something called Satan Doom and provide a website with red text on black background and animated flames at the bottom... But why not just focus on Eternity itself?
2. I'm torn between working on Eternity and AutoDoom (DOOM bot based on Eternity as an engine). The latter just seems to have a more visible role in the community, but the former isn't dead, judging from the feedback we still get on Discord.
3. Eternity needs to remain demo compatible, and preserve non-breaking gameplay quirks. If I fail to do that, it just becomes a ZDoom clone.
4. Real life and competing hobbies remove my time for the DOOM hobby. I may have given Graf a slightly better impression on being cooperative, but I still need to finish Umapinfo (when I do, I'll want to add the discussed level name prefix option, to satisfy the requirement at point 3 above).
5. I really like my Mac. But currently it has no good UDMF editor. And I need such an editor to test advanced Eternity stuff. So instead of developing Eternity, I have to develop this editor, which is a lot more boring than working on Eternity, which means it takes so much more time to finish.
6. Hell, because of Mac, now DOSBox is also ruined (actually not, but Boxer, its excellent Mac port, definitely is since Catalina), I'm stuck without a good, fluid (it went slow since the OS upgrade!) way to play vanilla DOOM+ or, worse, Heretic+ (no Crispy there, damnit)... Ah, nevermind my excuses. I need to work on Heretic Eternity. But still, anyway: now I'm tempted to add complevels and, most importantly, portable savegames: stuff which are the opposite of feature innovation.
Heh, heh, welcome to the club. If we could just clone ourselves, maybe there's a chance doing all the stuff we'd like to...
I see your situation with Eternity resembles my situation with ZDoom - when it was still active - a lot. Being dependent on someone who either has no time or no desire to maintain the port sufficiently.
printz wrote:
5. I really like my Mac. But currently it has no good UDMF editor. And I need such an editor to test advanced Eternity stuff. So instead of developing Eternity, I have to develop this editor, which is a lot more boring than working on Eternity, which means it takes so much more time to finish.
6. Hell, because of Mac, now DOSBox is also ruined (actually not, but Boxer, its excellent Mac port, definitely is since Catalina), I'm stuck without a good, fluid (it went slow since the OS upgrade!) way to play vanilla DOOM+ or, worse, Heretic+ (no Crispy there, damnit)... Ah, nevermind my excuses. I need to work on Heretic Eternity. But still, anyway: now I'm tempted to add complevels and, most importantly, portable savegames: stuff which are the opposite of feature innovation.
Well, Apple. I professionally develop iOS software and by now I've developed such a dislike for the platform I wish they burn in hell (and get splattered by Cyberdemons.)
For me the fun stops when software randomly breaks or features get deliberately removed or when software isn't even being made due to all the strings getting attached to the platform.
For me the Mac is a first grade productivity killer, no chance I'll ever use one privately.
OSX was great for casual computing like schoolwork (and OpenEmu...) when I got my Macbook Air back in 2011, but boy, they've really screwed the pooch on it in recent years. It's a pity, because competition leads to better products for everyone and there's not nearly as much antagonism between Windows and Linux nowadays (to the point where you can have one coexist inside the other as an official feature!)
Printz wrote:5. I really like my Mac. But currently it has no good UDMF editor. And I need such an editor to test advanced Eternity stuff. So instead of developing Eternity, I have to develop this editor, which is a lot more boring than working on Eternity, which means it takes so much more time to finish.
The non-Windows editor situation could be better, yeah. Hopefully this will improve now that UDB has dropped all the SlimDX junk and is entirely OpenGL. As things stand though, I think when Romero was doing SIGIL on his Mac he just ran one of the DB2-based editors inside VMware Fusion, which doesn't really help if you don't have a spare Win10 license but at least it's tried and tested.
Kinsie wrote:because competition leads to better products for everyone
And here's the problem: Apple considers itself a separate product category that does not need to compete. I guess we'll see how long this will continue to work.
UDB ... is entirely OpenGL.
Don't forget, Apple has deprecated OpenGL so for Macs this isn't a final solution.
Graf Zahl wrote:GZDoom has the full MBF working set for Dehacked. If these ports have more I have no objections adding it, but it'd only be worth something if PrBoom+ and Eternity had it, too.
Or if someone actually makes a high-profile mod (not a simple proof-of-concept testmap) making use of those.
StroggVorbis wrote:All I know is that of all "retro" ports, Doom Retro (no pun intended) has the highest DEHackEd limits.
Excerpt from the wiki's feature list:
DeHackEd support has been extended to allow for an additional 2,910 states (numbered 1,089 to 3,999), 100 additional map objects (numbered 150 to 249) and 100 additional sprites (numbered 145 to 244)
I am the one who asked Brad to extend the Dehacked states and sprites, things etc for my mod SMOOTHED which uses an ungodly number of extra states because it is an adaptation of smooth monster resources I got from Smooth Doom, the GZDoom mod. Later Crispy Doom also added these extensions (they don't break compatibility) and I see in the changelog of Russian Doom (which now also has english language) that it added support as well.
i am little late to the party, but i want to clarify some things about Vavoom.
Janis took some Quake code for lightmaps and other not-so-significant parts of the engine (mostly vector/plane math), but in its core Vavoom is still 2.5D Doom engine. no "full 3d map conversion" or something. at least no more than other advanced source ports, because i guess that all ports with HW rendering are creating 3D surfaces out of Doom maps for rendering, but they're still using Doom data structures for coldet and physics.
but Janis did one HUGE change: he switched the engine from lockstep to freestep. i.e. the engine doesn't run playsim on a fixed rate anymore, but is using "delta time" to calculate next frame. both lockstep and freestep engines has their own pros and contras, and there's no "best choice" there. it is just what Janis thought will be good for Vavoom. and as far as i know, Vavoom is the only freestep Doom engine out there.
still, Vavoom is very close to the original Doom physics. it is still using "microteleport" code for coldet, for example (but i am working on adding a proper tracebox collision code). i believe that various glide tricks are either impossible, or much harder to execute in Vavoom, tho, and wallrunning may not work too. but meh, i don't count those as essential Doom mechanics (and most players won't even notice their absence). also, Vavoom supports many vanilla compatibility options (uncluding infinite-tall actors), they're just not easily accessible.
the other huge thing Vavoom did quite early is moving ALL playsim logic to scripts (but i won't call VavoomC a "scripting language", it actually isn't). basically, C++ side only does wad management, sound management, rendering, and some helper tasks for coldet. everything else was moved to VavoomC more than a decade ago. and VavoomC is "real" programming language -- it is strongly typed, it has OOP, it even has pointers (and you can create dynamic arrays/dictionaries with any user-defined type, for example). i even developed a full-featured Spelunky remake entirely in VavoomC.
but as Graf wrote, early Vavoom versions were quite unstable. latest versions Janis did before freezing the project were much better in regards of stability, yet alas, it was too late.
and k8vavoom really needs a dedicated web home, but there are not enough resources for that. there are only two active developers there (me and id0; most engine compatibility features and decorate improvements were done due to id0 tireless testing of various mods and maps), and none of us have enough free time and inspiration to run a web site.
as for borrowing features... yeah, i believe that this is a good thing to do. i am using GZDoom code as a reference to implement various features in k8vavoom, and i don't mind if some other port will take k8vavoom code to implement something too. of course, i'd prefer k8vavoom to be That One Port With Lightmapped Lighting ;-), but i won't go mad if GZDoom (or others) will implement lightmaps, or shadow volumes. the engine is nothing without a content, and content is created by the community. the more tools we're giving the community, the better.
i may don't like GZDoom transition to ZScript as DECORATE replacement, tho (because ZScript is basically impossible to implement if your port is not a GZDoom fork), but i can understand that move: DECORATE was there for quite a long time, it was used in countless number of mods, yet somehow it wasn't adopted by other sourceports. so there is a little reason for GZDoom to improve DECORATE as it is, switching to a better language has more sense. i can't really blame GZDoom devs for not investing efforts in supporting the de-facto standard that nobody else picked up. it may annoy me alot, but i can see where this decision came from. alas.
ketmar wrote:
the other huge thing Vavoom did quite early is moving ALL playsim logic to scripts (but i won't call VavoomC a "scripting language", it actually isn't). basically, C++ side only does wad management, sound management, rendering, and some helper tasks for coldet. everything else was moved to VavoomC more than a decade ago. and VavoomC is "real" programming language -- it is strongly typed, it has OOP, it even has pointers (and you can create dynamic arrays/dictionaries with any user-defined type, for example). i even developed a full-featured Spelunky remake entirely in VavoomC.
The main reasons I'm not doing this are performance (for low level code like actor movement) or that there would be no significant gain. Whether native or scripted, the code cannot be removed, so in the end it's not relevant where it lives. And native code is still easier to debug. But surely the entirety of p_actionfunctions.cpp could theoretically be converted to ZScript, as could major parts of p_mobj.cpp.
>The main reasons I'm not doing this are performance
yeah. i'm not saying that it is impossible in GZDoom or something. just pointed out that Janis did it (and i had to partially undo it to support maps with 2000+ monsters with at least 35 FPS; still, i hope to improve the situation with JIT later). moving playsim code out of C++ is not something that "should be done at all costs", for me it is more like an interesting excersise.
still, something like Korax Mod was impossible in ZDoom at the time, for example. Vavoom executable inside Korax Mod distribution is just a "normal" Vavoom version that can play Doom/Heretic/Hexen/Strife with the proper base paks.
of course, you don't need to move all playsim code to scripting side to be able to do that, you only need to give a proper interfaces with virtual methods (and you can implement those virtual methods in C++). but having all the code in scripts is easier for modders, because they can look at it, copy-paste it, and so on.
