EXE hacking

[SaladBadger]

Well I mean, if you actually read the large post you quoted and extracted context, you'll realize I'm not working with the final version of doom, or on savegame buffers, but eh.

 

Anyways, it turns out my assumptions were right, all MT executables do have a number of blocks that are basically the same format, and they seem to be stored all the way up to the end of the executable. I attached a simple program that can read Doom 0.2 and Doom 0.3 and map out a flat executable version of it. It's not perfect, since I don't understand the fixup entries yet (doesn't 16 bits per entry seem a little.. small for programs with 32-bit address spaces? I must be missing something), so they're all mapped at 0 which causes conflicts (IE writing to VGA at 0xA0000), but I've been able to map flat executables of 0.2 and 0.3 in Ghidra and they should work in IDA just fine. All the initialized variables appear to be in the right place and everything. This is real nice, because I've been wanting to see how Alpha 0.3 varies from the tech demo, and the later 0.4 release.

 

ed: reupload because of a mistake

 

MTLoad.zip

Edited April 11, 2021 by SaladBadger

[ETTiNGRiNDER]

14 hours ago, SaladBadger said:

Anyways, it turns out my assumptions were right, all MT executables do have a number of blocks that are basically the same format, and they seem to be stored all the way up to the end of the executable. I attached a simple program that can read Doom 0.2 and Doom 0.3 and map out a flat executable version of it. It's not perfect, since I don't understand the fixup entries yet (doesn't 16 bits per entry seem a little.. small for programs with 32-bit address spaces? I must be missing something)

Segmented memory probably?

[SaladBadger]

Segmented would be a little weird for a 32-bit program (32-bit x86 programs are segmented via a much different scheme), but I'm really not sure. The only thing I see in the fixup table is a pile of increasing 16-bit numbers that eventually wrap over at some point. It doesn't correspond to fixup records I've seen in other executables, but at the same time I've never pursued it too closely. I need to study things closer.

[xttl]

Hello again, sorry for always suddenly disappearing for months on you. Just some long-standing problems in life, depression and shit.

 

I just decided to maybe take a look at the 0.2 exe again, but seems you're already figuring it out :) (haven't really read the posts yet or checked out the zip)

 

Anyway, I just wanted to comment on this:

 

On 4/12/2021 at 11:08 PM, SaladBadger said:

Segmented would be a little weird for a 32-bit program

 

32-bit executables can certainly and do have "segmented" fixups: even LE files have the relocation records stored separately for each 4kB page, with offsets to patch stored as relative to the page start, not relative to the start of the whole section ("object" in LE parlance) or whole executable image.

 

I don't remember off hand how modern Windows PE files store the fixups (not all PEs have them but they are needed for DLLs and nowadays also ASLR), but IIRC they are also split by page (512b or 4kB) though the format is otherwise a lot less overly complicated versus LEs.

 

edit: to clarify, of course this has nothing to do with the x86 16-bit real mode segmentation crap, just saying that it's very possible the fixups do not use straight linear 32-bit addresses, especially for the source address

 

also, if you want "flat" dump with good pointers of Doom 0.2 or 0.3 to analyze in IDA/Ghidra without figuring out the fixup the format, just load the game up in a debugging version of dosbox, break to the debugger, do a memdumpbin, cut out the executable from the dump, and load the raw binary with the base offset set correctly. actually i could go do that right now for you...

Edited April 15, 2021 by xttl

[Redneckerz]

2 hours ago, xttl said:

Hello again, sorry for always suddenly disappearing for months on you. Just some long-standing problems in life, depression and shit.

For what it is worth, know that you are a highly appreciated member here and thankful for all you have done. If i someone here can help, please, let it know.

 

Welcome back, partner. :)

 

[xttl]

11 hours ago, xttl said:

actually i could go do that right now for you...

 

Okay I can't really be bothered to cut the dumps to exact size, BUT here are 2MB memory dumps for Doom 0.2 and 0.3 you can load as raw 32-bit binaries @ 0x2000000 (entrypoint is 0x2000010). Lots of nulls at the end so they compress to about 80kB.

 

They were both dumped just as the C main() function of the game started executing (breakpoint on first instruction). For some reason the exes weren't fully loaded in memory if I set the breakpoint on 0x2000010 (at the jump just before "dbgoto main" which seems to be the real start of code section and also entry point), at least it looked that way in the debugger's data view...

 

@SaladBadger did you already create a tool for dumping the debug symbol info (and perhaps convert it to a IDC or MAP file) from Doom 0.2? As for 0.3, seems it doesn't have any symbols. :(

 

MemDumps.zip

 

edit: Hey look at what's on eBay. Sadly it is too expensive to buy just for something like this (and the seller does not even offer shipping to Europe, though of course they might agree to it if asked), and it probably does not even have any information on used file formats. There's also at least a "Intel 386/486 C Code Builder Kit Reference Manual" besides this book.

 

