Intuition: Sure, here are some misc notes and ramblings about porting AvP to MorphOS:

The game already had a Linux and AROS port which ment that there was an OpenGL and OpenAL backend already in place.
Without this I would have had to spend a lot of time converting from DirectX to OpenGL so I am glad this
had already been done!

Big thanks to BSzili for the great AROS port which served as the base for the MorphOS version!


I'd say most of the work involved getting the game running on PowerPC instead of x86, and chasing bugs
without using a debugger.

On top of just getting it running I felt that it needed some additional polish which I implemented:

- MUI dialog and installer for when you dont have the data files in the game drawer.
- FMV playback (intros + ingame video screens)
- Music
- Changed the default keybindings to be similar to modern FPS games.
- Volume sliders in the menu screen had an annoying 1sec delay before being modified. Removed it.
- Fixed some menu strings (for example, "exit to windows" became "exit to morphos")
- Made a new graphics options menu screen for setting resolution, mipmap on/off, 16/32bit textures, fullscreen/windowed.
(original game had just the option to set resolution)
- Some initial work to get "Classic Redux" high-res mod working. This makes the game look so much better but it eats a lot
of VRAM so I made a texture size limit and rescale option to get it running on my 32MB graphics card.
(I still need to expose this option to a menu, and fix a crash bug related to this mod - that crash exists on the PC version of Gold Edition as well)

There are still some polish features on the todo list, but the main lacking feature is multiplayer support.
I intend to revisit this. I used to play a TON of avp in multiplayer back when the game was new. Also it would be nice to add it
just for the sake of completion.

Here are some of the challenges:


Debugging:
------------------------
I didn´t have GDB set up and was relying soley on printf debugging. This is crazy, bordering insane, I know.. :)

High priority for me now is to get remote GDB setup with a decent GUI.
I'll also take a look to see if there is a MorphOS gui for GDB, otherwise this is probably going to have to be the
next thing I work on.

Being able to set breakpoints and pause execution to find where the program was stuck would have saved some headache for sure.


System robustness:
--------------------------------
I had quite some cases where crashes in AVP would bring down the whole system leaving me to hard reset the computer. Remote GDB would have been very nice in these cases.

For a long time I was chasing a hard crash that happened "randomly". Seemingly more often when the system was under heavy load.
Sometimes the machine would just lock up, and sometimes it would keep going but loose signal to the monitor (hinting that it was perhaps GL related)

In the end, the root of the issue was that I had quite early on added mipmap support using gluBuild2DMipmaps() from TinyGL and I was calling this function once every frame and this caused the system to eventually lock up.

By accident I found out about the TGLDEBUG envvar. This, together with the MorphOS logging tool helped to further pinpoint
gluBuild2DMipmaps() as the offender - the log was mentioning unimplemented stuff in TinyGL when calling this function.

So I just wrote my own mipmap generation code and this particular nasty crashes went away!


Big endian, or "PPC versus X86":
-----------------------------------------------
Endianess is not difficult in itself, for porting this is going to be more or less difficult or amount of work depending on how the original software was written.
AVP was a complete pain as it contains a huge amount of loading code spread over a lot of source files.

First step was to locate all "chunk loader" classes, and the source files they belonged to. This turned out to be quite a long list and I went through this, crossing off the loaders one by one in about a week by spending a few hours every day.
AVP is probably the most painful I've seen in this regard, if it would have had a few central places for loading to plug in the endian fixes instead of spreading out all over the place with custom chunk loading code it would have been a piece of cake.
However, it didn't require much thinking, just some good music to listen to while trying to not miss places which needed byteswapping.
(Of course I ended up going through all the files again a couple of times to spot and correct some misstakes here and there until I could load a whole level and get into the game)

Getting into the game, it was mostly working except for triggers and other game events not working as they should.
The final two issues, which took a lot of time to figure out, was:
- MorphOS defining the size of BOOL as 2 bytes instead of 4 which I had assumed (note to self: never assume anything!)
- game objects all have IDs. I had fixed endian in most places for this, but missed another place.

These two issues were hard to find, especially as the game was mostly working.
If *nothing* had worked it would have been easier but now I ended up spending quite some time focused on debugging certain door and switch types when the issue was in a completely different place.

Obviously there was a bunch of other places needing byteswapping besides the actual game: audio, graphics, player profile load/save etc etc. These were quick and easy to sort out though.

Short version: when you do miss a place which needs an endian fix it can be hard to find it in a large codebase!
It could also cause annoying issues like getting stuck in infinite loops (this is going to be especially annoying if you rely on printf debugging and dont have the ability to just pause execution and see where the program is stuck at).


Documentation:
--------------------------
I found that AHI and MUI documentation was not a problem at all as there are tons of information and examples online.
It is pretty awesome that I can go to some old website about Amiga programming and the information and examples are valid on my MorphOS machine. It really drives home the point that this is OS is a modern version of the Amiga.

TinyGL could do with some more documentation in general, I found the sourcecode for an old version of MorphOS TinyGL, it would be awesome if the latest one was available also.
If for nothing else, for general debugging and to know what functions do anything and which ones are just stubs.
Having the source can also help if you are looking for performance. For example, glVertex2f seem to just call glVertex4f internally.
Knowing this I would call glVertex4f from my code and get rid of that extra function call.
Same thing goes for understand if TinyGL preffers certain formats and gives conversion pently for others.


[ Edited by agranlund 14.10.2013 - 23:36 ]