DeutschEnglish USEnglish GB

Since 2011 GoldenCode aka Daniel 'Daytona675x' Mener develops or helps developing quality games for all major so called "next-generation" Amiga flavours:

AmigaOS4, MorphOS and AROS

Wings Remastered Development Diary

As you probably know I'm currently porting the PC game Wings Remastered back to our beloved Amigas.
First of all thanks to all those who preordered to make this happen!

Unfortunately only around half the number of preorders really necessary for this project has been reached so far.
That means that work continues but not at full speed. It's just not enough for me to be able to work full time on it.
Therefore it is rather unlikely now impossible that the release date of february 2016 can be hit.

Note: This whole thing is no comparably simple SDL port or so! It has to be rewritten from scratch! And many assets have to be adjusted as well.
The original estimation was about 3 months of work. But because it turned out that I cannot work full time on it (see above) it will take longer, of course.
If progress remains as it is now then mid March 2016 is realistic it's done when it's done (regarding my programming job).

Since forum activity takes away even more of that precious time I decided to provide you with this project diary. That way all important progress information etc. will be concentrated at one spot instead of being cluttered among different forums.
Hope you like it!
Click to jump to the latest entry.


Important links:

Preorder here
Some Screenshots
AmigaOS4 Demo video

Demo version for AmigaOS4 Warp3D
Demo version for AmigaOS4 Compositing
Demo version for MorphOS TinyGL
Demo version for AROS x86 OpenGL


Some of the following stuff had been added some time ago already, but I guess I'll start off where the demo version ended:




























Serious 3D model conversion phase 1:


Serious 3D model conversion phase 1, part 2:

These all have been imported into C4D by now and have been validated regarding texture completeness etc. Alas there are many more models but those are the most important, at least for now. Of almost all models there are two variants: normal and damaged. Unfortunately all those models appear in all kinds of different versions inside the assets-pile. They don't differ by design but by more technical aspects, e.g. polycount, materials, state of development, etc. So there are buggy or unfinished versions too. Now I have to check out all, chose the best and edit where necessary.








ModelConverter: many new commands (e.g. to center objects or to put them on the virtual floor), the most important ones being:




As you probably already know I'm using Cinema4D for 3D modelling / editing. Of course a slightly more modern version, actually the latest one, R17. Until recently I used a rather old R10 but this Wings-project forced me to upgrade because R10's FBX importer is horribly broken and outdated - and of course all of Wings' models are FBX. So I spent around 800 EUR to upgrade.
All in all C4D is a pretty fine piece of software, but there are some issues that make you ask yourself if they let an untalented trainee do it. Unfortunately the Wavefront OBJ exporter is such a thingy. We're talking about a standard 3D file format from 1989. And even in R17 it's totally broken (again; a small example: you can really find 'normals' with zero length in the output, no joke). Too bad that my framework relies on OBJ for data exchange...
Until today I had to do the following workaround: import model in R17, edit it, then export it to 3DS, then start up R10, import that 3DS and finally export an OBJ from R10, using a commercial plugin (Riptide Pro). Unfortunately there's no update for Riptide Pro to work with R17 and the R10-plugin isn't compatible :P
Today I've had enough of that! I decided to write yet another plugin for C4D. A COFFEE script to be exact. An OBJ exporter script for R17.


Weeeeelll, the script is working! It actually took about 1.5 workdays. Why? Because you cannot easily access a model's normal-vectors from COFFEE and because the documentation is a bad joke, grrr.
You have to calculate the normals yourself. Funny enough: in the meantime I found out that C4D's new Python interface offers a function named CreatePhongNormals for that task. Apparently they forgot to add that one to COFFEE, thanks a lot.
Of course it's not enough to simply calculate a triangle's normal and then average it to get the vertex-normals. That's the way some average Joe would do it, but we don't. No, no, if you want correct vertex-normals there's some more work to do. That's because we want hard lighting at hard edges. And not some smoothed lighting. For that task C4D has got so called Phong-tags. Simply speaking such a tag tells us at which angle between two triangles the normals should be smoothed or not. Well, without going into too much details: the documentation doesn't even tell you that, and of course it also doesn't tell you how to get that angle-attribute of such a tag via COFFEE...
But whatever, it's done and works well:

I just published a photo-session that illustrates the model conversion process. Have fun!



LevelConverter Part 1: it's about time to get to the real maps. For the demo versions I just took dirty shortcuts, of course... But this time it's for real ;)
I analyzed the XML format for the bombing and strafing missions in depth. Yes, it's the same format for both. For the PC version / Unity3D both types of levels are technically identical: in both cases it's a big 3D scene, with thousands of 3D objects and optional sub-objects ( = soldiers). Plus special information like 'is there a train?', 'weather?', etc.
All in all such a level file is composed out of 62 commands / structure elements. All are being processed correctly by my LevelConverter. But before I really generate my own files I'm doing more analysis on the concrete level-content (e.g. what's the max number of different tiles used inside a bombing level or the peek number of soldiers, etc.). That information is pretty vital to chose the optimal route when it comes to certain implementation aspects. And depending on that it may make sense to store certain data in the one or the other way in the level-file.
Btw., the original map definition files sum up to, please make sure that you're sitting: 99 MB! No kidding!
I'm of course using the universal binary chunk-based base format I came up with for my model-format, therefore the converted map files will be smaller by some magnitudes... I can't tell you exactly where we'll be at the end because I'm not 100% done with it yet, but I don't think that all levels will be larger than about 2 MB.


LevelConverter Part 2: Although the original format is the same for bombing and strafing missions, that doesn't mean that this is the best way to do things in this Amiga port. I found out that there's lot of mutual exclusive information inside those files; some stuff can only appear inside bombing levels, some other stuff only appears inside strafing levels. I also checked the data range of all attributes. After all: why store more than 1 byte for a positive integer value that's never larger than 255? Yes, it's nitpicking maybe, but I'd say: why not make it perfect when I'm at it?
Anyway, as being said, it's worth to differentiate between bombing and strafing maps. Today I had 'fun' with the bombing maps :P







Yes, yes, I know, I'm a bit lazy - but only regarding this diary ;)
Today I added three new screenshots that outline the bombing-missions's airplane optimization. Also note that the bombs you're carrying are optimized too: when attached to your airplane they are essentially only half-bombs and without bottom parts. Only when dropped the complete model is used. This makes quite a difference...
Of course there's much more optimization happening under the hood, have a look at these current stats:

Typical bombing-level on sam440ep, onboard-Radeon, 640x480 16bit, fullscreen, no vsync, no DXT texture compression (note: the low resolution has been chosen because here the differences are really large):

1. 8 bombs attached: ca. 140 fps
2. all 8 bombs dropping simultanously (thus using the full model 8 times): ca. 105 fps
3. no bombs: ca. 190 fps

And in 1680 x 1050 (the highest resolution this sam can do):

1.: ca. 75 fps
2.: ca. 65 fps
3.: ca. 95 fps

As you can see it runs super-smooth even in highest resolution on that low-end sam. Much faster than the temporary demo-'engine'...

















190 units already sold, only 110 remaining. Better preorder now!