CUzeBox - The new official Uzebox emulator

[Jubatian]

So that's one good reason to have "Joystick" support there!

My mental image of the "Joystick" (including what SDL provided) was the thing with the stick, which I couldn't imagine how would relate to Uzebox. Possibly because I didn't really see much else before (I only have an analog stick ditched away somewhere for some dead potentiometers). To have it for yourself, you may hack it into the "main.c", but I will figure out some more long-term method for adding it (like some module where the controller input should reside).

EDIT: After a bit of thought I say for now just hack it in for yourself (the easiest is to fork the repo, add the hack, so you can merge further changes or bugfixes as any comes). Supporting gamepads proper just leads a bit far off needing planning. The big problem is that as far as I see their layout could vary wildly, so it is a requirement there to be able to use a custom assignment. To support that it is necessary to have some user interface where the user can assign the buttons (unless you want to get it over with "edit this and this file"), and of course some configuration file where the user's layout can be stored. To have that it would be nice to properly support using whatever place the host commonly uses for this (such as ~/.config/cuzebox on Linux), which leads to devising how a proper CUzeBox installation should be laid out (such as to have the games stored there as well normally), also necessitating a game selector (adding proper support for running the bootloader). So it leads quite far, something I would likely put off until after the UCC as these are not overly critical for development uses, but necessities for later, to have a nice emulator.

[Jubatian]

For now I will suspend development on the emulator for a while, probably a duration strangely coinciding with the deadline of the UCC for unspecified reasons.

However if you need something in it, especially if you wish to use it to finish your own game for the UCC, and you need a particular feature to get it useful for that goal, just drop a comment here! I am open to add stuff to it for that cause even until then!

I also updated the opening post to reflect more the current state of the emulator.

[CunningFellow]

Just a performance report.

My ancient Thinkpad T60 struggles with Uzem to get 28Mhz and only just manages some times running T2K.

Cuzem when hitting F4 to remove the speed limits gets 240Mhz when running T2K and 280Mhz when running things that don't IJMP as hard.

This is obviously due to the rendering to screen, because the laptop has a 2.33ghz Core2Duo CPU that should be plenty for emulation. It is hampered by having a QXGA lcd screen though (2048x1536 pixels) that has a discreet ATI FireGL video card in it so it must really have to push all those pixels out the bus to the video memory.

Were as my partners T60 that only has a 2.0Ghz CPU, but has 1400x1050 LCD and Intel built in graphics manages 28Mhz no worries with Uzem.

[Jubatian]

Cuzem when hitting F4 to remove the speed limits gets 240Mhz when running T2K and 280Mhz when running things that don't IJMP as hard.

Are you sure that was the MHz, not the percentage report? I have a Thinkpad T61 (with NVidia Quadro 140M, thankfully not the model which would fry itself), 2.2GHz, and with lowest graphics settings it can peak around 380%, slightly above 100MHz. For Uzem with every possible optimization hurled at it I get around 70MHz.

What do you get if you remove all frame rate limiting from Uzem? (both PRESENTVSYNC and the delay loop in the audio) I think such a ridiculous difference (between your Core2Duo based machine and mine) could rather come from some architectural shortcoming (possibly deadlock) within Uzem somehow happening due to intereferences with your software environment (drivers).

Otherwise partly it may relate this problem, discovered by Artcfox. Probably CUzeBox can select a texture mode actually supported by the video card, while Uzem not having that code can't, and for some reason the conversion between modes is ridiculously slow (on my machine it wasn't: I got a 20% improvement for implementing it, and not like nearly 150% which would be the case if I assumed your CPU could also do 70MHz on Uzem otherwise).

[CunningFellow]

Sorry - yeah 240% and 280% respectively. My Desktop only manages 180Mhz it would be a miracle for a 10 year old laptop to beat it.

I changed to 1024x768 (1/2 the pixels in each vert and horiz) and tested T2K against 3 different colour depths.

uzem vs cuzem
8bit 18Mhz 22Mhz
16 bit 23Mhz 70Mhz
32 bit 24Mhz 70Mhz

Even pacman which runs at 80Mhz on Cuzem only manages 24% on uzem on the fireGL video card

HOWEVER, any game in uzem will run at 28mhz if I drag 2/3rds of its window off-screen. So it really has to just be something with copying the screen to video memory.

Any screen settings on my partners laptop and Uzem will manage 28Mhz.

They are both Thinkpad T60 Mine being the T60p with the FireGL video card with 256M on-board, hers just having the built in intel video.

[Jubatian]

Seems so then! I guess something is broken in that card's drivers or possibly in SDL's way of attempting to perform the texture conversion seemingly necessary with Uzem. To verify whether this is actually the case, you could compile this version of CUzeBox, just before I implemented querying the native texture format. With some luck the format I chose before is not native for that video card, and CUzeBox should show similar abysmal performance.

180MHz is quite impressive, what clock rate that beast runs at? Even if it did nearly 4GHz, this would mean processing an AVR instruction and associated hardware emulation tasks almost within 20 cycles on average! By the way it is not the "ijmp" which is costly, rather using a video mode with lots of 1cy instructions instead of more regular ones with LPM's and LD's. For example you will see much lower performace with the SPI RAM demo than like Tempest since its video mode has hardly anything apart from 1cy instructions, and also those are stuff wildly generating flags (it generates 1bpp by lsl and sbc reg,reg instructions to get 0x00 or 0xFF for pixels).

[CunningFellow]

The desktop peaks at 186Mhz in Cuzem

It's an i7 at 3.6Ghz (4ghz turbo) with inbuilt video.

[Jubatian]

I did some bits of new development on the emulator.

Now the emulator is capable to do frame merging, which means it blends the currently displaying frame with the previous one. This eliminates flicker for games which perform sprite cycling or in general any sort of 60Hz flashing to achieve some effect (such flashing on a normal TV screen shows as translucency, some games on various platforms utilized this, C64 demos heavily use it to increase apparent colour depth). This of course makes it running a bit slower. It is on by default, can be turned off by key F7. When off, since I did some optimizations, the emulator should run a few percents (3-5% possibly) faster than before.

I also added some configuration flags to the Make_config.mk file by which you can tweak how the emulator's display should look like on startup (most likely useful for the Emscripten target).

[D3thAdd3r]

Very nice. Do scrolling games look ok with this?

[Jubatian]

Try some. I can't notice anything, to test whether the frame merging actually happens, I captured screenshots from Tempest, only the screenshot could tell it.