Finding the complete v1.1 version of the compiler could also be helpful but it seems the only thing leaked to the public Internet is the incomplete v1.0 package.

 

edit2:

 

The "DT" debug info header which begins straight after the main game "MT" in 0.2 is probably:

000 uint16_t magic
002 uint32_t totalsize....: 0x0001abef (109551)
006 uint16_t recordcount..: 0x0007 (7)
008 uint16_t unknown......: 0x001c (28)

then recordcount times uint32_t pointers to different kinds of debug data

  table1[0]: 0x0000f799 (63385)
  table1[1]: 0x00011036 (69686)
  table1[2]: 0x000149be (84414)
  table1[3]: 0x0001a7d4 (108500)
  table1[4]: 0x000202e0 (131808)
  table1[5]: 0x00022a5d (141917)
  table1[6]: 0x000247c6 (149446)

These are counted starting from the beginning of the main game MT, not from the DT header (or whole exe). I do not know how exactly the debug data structures or tables those pointers to work yet. It does not seem like the 7 pointers just point to debug data for 7 source files because the formats look completely different, though if you only look at what's every other pointer it seems more similar.

 

I'll take a look at the fixups for you tomorrow.

 

Also the dword at 0xE in the main header (unknown4) definitely seems to be initial stack pointer. Try setting a breakpoint on program entry in DOSBox, change it and compare ESP values.

 

yet more editing:

 

@SaladBadger I'm starting to get how the fixups work now. I'm too tired to investigate more, write good explanations or post some code right now thoug (been having some problems getting sleep...)

 

Remove the last uint32_t from the main header definition, that's already part of fixup data. It probably tells the count of fixup records (probably each is exactly 2 bytes) which follow (=0x4AD in v0.2). If you skip that many bytes*2 ahead, you'll hit what I think is another fixup record count with more records to follow.

 

After the first count you can see the fixup data starts 0x15 0x80 0x36 0x80 ... ... Well, if you look at the disassembly, 0x15 and 0x36 (0x2000025 and 0x2000046 after relocation if you look at memdumps that start from 0x2000000) are excatly where the first addresses that need fixups applied are in the code, parts of mov instructions.

 

This actually mighy be much less overdone than LE fixups (and more like PE was IIRC).

 

I've also got a little trick for you that might help investigating more: you can change the address the loader will load the MT to in memory! Open the exe in a hex editor, see how there's "ORG=" in ASCII near the beginning and 0x2000000 in binary (00 00 00 02) right after that? Well, you can change the value and it really does also change the load address! But beware, some addresses will just crash DOSBox. ORG=0x3003412 (12 34 00 03) is one alternative to 0x2000000 that works. Now you can generate two memdumps using the DOSBox debugger with the game relocated to two different base addresses and compare them to quickly find all locations where fixups are applied.

Edited April 15, 2021 by xttl

[SaladBadger]

Oh, the debug information being offset to the beginning of the MT would explain why all the values were so confusing, now it suddenly makes a lot more sense. I was exploring some of the sub-tables. The first just seems to be basic information, the second seems to be type information, with structure dumps, and the third seems to be the delicious symbol data, containing information on all functions, their stack variables, and heap values and their offsets. I've been working on figuring out this format, and I can extract stack values from it at the moment, but I need to validate that I understood things properly still.

 

Each entry has a header defining the offset in memory where the heap variables will be loaded, as well as it's name. There's some other bits in there I'm still figuring out. Heap symbols always seem to start with a 0x05, followed by a 4-byte value which defines the offset from the offset specified in the header. Following that is two unknown bytes. My guess is that the first or possibly both define type information, as they seem equal across things with the same type (ie: it's 0x14 for all the s_ variables that define monster states, but different for something that isn't a s_ variable.). Following the two bytes, there's one byte that contains the length of the symbol string, followed of course by the symbol chars.

 

I'll explore this more today and work on getting extracting this information working in my MT load program.

 

Edit: Having some good success here. A couple of my assumptions were wrong, but I've been able to correct them and get something that works. Here's the first 100 symbol table entries as reported by my MTLoad: https://pastebin.com/04BTSKu1

 

Edit 2: Okay, yeah, some tweaks later, it loads the entire thing just fine (loading from pointer 2 in the table to pointer 3). The symbol information is basically a table of "commands", here's what I determined:

Command identifiers are specified by a single byte, followed by the payload. Here's the payloads:
All strings are an array of char, with the length specified by a preceding byte. "String" will be encoded as 06 53 74 72 69 6E 67 

cmd 0: Defines module
int32_t codesize; //Size of code in bytes
int32_t codestart; //Offset of the code
str name;

