Commander X16

2 hours ago, mobluse said:

When do start measuring the time? Is it from start of program or e.g. from when OXYGENE is shown?



 



It is a bit faster on second run: about 68% of full speed on my computer.

I start measuring time when the 3D part starts (the word "Oxygene" in yellow).

Apperently this really pushes the limits of even the emulator: it has to work quite hard ;).

I'm really impressed by this, just wow ?! A Wipeout style game could be in reach with the cx16. That's so impressive.

36 minutes ago, AndyMt said:

A Wipeout style game could be in reach with the cx16. That's so impressive.

Hmmmm - good point. And it's good the X16 has a sound chip that's not behind the vera ports, so you can have sound w/o injecting a lot of overhead moving the data ports back to the PSG registers. Plus, Atari arcade games used FM sound anyway, so it'd be pretty period-accurate to boot.

 

I understood that there is no 3d calculations involved. But for Wipeout those might not be needed if we accept some limitations. The course would be pre-calculated (as is the demo) and the perspective would be fixed to a virtual observer following the player in the middle of the course.

Tricky would be rendering the player and opponent pods... maybe Spites (ugly)?

Or pre-calculated polygons for each object for let's say 10 different distances (more cpu cycles)?

I'd say that using sprites isn't as big a problem if they're drawn in such a way that fits stylistically.

7 hours ago, Jeffrey said:

I start measuring time when the 3D part starts (the word "Oxygene" in yellow).

I was looking at the audio.asm and noticed that your IRQ handler uses PHA, TXA, PHA, TYA, PHA, and not just direct PHA PHX PHY - not that 4 cycles per frame is going to make a huge difference, but I think the initial portion of the ROM handler has already done the PHA PHX PHY before doing the JSR ($0314) so you can get away without even doing that, and the Kernal pops them back as well, so you don't need to spend the cycles saving the CPU registers at all - unless I'm missing something. Also, if not all of the Kernal's per-VBLANK routines are needed, then you could just JSR the ones you need in your own handler and not JMP to the Kernal's handler at all (for instance, you could skip the KBD/Joystick polling for a decent number of clock cycles back.)

Not sure how these savings would stack up in the grand scheme, but it might end up being several frames of time over the course of the entire demo run.

Edit: Although, I don't know if giving the main program a few hundred extra cycles would make any difference. I just thought I'd mention some potential "free" savings by disabling kernal routines that you don't need in case it helps. Awesome job, man!

That is amazing!


Sent from my iPhone using Tapatalk

.

On 5/21/2021 at 8:13 AM, DrTypo said:

On my computer (core i7 8700k), on the second execution it does take 1:39 from OXYGENE to the end.



On the first execution there are slow downs.



Yes it would have been nice to have an actual 256 pixels wide screen mode on VERA.

There can be a sort of 256 pixel wide mode. 255 pixels actually,  if the HSCALE is set to $33. Just use 8x8 tiles and set the tile map to 32 tiles wide. Admittedly this isn't a bitmap mode and would take some fiddling but it can be done. 

Very impressive! Coming from someone who wrote a Gameboy Color port of it. (spoiler: it took 3:32 to finish due to its horrible VRAM layout and access)