Originally posted by Inquisitor
Well, a unix port would pave the way to an OSX port, so, not sure this is "far" into the future, depends on the speed of the delivery of the *nix port 
As I frequently put on my progress reports at work, "we are making slow, but forward, progress"
The entire thing makes it through the C preprocessor now, so I got the filename thing straightened out, at least...
:V: has done things that irritate me in the code, but I can't blame them since I know what it's like having deadlines (and only needing to support one development platform)... But here's my top list:
1. case sensitivity in file names -- the file named MODEL.H is included as "Model.h" "model.h" etc. My solution was to convert all filenames to lower-case only (and update the #include lines to match)
2. Non-standard C++: using variable and struct members that have the same name as the type (stepped_rotation *stepped_rotation) I am renaming the probematic typedefs to use _t at the end (e.g., stepped_rotation_t), which is what POSIX does.
3. Non-standard C++ part 2: anonymous structs (the x,y,z in struct vector; and the vectors in struct matrix) Anonymous unions are part of standard C++, but anonymous
structs?!?
4. Assembly in the texture mapping code. Dammit.
[/list]
Fixing #2 and #3 will require making a lot of little changes throughout the code (um, vectors and matricies are used a fair amount...). And #4 will require obviously a ton of work, especially to move to non-Intel processors (PPC, Sparc, ...)
Then there's the DirectX -> OpenGL, but I want to get the existing code to compile completely (using stub headers and libraries for the Win32 and DirectX stuff) before actually changing any functionality.
The good news is that the :V: developers did an
outstanding job of separating the functionality (ai, sound, physics, graphics, etc.), so the port should move smoothly...
BTW, I am continuing to test to make sure my changes still work for that stinkin' MSVC compiler...
Originally posted by Inquisitor
Another thing that would be nifty, would be a developer list, things like who has what, I see porting projects as a seperate activity, that a small sub-group of the coders here could take on and do withoutrying about integration of nifty new features.
because if we document those nifty new features, they should be easy to integrate once the port is complete
Great idea. This will take care of two potential problems: multiple people working on the same problem (reinventing the wheel), and making sure people's work doesn't get lost.
