Prboom hexen download code#

Very nice explanation, this is exactly what I was after. ZDoom already does this, I believe, by using the Hexen map format. That is to say, a larger number of bytes would be needed to store the number. To increase the limit further, you would have to change the wad format to be able to store a number larger than 65535. To handle the 'no sidedef' case, you check for 65535, which is what -1 looks like if you interpret it as an unsigned number.

It is easy to double the largest sidedef number by interpreting the signed quantity as an unsigned quantity, therefore you get sidedefs numbered 0 to 65535. Sidedef numbers are stored in the linedefs lump in your wad file as signed 2-byte numbers, that means you can have sidedefs numbered -32768 to 32767, with -1 meaning 'no sidedef'

Yes, exactly, there is some limit in a table in the file structure.

Prboom hexen download code#

And I'm not much of a programmer (albeit not dumb either) so go easy on the code lingo. BTW, please note that there has been a fair bit of exchange of ideas and code - in both directions - between Choc and Prb+.Why does everyone double the limit as opposed to making it infinite, or something absurd like 512k? I understand that there might be a limit in some table in the file structure or whatever, but I'd like to have it explained to me. If wads appear that use them, I guess you could make a feature request to Andrey and he'd be able to incoprorate Chocolate's code. However, these are very rarely used features mostly in the Text area (which in many cases affect much more than game text). any limit-extending vanilla-compatible exe - rather than have my demo erased or ruined on the spot by a program crash.)Īddendum: Oh yeah, Chocolate supports a few dehacked features that AFAIK no other ports (incl. OK, but in that case I'd rather have a demo that will play back in something - i.e. (You also see the argument that you might end up recording a demo that hits a vanilla limit, and thus won't play back with Doom2.exe. You need to check the settings to bring them in line with what you want, of course. If you want the vanilla behaviour, but are happy to have many options with respect to resolution, visual features, higher limits and options of compatibility with several other standard formats, then you should go for Prboom+. Likewise if you don't want to bother yourself with setting options. If you prefer something that looks just like vanilla, and crashes or fails exactly when vanilla does, then you should go for Chocolate. Where there are problems with Prboom+, this tends to be due to the different memory management, meaning uninitialized fields will have different data.Īnyway, those are very rare problems and shouldn't worry anyone apart from the developers. Where vanilla demos fail with Chocolate, this has tended to be due to map issues that crash the program (pr+ will work around these map errors and attempt to play the map anyway, sometimes successfully).

So the claim that Choc will play back almost any vanilla demo successfully is more by presumption and the fact that very few demos have been discovered to fail with it. Though please note that Chocolate has not, as far as I know, actually been tested with every demo at compet-n and DSDA, in the way that Prboom+ has (as of 2007, anyway - yes, I actually did this). There are just a small handful out of many thousands of vanilla demos where there is a problem with either. But that's just the defaults you can change them to whatever you like.īetween Choc and Prboom+ (with -complevel 2, applied), in terms of behavioural compatibility with vanilla Doom2.exe, there's not much in it (and both have options for forcing the behaviour of the other main vanilla exes). The only basis for putting it 'in between' Choc and Prboom (other than fixes to compatibility issues) is that the default cfg is more vanilla-like. Prboom+ supports all options that Prboom does (it is based on it, after all), together with many extra ones, quite a few bug and glitch fixes and additional optional features.Įssentially, prboom+ is the current line of development of prboom (see the changelogs!). Between prboom and prboom+, I can't see much reason for not choosing prboom+, unless there are some compilation problems in the OS you're using (and it isn't one for which an executable is available).