Commander X16

Hey all, for those following, a small update:

The intro now plays 100% through to the first level, it's 99% accurate. Only bug is polygon scaling - it's an issue with wrapping on the Y-axis and I've spent hours/days trying to fix it, I'm really struggling. I'm reconsidering re-writing the graphics from scratch (again )

I now have sound working in the game with minimal performance loss. Only issue is that it's 2 channel (stereo), whereas the original audio is 4 channels. The program just picks the next available channel left or right and doesn't play the sample if nothing is free. Mixing might take up too much processing time, but I'm considering it.

Music will not work - simply not enough channels for audio (at least nothing that will sound decent). I am considering redoing it all in midi for the YM2151 (similar to what the 2nd reality demo did). I might check what some other system ports did.

I started writing a decompression routine in assembly (I have a working C version). The game will decompress all the data files before starting and store them on the SD card.

All that's left is the Keyboard/Joystick control, and fixing more bugs and optimisations. I'd say I'm about 70% done. If anyone who is a wiz at 65c02 assembly wants to help me fix the scaling bug I'd be willing to share my code. When the game is finished, I'll be releasing all the source. Something that absolutely astounds me is the .prg file is only 7kb lol.

Fantastic project

very cool project

idk if this helps with the audio issue, but I used the idea of virtual pcm channels without mixing

see here, can play up to 4 samples at once or 3 + streaming pcm or 4 pcm + zsmkit

viewtopic.php?p=34570#p34570

it's Prog8 code, but maybe the method could be useful?
Try It Now!

Thanks for the tip! That might work really well actually.

The only issue I can see with the multi-channel interleaving is the less channels playing at once the quieter it gets. But you could probably overcome that by duplicating active channels onto empty channels or dynamically changing the sample rate or something like that.

I'll look into it thanks again!

At the moment I'm still trying to fix my zoom issue (it's because the original game used 16.16 fixed point (32-bit) maths for the zoom calculations I think which sounds simple in principle but a nightmare on an 8-bit machine).

cosmicr wrote: ↑Sat Dec 14, 2024 12:30 pm Thanks for the tip! That might work really well actually.

The only issue I can see with the multi-channel interleaving is the less channels playing at once the quieter it gets. But you could probably overcome that by duplicating active channels onto empty channels or dynamically changing the sample rate or something like that.

I'll look into it thanks again!

At the moment I'm still trying to fix my zoom issue (it's because the original game used 16.16 fixed point (32-bit) maths for the zoom calculations I think which sounds simple in principle but a nightmare on an 8-bit machine).

This is one project I am so stoked to see completed....
Keep at it man... Great work so far...

Hi Everyone, another little update.

Things have been going slow but I have definitely made some great progress...

GRAPHICS
Re-wrote the graphics renderer (again). I think this will be the final version of the polygon renderer. It still doesn't use the VERA FX line helper, but I've run out of energy thinking about drawing polygons lol... The final version uses a combination of bresenham to calculate edges, and fast 32-bit cache writes for filling the polygons. It's working 95% correct now. The only other graphics I haven't implemented yet is "screen shaking" and scrolling. You can see on screenshots below the other glitch is some polygons going beyond the bounds of the screen. These don't affect gameplay. Theres still room for more optimisation.

INPUT
The game now has input controls! Took me a little bit of head scratching to work out how to detect multiple keys etc. I ended up using the PS2 keyboard input CX16 kernel routines rather than the usual C64 GETIN, it works pretty good. I have bolted on a few extra interrupt routines. I'll also add joystick/gamepad too which I don't expect to be too difficult now that I have the framework there. Different versions of the game seem to have different input controls (eg the Sega Megadrive version uses 2 buttons), but I'm going to stick with the original I think - one button action and "up" for jump.
AUDIO
I scrapped my old sound routine and started writing the new "mixed" 4 channel sound (ie 4 channels into 1 - see earlier posts). I'll probably shift my attention back to it now.

CURRENT ISSUES
1. The game is much slower than I anticipated. It turns out I overestimated how much time I have between vsyncs, so a lot of frames don't finish in time. I need to study it a bit more to understand it better. The more I optimise the better it gets, but some frames take longer than an entire vsync. I've done some cycle counting and each frame on average takes anywhere between 200,000 cycles to 600,000 cycles. Timing is something I struggle to wrap my head around when you include frame buffers, page flipping and page copying etc. I'll get there eventually. You'll see also there's timing issues in the gameplay example above, I was running the entire time but he still caught me (either that or I'm really bad at the game lol).

2. I've refactored heaps of code as I get better at 65c02 assembly. I've learned a few really good tricks using lookup tables and self-modifying code which have made things a lot better, but there's still bugs to be found...

3. ... one such bug I thought previously was with my zoom routine, but it turns out it's something else. I did fix my zoom - it uses fixed point 11.6 maths but I was having overflow issues because I was using 16 bits instead of 17. I've since clamped zoom to a max, and now it seems to work nicely.

4. But that still leaves an issue where residual images seem to be shown on previous frames (refer to animation in earlier posts where Lester seems to zoom in and out frequently). It also happens in other areas of the game. I thought it was the task scheduler (the game uses mutitasking), but I've poured over it and can't find a problem. Now I'm thinking it might be a logic test somewhere.

That's about it for now! We're getting close, I still want to have it unpack the data builtin, at the moment I'm using an external unpacker I wrote in python. That way people can just drop their game files in and play immediately.

Fun Fact: The game levels are little isolated games in themselves, so you can skip to any level without finishing the previous level, using code. So if I set the first level to be the end of the game I get this:
Oh and BONUS here's what it looks like using box16:

What screen resolution are you running in here. ? I'm curious.

I've learned a couple of tricks in my Movie Maker and video experiments to prevent screen glitching when your taking longer than Vsync to do a frame. Maybe I can help a little.

Excellent work. I've been stoked for this since your first Demo.

Thanks for compliments - it keeps me motivated

Do you mean my desktop or the game resolution? I'm using the gif recorder from the emulator. I don't actually own a CX16 yet. The original game was 320x200 on the Amiga. It's the same res on the MS-DOS version (where my assets come from). The CX16 version actually runs at 320x192 (4-bit) with the bottom 8 pixels cropped. There's a few reasons why, but the main reason is the 2048 byte alignment that the VERA requires to set the offset to display in bitmapped mode.

The second reason is that the game requires 4 display buffers, and the VERA only has $1F9BF or 129471 bytes of memory.
Page size 320x200 = $8000 ($8000*4= $20000 == overflow)
Page size 320x192 = $7800 ($7800*4= $1E000 == no overflow with 6591 bytes spare)

I haven't crunched the numbers yet, but I'm hoping that's enough space (with alignment) to fit the text mode in for layer 1.

Thanks for the offer on helping with timing, I'm hoping I'll be able to work it out a bit more on my own, but I'll keep it in mind if I really do hit a wall. At worst I think I'll just lower the game res to 256x192 which means no more 16-bit calcs and instant speed boost.

Oh and my desktop in the screenshot is 1440p

How About Making Another World Songs And Sounds YM2151/YM2164, VERA PSG And PCM

RulsanSoftware wrote: ↑Mon Feb 10, 2025 6:35 pm How About Making Another World Songs And Sounds YM2151/YM2164, VERA PSG And PCM

Hey not exactly sure what you mean there, but I considered using the YM2151 and ripping the tracks from the Megadrive version, however there was a suggestion by badmai earlier in this thread offering a way to use PCM audio with 4 tracks. So I'm going to try that first. It will be a bit of a performance hit, but any audio at all will be anyway. The PSG is an option, but not a good one Thanks for the suggestion!