Game Engine

During my adventures with porting Torque I have been using a variety of different build environments. First I was working natively on my Amiga, but compile times were horrible on my AmigaOne. So I decided to try cross compiling instead.

Windows and cygwin

My first choice was to try it on Windows with Cygwin installed. Building the cross compiler and building software for Amiga was easy simply follow the instructions from adtools.

Besides the speed up in compile time, another nice feature of cross compiling is, that you are able to run configure scripts. But if you try this, you will run into a performance issue with Cygwin. Cygwin is slow at creating new files and opening files and starting executables, unfortunately this is what a configure script does a lot of inorder to determine compiler features, hence configuring can be terribly slow. Actually you will see this already when building the cross compiler as it takes a long time.

Which made me decide to try something else.

OSX Lion

I could of course have chosen to try cross compiling under Linux, but my main computer, that is not an Amiga, is my Mac Book Pro, where I run both Windows and OSX. Before deciding to try cross compiling I had just updated OSX to Lion and XCode to 4.1, so that is what I had to work with.

What I did was to download the tar file for trunk in the svn repository and the tar file for gcc 4.5 in the branches in the svn repository.

I then setup my directory structure in the same way as the adtools svn repository:

• adtools
• –branches
• —-gcc
• ——4.5.x
• –trunk

Simply follow the instruction to build the binutils, there was no problem building those.

Then go into adtools/trunk/gcc-build and change the following lines in the Makefile

SRC_DIR=../../branches/gcc/4.5.x
VERSION=4.5.x
DEST_DIR=cross-$(VERSION)
PREFIX=/usr/local/amiga
#BUILD=i686-pc-linux-gnu ## for some reasons configure script of gcc 4.2.4 doesn't identify the correct build type

Now simply type make and your cross compiler should build, but on OSX Lion with XCode 4.1 that is unfortunately not the case.

To clang or not to clang?

By default with XCode 4.1 the installed gcc uses clang which turned out to be a problem. While configuring the cross compiler I would always get this error:

configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

I inspected config.log and found this:

conftest.c:16:1: internal compiler error: in execute_ipa_pass_list, at passes.c:1800
Please submit a full bug report

That is really strange and the code in conftest.c looks absolutely fine, but after spending some time on Google I found more people with the same problem and one actually had a solution and an answer to the questions above, which is it not to clang.

So instead of simply typing make inside the gcc-build folder type:

CC=/usr/bin/gcc-4.2 CPP=/usr/bin/cpp-4.2 CXX=/usr/bin/g++-4.2 LD=/usr/bin/gcc-4.2 make

Will it build?

No, it will not. Now I got compile errors like this:

../../../../../branches/gcc/4.5.x/libiberty/physmem.c:52:25: fatal error: sys/sysctl.h: No such file or directory
compilation terminated.

I found this very strange. Usually configure detects missing headers and sets some defines to change code paths. It is correct that sys/sysctl.h is not part of clib2 but looking at the configure log shows that it is able to find sys/sysctl.h.  I still do not know why this happens or if it is caused to explicitly setting of CC and the others, but I do know that sys/sysctl.h is found among the standard headers of OSX.

My fix for this was to remove any references to sys/sysctl.h in /adtools/branches/gcc/4.5.x/libiberty/configure which made the build go further but more headers where mistakenly being found. I ended up removing references to:

• sys/sysctl.h
• sys/file.h
• sys/params.h
• alloca.h

Now it would build and I have successfully used it to build programs for my Amiga.

Notes

I am not sure I have found the right solution but it works for me. If some one knows of a better solution for not getting the wrong headers please let me know.

It should also be noted that there is a bug in the spec file for gcc which prevents C++ code to link correctly for Amiga OS, this can be fixed by explicitly linking with the C++ libraries like this:  -lstdc++ -lgcc_eh

Have fun writing programs for Amiga on OSX.

A long long time ago I promised a video of Torque in action on Amiga OS4. I have been holding back on this because it was very unstable. The stability issues seems to have been fixed now so enjoy:

 