cmd 1: Defines function
int32_t offset; //Absolute offset from the base address
int16_t typeid; //Type id of return type, I think
int8_t b1: //unknown
int32_t stacksize; //assumption
int32_t dw1; //unknwon
str name;

cmd 2: Ends block. No payload. After a function or module. 

cmd 3: Specifies that following variables are relative to the specified offset.
int32_t offset;

cmd 4: Specifies that following variables are relative to the stack, or something like that. Used for parameters.

cmd 5: Variable. Can be relative to the stack or a heap pointer from the previous two commands
int32_t offset;
int16_t typeid;
str name;

cmd 15: Unknown. Usually before heap variables
int8_t b1; //always 0 in Doom 0.2, I think

cmd 23: Unknown. Usually before heap variables
int8_t b1; //always 0 in Doom 0.2, I think

cmd 64: Register variable. Can be used for args, but args are always passed by stack. Args specified this way appear to be MOVed into a register at the start.
int8_t b1; //Probably identifies the register
int16_t typeid; 
str name;

I'm not 100% sure I can create a coherent .MAP file, mostly due to the weird sectioning scheme compared to other executable formats like PE. Creating IDC should work, if there's some documentation on how it works. But creating some sort of table to get absolute addresses in memory should absolutely be possible.

 

edit 3: Actually looking at the heretic/hexen .MAPs it shouldn't be impossible, but lacking any further information about how things go I'm kinda forced to just give everything the same selector. It's not really a big deal, I think? But it looks strange. So far as I can tell, the memory bits in the executable have absolutely no way of distinguishing between TEXT and DATA sections, everything's.. just.. memory... There's nothing that even resembles a BSS section, beyond the bit in the header that specifies how large the program's address space is.

 

ah, let's just try this for now. I just gave all heap vars a selector of 0001 for now. Why not... It should be functional though, and it's been helpful for my own use.

Edited April 15, 2021 by SaladBadger

[xttl]

@SaladBadger

 

First, read 32-bit value at @ 0x18 (=0x3A in Doom 0.2) and jump to there, that is the start of fixup data. Here are two 16-bit values, first is the count of fixup records following, the second is unknown so far.

 

