CUzeBox - The new official Uzebox emulator
Re: CUzeBox - a new Uzebox emulator in progress
It is a planned feature. I build the architecture so it is possible to add support for that later.
Re: CUzeBox - a new Uzebox emulator in progress
Awesome!Jubatian wrote:It is a planned feature. I build the architecture so it is possible to add support for that later.
Using your latest changes, I was able to play the Emscripten version of Bugz full screen at 60 fps on a three year old Chromebook that retailed for $199 back when it was brand new. Both the sound and video were perfect. Color me impressed!
Re: CUzeBox - a new Uzebox emulator in progress
This is the first time I've cross-compiled a Windows executable on a Linux system, but I successfully created cuzebox.exe from a Debian system, and it runs on a Windows 7 machine I found.
The only problem I ran into is if tried to maximize or resize the window, then it would crash, saying something happened within the SDL2.dll module. Pressing F2 followed by F4 tore down the GUI and recreated it at a smaller size, without a crash; and the same goes for pressing F2 followed by F4 again, it tore down the GUI and recreated it back at its original size, without a crash.
It could very well be that this Windows machine has buggy drivers—it was a fresh install of Windows 7 Enterprise, and I did not run Windows Update at all, though it also crashes when I try to resize it under Wine.
The only problem I ran into is if tried to maximize or resize the window, then it would crash, saying something happened within the SDL2.dll module. Pressing F2 followed by F4 tore down the GUI and recreated it at a smaller size, without a crash; and the same goes for pressing F2 followed by F4 again, it tore down the GUI and recreated it back at its original size, without a crash.
It could very well be that this Windows machine has buggy drivers—it was a fresh install of Windows 7 Enterprise, and I did not run Windows Update at all, though it also crashes when I try to resize it under Wine.
Code: Select all
Unhandled exception: page fault on read access to 0x00000014 in 32-bit code (0x6c792b8d).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:6c792b8d ESP:0083f85c EBP:0083f8d0 EFLAGS:00210297( R- -- I S -A-P-C)
EAX:00000000 EBX:00232bc8 ECX:0083f85c EDX:0012e988
ESI:00000000 EDI:00235808
Stack dump:
0x0083f85c: 00198fa0 00000000 6c7c65d0 6c7d57f0
0x0083f86c: 7fea0008 0000026c 000001c8 000009b0
0x0083f87c: 00000000 01780020 00232d10 000001c8
0x0083f88c: 00235860 00000000 00000000 0083f918
0x0083f89c: 6c789f5d 00232bc8 00235860 ffffffff
0x0083f8ac: 00000000 00000000 00000000 00000000
Backtrace:
=>0 0x6c792b8d in sdl2 (+0x52b8d) (0x0083f8d0)
1 0x6c7930d1 in sdl2 (+0x530d0) (0x0083f91c)
2 0x6c7936a3 in sdl2 (+0x536a2) (0x0083f988)
3 0x0040525b in cuzebox (+0x525a) (0x7ffb37d8)
0x6c792b8d: movl 0x14(%esi),%eax
Modules:
Module Address Debug info Name (130 modules)
PE 400000- 636000 Export cuzebox
PE 6c740000-6c849000 Export sdl2
ELF 7b23a000-7b800000 Deferred i965_dri.so
ELF 7b800000-7ba55000 Deferred kernel32<elf>
\-PE 7b810000-7ba55000 \ kernel32
ELF 7bc00000-7bcd6000 Deferred ntdll<elf>
\-PE 7bc10000-7bcd6000 \ ntdll
ELF 7bf00000-7bf04000 Deferred <wine-loader>
ELF 7c4ba000-7c4f1000 Deferred libtxc_dxtn.so
ELF 7c7f1000-7c7fd000 Deferred libpciaccess.so.0
ELF 7c7fd000-7c81a000 Deferred libgcc_s.so.1
ELF 7c90c000-7c91b000 Deferred libdrm_radeon.so.1
ELF 7c91b000-7c940000 Deferred libdrm_intel.so.1
ELF 7c940000-7c952000 Deferred libudev.so.1
ELF 7c952000-7c96c000 Deferred libxcb-glx.so.0
ELF 7c96c000-7c985000 Deferred libglapi.so.0
ELF 7c985000-7c9ae000 Deferred libexpat.so.1
ELF 7c9ae000-7ca59000 Deferred libgl.so.1
ELF 7ca59000-7cb75000 Deferred opengl32<elf>
\-PE 7ca80000-7cb75000 \ opengl32
ELF 7d3fe000-7d406000 Deferred libdrm_nouveau.so.2
ELF 7d406000-7d415000 Deferred libdrm.so.2
ELF 7d434000-7d564000 Deferred wined3d<elf>
\-PE 7d440000-7d564000 \ wined3d
ELF 7d564000-7d5a1000 Deferred d3d9<elf>
\-PE 7d570000-7d5a1000 \ d3d9
ELF 7d5a1000-7d5d4000 Deferred msctf<elf>
\-PE 7d5b0000-7d5d4000 \ msctf
ELF 7d804000-7d80b000 Deferred libxcb-sync.so.1
ELF 7d80b000-7d820000 Deferred xinput1_3<elf>
\-PE 7d810000-7d820000 \ xinput1_3
ELF 7d820000-7d869000 Deferred dinput<elf>
\-PE 7d830000-7d869000 \ dinput
ELF 7d869000-7d885000 Deferred dinput8<elf>
\-PE 7d870000-7d885000 \ dinput8
ELF 7d885000-7d8b2000 Deferred libvorbis.so.0
ELF 7d8b2000-7d8bb000 Deferred libogg.so.0
ELF 7d8bb000-7d8cf000 Deferred libgpg-error.so.0
ELF 7d8cf000-7d95e000 Deferred libvorbisenc.so.2
ELF 7d95e000-7d995000 Deferred libflac.so.8
ELF 7d995000-7d9ad000 Deferred libresolv.so.2
ELF 7d9ad000-7da5e000 Deferred libgcrypt.so.20
ELF 7da5e000-7da87000 Deferred liblzma.so.5
ELF 7da87000-7da8d000 Deferred libuuid.so.1
ELF 7da8d000-7da93000 Deferred libattr.so.1
ELF 7da93000-7db0c000 Deferred libsndfile.so.1
ELF 7db0c000-7db16000 Deferred libwrap.so.0
ELF 7db16000-7db3f000 Deferred libsystemd.so.0
ELF 7db3f000-7db47000 Deferred libxtst.so.6
ELF 7db47000-7db51000 Deferred libsm.so.6
ELF 7db51000-7db6e000 Deferred libice.so.6
ELF 7db6e000-7dbc5000 Deferred libdbus-1.so.3
ELF 7dbc5000-7dc47000 Deferred libpulsecommon-5.0.so
ELF 7dc47000-7dc9f000 Deferred libpulse.so.0
ELF 7dc9f000-7dda7000 Deferred libasound.so.2
ELF 7ddfe000-7de02000 Deferred libxcb-present.so.0
ELF 7de02000-7de06000 Deferred libxcb-dri3.so.0
ELF 7de06000-7de0c000 Deferred libxcb-dri2.so.0
ELF 7de0c000-7de10000 Deferred libxdamage.so.1
ELF 7de10000-7de19000 Deferred libasound_module_pcm_pulse.so
ELF 7de20000-7de29000 Deferred librt.so.1
ELF 7de29000-7de58000 Deferred winealsa<elf>
\-PE 7de30000-7de58000 \ winealsa
ELF 7de58000-7de7a000 Deferred mmdevapi<elf>
\-PE 7de60000-7de7a000 \ mmdevapi
ELF 7de7a000-7dec2000 Deferred dsound<elf>
\-PE 7de80000-7dec2000 \ dsound
ELF 7df08000-7df3d000 Deferred uxtheme<elf>
\-PE 7df10000-7df3d000 \ uxtheme
ELF 7df3d000-7df44000 Deferred libxfixes.so.3
ELF 7df44000-7df50000 Deferred libxcursor.so.1
ELF 7df50000-7df63000 Deferred libxi.so.6
ELF 7df63000-7df6f000 Deferred libxrender.so.1
ELF 7df6f000-7df76000 Deferred libxxf86vm.so.1
ELF 7df76000-7df9c000 Deferred libxcb.so.1
ELF 7df9c000-7e0ee000 Deferred libx11.so.6
ELF 7e0ee000-7e103000 Deferred libxext.so.6
ELF 7e103000-7e190000 Deferred winex11<elf>
\-PE 7e110000-7e190000 \ winex11
ELF 7e190000-7e1bd000 Deferred libpng12.so.0
ELF 7e1bd000-7e1da000 Deferred libz.so.1
ELF 7e1da000-7e28c000 Deferred libfreetype.so.6
ELF 7e28c000-7e2af000 Deferred libtinfo.so.5
ELF 7e2af000-7e2d7000 Deferred libncurses.so.5
ELF 7e2d7000-7e2de000 Deferred libasyncns.so.0
ELF 7e2de000-7e2e1000 Deferred libx11-xcb.so.1
ELF 7e2e1000-7e2e7000 Deferred libcap.so.2
ELF 7e2e7000-7e2f3000 Deferred libjson-c.so.2
ELF 7e2f3000-7e2f6000 Deferred libxshmfence.so.1
ELF 7e2f6000-7e321000 Deferred msacm32<elf>
\-PE 7e300000-7e321000 \ msacm32
ELF 7e321000-7e3d9000 Deferred winmm<elf>
\-PE 7e330000-7e3d9000 \ winmm
ELF 7e3d9000-7e4d3000 Deferred comctl32<elf>
\-PE 7e3e0000-7e4d3000 \ comctl32
ELF 7e4d3000-7e549000 Deferred shlwapi<elf>
\-PE 7e4e0000-7e549000 \ shlwapi
ELF 7e549000-7e772000 Deferred shell32<elf>
\-PE 7e560000-7e772000 \ shell32
ELF 7e772000-7e89c000 Deferred oleaut32<elf>
\-PE 7e790000-7e89c000 \ oleaut32
ELF 7e89c000-7e917000 Deferred rpcrt4<elf>
\-PE 7e8b0000-7e917000 \ rpcrt4
ELF 7e917000-7ea45000 Deferred ole32<elf>
\-PE 7e930000-7ea45000 \ ole32
ELF 7ea45000-7eb93000 Deferred user32<elf>
\-PE 7ea60000-7eb93000 \ user32
ELF 7eb93000-7ebb7000 Deferred imm32<elf>
\-PE 7eba0000-7ebb7000 \ imm32
ELF 7ebb7000-7ec25000 Deferred advapi32<elf>
\-PE 7ebc0000-7ec25000 \ advapi32
ELF 7ec25000-7ed3f000 Deferred gdi32<elf>
\-PE 7ec30000-7ed3f000 \ gdi32
ELF 7ed3f000-7edec000 Deferred msvcrt<elf>
\-PE 7ed50000-7edec000 \ msvcrt
ELF 7ef75000-7ef82000 Deferred libnss_files.so.2
ELF 7ef82000-7ef9b000 Deferred libnsl.so.1
ELF 7ef9b000-7efe1000 Deferred libm.so.6
ELF 7efe1000-7efe7000 Deferred libxdmcp.so.6
ELF 7efe7000-7f000000 Deferred version<elf>
\-PE 7eff0000-7f000000 \ version
ELF f7402000-f740e000 Deferred libnss_nis.so.2
ELF f740f000-f7414000 Deferred libdl.so.2
ELF f7414000-f75c1000 Deferred libc.so.6
ELF f75c2000-f75de000 Deferred libpthread.so.0
ELF f75f0000-f75f4000 Deferred libxau.so.6
ELF f75f4000-f75fd000 Deferred libnss_compat.so.2
ELF f75fd000-f77b2000 Dwarf libwine.so.1
ELF f77b4000-f77d5000 Deferred ld-linux.so.2
ELF f77d5000-f77d6000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
00000008 (D) Z:\home\user\cuzebox\cuzebox.exe
00000029 2
00000028 15
00000027 0
00000026 0
00000025 0
00000024 0
00000009 0 <==
0000000e services.exe
0000001e 0
0000001d 0
00000018 0
00000016 0
00000014 0
00000010 0
0000000f 0
00000012 winedevice.exe
0000001c 0
00000019 0
00000017 0
00000013 0
0000001a plugplay.exe
00000020 0
0000001f 0
0000001b 0
00000021 explorer.exe
00000023 0
00000022 0
System information:
Wine build: wine-1.6.2
Platform: i386
Host system: Linux
Host version: 3.16.0-4-amd64
Re: CUzeBox - a new Uzebox emulator in progress
It could be that I missed something in interfacing SDL proper. I have Wine (and tested building and starting the emulator in it), so if the crash is reproducible there I should find what could cause it.
Crashing for resizing is weird though since there is nothing in my code handling resize events (so it is all done by SDL itself, as I understand it, the renderer should take care of everything transparently).
I found something related, which could be it:
https://forums.libsdl.org/viewtopic.php ... 69c95a0031
The commit fixing it is rather fresh (June, 2016). Are you sure the SDL2.dll you use has this fix?
It bugs me that I could be using an unsupported texture format (by the hardware), but I was unable to find anything to truly request some supported format. As I poked around in Uzem, I think the method it uses neither would definitely create a native format texture, it just creates a surface without specifying its arrangement and it isn't documented anywhere what exactly it would default to. Surfaces are just for compatibility in SDL2, if Uzem works well, I lean to think that it is merely by chance: that whatever default the surface creation provides just happens to be a supported format for some machines.
Damn. I found it. Line 387 in this source code. If you passed 0 as format for SDL_CreateTexture, it would use the first native format provided by the renderer. This isn't documented in SDL_CreateTexture, although could be useless if the renderer provided a rather arbitrary format there (such as indexed color even if it supported RGBA). The correct way could be using SDL_RendererInfo to find out what the renderer has and choose one of those. Messy thing, it doesn't seem like I could shortcut to just ask for any 32 bit, 8 bit per component format...
Crashing for resizing is weird though since there is nothing in my code handling resize events (so it is all done by SDL itself, as I understand it, the renderer should take care of everything transparently).
I found something related, which could be it:
https://forums.libsdl.org/viewtopic.php ... 69c95a0031
The commit fixing it is rather fresh (June, 2016). Are you sure the SDL2.dll you use has this fix?
It bugs me that I could be using an unsupported texture format (by the hardware), but I was unable to find anything to truly request some supported format. As I poked around in Uzem, I think the method it uses neither would definitely create a native format texture, it just creates a surface without specifying its arrangement and it isn't documented anywhere what exactly it would default to. Surfaces are just for compatibility in SDL2, if Uzem works well, I lean to think that it is merely by chance: that whatever default the surface creation provides just happens to be a supported format for some machines.
Damn. I found it. Line 387 in this source code. If you passed 0 as format for SDL_CreateTexture, it would use the first native format provided by the renderer. This isn't documented in SDL_CreateTexture, although could be useless if the renderer provided a rather arbitrary format there (such as indexed color even if it supported RGBA). The correct way could be using SDL_RendererInfo to find out what the renderer has and choose one of those. Messy thing, it doesn't seem like I could shortcut to just ask for any 32 bit, 8 bit per component format...
Re: CUzeBox - a new Uzebox emulator in progress
I did it! I mean I implemented a proper query for the native format, so now the emulator should use it! In particular on my PC this gives a very substantial kick in performance (about 20 percents, some games peak near a ridiculous 400%, well, now compare this to that a year ago I was happy if the Halloween demo broke the 25MHz barrier on the then-current Uzem...), not something insanely useful though as it has no effect on the Emscripten build.
Hopefully it also gets that pesky Windows SDL bug going away. And hopefully it doesn't break anything (as supporting multiple pixel formats also comes with that I can't simply test them all), I would be particularly interested in what happens on a Big Endian machine.
Hopefully it also gets that pesky Windows SDL bug going away. And hopefully it doesn't break anything (as supporting multiple pixel formats also comes with that I can't simply test them all), I would be particularly interested in what happens on a Big Endian machine.
Re: CUzeBox - a new Uzebox emulator in progress
Sweet! Confirmed working on a native Windows 7 install.
Re: CUzeBox - a new Uzebox emulator in progress
I see that you added the ability to use Uzem's keymappings (yay!), but you forgot to switch the location of the Select button. Select should be mapped to the Tab key.
Edit: Uzem's full keymappings are:
Edit: Uzem's full keymappings are:
Code: Select all
Up Down Left Right A B X Y Start Sel LShldr RShldr
NES: ----arrow keys---- a s Enter Tab
SNES 1p: ----arrow keys---- a s x z Enter Tab LShift RShift
2p P1: w s a d f g r t z x q e
2p P2: i k j l ; ' p [ n m u o
Re: CUzeBox - a new Uzebox emulator in progress
Will this be able to create new files? It would be very convenient to make a simple internet utility that occupies the SD card with all roms.
Re: CUzeBox - a new Uzebox emulator in progress
It should be able to create new files (not "will", it already has this implemented). You can do it by first setting up the FAT, then writing the file contents. If it detects that what you write belongs to a proper file by the Virtual FAT, but one which doesn't exist on the host, it creates the file. You can also expand files (increasing file size), and it also supports fragmentation.
Artcfox: I fixed that bug yesterday, it wasn't intentional.
Artcfox: I fixed that bug yesterday, it wasn't intentional.
Re: CUzeBox - a new Uzebox emulator in progress
Awesome! I just ordered an XBox 360 Wired USB controller, so Tuesday I'm hoping to test it with Uzem to make sure it works, and then hopefully we'll be able to add joypad support to CUzeBox.