Does the CX16 emulator set to 8 MHz run at a similar speed to the actual hardware?

[russell-s-harper]

In a recent YouTube video, David Murray, The 8-Bit Guy, mentioned he was interested in seeing 3-D games added to the body of existing programs available for the CX16.

I have an early demo, done way back in 1992, that I thought might work. This is it https://youtu.be/XTOIfkqW9O0 running in DOSBox set to the equivalent of an early i486 running at 25 MHz, to generate about five frames per second.

The CX16 runs at 8 MHz, and has an 8-bit processor, so for sure not expecting the same performance. However, even this very simple demo https://youtu.be/xFiW-2bUJUk running on an emulator is painfully slow, like less than one frame a second.

Question: Does the CX16 emulator set at 8 MHz run at a similar speed to the actual hardware?

[TomXP411]

Yes, the X16 emulator is close to the real thing.

I've done some testing of my own, and the programs I tested all came very close, performance wise.

Elite, had polygon rendering, as did Echelon and Flight Simulator. I also remember a 3D space flight game that even had Newtonian physics, although I can't remember the name of it. (Looking around at game sites, there were actually a bunch of C64 flight simulators..)

What language did you write those demos in?

[russell-s-harper]

Thanks for confirming that the speeds are comparable, I can look into optimizing.

With VERA interfacing and extended memory, the CX16 code is already more complex than the DOSBox demo. It would be helpful to have a profiler to know what to optimize first.

Both were written mostly in ANSI C.

The DOSBox demo has a few functions written in x86 assembler. It was compiled with Borland Turbo C.

The CX16 demo is still exclusively in C. It was compiled with cc65 using FLT https://github.com/Russell-S-Harper/FLT to provide floating-point capability for data initialization. Only basic optimizations at the compiler level -Cl -Oir are being used.

[russell-s-harper]

I managed to optimize the Basic Demo to improve the performance from 1.36 s/frame to 0.91 s/frame. While better, it's still far from the 0.20 s/frame goal. Add in a real scenario as in the DOSBox "Explore" Demo and achieving 0.20 s/frame is likely going to be very difficult.

At the core of the issue is that there isn't enough regular memory to handle a screen mask, so we have to resort to extended memory. When drawing the polygon's lines, you have to access the mask in extended memory many times. It usually isn't predictable which page "comes next", so for each pixel, you have to set the page where its mask is located, then access the memory. This translates into several operations just to access a byte, and it ends up being a bottleneck.

As mentioned, there are 3-D games for the C64, so it could conceivably be possible to optimize using hard coding and assembler to get something acceptable in the CX16, but at the expense of flexibility and ease of maintenance. Ideally, we'd like an accommodating environment to create 3-D games as opposed to one where you have to fight and compromise for every millisecond improvement in frame rate. Right now I think hardware is the way to go, either via VERA or some external add-on. I understand the cartridge interface exposes a lot of functionality, even a low-end RasPi might be sufficient.

This is the revised Basic Demo here https://www.youtube.com/watch?v=H0h6VMAwbqY

If anyone is interested in the code for the DOSBox "Explore" Demo or the CX16 Emulator Basic Demo, I'll be creating GitHub repositories for them soon.

[russell-s-harper]

Some optimizations were made to masking and extended memory handling. So now down to 0.66 s/frame, but still a long way from a 0.20 s/frame goal. I'm thinking about using VERA to render filled polygons, so instead of drawing from near to far and using masking, going in the opposite order, far to near, and "drawing over" what's been rendered.

The latest progress-to-date: https://youtu.be/TsXz8cJG-AU

For those interested, the original DOS x86 demo and CX16 demo in progress are located in this repository: https://github.com/Russell-S-Harper/EXPLORE

[TomXP411]

Some optimizations were made to masking and extended memory handling. So now down to 0.66 s/frame, but still a long way from a 0.20 s/frame goal. I'm thinking about using VERA to render filled polygons, so instead of drawing from near to far and using masking, going in the opposite order, far to near, and "drawing over" what's been rendered.

The latest progress-to-date: https://youtu.be/TsXz8cJG-AU

For those interested, the original DOS x86 demo and CX16 demo in progress are located in this repository: https://github.com/Russell-S-Harper/EXPLORE

Z sorting is very useful, especially when Z-buffering isn't an option or when you're doing things like partial transparency (z-buffering is useless on translucent objects.)

The catch is that for larger objects, you will need to subdivide the mesh, so that objects turned end-wise to the viewer can't be incorrectly shown in front of objects they're actually behind. Setting some sort of maximum mesh block size helps with that (for example, no straight lines longer than 1 meter or something.)

Z buffering without hardware acceleration probably doubles your pixel fill time, making things take a lot longer.

[funkheld]

-------------------------
What language did you write those demos in?
-------------------------

If you look at this program, you will see that it is written in ASM.
for the c64 the other languages were just for entertainment. thought: comal, forth, C etc. they were also from asm.
The programs from the prog8 and cc65 are also in ASM when they are finished.

The advantage of the C64 is that it has 2 screens, one for drawing in the background and then pushing it forward to admire and then describing the one in the background again.

the cpc6128 did the same thing as the c64 , 2 screens.

It would be nice if there was a graphic screen switch for the x16 too.
the x16 has the system with the banks.
64 at 500kb and 255 at 2mb. a bank has 8kb.

A screen then has 76800 bytes, 320x240 and 255 colors. one byte one color.
There are about 9 banks for one screen. at 500kb you could create 2 screens.

The experts here are now asking you how you can make this dream come true with the x16.
With the C program prog8 or cc65 and ASM inline it would be possible
to create a quick program.


greeting

[ahenry3068]

If you want to do double buffering there is the ROM routine GRAPH_draw_image. (See DOCS for calling parameters)

you can load a raw image file to BRAM then call GRAPH_draw_image.

CURRENT GRAPH_draw_image IS NOT "Banked RAM aware". Thus image size is limited to 90 x 90 or 100 x 81 or other size < 8192 bytes.

GRAPH_draw_image in the latest ROM on github IS "Banked RAM aware" and can handle image size in Banked Ram all the way to 320 x 240

[funkheld]

That means you could create the image 320x200?
That would be wonderful too.

Please do a small clear demo in prog8?
is very interesting.
I haven't read about it yet.
explain this to us laypeople?

Thanks.
greeting

[funkheld]

--------------------------------------------
GRAPH_draw_image in the latest ROM on github IS "Banked RAM aware" and can handle image size
in Banked Ram all the way to 320 x 240
-------------------------------------------

Does this also affect the x16 emulator please?

Thanks.
greeting