Sprinkled Doom - 3.4.1 (updated June 12th 2022)

Sorry I didn't get back quickly.

The Launcher is written in C++ using plain WIN32 API for Windows and Cocoa in Objective-C for MacOS

1 minute ago, Gibbon said:

Sorry I didn't get back quickly.

 

The Launcher is written in C++ using plain WIN32 API for Windows and Cocoa in Objective-C for MacOS

No biggie, I actually don't see the need to write anything about the language no that I've finished the changes.

Just now, Dusty_Rhodes said:

No biggie, I actually don't see the need to write anything about the language no that I've finished the changes.

Those who want to peek will peek :) 

I guess I should have also posted about the fancy new icon!

https://github.com/atsb/chocolate-doom-plus-plus/blob/master/data/sprinkled.png

And thanks for updating the wiki..  I really should get an account there.

4 hours ago, Dusty_Rhodes said:

Here's the pending changes page, with a link to the newest version:

 

https://doomwiki.org/w/index.php?title=Sprinkled_Doom&stable=0&shownotice=1

I mean it is approved already by Xymph but i will make a change to it:

• Redirect to latest releases page instead of binary. I kept 1.0 separate because it is a rather pure fork - Its the Doom plus limits
• And since your link mentions 3.2.1, ill also update the versioning table :P

Thank you :)

17 minutes ago, Redneckerz said:

I mean it is approved already by Xymph but i will make a change to it:

• Redirect to latest releases page instead of binary. I kept 1.0 separate because it is a rather pure fork - Its the Doom plus limits
• And since your link mentions 3.2.1, ill also update the versioning table :P

Thank you :)

No thank you! I figure I would have missed something, it's my first time editing the wiki. Doomwiki.org is such a good and useful website, I want to help keep it that way. I hope I did it correctly.

3 hours ago, Dusty_Rhodes said:

No thank you! I figure I would have missed something, it's my first time editing the wiki. Doomwiki.org is such a good and useful website, I want to help keep it that way. I hope I did it correctly.

If anything else, keep on editing! Happy to have you.

Story time!

So someone, lets call them Silly User just compiled the shiny new "stable" version 3.2.1. Silly User was mucking around in Doom when he wanted to change a setting! Now, Silly User thinks he is a clever bloke so he tried to launch sprinkled-setup but was unable due to a "Segmentation fault (core dumped)" message. Silly User sat confused but determined to find an answer. He was able to trace the issue to a commit 82a37e2191e53e0c8689dbcea9596ba97102910e labeld "Stupid hardcoded icon is gone!" by Silly Programmer.

The End

4 hours ago, HackNeyed said:

Story time!

So someone, lets call them Silly User just compiled the shiny new "stable" version 3.2.1. Silly User was mucking around in Doom when he wanted to change a setting! Now, Silly User thinks he is a clever bloke so he tried to launch sprinkled-setup but was unable due to a "Segmentation fault (core dumped)" message. Silly User sat confused but determined to find an answer. He was able to trace the issue to a commit 82a37e2191e53e0c8689dbcea9596ba97102910e labeld "Stupid hardcoded icon is gone!" by Silly Programmer.

 

The End

One programmer was clearly too lazy to test it.

Ill fix it!

But I still hate hard coded icons converted to a C binary array..  there is just no need for such 80's style hackery 

@HackNeyed - fixed with my own hardcoded icon :D

Just an update.  I'm going to be modifying the GitHub actions trigger to make release images of Sprinkled Doom for all platforms (except Mac which I'll do myself).  This way I can deliver multiple architectures including 32bit without it affecting my time too much.

I remember when this was called Chocolate Doom Plus Plus. Hehehe. I thought Sprinkled Doom was a new thing.

Just now, RetroAkaMe said:

I remember when this was called Chocolate Doom Plus Plus. Hehehe. I thought Sprinkled Doom was a new thing.

