prboom: support up to 65536 sidedefs instead of 32768

[entryway]

VinceDSS said in prboom issues thread:
here's a quick list:
- add support for WADs like Deus Vult map05

Get the test version here: prboom226_19d

[Grazza]

I've only time to do some cursory testing, but it seems to work well.

[entryway]

prboom226_19d
Use -heapsize x parameter for fast loading from savegames. Especially for prboom. Default values: 8 for prboom, 16 for glboom.

glboom.exe -file dv.wad -warp 5 -heapsize 64

[Doom Marine]

Wow! That's a relief!! Now I won't have to trim any details in my current map, if it comes down to that!

[Grazza]

I got some intermission crashes with 226_19 and 226_19b. These occurred when watching e3cm1659 using glboom.exe (at the end of E3M3, but also with some later intermissions when bypassing E3M3).

I tested it with 226_18 (again with glboom.exe), and these crashes did not occur.

[entryway]

who has the sources and binaries of any previous versions of my prboom send me them on e6y@yahoo.com

[Grazza]

I've got most of them (more than 25 megs in source zips, and over 22 megs in binary zips). Which ones would be most useful?

[entryway]

Grazza said:

I've got most of them

wow. I have only last version %)

Grazza said:

more than 25 megs in source zips

Send me all of them on entryway at all-info com ua. Thanks.

[Quasar]

I DO hope there is going to be some commentary and/or changelogs from the prboom guys on how this is done so that other ports can share the modifications. No other port authors have ever been kind enough to point out a *complete* list of signed short bottlenecks that must be eliminated in order to support large maps, as well as making sure that their changes do not break compatibility in any way.

[entryway]

It is enough to compare source codes of last and penultimate version. Or to make search in last version of source codes of lines with "unsigned short" and marked by the comment //e6y

[deep]

Quasar said:

I DO hope there is going to be some commentary and/or changelogs from the prboom guys on how this is done so that other ports can share the modifications. No other port authors have ever been kind enough to point out a *complete* list of signed short bottlenecks that must be eliminated in order to support large maps, as well as making sure that their changes do not break compatibility in any way.

You really don't need that. I think it would be faster for one to just change one's own code vs plodding some other code. Anyway, it was pretty trivial for me to change JDOOM's code to handle this.

If you use MSVC (and BC and others assuming you havent turned the error off), what happens is that the unsigned vs signed comparison error pops up. Not too many of those.

To make this "easy" change the internal format to int when reading in a PWAD and nodes, hence that part of the code (that works with the internal format) works ok.

The other thing is that when reading in a PWAD, you typically can't use -1 for a "not present" check. So you need a special "define for -1" here since it can't be a signed comparision (at load time), and then store -1 in the internal "int" format. Hence the rest of the code works as intended.

That's the basic drill. There are some other issues that come up since now maps are much larger, hence if you have any "limits", they will get reached. Just grab a large PWAD and these sort of things just pop right out.

Don't recall how long it took me, but it was within 1 day and way shorter than the editor :) I wasn't even familiar with JDOOM.