Now follow count times 16-bit values which are the fixup records themselves. I think the first n bits may be some sort of flags (eg. if you take first 4 it's always 8 in Doom 0.2) and then the next n bits are the fixup source address. Target address isn't specified at all, the loader must just read the unrelocated value already stored in the code/data anyway (this is how Windows PE .reloc data also works).

 

If you loop through the data setting addr=value&0x7FFF, the addresses all make sense for Doom v0.2, up until and including 0xFFF5 which becomes 0x7FF5. That's also at the end of the first fixup "section".

 

If you don't filter the bits at all, the addresses from the first "fixup section" will be 0x8000 too high, but then the addresses from the second section (eg. first is 0xD974) do match reasonable locations in the exe or memory dump.

 

edit: hmm I guess the unknown value stored along the count of fixups in "section" may be related? In Doom 0.2 it's 0 for the first fixups, 1 for the second, 4 for third, 7 for fourth. If you filter addresses with &0x7FFF, then take that unknown value and multiply it by 0x8000, and use it as the base address for fixups in the following "section" you get this.

 

I have to go through some of those and see if they're reasonable... (output format in that paste is raw 16 bit fixup data => guessed bit flags, guessed address)

 

Edited April 16, 2021 by xttl

[Never_Again]

20 hours ago, xttl said:

edit: Hey look at what's on eBay. Sadly it is too expensive to buy just for something like this

 

It isn't.

 

20 hours ago, xttl said:

(and the seller does not even offer shipping to Europe, though of course they might agree to it if asked),

 

If that book helps you in your alpha hacking endeavors I can buy it and have it shipped to you or ship it myself.

[SaladBadger]

thank you so much for the research xttl. The lowest fixup records are giving me confusing results, usually not directly aligning with a memory access, but later ones seem to start being more sensible. Against my 0-based flat executable, I'll see a record against 000079A7 and then I poke at 000079A5 in ghidra and there's a cmp ebx, dword ptr [#0003a1d0] (3b 1d d0 a1 03 00) which corresponds directly. I'll get fixup support implemented tonight, and hopefully I can dump my new sources with the MAP generator and fixup support added tomorrow.

 

One minor issue I'm still yet to track down is that the texture mapping function tables (the alpha texture mappers in all builds I've studied is much like the heretic one, essentially using a huge unrolled loop with jumps into it depending on how many pixels need to be drawn. I think it evolved directly into the heretic one actually, from my work with 0.5) don't appear to show up in the information, but I may just be being dense parsing my own output. The ASM texture mappers seem slightly enigmatic to me since they don't register in the symbol tables at all, but I'm sure I'm just missing something obvious.

 

edit: I think the second value is just an offset applied to the values, kinda. The first int16 is the amount of records, the second is added to the read values * 32768. This has had successful effects for me. I'm now really curious what the highest bit of the records indicate.

 

edit (god here we go again) 2: Something definitely is fishy with the values that have the high bit set, masking out the highest bit doesn't seem to create coherent values. All without the high bit set correspond directly to memory addresses in the code. I'll spend a little more time analyzing it.

Edited April 16, 2021 by SaladBadger

[xttl]

23 minutes ago, SaladBadger said:

edit: I think the second value is just an offset applied to the values, kinda. The first int16 is the amount of records, the second is added to the read values * 32768. This has had successful effects for me. I'm now really curious what the highest bit of the records indicate.

 

Yeah, I already figured that out and edited the previous post. :P

 

ATM I'm going to try and see if I can get v0.2 or v0.3 to launch inside a 32-bit process in Windows/Linux (so like LE loader but for MT).

[SaladBadger]

Ah heh, I had missed that since I've been buried in my output. I resolved the issue of the missing texture mappers, I was just being dense. The texture mapper fixups are present in the table with the offset value of 1, but they appear before the function fixups, creating a discontinuity. For now, I'm trying to apply values while ignoring the flagged entries because I don't get them. They're there so they probably have a meaning, but I can't comprehend what it is yet.

[xttl]

3 minutes ago, SaladBadger said:

For now, I'm trying to apply values while ignoring the flagged entries because I don't get them. They're there so they probably have a meaning, but I can't comprehend what it is yet. 

 

It probably tells the fixup type at least, eg. you may need to fixup a 16-bit addres in some cases.

[SaladBadger]

That was my assumption for a while, but I eventually realized I wouldn't get sane values at all unless I always masked out the highest bit. Like I had my program set to ignore any values where it was set and then nothing loaded at all... At the moment I'm just throwing out the first table because I can't make heads or tails of why the values are the way they are. Everything else seems to work so far, I'm analyzing a relocated flat binary right now in ghidra and there's no obvious issues.. I'll compare the output against your DosBox capture and see if I can determine where anomalies are rising. 

 

edit jesus i'm a fucking idiot the anomalous values were coming from the FPU emulator executable, which I process for... some reason? (actually I started processing it just to ensure my assumptions are correct) everything is fine please proceed as normal. Don't do this when you're running on no sleep, I guess is my moral of tonight.

 

and yeah, with these changes, I mostly match the dump. There's some exceptions, since the C CRT and the like have started up at the time of your dump, some values in memory have changed, but my relocated values in the code data all seem to match.

 

Here's my version of MTLoad for the night. It will generate a simple address map when there is sufficient information, and you can now specify a base address with the -b command line parameter.

MTLoad.zip

Edited April 16, 2021 by SaladBadger

[xttl]

9 hours ago, xttl said:

ATM I'm going to try and see if I can get v0.2 or v0.3 to launch inside a 32-bit process in Windows/Linux (so like LE loader but for MT). 

 

Current status is:

 

Doom 0.2 can launch and display the TITLEPIC. It gets stuck in an infinite loop waiting for variable lastscan to change (normally it is changed by the installed custom keyboard interrupt handler but obviously there is no such thing now).

 

If that loop is patched out, it gets into the game and draws the HUD border but no actual game view and gets stuck in another loop inside IO_NewFrame where it is waiting for processedframe != playercmdframe[consoleplayer].

 

If THAT loop is also patched out, it fails due to a divide by zero in FixedDiv (called from R_DrawPlanes, at 0x69CE).

 

If I install an exception handler that just ignores divides by zero, it does not crash but still draws nothing on screen except for the view border.

forgot to increment the instruction pointer inside the exception handler, anyway it's still not working, it's crashing in HIGHBLIT now

forgot that obviously I need to alloc executable memory in my malloc hook handler because of that thing, now it's not crashing but it still isn't drawing the game view on screen either

 

I dunno how much more I'm going willing work on this, running the 0.2 alpha isn't that useful.

 

OMG IT FINALLY DID SOMETHING INTERESTING

It's just stuck there but at least it rendered one actual ingame frame.

 

Also the guess at the fixup data format seems 100% correct so far. (full list of fixups from Doom v0.2)

(I'm going to say it IS 100% correct since the loder managed to launch the game)

Edited April 16, 2021 by xttl

[SaladBadger]

Have you gotten any of the pre-PRB versions in leloader working before? I worry some they might be tricky since the timer interrupt does a lot of work in them, such as collecting user input and advancing playercmdframe. I suspect that's all emulatable with some work, but it makes things trickier

[xttl]

1 minute ago, SaladBadger said:

Have you gotten any of the pre-PRB versions in leloader working before? I worry some they might be tricky since the timer interrupt does a lot of work in them, such as collecting user input and advancing playercmdframe. I suspect that's all emulatable with some work, but it makes things trickier

 

Nope, haven't even tried. Indeed it makes it impossible to use the same approach as in newer versions.

 

11 hours ago, Never_Again said:

If that book helps you in your alpha hacking endeavors I can buy it and have it shipped to you or ship it myself.

 

Thanks for the offer, but seems that at this point it won't be needed. I suspect that it wouldn't have contained information about the file formats anyway. (most users of the compiler wouldn't need it, they'd probably put it in a supplement of some kind or maybe the reference book)

[OpenRift]

Okay, so I probably should've asked about this a while ago, but when I was experimenting with hacking the Final Doom EXE, I did my best in implementing the increased visplane limit as seen in doom-plus. Once I did, I got this result:

Yeesh. My only guess is that I would also have to increase the drawsegs limit to match. Am I getting that right? Or did I just not do the visplane hack right begin with?

Here's the patch I have so far (you'll have to provide the EXE yourself to test because it wouldn't fit the size limit):

visplane_test.zip

 

For reference, here's the relevant changes I made to it look like.

Header                        : It's always necessary
DOOM2.EXE
00027BC0: C0 00 ;new size of segment
00027BC1: 77 F0
00027BC2: 08 1A

visplanes[MAXVISPLANES]       : 128    * 8   = 1024
DOOM2.EXE
0003ADDF: 74 00
0003ADE0: B8 00
0003ADE1: 03 09
0003AE4B: 94 00
0003AE4C: 3C 00
0003AE4D: 03 09
0003AE54: B0 00
0003AE55: A9 00
0003AE56: 03 09
0003AF33: C0 00
0003AF34: 3C 00
0003AF35: 03 09
0003AF60: C0 00
0003AF61: 3C 00
0003AF62: 03 09
00078e35: 94 00
00078e36: BB 00
00078e37: 03 09
00078ed2: 94 00
00078ed3: BB 00
00078ED4: 03 09
00078EFF: 94 00
00078F00: BB 00
00078F01: 03 09
00078F15: 80 00
00078F16: 00 04
00079142: 94 00
00079143: BB 00
00079144: 03 09
00079153: 80 00
00079154: 00 04
00079189: 94 00
0007918A: BB 00
0007918B: 03 09

 

[Redneckerz]

@OpenRiftI am sure i have asked before but you are aware of all the .CRK Cracker files that exist for Doom, right? When opened in Notepad++, you can see their offsets.

 

I don't think that works on Final Doom perse since the binary is different, mind you.

 

You just want @xttl to release his UDoomHack version in full so there is one and only vanilla Doom engine out there. ;)

[OpenRift]

1 hour ago, Redneckerz said:

@OpenRiftI am sure i have asked before but you are aware of all the .CRK Cracker files that exist for Doom, right? When opened in Notepad++, you can see their offsets.

  

I don't think that works on Final Doom perse since the binary is different, mind you.

 

You just want @xttl to release his UDoomHack version in full so there is one and only vanilla Doom engine out there. ;)

