Chocolate Doom

[Gez]

Here's a dumb stupid question: is it possible to make it so that some constant values will always be at the same predictable space (for example, positive offset from the beginning, or negative offset from the end) in a compiled executable, regardless of compiler used?

[Danfun64]

How is that question "dumb and stupid"? It's fairly complicated, and, not being a programmer, I'm not sure I completely understand it. More importantly, does this feature you are asking about exist in vanilla? If it isn't, why bother?

[fraggle]

Gez said:

Here's a dumb stupid question: is it possible to make it so that some constant values will always be at the same predictable space (for example, positive offset from the beginning, or negative offset from the end) in a compiled executable, regardless of compiler used?

It's not that simple. The limits aren't just constant values stored as a value inside the executable. They're used for eg. the sizes of arrays. So you can't change them without recompiling.

Danfun64 said:

How is that question "dumb and stupid"? It's fairly complicated, and, not being a programmer, I'm not sure I completely understand it. More importantly, does this feature you are asking about exist in vanilla? If it isn't, why bother?

It was a reasonable question. If you don't have anything positive to contribute, please refrain from commenting.

[Danfun64]

Sorry. I came off more negative than I was trying to. I was just saying that the question didn't seem dumb or stupid to me. I wasn't consciously attacking the question.

Gez, For those of us who can't code, could you explain the advantage of settings things up like you suggested?

[Csonicgo]

fabian said:

Yes, I had to replace some functions in Chocolate Doom to e.g. work around rendering glitches or bugs that lead to maps crashing. Which "features" do you exactly mean that have replaced Vanilla "features"?

I want low detail back. I want to know that your port can be rebased with chocolate doom code so I can enjoy the latest in the OPL sound code and misc. fixes without having to wait on your fork to catch up.

Waiting on someone else's "fork" to catch up to the latest code is the most frustrating thing. Maybe I could make my own "fork" to resolve the problem, but that's yet another fork, which isn't helping.

[Gez]

Danfun64 said:

How is that question "dumb and stupid"? It's fairly complicated, and, not being a programmer, I'm not sure I completely understand it. More importantly, does this feature you are asking about exist in vanilla? If it isn't, why bother?

My understanding was that entryway's Doom+/Heretic+/Hexen+ were patched by "simply" finding where the array sizes are indicated in the exe, and writing larger values there, so that when the program is run, the arrays are bigger. But now looking at it more closely, though, it's more complicated than that, the values being changed are not directly the array sizes (e.g., in Heretic+ changing MAXVISPLANES from 128 to 1024 does not involve replacing 80 00 by 00 04, but instead 0C 92 03 00 by 00 00 08 00).

Question was dumb because I should have looked at how they worked before idly asking. :p

[fabian]

Csonicgo said:

I want low detail back.

If you mean the original 320x200 resolution, it's under "Options -> Graphic Detail: Low".

I want to know that your port can be rebased with chocolate doom code so I can enjoy the latest in the OPL sound code and misc. fixes without having to wait on your fork to catch up.

It does and I merge in Choco's changes regularly.

[xttl]

Gez said:

My understanding was that entryway's Doom+/Heretic+/Hexen+ were patched by "simply" finding where the array sizes are indicated in the exe, and writing larger values there, so that when the program is run, the arrays are bigger. But now looking at it more closely, though, it's more complicated than that, the values being changed are not directly the array sizes (e.g., in Heretic+ changing MAXVISPLANES from 128 to 1024 does not involve replacing 80 00 by 00 04, but instead 0C 92 03 00 by 00 00 08 00).

To eg. patch MAXVISPLANES from 128 to 1024 in vanilla EXEs, you have to:

- extend the amount of memory reserved for data specified in LE header. you place your new visplanes array here, after all the old data and stack.

- patch all references to the start address of the old visplane array. not enough to patch these in the code, you have to patch the related relocation records in the LE header too.

- patch the visplane overflow checks code with your new limit.

The value 128 will only show up as is in the overflow checks.

In this case, 0x3920C is the unrelocated address of the old array and 0x80000 is the address for the new, extended one.

[Csonicgo]

fabian said:

If you mean the original 320x200 resolution, it's under "Options -> Graphic Detail: Low".

It does and I merge in Choco's changes regularly.

Oh. Looks as if someone told me incorrectly. My apologies.

Spoiler

I still want doom+ demo support though in a port, no idea how, grumblegrumblegrumble

