entryway Posted September 15, 2005 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 0 Share this post Link to post
Grazza Posted September 15, 2005 I've only time to do some cursory testing, but it seems to work well. 0 Share this post Link to post
entryway Posted September 16, 2005 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 0 Share this post Link to post
Doom Marine Posted September 16, 2005 Wow! That's a relief!! Now I won't have to trim any details in my current map, if it comes down to that! 0 Share this post Link to post
Grazza Posted September 18, 2005 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. 0 Share this post Link to post
entryway Posted September 18, 2005 who has the sources and binaries of any previous versions of my prboom send me them on e6y@yahoo.com 0 Share this post Link to post
Grazza Posted September 18, 2005 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? 0 Share this post Link to post
entryway Posted September 18, 2005 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. 0 Share this post Link to post
Quasar Posted September 21, 2005 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. 0 Share this post Link to post
entryway Posted September 21, 2005 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 0 Share this post Link to post
deep Posted September 21, 2005 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. 0 Share this post Link to post