I mean like, I essentially matched the patterns to find which data to patch, which worked out for the SAVEGAMESIZE fix. It's hard to describe. I know you can open them in Notepad++, that's where I'd been inputting all this stuff. 

 

Of course I want UDoomhack to be finished, but I wanted to try my hand at something in the meantime, taking a bit of a different approach to covering all the limit-removing bases: having one each for 1, 2 and Final.

[OpenRift]

Well, I figured out the pattern for raising the visplane limits in Final Doom's EXE!

 

Here's the patched EXE with the crack file! Tested on Plutonia 2's Map09, which normally has a VPO right as you get the red key. 

FDOOMP.zip

[Redneckerz]

3 hours ago, OpenRift said:

Well, I figured out the pattern for raising the visplane limits in Final Doom's EXE!

 

Here's the patched EXE with the crack file! Tested on Plutonia 2's Map09, which normally has a VPO right as you get the red key. 

FDOOMP.zip

Epic stuff. So now we have two FDoomP's:

• Archy's, based on Ultimate Doom, Doom-plus 1.92.2 actually (And not actual Final Doom)
• And your's based on the actual Final Doom codebase.

I take it you raised the limits to the same standard as Entryway's Doom-plus hacks do?

Edited May 4, 2021 by Redneckerz

[OpenRift]

6 minutes ago, Redneckerz said:

Epic stuff. So now we have two FDoomP's:

•  Archy's, based on Ultimate Doom, Doom-plus 1.92.2 actually (And not actual Final Doom)
• And your's based on the actual Final Doom codebase.

 I take it you raised the limits to the same standard as Entryway's Doom-plus hacks do?

Wdym by 'same standard'?

[Redneckerz]

2 minutes ago, OpenRift said:

Wdym by 'same standard'?

Its not really an exact standard, but Entryway raised the limits for all his -plus executable hacks in the same way. See Doom2-plus:

