Hi Everyone another update for those following along.
I tried implementing the pseudo 4-channel mixing method for pcm audio (play 4x 11025hz samples at 44100hz). Unfortunately it did not work. I mean I got it working, but the game uses frequency shifts to change the pitch of sounds, which is not entirely possible using the mixing method unless I start doing some serious sample interpolation. And as it stands profiling my test code, it half the frame rate of the already somewhat sluggish game.
I'm reconsidering the lower 256x192 resolution, would make the game much faster (not 60fps, but at least 40 I reckon). It's a shame because I felt like I was on the home stretch.
I've got a couple more options on audio, but none are ideal: Use 1-channel audio with limited sfx, Use YM2151 Audio from the Megadrive version (not ideal) - both will add overhead to the game, so the lower resolution option seems more likely. Last option is to have no audio at all - but the game wouldn't be the same then.
On the plus side I finally fixed my zoom bug - it turned out I was reading an opcode incorrectly doh. Zoom is now highly optimised and fast. Graphics are 99% accurate.
The game is starting to get to a point where it's becoming a chore which is never great. I'm so close, yet so far on so many things:
- Decompression of data built-in to the game at startup
- Vertical scrolling (not as easy as it sounds)
- Text engine rewrite (text must be applied to bitmaps, can't use tiled mode)
- Gamepad controls (currently only keyboard)
- Background bitmaps (roughly 6 backgrounds weren't polygons, they were bitmaps).
- Fix sound issues/Rewrite Graphics Engine/Optimisations/Polish/Code cleanup/etc
I reckon if I didn't have a day job and was more experienced with assembly I'd get it done better and faster, so thanks for being patient those who have been following along!
Another World (Out of this World) port for the CX16
Forum rules
This section is for testing Commander X16 programs and programs related to the CX16 for other platforms (compilers, data conversion tools, etc.)
Feel free to post works in progress, test builds, prototypes, and tech demos.
Finished works go in the Downloads category. Don't forget to add a hashtag (#) and the version number your program was meant to run on. (ie: #R41).
This section is for testing Commander X16 programs and programs related to the CX16 for other platforms (compilers, data conversion tools, etc.)
Feel free to post works in progress, test builds, prototypes, and tech demos.
Finished works go in the Downloads category. Don't forget to add a hashtag (#) and the version number your program was meant to run on. (ie: #R41).
- ahenry3068
- Posts: 1224
- Joined: Tue Apr 04, 2023 9:57 pm
Re: Another World (Out of this World) port for the CX16
Please keep at it. I have been so stoked for this one project since you started it.
Believe it or not a few months before you started this I actually tried to contact the original developer of this game to see if he might be interested in the platform. I don't know if I got correct contact information. (The person I tried to contact is the same name as the developer and apparently upper management in a French Software firm). I didn't receive any reply.
Great work so far.
Believe it or not a few months before you started this I actually tried to contact the original developer of this game to see if he might be interested in the platform. I don't know if I got correct contact information. (The person I tried to contact is the same name as the developer and apparently upper management in a French Software firm). I didn't receive any reply.
Great work so far.
Re: Another World (Out of this World) port for the CX16
I'm still at it - I reduced the game to 256x192. Took a fair bit of changes to the code, but made things about 20% faster. I implemented a frame wait/sync so the game runs capped at a max of 30fps where possible, otherwise, as fast as it can. Most of the time it hits the frame rate target. I wish I had a way to measure like they do on Digital Foundry on Youtube lol. I'm currently working on the bitmap decoding/drawing. My goal now is to get it to be good enough to release.
Screencapture: Yes I'm really bad at this game lol.
Screencapture: Yes I'm really bad at this game lol.
- desertfish
- Posts: 1137
- Joined: Tue Aug 25, 2020 8:27 pm
- Location: Netherlands
Re: Another World (Out of this World) port for the CX16
thanks for the update 

Re: Another World (Out of this World) port for the CX16
Another update for anyone following along:
Bitmap loading
I believe the designer (Eric Chahi) got fed up towards the end of development and decided to just draw the rest of the game using bitmaps instead of polygons. So I had to code a bitmap decompressor. The game uses 4-bit planar bitmaps, which for anyone who is a modern graphics programmer can be difficult to get your head around. Basically the game stores each "bit" of the 4-bits, 4 sequential "planes". So for a 320x200 image, the first 32000 bits are "bit 0", then the next 32000 bits are "bit 1" and so on. Took me quite a while to understand. Then I had to do scaling from 320 to 256. I spent ages devising a bresenham-like accumulator scaling method when I realised I can just skip every 5th pixel when drawing lol. That said it's skip every 5th "bit" which is a bit trickier than it sounds. But now I have bitmap images in the game - there's about 6 or 7 images in total, including the title screen(s) and some later levels. Different versions such as the DOS version also have an "Interplay" title screen that's a bitmap too.
These screens were drawn from bitmaps.
Text engine
I really really wanted to use the CX16 built in kernel font which is basically a copy of the C64 font, but the game architecture wouldn't allow it. I had it working somewhat, but because the game uses 4 display buffers, you can't just use Layer 1 in tiled mode and call it a day.
So for that reason, I wrote a new text engine from scratch. Because my game is 256 pixels wide I had to create a new font too. So I hand-pixelled a new 6x8 pixel font for the game, based on the Amiga/DOS game font. I then wrote a basic encoder/decoder for the font, and wrote a "display char" and "display string" procedures. The spacing (kerning?) on the text isn't perfect because there's no subpixel scaling, but it works fine for what it is - text is used rather sparingly in the game. I can use the original ASCII encoding rather than PETSCII or Screen Codes instead too.
Other stuff
- I re-wrote the input engine to be a bit more responsive. It runs at the same 60hz interval as the refresh etc. It works fine, no worse than the original game... I am yet to add gamepad control (I'm hoping it will be easy).
- The only outstanding visual item now is vertical scrolling. I can brute force it which is what the DOS version does, but I will see if I can make use of the VERA scrolling registers - I'm not confident it will work. I might have to sacrifice vertical scrolling in the game and those sections will be a bit glitchy. I'll see how it goes I haven't looked into it too deeply yet.
- The elephant in the room is still sound - I'm probably going to go for 1-channel sound effects - the experience will be OK, but not as good as the original.
- I am yet to look into YM251 music... I wanted to make installing and running the game easy, but if you have to pull game data files from here and there, it won't be as accessible to everyone. So music might be optional.
- I still have the game data decompression to do, which should be easy as I've already done it, but will just take some time to translate my C code to assembly - if I get lazy, I might just make it an external application you have to run once before playing the game.
- Finally, one of the big optimisations I realised is the whole "array of structs" vs "struct of arrays" argument. I'm hoping to speed up the game some more by adopting better arrangement of internal data. There's also a few small bugs to squash too.
Bitmap loading
I believe the designer (Eric Chahi) got fed up towards the end of development and decided to just draw the rest of the game using bitmaps instead of polygons. So I had to code a bitmap decompressor. The game uses 4-bit planar bitmaps, which for anyone who is a modern graphics programmer can be difficult to get your head around. Basically the game stores each "bit" of the 4-bits, 4 sequential "planes". So for a 320x200 image, the first 32000 bits are "bit 0", then the next 32000 bits are "bit 1" and so on. Took me quite a while to understand. Then I had to do scaling from 320 to 256. I spent ages devising a bresenham-like accumulator scaling method when I realised I can just skip every 5th pixel when drawing lol. That said it's skip every 5th "bit" which is a bit trickier than it sounds. But now I have bitmap images in the game - there's about 6 or 7 images in total, including the title screen(s) and some later levels. Different versions such as the DOS version also have an "Interplay" title screen that's a bitmap too.
These screens were drawn from bitmaps.
Text engine
I really really wanted to use the CX16 built in kernel font which is basically a copy of the C64 font, but the game architecture wouldn't allow it. I had it working somewhat, but because the game uses 4 display buffers, you can't just use Layer 1 in tiled mode and call it a day.
So for that reason, I wrote a new text engine from scratch. Because my game is 256 pixels wide I had to create a new font too. So I hand-pixelled a new 6x8 pixel font for the game, based on the Amiga/DOS game font. I then wrote a basic encoder/decoder for the font, and wrote a "display char" and "display string" procedures. The spacing (kerning?) on the text isn't perfect because there's no subpixel scaling, but it works fine for what it is - text is used rather sparingly in the game. I can use the original ASCII encoding rather than PETSCII or Screen Codes instead too.
Other stuff
- I re-wrote the input engine to be a bit more responsive. It runs at the same 60hz interval as the refresh etc. It works fine, no worse than the original game... I am yet to add gamepad control (I'm hoping it will be easy).
- The only outstanding visual item now is vertical scrolling. I can brute force it which is what the DOS version does, but I will see if I can make use of the VERA scrolling registers - I'm not confident it will work. I might have to sacrifice vertical scrolling in the game and those sections will be a bit glitchy. I'll see how it goes I haven't looked into it too deeply yet.
- The elephant in the room is still sound - I'm probably going to go for 1-channel sound effects - the experience will be OK, but not as good as the original.
- I am yet to look into YM251 music... I wanted to make installing and running the game easy, but if you have to pull game data files from here and there, it won't be as accessible to everyone. So music might be optional.
- I still have the game data decompression to do, which should be easy as I've already done it, but will just take some time to translate my C code to assembly - if I get lazy, I might just make it an external application you have to run once before playing the game.
- Finally, one of the big optimisations I realised is the whole "array of structs" vs "struct of arrays" argument. I'm hoping to speed up the game some more by adopting better arrangement of internal data. There's also a few small bugs to squash too.