Uzem ported to SDL2
Uzem ported to SDL2
I just finished porting the uzem140 branch to SDL2, and right now I'm still rendering into a 640x480 chunk of memory, but I've created a streaming texture from that memory and I'm letting the GPU do the rescaling. When running in windowed mode, you can now resize the window, and the pixels will be scaled depending on the size of the window. Fullscreen mode no longer changes the monitor's resolution, but it creates a fullscreen window and uses the GPU to scale the texture up to the full size of the screen.
For the next step, I'm going to try rendering into a 640x224 chunk of memory, and then letting the GPU scale that up, rather than having to manually duplicate every scanline. Once that is working, the plan is to try rendering into a 1440x224 chunk of memory (or 720x224), creating a texture out of that, and then letting the GPU scale that to fit the screen.
Edit: The SDL2 port is now fully complete.
For the next step, I'm going to try rendering into a 640x224 chunk of memory, and then letting the GPU scale that up, rather than having to manually duplicate every scanline. Once that is working, the plan is to try rendering into a 1440x224 chunk of memory (or 720x224), creating a texture out of that, and then letting the GPU scale that to fit the screen.
Edit: The SDL2 port is now fully complete.
Last edited by Artcfox on Sun Sep 27, 2015 10:08 pm, edited 2 times in total.
Re: Uzem ported to SDL2
Okay, so I've now modified the code so that it render into a 640x240 chunk of memory, and then it uses the GPU to scale it up to the proper aspect ratio. It was very easy to change the video recording code so that it takes a squished video as input, and stretches it back out in addition to scaling it up to 720p.
Once I disabled the compositor on my Linux desktop, this thing FLIES! I'm getting so much better performance than I ever did with the old version of SDL!
We can think about switching to a 720x240 array in order to automatically support all future video modes.
Once I disabled the compositor on my Linux desktop, this thing FLIES! I'm getting so much better performance than I ever did with the old version of SDL!
We can think about switching to a 720x240 array in order to automatically support all future video modes.
Last edited by Artcfox on Sun Sep 27, 2015 10:08 pm, edited 1 time in total.
Re: Uzem ported to SDL2
Attached is a patch file against the latest uzem140 branch as of this writing (commit 135c2bb8104832d64e49d3bc4a954db3135bd0d6).
It includes the following general bugfixes:
It turned out to be a very clean port, and it builds and runs amazingly fast, even on my slow laptop. It's so fast now (running at 100% real-hardware speed) that it's actually difficult for me to beat my own work in progress.
The easiest way to test this on Linux is to clone a new copy of the repo, but first, be sure you have the SDL2 development libraries installed.
download the attached .zip file, and extract the .patch file into the uzemSDL2/uzebox directory. Then run:
It includes the following general bugfixes:
- Fix for undefined behavior (and uninitialized) bug in tools/gconvert/lodepng.cpp
- Adds missing tools/gconvert/paletteTable.h file so gconvert will compile
- Fix for "consider adding parenthesis warning" in tools/gconvert/tinyxmlparser.cpp
- Remove strlwr() since it causes ROMS with mixed case to give "not found" errors on case sensitive filesystems (Linux). Instead, it checks for both upper and lower case extensions.
- Zero uzebox.captureFile after closing it when reading the capture file so fclose() doesn't get called twice in shutdown() causing a segfault on Linux.
- Conditionalize Windows-only code, so uzem can be compiled on Linux.
- Finish removing the unused SDL_framerate class
- Add missing #include <stdio.h> to gdbserver.h so it compiles on Linux now that the SDL_framerate class is totally gone
- Change keyboard scancodes type and constants to SDL2 compatible in uzem/Keyboard.h and avr8.cpp
- Fix Makefile so it uses SDL2, and no longer compiles SDL_framerate.cpp
- avr8.h - Change include files to SDL2, and initialize the ring buffer with silence, since SDL2 does not initialize the audio buffer anymore (fixes sound glitch on startup). Remove the undefined sdl_flags, since SDL doesn't have those anymore. Remove SDL_EnableKeyRepeat since it no longer exists in SDL2 (it's the default behavior).
- Modify rendering code so it renders into a 640x240 chunk of memory (much faster!) and change recording parameters to compensate for the different aspect ratio, so it still records at 720p with the proper aspect ratio.
- Fullscreen mode no longer switches the mode of the monitor, instead it makes a fullscreen window and uses the GPU to scale the image.
- Ported Joystick code over, removing the functions that don't exist on SDL2 anymore. According to the documentation, if the joystick is not opened, its handle will be null.
It turned out to be a very clean port, and it builds and runs amazingly fast, even on my slow laptop. It's so fast now (running at 100% real-hardware speed) that it's actually difficult for me to beat my own work in progress.
The easiest way to test this on Linux is to clone a new copy of the repo, but first, be sure you have the SDL2 development libraries installed.
Code: Select all
sudo apt-get install libsdl2-dev
mkdir uzemSDL2
cd uzemSDL2
git clone https://github.com/Uzebox/uzebox.git
cd uzebox
git checkout uzem140
Code: Select all
git apply uzem140_SDL2_port_and_general_bugfixes-v2.patch
make
- Attachments
-
- uzem140_SDL2_port_and_general_bugfixes-v2.zip
- Patch file for SDL2 upgrade (now with Joystick support!), and general bugfixes against the uzem140 branch
- (7.05 KiB) Downloaded 619 times
Last edited by Artcfox on Sun Sep 27, 2015 9:44 pm, edited 1 time in total.
Re: Uzem ported to SDL2
Great work wow that is a lot. I'm going to have to try compiling on linux and see if my slow laptop can run it full speed now, and check out the scaling.
Re: Uzem ported to SDL2
Thanks! Here is a quick video of what this rescaling looks like in real-time:D3thAdd3r wrote:Great work wow that is a lot. I'm going to have to try compiling on linux and see if my slow laptop can run it full speed now, and check out the scaling.
(Sorry for the crappy video quality, it looks darker when I shrunk it down, but that's just because of the viewing angle of my screen, the actual pixels themselves look awesome.)
I'm not sure how to disable the compositor under Ubuntu, but a surefire way to disable it under Debian was to run:
Code: Select all
metacity --replace&
Edit: I just finished porting the Joystick code over to SDL2, and updated the patch file in my previous post. I'm assuming that someone else here is familiar with how the Joystick stuff works, and could assist with testing that it works correctly. There were actually very minimal changes to the joystick code.
Last edited by Artcfox on Sun Sep 27, 2015 11:44 pm, edited 3 times in total.
Re: Uzem ported to SDL2
Holy crap that is great!
When you say your slow laptop, what is the clock speed of a single core you have running that fullspeed? My x64 AMD 4x1.9 just wont do it currently.
When you say your slow laptop, what is the clock speed of a single core you have running that fullspeed? My x64 AMD 4x1.9 just wont do it currently.
Re: Uzem ported to SDL2
Thanks!D3thAdd3r wrote:Holy crap that is great!
When you say your slow laptop, what is the clock speed of a single core you have running that fullspeed? My x64 AMD 4x1.9 just wont do it currently.
I just looked it up, apparently it's got an Intel® Core™ i5-560M Processor (3M Cache, 2.66 GHz) from 2010 inside.
I'm using whatever Intel open source drivers came with Debian Wheezy (i915 driver, I believe), since I still haven't bothered to upgrade to Debian Jessie on this machine. I actually found it in the trash (without a working keyboard), but after a keyboard swap, I found that I use this machine more than I do my newer, faster desktop just because it's so portable.
Edit: I may have disabled the Turbo Boost technology, because when I monitor the actual CPU frequency while running Uzem it never goes above 2.66 GHz, and it never consumes more than 88% of one core.
Re: Uzem ported to SDL2
I just finished porting the Joystick code over to SDL2, so this should be a completely functional port now!
I updated the patch file and instructions in my earlier post.
If anyone on this forum is familiar with using the NDK in Android, SDL2 now has official Android support. It's not entirely unreasonable to assume that someone could use this to build a version of Uzem that runs on Android.
I updated the patch file and instructions in my earlier post.
If anyone on this forum is familiar with using the NDK in Android, SDL2 now has official Android support. It's not entirely unreasonable to assume that someone could use this to build a version of Uzem that runs on Android.
Re: Uzem ported to SDL2
Great work Thanks! I had started fiddling with it a while ago, but I always use pushed it for later.
Is it possible to send a pull request on github instead of a patch? I'd like to review the changes before and I'm used to the pull process. thanks!
Is it possible to send a pull request on github instead of a patch? I'd like to review the changes before and I'm used to the pull process. thanks!
Re: Uzem ported to SDL2
Sure, I'll give that a shot. I've never done that before so it might take me a bit to figure out how.uze6666 wrote:Great work Thanks! I had started fiddling with it a while ago, but I always use pushed it for later.
Is it possible to send a pull request on github instead of a patch? I'd like to review the changes before and I'm used to the pull process. thanks!