At some point in the vidoe I fire a shot at the Mac player and turn the camera towards the Mac and you see an explosion in front of the Mac player. That is NOT delay or lag, I fired two shots and it is the second shot you see on the Mac. Just in case you were wondering.

Hello again,

I promised some time ago to show some screenshots of TGE on Amiga, here you go:

All images are grabbed inside TGE so you can’t see any Amiga window borders or anything, but trust me they are there.

The first image is simply the main menu. The second image is first person view while approaching a village. The second image is an editor camera view of me inside a village hut and the final image is also a editor camera view.

As can be seen on the final image there are still some rendering bugs to be solved.

What I have been doing since the last update, is that I have managed to get a Cygwin cross compiler working, so I am now working in Visual Studio. With this cross compiler, which is a newer version of gcc than supplied by the official SDK, I have finally managed to build an optimized version of TGE.
I have also removed some of the deprecated AmigaOS API methods I was using, like IExec->Examine and IExec->ExNext.

In the next period of time I will be focusing on the rendering bugs and I will take some photos and videos of my screen to actually prove that these images are from the AmigaOS4 port of TGE and to demonstrate that networking is also working.

Hi Folks!

Do not worry the project has not been abandoned.

I have simply moved into my new house with my family and have been busy fixing up the house and painting a lot of walls and ceilings.

Now I have also set up my home office, so my amiga is up and running again and I will continue were I left off. I hope to have the release build fixed in a short time and continue with graphical bug fixing and more.

I will keep you posted.

Time for another update. No screen shot yet but soon.

Release Mode

I have spent quite some time figuring out why TGE would not start up when built in release mode, and to be honest I have not fixed the problem yet. I do know what is wrong though: The programmers of TGE has assumed that all local variables are put on the stack, which is also true on x86 and probably also with earlier versions of GCC. Remember TGE is old.

Unfortunately with the latest OS4.1 SDK, the GCC optimiser has changed and local variables might be put into registers. So when TGE tries to find the address of a local variable which has been put into a register, GCC generates strange code. I don’t know if this is a bug in GCC or what to make of it, but finding and fixing these problems has taken a long time and right I am stuck on a single issue where TGE wants to endian swap a double, write it to disk, read it back and endian swap it back. It sounds simple enough and it works fine when the optimiser is disabled, but with optimisations enabled it fails. Still looking into this.

Multithreading

At first I thought this was going to be difficult to get to work, because earlier trials had shown that TGE would lockup before main() was reached. Luckily it was quite simple:  My first implementation of the mutex wrapper in TGE was using the mutex implementation in pthreads, but it turns out that these mutex’s cannot be locked multiple times by the same task, which a lot of mutex implementations usually allow and which TGE relies on.

The solution was, of course, to use the mutex implementation in Exec which does allow for the mutex to be locked multiple times by the same task. Only requirement is that the mutex is unlocked as many times at it is locked, which TGE does, so no problem there.

I will be moving on, to the rendering bugs now and still try to fix the remaining optimisation bugs.

Working with source code one has not touched in many months or years can some times be surprising.

Tonight I thought I would try to get the audio working, so I inserted a few debug printf’s in the audio init functions just to check that it started up and to my big surprise it did startup just fine. Well why did it not work then?

Just skimming through the audio source code I discovered a define which would disable ogg audio files and a quick inspection of the audio assets in the demo game revealed that indeed the audio files were ogg files.

It turns out that I had added the define which would disable ogg files to the makefile instead of the usual TGE config file, which would explain why I did not see it in the first place. Why I added the define back then, I have no idea.

I quickly removed the define and recompiled the project and now TGE on Amiga OS4 has audio.

I just hope the rest of my issues will be that easy to fix.

It has been a while since last update and a lot has happend.

Crash on exit.