[vadrig4r]

Just in case anyone had forgotten (as I had) or wasn't aware, you can find development builds of Chocolate Doom for Win32 at http://latest.chocolate-doom.org/. Hopefully someone will find this reminder useful.

[fraggle]

vadrig4r said:

Just in case anyone had forgotten (as I had) or wasn't aware, you can find development builds of Chocolate Doom for Win32 at http://latest.chocolate-doom.org/. Hopefully someone will find this reminder useful.

Thanks; added to the top post.

[Superluigieth1]

obsoleted

[vesperas]

Must be a joke :(

[fraggle]

I'm not really banned, folks.

[Superluigieth1]

Yay!

[axdoomer]

fraggle said:

It's not that simple. The limits aren't just constant values stored as a value inside the executable. They're used for eg. the sizes of arrays. So you can't change them without recompiling.

Why not use dynamic allocation? The arrays that are increased in Doom+ never overflow, so it doesn't matter.

[realtv123]

Is Chocolate Doom's Online Multiplayer still a thing? Thats what I'd like to know...

[Danfun64]

...yes. It's still there for anybody who wants to use it.

[TheDoomerGuy12345]

Im new to this kind of stuff and I want to play eternal doom on chocolate doom but I have no idea what to do. I read the FAQ but don't know how to run the line command thingy it talked about on how to install it can some please help me?

[vesperas]

I was thinking, would it be possible to add here http://latest.chocolate-doom.org/ the SDL2 builds? I know it's not finished yet, but I'm really looking forward to this. Thank you!

[VGA]

TheDoomerGuy12345 said:

Im new to this kind of stuff and I want to play eternal doom on chocolate doom but I have no idea what to do. I read the FAQ but don't know how to run the line command thingy it talked about on how to install it can some please help me?

Get this launcher:
https://github.com/qbasicer/qzdl/releases/tag/v3.2.2.2-stable

And configure a new engine, call it Chocolate and point it to the Chocolate Doom executable and then add your IWADS (your doom.wad and doom2.wad). Then you can drop wad and deh files in the left list and press launch. No need for cmdline.

[TheDoomerGuy12345]

VGA how do I point the github thing to the chocolate thing just in a little more detail please

[VGA]

TheDoomerGuy12345 said:

VGA how do I point the github thing to the chocolate thing just in a little more detail please

Download that ZDL-3.2.2.2-stable.zip and unzip it in some folder, then run it.

Then you configure a Doom engine (point it to the Chocolate Doom exe) and the your IWADs. Then you add the mappack to the left list and press launch.

[TheDoomerGuy12345]

Ok I got everything I just cant find the map pack in the eternal file but I might just not know what ots called or something can you help me?

[TheDoomerGuy12345]

and I cant get doom2 into the sourceport thing

[VGA]

TheDoomerGuy12345 said:

and I cant get doom2 into the sourceport thing

Go to Settings and press Add on the Sourceports list. Then point it to the exe of Chocolate Doom.

Then on the right list add the iwads.

[TheDoomerGuy12345]

Ok I got everything I just cant find the map pack in the eternal file but I might just not know what its called or something can you help me?

[VGA]

TheDoomerGuy12345 said:

Ok I got everything I just cant find the map pack in the eternal file but I might just not know what its called or something can you help me?

Holy crap, Eternal is so old that it has some instalation procedure for DOS. Screw that, go here:
https://www.doomworld.com/vb/wads-mods/62529-back-to-saturn-x-e1-99i9-plus-new-unheard-midis-on-page-13/

And play an actually good megawad. Load the wad and the deh file in the left list with drag and dropping.

Forget about Eternal IMO.

[vesperas]

TheDoomerGuy12345 said:

Im new to this kind of stuff and I want to play eternal doom on chocolate doom but I have no idea what to do. I read the FAQ but don't know how to run the line command thingy it talked about on how to install it can some please help me?

You just need to put doom2.wad and eternall.wad in the same directory of your Chocolate Doom executable and then launch chocolate-doom -iwad doom2.wad -merge eternall.wad. Don't bother with all the other files...

[vesperas]

I noticed a minor issue after setting the video_driver from "" to "directx" in chocolate-doom.cfg. Basically, every time I quit the game, the music keeps playing for a couple of seconds while I'm already on the desktop. Is this a know problem? The directx driver seems to give smoother FPS btw :)