:) same thing just a more memorable name since it added more enhancements and changes than just increased limits.

Ok, 32bit is done and the download is available.  I spent some time compiling 32bit versions of Samplerate, zlib, libpng, ogg and vorbis so the build system is now on par with the 64bit version.  I also included a 32bit sprinkled launcher too

EDIT: In-case anyone is curious about the launchers, I want to make that visible

https://github.com/atsb/launcherWin32 (inc link to the Obj-C version for Mac).

No, I haven't forgotten you my dear Sprinkled Doom.  In fact, I've been busy enjoying Strife!

So much so, that even The Order aren't safe from Extra Gibbing! (from a hidden blade no less!)

The code was a bit different, so Strife's implementation is very much brute forced.  Whatever and whenever the config is enabled, instead of nicely checking the source and target, I basically tell it to "shut up and gib that sucker".  And that's exactly what happens :)

Oh and I also coded it for Heretic as well..  meh.

Sprinkled Doom 3.2.2 Released!

Release: https://github.com/atsb/chocolate-doom-plus-plus/releases/tag/3.2.2

Changes:

• Insane Gibbing for Heretic and Strife
• Two critical bug fixes for Strife (not related to Chocolate Doom)
• Latest merges from Chocolate Doom

Binaries included for MacOS (Universal.app), Windows 64bit and Windows 32bit.  All releases contain my Sprinkled Launcher.

Note: This is the first release from pulling in changes from Choco that remove midiproc.

9 hours ago, Gibbon said:

Note: This is the first release from pulling in changes from Choco that remove midiproc.

yeeeeees

I hear you!  All hail the..  master volume control :)

Finally, native MIDI! Thank you :D

Just had a thought, is there a command line switch for enabling/disabling doom-plus limits?

Also, could you perhaps implement some of Doom32's raised limits as well (or have they already been implemented)?

14 minutes ago, OpenRift said:

Just had a thought, is there a command line switch for enabling/disabling doom-plus limits?

 

Also, could you perhaps implement some of Doom32's raised limits as well (or have they already been implemented)?

Sprinkled Doom has the same raised limits as Doom2-plus through a universal file, dpplimits.h.

I am not sure if it increases heapsize or lump stack, but likely it does not.

1 hour ago, OpenRift said:

Just had a thought, is there a command line switch for enabling/disabling doom-plus limits?

 

Also, could you perhaps implement some of Doom32's raised limits as well (or have they already been implemented)?

Doom 2 plus limits are only via the setup utility.

Heap and lumpsize aren't touched, but thats alright, I can increase them.

I can do command line options for all 3 of them, since it has its own launcher it makes sense as it's more accessible now than having to load up cmd.exe

Go Gibbon! Great update, I'll be happy to check this out later. 

So I did a little commit and bumped the default heap size to 64MB (also for Hexen) and added an option -reml to set doom plus limits to 1 (on).  I'll do the others later.

EDIT:

So that's all the games with -reml done.

