wesleyjohnson
Forum Regular
Posts: 675
Registered: 04-09 |
Am already overloaded with projects so cannot take on another, but can give you info.
DoomLegacy already did the fixes for making Doom source compile on 64 bit machines. You can download the DoomLegacy source and compare the wad data structures to see how it is done.
The problem is that short and int in the original source are used to mean 16 bit and 32 bit fields in the wad file. Compiling with a 64 bit machine makes short a 32 bit field and int a 64 bit field, makes the wad structure size and field alignment wrong, and when used to read a wad gets wrong data.
The data structures in Doom must be changed to be 16 bit and 32 bit fields for all compilers.
This is done using stdint, which tests the machine size and selects a type that gives the specified size. Some ports do the same determinations in their own header files.
1. #include <stdint.h>
2. In wad handling structures, change uses of "short" to int16_t
3. In wad handling structures, change uses of "int" to int32_t
4. There are some exceptions to the above general rules, and the best way to find them is to look at the DoomLegacy source.
5. Many fields become uint32_t in order to use a larger unsigned range.
But some must remain int32_t because a -1 was used to mark unused fields. Once the tests to detect the -1 are changed to be unsigned, then uint32_t can be used. This also fixes some field range overflows from overly-large wads.
Using val as an example:
--- int val;
--- if( val < 0 )
+++ // detect -1 value in wad
+++ #define VAL_UNUSED 0xFFFFFFFF
+++ uint32_t val;
+++ if( val == VAL_UNUSED )
Do the same for fields using short, but substitute uint16_t and 0xFFFF instead.
DoomLegacy source has comments that explain the choices better than I can remember. Other ports will have similar fixes, but Chocolate Doom, DoomLegacy, and prboom will be closer to the original than most others.
BTW: Doom compiled as a 64 bit program probably will run slower than if it is compiled as a 32 bit program. This is because so much of the data is 16 bit and 32 bit lengths, that compiled as 64 bit it must make extensive use of instruction prefixes to access wad data.
The only solution for this is to convert all the wad contents to 64 bit data fields (kept in a new internal data structure) upon reading the wad, and waste the memory. But then processor cache will only hold half as many wad structures, which forces more main memory fetches, which also slows the program execution.
If it affected video rendering it would be serious, but it doesn't.
It just does not give you any gain in performance.
I just prefer to keep compiling doom as a 32 bit program, which switches the hardware to 32 bit instruction set default memory accesses.
Last edited by wesleyjohnson on 12-29-12 at 22:06
|
12-29-12 20:04 