I found two reasons for TGE to crash on exit, the first reason was simply that I forgot to shutdown the graphics system  so TGE would deallocate everything else but still try to do some rendering, which resulted in a crash.

Second reason for a crash on exit I was unable to fix, but I worked around it. During static destruction of some container ‘A’, TGE would print messages to the log file. This  involved an other static container ‘B’  which did dynamic allocations. There might be two reasons for this to crash, ‘B’ could already have to destructed, you can’t rely on the order of static destruction, or Exec Library might already have been closed so dynamic allocations are not possible. I never found out which to blame, I simply disabled the log messages in the destructor and the crashes were gone.

Input

The input layer has been heavily upgraded and both keyboard and mouse input are working very well now, in windowed mode.

The mouse has been nicely integrated between Torque and Workbench. TGE will seamlessly switch between the TGE mouse and Workbench mouse when moving the pointer in and out of the window. TGE will grab the mouse in game mode, so that other windows or the Workbench are not accidentally selected.

I have not tested this in full screen mode yet, simply because full screen mode does not work properly yet.

Finally the keyboard input has actually been implemented. Now it is possible to move around, use the built in editor and everything else you would expect of a game engine.

For now the keyboard input is restricted to the rom keymap ‘usa’ so special charaters can’t be used and further more deadkeys are not supported.

Next…

Well there is still much work that needs to been done for this port to be complete.

When building TGE in release mode it does not start up, I think there might be a semaphore or something which gets used in release mode, and this semaphore might not be released or something like that.

Audio is still missing aswell as multithreading which I disable early in the process and there are some rendering bugs, probably caused by some endian issues. Worst of all, the game freezes at some point while playing. My guess is that it crashes while minigl has the screen locked, so I am not seeing the Grim Reaper, which means I have to find a way to get serial debugging working on my setup.

I have been hunting this strange bug in TGE. When TGE is build in debug mode it always tests if the correct OpenGL state is setup before rendering any objects. For some reason this test has always failed on my Amiga and I have for a long time just been running the engine without these test.

The required state is that texture unit 0 must have GL_TEXTURE_ENV_MODE set to GL_REPLACE, but it always failed because the mode was GL_MODULATE.

Now I set out to find this annoying bug and fix it but debugging on the Amiga is no easy task. There is a semi working GDB but absolutely no tools for debuging OpenGL. So the only way forward was to do the good old binary search with good old trusty printf(...).

Granted, it took quite some time, especially because my TGE port can not exit without crashing, so I had to add some printf(...), compile, watch output, crash, reboot and repeat untill I found the code segment that caused the problem.

It turns out that the misbehaving code segment was this:

glGenTextures(1, &tex);
glBindTexture(GL_TEXTURE_2D, tex);

But how can this change the texture environment mode? That is right, it should not change the mode, but it did. That could only be caused by a bug in MiniGL. Two minutes later, I fixed the bug in MiniGL and submitted the code to the MiniGL repository, to the benefit of all Amiga developers.

Best of all TGE stopped complaining about an invalid state and I can move on.

This site is dedicated to my ramblings about game engine architecture and other game engine related stuff.

My first post is not so much about architecture. You see, I always have a million things going on in my head, with that unfortunate side effect that I never fully complete one project before moving on to the next and leaving the old projects to decay and finally die.

But one of my reasons to begin writing on this page is to keep my mind focused on one project at a time and hopefully see it come to a working and later releasable state. It is no secret that this site also one of the many things on my mind and I have a lot of things I would like to share with you, all of them more or less game related.

The project I have decided to throw my attention at is actually one of my older projects and some would say stupid/silly/crazy/geeky projects. I have decided to finally finish my TGE (Torque Game Engine) port for Amiga OS 4. In fact it is so old that I can not even link to it anymore, but only to GarageGames, the creators of TGE.

I will be posting screenshots and progress reports on this site, there will be no code snippets or anything as TGE is a closed source engine. Only if you can prove you are a TGE licens holder will I be able to share anything with you.

Well… wish me luck 🙂