I wanted to create a new post but it seems like the forums are not quite working as they should (either that or it is just me :)

I have uploaded the first version of AvP for MorphOS on AmiNet.

Executable: http://mos.aminet.net/package/game/shoot/avp.ppc-morphos
Sourcecode: http://mos.aminet.net/package/game/shoot/avp.src-morphos


(It was also submitted to Morphos-files and should hopefully appear there as well at some point in the future)


I have only tested it on my own computer so feel free to provide feedback on how it runs on your machine.
You'll need the original game, either the old "Gold Edition" or the newer "Classic 2000 Edition".
Classic2000 is easier to get hold of since you can still buy it on Steam (it also features background music while playing).

You need to have a TinyGL supported graphics card to run the game.


My machine has this configuration:
MacMini G4 - 1.25Ghz
1GB Ram (upgraded from 512MB)
Radeon 9200 with 32 MB VRAM
MorphOS 3.2 (I have not yet upgraded to 3.3)


I still have things on the todo list, both major and minor (for example, support for multiplayer is missing).
But for now it is at a point where I am going to enjoy playing through the three singleplayer campaigns completely - it was quite some time ago since I last did that so it should be good fun :)

Cheers,
--Anders

I saw that you are included libav in your port. Is it only for playing the intro/outro FMVs, or you you added support for the in-game Smacker animations too? I planned to backport the the Bink and Smacker support from AVPx, but never got around to finish it. You might want to replace the full libav with just libsmackerdec and libbinkdec. They are based on FFMpeg. http://homepage.eircom.net/~duncandsl/avp/

It is used for playing the intro/outro FMVs, the ingame smacker animations, and the background music (on Classic 2000 edition).

For Gold Edition, I had on the todo list to make the installer be able to rip CD2 of the game into .ogg files and play those - this is not done yet.


I am building only the stuff I need from libav (bink+smacker decoding and some support functionality I wanted) so the library is really quite small compared to if you just build the whole lot.

[ Edited by agranlund 14.10.2013 - 18:32 ]

Great stuff :D thanks for this wonderfull port !.

Great, one of my favorite shooters.
Thx!

Thanks for the port, very much appreciated.

Would there be any chance of you writing up some notes on challenges you faced while creating a MorphOS port and what you did to overcome them etc?

I have made a quick test and in full screen I see wrong colors in menus, anims etc... When the game start I see ok but with color glitches.
In windowed mode it is all ok. Ill try later to see if I can do something.

Quote:

A quick quess is 16bit graphics not agreeing with your system.
Does it happen on both your G5 and G4 machine?

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 ]

Thanks a lot agranlund for this new port for MorphOS

I will test it at the Alchimie X

@agranlund

Wow, thanks very much for the notes. They are very interesting and I'm sure I won't be the only one who will find them useful in the future. :)

What an interesting reading! Thanks. Something that I liked is your idea of a gdb gui. Ill kill for it.

This is a wonderfull and fantastic game for morphos!!! A lot of thanks for this port to the MorphOS community :)

Quote:
If you are looking for performance, your code shouldn't have any glVertex*() calls

But in any case, good work! Not expecting you to rewrite the whole gfx engine to OpenGL 1.1 standard (yes, that's when glDrawArrays(), glDrawElements() etc. were introduced, and nowadays people STILL use immediate mode in NEW programs...) - at least for the first release!

Just curious, was it glVertex*() all over (like data loading / saving), or only in certain files?

Quote:

I picked glVertex more or less randomly just as an example (in retrospect, it was probably a bad example, but still :)
The point was more that the more you know what is going on inside a closed black-box the better - especially in APIs that provide multiple ways of doing the same thing.
Also, I am just very curious :)

But absolutely, the bulk of the rendering in avp is already using glDrawElements (this was present in the linux port already).

I agree on TinyGL the documentation being a little sparse, because you can't tell from the autodocs which functions are stubs and which ones are actually implemented. Fortunately the output of TGLDEBUG can help, but it would be a bit easier to know beforehand that you can't use certain functions. I remember glPushClientState() and glPopClientState() being a bit of a head-scratcher for me for example.

Also, I find it rather annoying that tgl is missing const qualifier from a few pointers in the headers

Quote:

if i remember well this is the "old sdk" (pre 3.x release) http://wozniak-m.w.interia.pl/tinygl-sdk.lha here you can find some useful information :oD

The game works very nice. One minor issue is flickering text on level loading screen, but other than that, very good. It seems to have lower hardware requirements compared to Return To Castle Wolfenstein, so on Pegasos II with Radeon 9200 I can play 1280 x 1024 with full details. Well done .

Thanks you for the really good and very fast port.
Good work!

@forgottenhero

Does it work for you under the 9800XT? Haven't found the time to bloody test it for the time being..

@agranlund

Thanks for your hard work! Will I be able to use the high res pack with the classic 2000 version? Because I have the required horsepower to do so.

Quote:

If you enable 'developer mode' for Taskmanager (right click the icon, choose information, doubleclick on the line saying '(DEVELOPERMODE)' and then press 'save'), then if you right click on a task you get the option to 'dump task state'. This dumps the state of a task to the system debug log in the same way as if it had made an illegal access. From there you get the program counter (called SRR0) and a stack trace. Not perfect, but a lot better than adding dprintf() all over the place.

Quote:

That's not true. If you look at gg:os-include/tgl/gl.h you will find this line:
Code:

So it maps to glVertex3f, but it does so by a macro, so it's the same as if you had called glVertex3f directly yourself. But in general everything will always be slow if you're using immediate mode OpenGL, no matter which exact function call you make.

Quote:

That's awesome, thanks for the tip!

Quote:

I assume you are talking about this one?
http://www.moddb.com/mods/aliens-versus-predator-classic-redux

Unfortunately, it doesn't matter which gamedata you have installed. Certain files from this mod will crash the game.
You can get it to work by not using the "avp_hud" folder from the mod, but of course then your HUD will not look correct.

When I tested it, it looked very nice even on with my 32MB gfxcard. I had to limit the texture sizes but even doing so they still have more detail than the tiny original textures.
Getting this mod properly running would be great indeed, I'd like to take a pass at it at some point.

How to play this game in the window?