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:

• The CPP_EngineObjects_DE.cpp had quite some problems which conflicted with our compiler, We could solve this only by splitting the file into two files, basically the CPP_EngineObject_DE.cpp and the engineobjects.c in API/. The main problem were conflicting storage classes which prevented a strict C++ Compiler from compiling the source. With our compiler we have to choose to compile the whole project as C++ or as C, we cannot mix.
  
  
• There were also some function pointer references to member functions which our compiler did not accept despite them being static. We could fix this problem though.
  
  
• A major problem was the file serverobj_de.h with all it's macros. These problems are now solved.
  
  
• The concept of dynamic libraries is different in Windows and Amiga/Mac systems. Currently we are using static linking for testing. We have developed a concept for dynamic linking based on shared libraries and an implicit function table (like in the Windows DLLs), which we will use once the basic porting is done.
  
  
• The case of endian problems concerning the message functions. It is often unclear what the datatype of the sent data is.

Previous News Article.

Next News Article.