Will Choco Doom Support or Emulate the Doom+ Patch?

I really like Chocolate Doom and it's become my port of choice for that classic feel but I would also love to be able to use it as a limit removing source port as well. Maybe I've missed this and it's already implemented but do you think Choco Doom will or can support the Doom+ patch? I mean, it would still be vanilla-like in all other ways and this would obviously need to be an option set to off by default... I'd like to see it though. :)

I think there's Strawberry Doom that does just that.

http://doom.wikia.com/wiki/Strawberry_Doom

Ah, cool. I thought that Strawberry Doom had stopped development a while back though?

No.

fraggle said:

No.

Don't mean to sound obtuse but is that 'no' Choco Doom won't support Doom+ or 'no' Strawberry hasn't ceased development? :)

Is it possible to find the same patterns in chocolate-doom.exe as in doom.exe to replace the values to what entryway suggested?

printz said:

Is it possible to find the same patterns in chocolate-doom.exe as in doom.exe to replace the values to what entryway suggested?

They did that in doom.exe because there was no source code to work on, at the time. With the full source code available, why resort to that? Get Choco doom's code, alter the static limits to whatever you wish (even beyond Doom+'s ones) and recompile.

Being lucky to find the same patterns of hexadecimal code in the executable is way faster than having to deal with cygwin and all the other wild source code interfaces, for me.

printz said:

Being lucky to find the same patterns of hexadecimal code in the executable is way faster than having to deal with cygwin and all the other wild source code interfaces, for me.

Sure, assume that any occurrence of a byte value "128" or of a whole-int value of 128 (0x00000080 or rather 80000000 for Intel) could be the visplanes limit, and you'll see how "easy" it is unless you know exactly where it should occur.

printz said:

Being lucky to find the same patterns of hexadecimal code in the executable is way faster than having to deal with cygwin and all the other wild source code interfaces, for me.

... says somebody who apparently has no idea about how much work is needed here.

The biggest obstacle is that different compilers output different code so even the same source compiled with GCC or MSVC won't look the same anymore. How will you find patterns there?

Also, the C compiler used to compile Doom did not optimize as well as modern compilers so the machine code is a lot easier to read as disassembly.

Just phone John - though be sure to turn on your rocket defense system.

If you don't want to deal with "cygwin and all the other wild source code interfaces" the alternate build environments can work wonders. I typically use the code::blocks project and everything compiles nicely for me.

Of course, I'm not sure if prebuilt libraries of sdl-mixer and sdl-net for mingw actually exist (they probably do and I wasn't looking nearly hard enough), so I ended up building both of those myself via MinGW but once I had those working building Choco with Code::Blocks was quite easy.

Average said:
Don't mean to sound obtuse but is that 'no' Choco Doom won't support Doom+ or 'no' Strawberry hasn't ceased development?

The former. I'm not sure about Strawberry, but GhostlyDeath worked on it about a year ago, so maybe he's interested in updating it once in a while.

Personally, I use Doom+, itself.

Graf Zahl said:

... says somebody who apparently has no idea about how much work is needed here.

The biggest obstacle is that different compilers output different code so even the same source compiled with GCC or MSVC won't look the same anymore. How will you find patterns there?

Also, the C compiler used to compile Doom did not optimize as well as modern compilers so the machine code is a lot easier to read as disassembly.

Actually I have found even the "highly optimized" binary of Eternity spit out complete with SSE2 opcodes by VC2008 is surprisingly navigable in IDA Pro.

Also, you can't just change a number "128" to increase the visplane count, guys. You have to find an empty space in the BSS segment that is large enough (or resize the virtual segment by editing the PE header) and then redirect ALL references to that address in the program to the new location you chose.

Simple, absolutely NOT.

Not being a coder I didn't realise that Doom+ was more than just 'modular' patch. So, it's really integrated into the original code then?

I really hope that Strawberry Doom is continued in that case. BTW, where can I download the last build - I can't seem to find a build anywhere *shuffles feet in an embarrassed manner...*

These are the most recent I can find.

^
Thank you. :)

I have been working on a source port that I intend for multiplayer, but it has extended limits and some other bug fixes, so it pretty much fills the niche for Strawberry Doom as it is right now, synced with choco 1.6.0. You can download it here.

Maes said:

Get Choco doom's code, alter the static limits to whatever you wish (even beyond Doom+'s ones) and recompile.

Which source file are these in?

SVN r2344

MAXVISPLANES - r_plane.c - line 53
MAXVISSPRITES - r_things.h - line 33
MAXDRAWSEGS - r_defs.h - line 57
MAXPLATS - p_spec.h - line 311
SAVEGAMESIZE - g_game.c - line 81
MAXLINEANIMS - p_spec.c - line 144
MAXOPENININGS - r_pane.c - line 60

Awesome, thanks.

edit: passed conduits.wad yay

tm512 said:

I have been working on a source port that I intend for multiplayer, but it has extended limits and some other bug fixes, so it pretty much fills the niche for Strawberry Doom as it is right now, synced with choco 1.6.0. You can download it here.

Do you have a project page or list of changes?

tm512 said:

I have been working on a source port that I intend for multiplayer, but it has extended limits and some other bug fixes, so it pretty much fills the niche for Strawberry Doom as it is right now, synced with choco 1.6.0. You can download it here.

Sounds interesting. Dl'ing it now...

EDIT: Just trying out some limit removing wads and gave sacrment.wad by Clan BOS a bash. It crashed with:

W_CacheLumpNum: 2624205 >=Numlumps

Don't know if that's of interest to you but thought I'd share anyway. :)

Randy87 said:

Do you have a project page or list of changes?

Yes

W_CacheLumpNum: 2624205 >=Numlumps

This is an issue with vanilla doom as well. It has something to do with the way the wad is ordered, I'm not exactly sure. Fixing it is on my to-do list, though.

Average said:

Don't mean to sound obtuse but is that 'no' Choco Doom won't support Doom+ or 'no' Strawberry hasn't ceased development? :)

It means I won't be supporting Doom+ limits any time soon. I've been asked this question before on multiple occasions and I wrote a detailed post several months back explaining my reasons why not. I understand why you want the feature but it simply doesn't fit in with what I want the port to be about.

Sorry.

Thanks for replying and linking to the older post. It also answered my suspicions regarding the death of Strawberry Doom too.

I totally understand your point and I totally appreciate your clear goals. I'll keep on using CD for all my vanilla needs and resort to other ports as and when required... It's just so pretty! :)