Sprinkled Doom - 3.4.1 (updated June 12th 2022)

[OpenRift]

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.

[Redneckerz]

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/

[Gibbon]

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

[OpenRift]

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.

[xX_Lol6_Xx]

Can confirm that

[Gibbon]

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

 

[OpenRift]

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?

[xX_Lol6_Xx]

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

[OpenRift]

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.

[xX_Lol6_Xx]

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.

[Gibbon]

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).

[xX_Lol6_Xx]

It may be my system then, but I'm not surprised, it's a crappy laptop.

[Gibbon]

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 ;)

[OpenRift]

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. 

[fabian]

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. 

[Gibbon]

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..

[OpenRift]

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

[fabian]

Didn't you say this was a limit *raising* port?

[Gibbon]

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

[Catoptromancy]

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

[Gibbon]

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'.

[Catoptromancy]

#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

[Gibbon]

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

[Catoptromancy]

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

[Gibbon]

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..

[Julia Nechaevskaya]

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.

[GoneAway]

There are also still limits like the number of linedefs owing to the format of the maps themselves :^)

[Gibbon]

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

[OpenRift]

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. ;)

[Redneckerz]

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/