==Raised limits==
The following static limits are raised in Doom2-plus:
limit                         : old    * k   = new
-------------------------------------------------------
visplanes[MAXVISPLANES]       : 128    * 8   = 1024
drawsegs[MAXDRAWSEGS]         : 256    * 8   = 2048
SAVEGAMESIZE                  : 180224 * 16  = 2883584
activeplats[MAXPLATS]         : 30     * 256 = 7680
vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
linespeciallist[MAXLINEANIMS] : 64     * 256 = 16384
openings[MAXOPENINGS]         : 16384  * 4   = 65536

Doom-plus was actually derived from Doom2-plus, which serves as a base hack for the others.

[OpenRift]

5 minutes ago, Redneckerz said:

Its not really an exact standard, but Entryway raised the limits for all his -plus executable hacks in the same way. See Doom2-plus:

==Raised limits==
The following static limits are raised in Doom2-plus:
limit                         : old    * k   = new
-------------------------------------------------------
visplanes[MAXVISPLANES]       : 128    * 8   = 1024
drawsegs[MAXDRAWSEGS]         : 256    * 8   = 2048
SAVEGAMESIZE                  : 180224 * 16  = 2883584
activeplats[MAXPLATS]         : 30     * 256 = 7680
vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
linespeciallist[MAXLINEANIMS] : 64     * 256 = 16384
openings[MAXOPENINGS]         : 16384  * 4   = 65536

Doom-plus was actually derived from Doom2-plus, which serves as a base hack for the others.

Ah, well I used the same replacement hex values, so it should be.

[OpenRift]

Figured out drawsegs!! I tried to do visprites but haven't gotten anywhere yet. Hopefully I'll figure it out next time I have a go at it!

 

Here's the patched exe with crk file (also includes visplanes and SAVEGAMESIZE increases): FDOOMP_drawsegs.zip

[OpenRift]

Okay, I've increased the limits for MAXOPENINGS and MAXLINEANIMS.

 

Here's the updated version.

FDOOMP_openings&linespeciallist.zip

 

Still having a tough time finding where vissprites and activeplats addresses are in Final Doom's EXE. Don't see any matching patterns that make me confident enough to say that I've found which values need replacing. If anyone else would like a crack at it, here's doom-plus's changes that I've been using for reference:

activeplats[MAXPLATS]         : 30     * 256 = 7680
DOOM.EXE
000374C6: 14 00
000374C7: C4 00
000374C8: 02 16
000374CF: 14 00
000374D0: C4 00
000374D1: 02 16
000374E1: 14 00
000374E2: C4 00
000374E3: 02 16
000374EA: 14 00
000374EB: C4 00
000374EC: 02 16
000374F3: 14 00
000374F4: C4 00
000374F5: 02 16
000374FC: 14 00
000374FD: C4 00
000374FE: 02 16
00037505: 14 00
00037506: C4 00
00037507: 02 16
0003750E: 14 00
0003750F: C4 00
00037510: 02 16
00037520: 14 00
00037521: C4 00
00037522: 02 16
00037529: 14 00
0003752A: C4 00
0003752B: 02 16
00037532: 14 00
00037533: C4 00
00037534: 02 16
0003753B: 14 00
0003753C: C4 00
0003753D: 02 16
00037544: 14 00
00037545: C4 00
00037546: 02 16
00038AC2: 14 00
00038AC3: C4 00
00038AC4: 02 16
0006F256: 14 00
0006F257: C4 00
0006F258: 02 16
0006F271: 14 00
0006F272: C4 00
0006F273: 02 16
0006F27F: 83 66
0006F280: F8 3D
0006F281: 78 00
0006F282: 75 78
0006F283: D0 75
0006F284: 5A CF
0006F285: 59 5A
0006F286: 5B 59
0006F287: C3 5B
0006F288: 8D C3
0006F2A6: 14 00
0006F2A7: C4 00
0006F2A8: 02 16
0006F2C5: 14 00
0006F2C6: C4 00
0006F2C7: 02 16
0006F2D2: 14 00
0006F2D3: C4 00
0006F2D4: 02 16
0006F2E0: 83 66
0006F2E1: F8 3D
0006F2E2: 78 00
0006F2E3: 75 78
0006F2E4: BF 75
0006F2E5: 5A BE
0006F2E6: 59 5A
0006F2E7: 5B 59
0006F2E8: C3 5B
0006F2E9: 8D C3
0006F2FA: 14 00
0006F2FB: C4 00
0006F2FC: 02 16
0006F303: 09 08
0006F306: 14 00
0006F307: C4 00
0006F308: 02 16
0006F30A: 5A EB
0006F30B: 5B 21
0006F30C: C3 83
0006F30D: 83 C0
0006F30E: C0 04
0006F30F: 04 66
0006F310: 83 3D
0006F311: F8 00
0006F317: 14 00
0006F318: C4 00
0006F319: 02 16
0006F31F: ED EC
0006F339: 14 00
0006F33A: C4 00
0006F33B: 02 16
0006F342: 27 25
0006F345: 14 00
0006F346: C4 00
0006F347: 02 16
0006F355: 14 00
0006F356: C4 00
0006F357: 02 16
0006F362: 14 00
0006F363: C4 00
0006F364: 02 16
0006F366: 5E EB
0006F367: 5A 21
0006F368: 5B 83
0006F369: C3 C2
0006F36A: 83 04
0006F36B: C2 66
0006F36C: 04 81
0006F36D: 83 FA
0006F36E: FA 00
0006F374: 14 00
0006F375: C4 00
0006F376: 02 16
0006F37B: EE EC
00072505: 14 00
00072506: C4 00
00072507: 02 16
0007250A: 1E 00
0007250B: 00 1E

vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
DOOM.EXE
0003B27E: E4 00
0003B27F: C3 70
0003B280: 05 17
0003B40A: E4 00
0003B40B: A5 80
0003B40C: 05 16
0003BE70: E4 00
0003BE71: A5 80
0003BE72: 05 16
0003BE79: E4 00
0003BE7A: A5 80
0003BE7B: 05 16
0003BEB8: E4 00
0003BEB9: A5 80
0003BEBA: 05 16
0003C23C: E4 00
0003C23D: A5 80
0003C23E: 05 16
0003C245: E4 00
0003C246: A5 80
0003C247: 05 16
00079DBA: E4 00
00079DBB: A5 80
00079DBC: 05 16
0007A1AE: E4 00
0007A1AF: C3 70
0007A1B0: 05 17
0007A614: E4 00
0007A615: A5 80
0007A616: 05 16
0007A638: E4 00
0007A639: A5 80
0007A63A: 05 16
0007A660: E4 00
0007A661: A5 80
0007A662: 05 16
0007A665: E4 00
0007A666: A5 80
0007A667: 05 16
0007A942: E4 00
0007A943: A5 80
0007A944: 05 16

Maybe I can work on increasing the heapsize to 32MB instead. 

[Redneckerz]

6 minutes ago, OpenRift said:

Okay, I've increased the limits for MAXOPENINGS and MAXLINEANIMS.

 

Here's the updated version.

FDOOMP_openings&linespeciallist.zip

 

Still having a tough time finding where vissprites and activeplats addresses are in Final Doom's EXE. Don't see any matching patterns that make me confident enough to say that I've found which values need replacing. If anyone else would like a crack at it, here's doom-plus's changes that I've been using for reference:

activeplats[MAXPLATS]         : 30     * 256 = 7680
DOOM.EXE
000374C6: 14 00
000374C7: C4 00
000374C8: 02 16
000374CF: 14 00
000374D0: C4 00
000374D1: 02 16
000374E1: 14 00
000374E2: C4 00
000374E3: 02 16
000374EA: 14 00
000374EB: C4 00
000374EC: 02 16
000374F3: 14 00
000374F4: C4 00
000374F5: 02 16
000374FC: 14 00
000374FD: C4 00
000374FE: 02 16
00037505: 14 00
00037506: C4 00
00037507: 02 16
0003750E: 14 00
0003750F: C4 00
00037510: 02 16
00037520: 14 00
00037521: C4 00
00037522: 02 16
00037529: 14 00
0003752A: C4 00
0003752B: 02 16
00037532: 14 00
00037533: C4 00
00037534: 02 16
0003753B: 14 00
0003753C: C4 00
0003753D: 02 16
00037544: 14 00
00037545: C4 00
00037546: 02 16
00038AC2: 14 00
00038AC3: C4 00
00038AC4: 02 16
0006F256: 14 00
0006F257: C4 00
0006F258: 02 16
0006F271: 14 00
0006F272: C4 00
0006F273: 02 16
0006F27F: 83 66
0006F280: F8 3D
0006F281: 78 00
0006F282: 75 78
0006F283: D0 75
0006F284: 5A CF
0006F285: 59 5A
0006F286: 5B 59
0006F287: C3 5B
0006F288: 8D C3
0006F2A6: 14 00
0006F2A7: C4 00
0006F2A8: 02 16
0006F2C5: 14 00
0006F2C6: C4 00
0006F2C7: 02 16
0006F2D2: 14 00
0006F2D3: C4 00
0006F2D4: 02 16
0006F2E0: 83 66
0006F2E1: F8 3D
0006F2E2: 78 00
0006F2E3: 75 78
0006F2E4: BF 75
0006F2E5: 5A BE
0006F2E6: 59 5A
0006F2E7: 5B 59
0006F2E8: C3 5B
0006F2E9: 8D C3
0006F2FA: 14 00
0006F2FB: C4 00
0006F2FC: 02 16
0006F303: 09 08
0006F306: 14 00
0006F307: C4 00
0006F308: 02 16
0006F30A: 5A EB
0006F30B: 5B 21
0006F30C: C3 83
0006F30D: 83 C0
0006F30E: C0 04
0006F30F: 04 66
0006F310: 83 3D
0006F311: F8 00
0006F317: 14 00
0006F318: C4 00
0006F319: 02 16
0006F31F: ED EC
0006F339: 14 00
0006F33A: C4 00
0006F33B: 02 16
0006F342: 27 25
0006F345: 14 00
0006F346: C4 00
0006F347: 02 16
0006F355: 14 00
0006F356: C4 00
0006F357: 02 16
0006F362: 14 00
0006F363: C4 00
0006F364: 02 16
0006F366: 5E EB
0006F367: 5A 21
0006F368: 5B 83
0006F369: C3 C2
0006F36A: 83 04
0006F36B: C2 66
0006F36C: 04 81
0006F36D: 83 FA
0006F36E: FA 00
0006F374: 14 00
0006F375: C4 00
0006F376: 02 16
0006F37B: EE EC
00072505: 14 00
00072506: C4 00
00072507: 02 16
0007250A: 1E 00
0007250B: 00 1E