About the file lump cache issue.  I read the original post on it from Quasar, this would not affect Chocolate Doom (and thus Sprinkled Doom) because it only happened on the original (and Linux Doom) due to the unsafe alloca function used for assigning the size at compile-time.  Since Choco uses Z_Malloc for fileinfo, this is basically fixed (does this mean Choco isn't 100 percent vanilla bug compatible?).

From what I've read, whatever you load in as lumps, Z_Malloc will increase the size to fit those lumps.

A new release of Sprinkled Doom!

Changes:

1. Enabled old, previously disabled code for the WIN32 dialog popup for choosing WADS in the setup program.
2. Removed Doom Plus Plus limits and hard coded the DOOM32 limits by multiplying them onto the limit definitions (increasing the limits exponentially)
3. Added solid seg limit increases
4. Added support for the Blasphemer IWAD (Heretic)
5. Removed vanilla save limits
6. Removed vanilla demo limits
7. Added support for vanilla wads requiring HUGE limits (equinox)

I also merged in the latest Choco git commits too.

The limit changes made sense to me, because Sprinkled is all about having that Choco compatibility but with insane limits (and nothing else but minor things).  So having those as optional, didn't make any sense.

Due to the WAD dialog enabling, I have deprecated the Sprinkled Launcher.

Binaries for Windows 32bit, 64bit and Mac Intel and M1 universal binary:

https://github.com/atsb/chocolate-doom-plus-plus/releases/tag/3.3.0

7 hours ago, Gibbon said:

A new release of Sprinkled Doom!

 

Changes:

1. Enabled old, previously disabled code for the WIN32 dialog popup for choosing WADS in the setup program.
2. Removed Doom Plus Plus limits and hard coded the DOOM32 limits by multiplying them onto the limit definitions (increasing the limits exponentially)
3.  Added solid seg limit increases
4. Added support for the Blasphemer IWAD (Heretic)
5. Removed vanilla save limits
6. Removed vanilla demo limits
7. Added support for vanilla wads requiring HUGE limits (equinox)

 

I also merged in the latest Choco git commits too.

 

The limit changes made sense to me, because Sprinkled is all about having that Choco compatibility but with insane limits (and nothing else but minor things).  So having those as optional, didn't make any sense.

 

Due to the WAD dialog enabling, I have deprecated the Sprinkled Launcher.

 

Binaries for Windows 32bit, 64bit and Mac Intel and M1 universal binary:

https://github.com/atsb/chocolate-doom-plus-plus/releases/tag/3.3.0

So now the raised limits surpass standard Doom32, or am I misreading this? Also thanks for enabling the WAD select thing back!!

16 minutes ago, OpenRift said:

So now the raised limits surpass standard Doom32, or am I misreading this? Also thanks for enabling the WAD select thing back!!

The limits are using the DOOM32 limits, the difference is, for example.  I bumped the limits to DOOM32 then multiplied them again against DOOM32 factor.

#define MAXLINEANIMS 16384 * DOOM_PLUS_PLUS_MAXLINEANIMS_FACTOR

So I am multiplying MAXLINEANIMS with the DOOM32 factor (256).

Essentially they are 'removed'.  DOOM32 limits are nice but I didn't like how some things were not playable (like equinox) and that bothered me.  I guess I'll call these DOOM128 limits :P

1 minute ago, Gibbon said:

The limits are using the DOOM32 limits, the difference is, for example.  I bumped the limits to DOOM32 then multiplied them again against DOOM32 factor.

  

#define MAXLINEANIMS 16384 * DOOM_PLUS_PLUS_MAXLINEANIMS_FACTOR

 

So I am multiplying MAXLINEANIMS with the DOOM32 factor (256).

  

Essentially they are 'removed'.  DOOM32 limits are nice but I didn't like how some things were not playable (like equinox) and that bothered me.  I guess I'll call these DOOM128 limits :P

Well fuck, looks like we're gonna have to figure out how to make that EXE hack...

Anyway, thanks for the clarification.

By the way, I was testing out the WAD-select function, and found that the only way to select the WADs from the file select window is by typing the filename in the bar, because .WAD and .DEH files aren't being listed. So you may want to look into that.

I added that to the issue you raised on the Choco repo.  That it won't select it until you type it.  Hopefully fraggle sees it sooner or later.  I can fix it, but Choco would need to take it otherwise every merge that touches that area I would have to manually reconcile from Choco, and I'd like to avoid that.

13 minutes ago, OpenRift said:

Well fuck, looks like we're gonna have to figure out how to make that EXE hack...

 

Anyway, thanks for the clarification.

 

By the way, I was testing out the WAD-select function, and found that the only way to select the WADs from the file select window is by typing the filename in the bar, because .WAD and .DEH files aren't being listed. So you may want to look into that.

I could take a look.  Would be nice to have a 'DOOM1024.EXE' :P