Uzem ported to SDL2

The Uzebox now have a fully functional emulator! Download and discuss it here.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to SDL2

Post by Artcfox »

uze6666 wrote:Also, palette mode works in windowed mode?
It wouldn't be palette mode in the old school sense where you set the entire display to X colors. If it works, it would be passing an 8-bit texture (as opposed to an RGBA texture) to the GPU, along with the palette you want it to use, and letting the GPU's shader use the palette you passed it as a LUT for the 8-bit texture pixels. Basically offloading more work to the GPU, while decreasing the amount of data that you need to transfer to the GPU each frame. It's certainly possible if you use OpenGL directly with a custom GLSL program, but the hope is that this is something common enough that SDL2 supports it natively without having to resort to writing our own shader program. The only caveat would be making sure that all cards support doing it in hardware at a similar speed.
uze6666 wrote:
So with that change, you're happy with the performance of SDL2?
Absolutely, with all the fixes applied, it's even a bit better on my machine.
Excellent! :)
uze6666 wrote:If I disable that delay line, it looks better at first sight and I didn't get sound drops so far. But you bring a good point, can we assume all monitors are at 60hz? Not so sure. Perhaps it's better to keep that line for now (or have so flag or config). I'll commit my changes to the branch for others to check out.
My vote is to have a configuration flag that can swap out the audio delay line and put in that vsync parameter. (Maybe call it --limit-speed-vsync versus the default of --limit-speed-audio)
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to SDL2

Post by Artcfox »

Your new speed improvements broke the recording feature, and make the vertical scaling look ugly, but both were an easy fix, and I've already submitted a pull request.

The interesting part was now that you've passed all 0's for the pixel format (meaning use whatever order is optimal for the current video card) I wasn't sure which pixel format to tell ffmpeg to use when I gave it the raw data, and my recorded videos come out with the colors swapped. I added code to query the SDL_Surface for its pixel format, and use that to build the string that I pass to ffmpeg.

Now it shouldn't matter which format a person's video card chooses as its optimal format, and the ugly black borders are gone from both the SDL2 window, and the recording! :D
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to SDL2

Post by uze6666 »

Great stuff! It's been merged. :)

Jubatian, hopefully those latest fixes will improve your framerate too.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to SDL2

Post by uze6666 »

I just tried the sprite-demo posted previously. Can you try making a movie out of it. For me the resulting compression is just awful after about 10 seconds. Probably because there is so much scrolling all over the place. I think we may have to be able to specify the bitrate or something.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to SDL2

Post by Artcfox »

uze6666 wrote:I just tried the sprite-demo posted previously. Can you try making a movie out of it. For me the resulting compression is just awful after about 10 seconds. Probably because there is so much scrolling all over the place. I think we may have to be able to specify the bitrate or something.
Oh, I told you a while back that I don't use the default recording settings. It takes too long to encode and looks like crap.

Get rid of the:

Code: Select all

-b:v 1000k
and replace it with:

Code: Select all

-preset ultrafast -qp 0 -tune animation 
That allows me to play at full speed while recording, and it is lossless, so it should be a good default for anything anyone wants to throw at it. The lossless part makes a difference because YouTube is going to transcode whatever you upload, and by encoding as lossless, you avoid any double-compression artifacts.

Here is what it looks like with my recording defaults.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to SDL2

Post by uze6666 »

Look pretty to good to me, but isn't the resulting file huge? That could take more time to upload, but it's a trade off I'm willing to take.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to SDL2

Post by Artcfox »

uze6666 wrote:Look pretty to good to me, but isn't the resulting file huge? That could take more time to upload, but it's a trade off I'm willing to take.
For Bugz it actually produces smaller files; for that sprite demo it made a larger file.

My thoughts on the matter are: You do the recording and upload once, but the video potentially gets played back thousands of times. Why not ensure it looks great?

If you're hurting for bandwidth that bad, then it would probably be more prudent to use lossy compression, and switch codecs to something like VP9, which would immediately knock 50% off the final size as compared to x264, but I hear the encoding times are much longer, though I've never tried.

As an aside, the videos I record using my SLR end up being over 600 MB, and YouTube is able to suck up the entire file in ~6 seconds, before I can even finish typing the title usually. :shock:
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to SDL2

Post by uze6666 »

My thoughts on the matter are: You do the recording and upload once, but the video potentially gets played back thousands of times. Why not ensure it looks great?
Oh, I totally agree with you, quality matters most for me so I don't mind waiting.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzem ported to SDL2

Post by Artcfox »

So I've been making some improvements to the SDL2 port, and one of the things I added back was support for sdl_flags. Now using command line options, you can choose between SDL's accelerated renderer (which works better on newer computers, and can still run at faster than 100% emulation speed on a 2.0 GHz Core 2), and SDL's software renderer (which works better on really old or slow computers). I also added a command line option to allow you to disable the SDL_RENDERER_PRESENTVSYNC flag, in case you want to run without that to make performance testing easier, as you can just pass the options "-vn" and the emulator will run as fast as it can.

Both the accelerated rendering and the software rendering modes allow you to resize the window to an arbitrary size.

I also made the "-f" command line flag switch the resolution of the monitor again, because on older computers that makes it much faster than having to scale up to the full resolution of your monitor if you don't have a decent GPU. Fullscreen mode is back to being fast again for both accelerated and software rendering modes, even on the 2.0 GHz Core 2.

I fixed the screenshotting function so the screenshot it saves is always 630x448, no matter what your window size is, rather than it being fixed at 720x224. And I also added a feature so if you're holding down shift when you press printscreen, the screenshot will be 240x224. (320x224 had too many artifacts). Unfortunately on Linux, GNOME traps the print screen key, which means unless I remap it at the OS level, I can't take screenshots at all.
  • Could we remap the screenshot key to something else so everyone on Linux can use the screenshotting function?
  • Which rendering option should be the default?
My 9 year old 2.0 GHz Core 2 can run both the accelerated mode and the software mode faster than 100% emulation speed, but the software rendering mode can't use the default SDL_RENDER_PRESENTVSYNC flag, so if we want the default to be a buttery-smooth 60fps, then I think it should be accelerated, and people with older computers can just pass the -w flag to switch over to software rendering. Thoughts?

Edit: Uze, if you want to check it out before I issue a pull request to you, the code is here: https://github.com/artcfox/uzebox/tree/uzem140-fast

Can you test that compiling my uzem140-fast branch which includes the "-Ofast -flto -fwhole-program" in both the CFLAGS and LDFLAGS of the Makefile works on Windows? That gave the emulator a whopping 35 MHz speed boost on my desktop, so if it works on Windows too, that will be a great thing to have.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzem ported to SDL2

Post by uze6666 »

Ok, I'll check it out. All these options are required but I don't think there must be a better approach than command line. Something I wanted for a long time is a standard .ini/.cfg text file that would reside in the same directory as the executable. That should be loaded first and the command line overrides any one. Uzem would create a default one if none present. We can put so much more tweaking parameters and options in there. Should not be too hard to do right? ;)
Post Reply