vissprites[MAXVISSPRITE]      : 128    * 8   = 1024
DOOM.EXE
0003B27E: E4 00
0003B27F: C3 70
0003B280: 05 17
0003B40A: E4 00
0003B40B: A5 80
0003B40C: 05 16
0003BE70: E4 00
0003BE71: A5 80
0003BE72: 05 16
0003BE79: E4 00
0003BE7A: A5 80
0003BE7B: 05 16
0003BEB8: E4 00
0003BEB9: A5 80
0003BEBA: 05 16
0003C23C: E4 00
0003C23D: A5 80
0003C23E: 05 16
0003C245: E4 00
0003C246: A5 80
0003C247: 05 16
00079DBA: E4 00
00079DBB: A5 80
00079DBC: 05 16
0007A1AE: E4 00
0007A1AF: C3 70
0007A1B0: 05 17
0007A614: E4 00
0007A615: A5 80
0007A616: 05 16
0007A638: E4 00
0007A639: A5 80
0007A63A: 05 16
0007A660: E4 00
0007A661: A5 80
0007A662: 05 16
0007A665: E4 00
0007A666: A5 80
0007A667: 05 16
0007A942: E4 00
0007A943: A5 80
0007A944: 05 16

Maybe I can work on increasing the heapsize to 32MB instead. 

Impressive work on this, i'd love to see the final part in the end.

 

Or maybe pray to the executable overlords that Xttl brings forward the Ultimate Hack. Till then, Doom32 it is!

[OpenRift]

23 minutes ago, Redneckerz said:

 Impressive work on this, i'd love to see the final part in the end.

  

Or maybe pray to the executable overlords that Xttl brings forward the Ultimate Hack. Till then, Doom32 it is!

Well shit, I forgot how simple changing the heapsize is, it's literally only 4 values that have to be changed.

 

Here you go :)

 

Final Doom

fdoom32.zip

The Ultimate Doom

udoom32.zip

 

UDOOM32 also comes with all the limit increases seen in Doom-plus.

 

FDOOM32's heapsize increase should be especially helpful on Urania, because I know that one can have zone memory issues if you try to save in certain situations (not like a savegame size limit overflow), akin to some points in Back to Saturn X Episode 2.

Edited May 26, 2021 by OpenRift

[Redneckerz]

13 minutes ago, OpenRift said:

Well shit, I forgot how simple changing the heapsize is, it's literally only 4 values that have to be changed.

 

Here you go :)

 

Final Doom

fdoom32.zip

The Ultimate Doom

udoom32.zip

 

UDOOM32 also comes with all the limit increases seen in Doom-plus.

 

FDOOM32's heapsize increase should be especially helpful on Urania, because I know that one can have zone memory issues if you try to save in certain situations (not like a savegame size limit overflow), akin to some points in Back to Saturn X Episode 2.

LMAO, you may want to craft a directory for these things!

So UDoom32 is Doom+ + 32 MB heapsize?

 

Ill be having a hard time documenting all these variants! :P

 

PS: One thing i thought for no sensible reason: How far can heapsize be pushed? I was reminded of this when the new Woof was given 64 MB as a standard. Now, under DOS, there are more limits (and perhaps you need an extender), but i am curious..*

 

PPS: This is also a completely off-beat case ofcourse. 32 MB under DOS is enough to support insane things like BTSX, and i can't think of a Vanilla WAD that pushes more than that. But who knows. Doom64 with 64 MB heap? Doom128? :P