OpenRift Posted February 6, 2022 2 minutes ago, Gibbon said: I could take a look. Would be nice to have a 'DOOM1024.EXE' :P I don't even know if I'd have enough wiggle-room to fix values like that in there. 1 Share this post Link to post
Redneckerz Posted February 6, 2022 55 minutes ago, Gibbon said: I could take a look. Would be nice to have a 'DOOM1024.EXE' :P A DOS executable with those limits removed but leaving everything else intact would be a significant exe hack for DOS. 52 minutes ago, OpenRift said: I don't even know if I'd have enough wiggle-room to fix values like that in there. Is this due to DOS limits/ 0 Share this post Link to post
Gibbon Posted February 6, 2022 (edited) 1 minute ago, Redneckerz said: Is this due to DOS limits/ I don't think so. ReBOOMRL-DOS uses the Unity port's limits then I multiply that 4x greater. Runs on DOS just fine. Edited February 6, 2022 by Gibbon 1 Share this post Link to post
OpenRift Posted February 6, 2022 31 minutes ago, Redneckerz said: A DOS executable with those limits removed but leaving everything else intact would be a significant exe hack for DOS. Is this due to DOS limits/ Mostly due to how many bytes that higher values will occupy, because most limit-raising hacks are the exact same file size as the vanilla EXE they're based on. The thing is, I've only ever seen one WAD exceed Doom32's static limits, and that was Auger Zenith, which surpassed the increased visplane limit. Usually other WADs have some other issue that's not related to static limits, like using unoptimized node builders, sloppy texture usage (tutti-frutti, medusa effect, etc.), or some other technical issue. 3 Share this post Link to post
Gibbon Posted February 6, 2022 13 minutes ago, OpenRift said: Mostly due to how many bytes that higher values will occupy, because most limit-raising hacks are the exact same file size as the vanilla EXE they're based on. The thing is, I've only ever seen one WAD exceed Doom32's static limits, and that was Auger Zenith, which surpassed the increased visplane limit. Usually other WADs have some other issue that's not related to static limits, like using unoptimized node builders, sloppy texture usage (tutti-frutti, medusa effect, etc.), or some other technical issue. Indeed, keeping the same byte size would be impossible. It would increase by at least 3 bytes, minimum 'if' it was done. And yes, Auger Zenith... finally now I don't have to use RZDoom to play it ;) Spoiler 2 Share this post Link to post
OpenRift Posted February 6, 2022 8 minutes ago, Gibbon said: And yes, Auger Zenith... finally now I don't have to use RZDoom to play it ;) Hide contents Hide contents This in sprinkled? Have you beaten the first level without a VPO? 0 Share this post Link to post
xX_Lol6_Xx Posted February 6, 2022 (edited) 12 minutes ago, Gibbon said: Indeed, keeping the same byte size would be impossible. It would increase by at least 3 bytes, minimum 'if' it was done. And yes, Auger Zenith... finally now I don't have to use RZDoom to play it ;) Hide contents I've tried playing it with sprinkled doom, but when you open the first door (Literally), the port crashes for me, but with that window that says "Sprinkled Doom.exe stopped working". I have no idea if it's just a problem in my end, or the port itself (Probably the first, but it's no big deal) Here, check it out Spoiler Edited February 6, 2022 by Lol 6 0 Share this post Link to post
OpenRift Posted February 6, 2022 1 minute ago, Lol 6 said: I've tried playing it with sprinkled doom, but when you open the first door (Literally), the port crashes for me, but with that window that says "Sprinkled Doom.exe stopped working". I have no idea if it's just a problem in my end, or the port itself (Probably the first, but it's no big deal) Trust me, Auger Zenith, much like other DBP WADs, is specifically made for Crispy Doom or better. Getting it to work in Sprinkled would require practically remaking half the WAD. 2 Share this post Link to post
xX_Lol6_Xx Posted February 6, 2022 Just now, OpenRift said: Trust me, Auger Zenith, much like other DBP WADs, is specifically made for Crispy Doom or better. Getting it to work in Sprinkled would require practically remaking half the WAD. Heh, true. Still, it's no big deal. 0 Share this post Link to post
Gibbon Posted February 6, 2022 7 minutes ago, Lol 6 said: I've tried playing it with sprinkled doom, but when you open the first door (Literally), the port crashes for me, but with that window that says "Sprinkled Doom.exe stopped working". I have no idea if it's just a problem in my end, or the port itself (Probably the first, but it's no big deal) Here, check it out Reveal hidden contents Spoiler Works on my machine :P I even idclipped through everything to give it a good test. No issues (on a Mac). 0 Share this post Link to post
xX_Lol6_Xx Posted February 6, 2022 It may be my system then, but I'm not surprised, it's a crappy laptop. 1 Share this post Link to post
Gibbon Posted February 6, 2022 8 minutes ago, OpenRift said: Trust me, Auger Zenith, much like other DBP WADs, is specifically made for Crispy Doom or better. Getting it to work in Sprinkled would require practically remaking half the WAD. Yeah it does have its rough spots. MAP18 for example bails out. I do hate it when designers don't use actual vanilla limit removing ports for vanilla limit removing wads ;) 1 Share this post Link to post
OpenRift Posted February 7, 2022 1 hour ago, Gibbon said: Yeah it does have its rough spots. MAP18 for example bails out. I do hate it when designers don't use actual vanilla limit removing ports for vanilla limit removing wads ;) I fell like there needs to be a distinction; that being limit-raising, for legacy increased-limit ports/exes, and limit-removing, for stuff that fixes a lot of common vanilla-format bugs. Playing limit-removing WADs in Doom32 can really be a mixed bag sometimes, because sometimes you just have to fix things yourself (i.e. Manually tiling sub-128 unit textures to 128 units) or it straight up just doesn't work. This is why I'm hopeful about the recent vanilla source code restoration, because it could pave the way for a barebones DOS port that fixes those issues (especially texture-related ones) while still behaving 100% vanilla everywhere else. 1 Share this post Link to post
fabian Posted February 7, 2022 8 hours ago, Gibbon said: I do hate it when designers don't use actual vanilla limit removing ports for vanilla limit removing wads ;) Crispy *is* a Vanilla limit removing port. 1 Share this post Link to post
Gibbon Posted February 7, 2022 13 minutes ago, fabian said: Crispy *is* a Vanilla limit removing port. Yeah I know that, my point was that if something works on crispy but not on a similar limit removing port, then it doesn't help that the definition if very vague. Would be nice for example, to have Crispy Limit Removing, Boom Limit Removing.. etc.. 0 Share this post Link to post
OpenRift Posted February 7, 2022 13 minutes ago, Gibbon said: Yeah I know that, my point was that if something works on crispy but not on a similar limit removing port, then it doesn't help that the definition if very vague. Would be nice for example, to have Crispy Limit Removing, Boom Limit Removing.. etc.. Or limit-raising vs limit-removing.... that's a lot simpler lol 2 Share this post Link to post
fabian Posted February 7, 2022 Didn't you say this was a limit *raising* port? 0 Share this post Link to post
Gibbon Posted February 7, 2022 (edited) Apparently, it is. I would think that a 'limit raising port' should at least work on a vanilla port that raises the limits to 3x beyond what the unity ports limits are :P But still, limit raising vs limit removing.. I mean, sure it is slightly different but raising limits to a certain point pretty much renders them null. Edited February 7, 2022 by Gibbon 2 Share this post Link to post
Catoptromancy Posted February 7, 2022 (edited) Sprinkled does not #make install, from the latest repo. Ill check out the makefiles. They are old style autotools, so I might be able to figure it out. #make install goes into many directories, does nothing, eventually errors in the "setup" directory. Edited February 7, 2022 by Catoptromancy 0 Share this post Link to post
Gibbon Posted February 7, 2022 Just now, Catoptromancy said: Sprinkled does not #make install, from the latest repo. Ill check out the makefiles. They are old style autotools, so I might be able to figure it out. #make install goes into many directories, does nothing, eventually errors in the "setup" directory. Reveal hidden contents Making install in strife make[2]: Entering directory '/home/cato/.local/src/chocolate-doom-plus-plus/src/strife' make[3]: Entering directory '/home/cato/.local/src/chocolate-doom-plus-plus/src/strife' make[3]: Nothing to be done for 'install-exec-am'. make[3]: Nothing to be done for 'install-data-am'. make[3]: Leaving directory '/home/cato/.local/src/chocolate-doom-plus-plus/src/strife' make[2]: Leaving directory '/home/cato/.local/src/chocolate-doom-plus-plus/src/strife' Making install in setup make[2]: Entering directory '/home/cato/.local/src/chocolate-doom-plus-plus/src/setup' make[2]: *** No rule to make target '../../data/setup.png', needed by 'setup_icon.c'. Stop. make[2]: Leaving directory '/home/cato/.local/src/chocolate-doom-plus-plus/src/setup' make[1]: *** [Makefile:1106: install-recursive] Error 1 make[1]: Leaving directory '/home/cato/.local/src/chocolate-doom-plus-plus/src' make: *** [Makefile:561: install-recursive] Error 1 I don't test the autotools. I only build using cmake, I keep those old things there just so I can pull commits from Choco, but consider them 'deprecated'. 0 Share this post Link to post
Catoptromancy Posted February 7, 2022 (edited) #make install using cmake stops doing anything immediately. # make install make: *** No rule to make target 'install'. Stop. Ill grab latest choco repo and compare cmake and autotools. Edited February 7, 2022 by Catoptromancy 1 Share this post Link to post
Gibbon Posted February 7, 2022 Just now, Catoptromancy said: #make install using cmake stops doing anything immediately. # make install make: *** No rule to make target 'install'. Stop. Ill grab latest choco repo and compare cmake and autotools. I also 'never' install anything via make. I make them locally and have my own local directories under which I have a path pointing to them. I like to keep my GNU/Linux system as clean and pristine as possible (read OCD) :P 0 Share this post Link to post
Catoptromancy Posted February 7, 2022 (edited) Sprinkled $make installs with autotools by just editing the chocolate-doom.pngs to sprinkled.png in a couple makefiles. Cmake gives me same $make install message with chocolate-doom repo. In chocolate-doom-plus-plus/src/setup/Makefile.am around lines 43-44. #setup_icon.c : $(top_builddir)/data/setup.png setup_icon.c : $(top_builddir)/data/sprinkled.png # $(top_builddir)/data/convert-icon $(top_builddir)/data/setup.png $@ $(top_builddir)/data/convert-icon $(top_builddir)/data/sprinkled.png $@ And in chocolate-doom-plus-plus/src/Makefile.am Lines 277-278 icon.c : $(top_builddir)/data/sprinkled.png $(top_builddir)/data/convert-icon $(top_builddir)/data/sprinkled.png $@ Edit: It plays Blasphemer great! Edited February 7, 2022 by Catoptromancy 0 Share this post Link to post
Gibbon Posted February 7, 2022 Just now, Catoptromancy said: Sprinkled $make installs with autotools by just editing the chocolate-doom.pngs to sprinkled.png in a couple makefiles. Cmake gives me same $make install message with chocolate-doom repo. In chocolate-doom-plus-plus/src/setup/Makefile.am around lines 43-44. #setup_icon.c : $(top_builddir)/data/setup.png setup_icon.c : $(top_builddir)/data/sprinkled.png # $(top_builddir)/data/convert-icon $(top_builddir)/data/setup.png $@ $(top_builddir)/data/convert-icon $(top_builddir)/data/sprinkled.png $@ And in chocolate-doom-plus-plus/src/Makefile.am Lines 277-278 icon.c : $(top_builddir)/data/sprinkled.png $(top_builddir)/data/convert-icon $(top_builddir)/data/sprinkled.png $@ Edit: It plays Blasphemer great! Thanks, I'll edit that and credit you. Blasphemer is pretty awesome.. 0 Share this post Link to post
Julia Nechaevskaya Posted February 8, 2022 May I bring some more confusing to "raising / removing" aspects, please? Pretty obvious, but still. Even if static rendering limits are removed (not raised), there is still one little-huge problem: map NODES. I.e., engine can draw extremally complex scenes few thousands visplanes and ~15000 segs, but -- only if engine can load map at all. If not, a support for extended nodes (as Fabian calling them) must be added. Shortly and simply speaking, if port can load such maps like a Okuplok, NOVA (map31 and few others) and notably Sunder (map15 and farther ones), and player can travel trough them without any crashes, then it's real "limit removing". Speaking about these maps: there will be few more support problems, like mixed flat/texture names as well as mess with REJECT lump and support for Boom specs (w/o it map can still be loaded, but progress will stopped near first Boom switch or linedef), but that's another story. 2 Share this post Link to post
GoneAway Posted February 8, 2022 There are also still limits like the number of linedefs owing to the format of the maps themselves :^) 3 Share this post Link to post
Gibbon Posted February 8, 2022 5 hours ago, Julia Nechaevskaya said: May I bring some more confusing to "raising / removing" aspects, please? Pretty obvious, but still. Even if static rendering limits are removed (not raised), there is still one little-huge problem: map NODES. I.e., engine can draw extremally complex scenes few thousands visplanes and ~15000 segs, but -- only if engine can load map at all. If not, a support for extended nodes (as Fabian calling them) must be added. Shortly and simply speaking, if port can load such maps like a Okuplok, NOVA (map31 and few others) and notably Sunder (map15 and farther ones), and player can travel trough them without any crashes, then it's real "limit removing". Speaking about these maps: there will be few more support problems, like mixed flat/texture names as well as mess with REJECT lump and support for Boom specs (w/o it map can still be loaded, but progress will stopped near first Boom switch or linedef), but that's another story. Oh don't get me started on Extended nodes. I am a big 'vanilla should be without any extended nodes, zero additional lumps' and all that jazz :) Boom stuff belongs in Boom :P 3 Share this post Link to post
OpenRift Posted February 8, 2022 2 hours ago, Gibbon said: I am a big 'vanilla should be without any extended nodes, zero additional lumps' and all that jazz :) When it doubt, just use a different nodebuilder. ;) 0 Share this post Link to post
Redneckerz Posted February 8, 2022 On 2/6/2022 at 10:38 PM, OpenRift said: Mostly due to how many bytes that higher values will occupy, because most limit-raising hacks are the exact same file size as the vanilla EXE they're based on. The thing is, I've only ever seen one WAD exceed Doom32's static limits, and that was Auger Zenith, which surpassed the increased visplane limit. Usually other WADs have some other issue that's not related to static limits, like using unoptimized node builders, sloppy texture usage (tutti-frutti, medusa effect, etc.), or some other technical issue. I mean, was Doom32 ever built for Auger Zenith? :P How much further can you even push Doom32 before it crosses the boundary from exe hack to actual port/ 0 Share this post Link to post
Recommended Posts