Shogo: Progress Report
27-July-1999: Progress update by Thomas Frieden
INTRODUCTION
When we started, our first efforts were to concentrate on analysing the code. We tried to work through the concepts, and come up with solutions to problems we found. The first port we'll do is the Amiga port, as it's the system where we have the most expertise. The Mac version will be done when we have a fully working Amiga version, the endian problems will be sorted out until then, and the renderer will probably be OpenGL, so all that's left to do is the system-speciffic code.
As it was clear that we will have -with exception of the renderer- a 100% compile soon, we started working parallel on the functionality. In this field we started mainly on the server. We are currently putting finishing touches to it. We intend to compile a stand-alone server first to connect a PC client to an Amiga server for easier debugging of the system-dependent parts. This also saves us the hassle of first compiling a renderer, which will most likely be written from scratch. Also, the server does not include too much system dependent stuff.
.REZ file management is now endian-aware as far as file headers are concerned (no data is interpreted during REZ file loading).
The ClientShell part is more or less complete, as is the ObjectsDLL minus a few glitches during linking which will be fixed soon, see below under "Problems and Solutions". A certain amount of work was invested to even out a few VC++ specialities and dependencies, as well as a few points that our compiler was too picky to overlook.
PROBLEMS AND SOLUTIONS
ClientShell and ObjectsDLL
Most of these compile -actually ObjectsDLL already compiles fully. The message handling is still a bit doubtful due to the necessity for byteswapping. Since some data is only passed through the message system without interpretation of the actual data, a bit of additional work has to be invested to assure correct data alignment.
Some files that have dependencies on MFC or DirectX still need to be handled. We intend to go for Clawbert first, since it will be less of a hassle and still run the entire LithTech engine.
Input
Neither the Amiga nor the Mac has DirectInput, so a replacement for this needs to be coded. In this case no direct replacement of DirectInput was coded, but the InputMgr was re-coded instead. It's 98% system independent, so it can also be used on the Mac version (and not only on the Amiga version, where the new InputMgr Code is currently implemented). Update: It's finished and working!
Sound
This is the second big problem. It consists of two parts. One is the sound-files inside the LithTech WIN Directory (which is basically ported), the other one are the underlying sound-libraries. Certain functions -like 3D Sound- do not exist for the Amiga, and the recoding of the required sound library is currently in progress.
Video
There is no .SMK for the Amiga. We have a few possible solutions for replacements, but have not decided yet which is the better one. We will decide this at the end.
Renderer
Work on the Renderer did not yet start. We now have a set of functions, though, which are sort of a "bridge" between Direct3D and Warp3D, the 3D Hardware System of the Amiga. Warp3D and Rave3D are rather similar, so this code could -with changes- also be of profit for the Mac Version. But before detailed work on the Renderer is done we want to finish a working Server. We are also considering an OpenGL-Renderer, which we will develop on the PC. That way, we can test and debug it in an environment guaranteed to work.
Server
As the server is the most urgent current work, it gets an extra chapter in this report. The main problems in the Amiga port for the server were - and we think other systems will get similar problems here. After all we tried to keep the code as OS-independent as possible:
Back