Home again. I looked and all I had to change to compile on Win7x64 was some directory location things.
I didn't touch the line
FLAG_USE_SDL1=0
CUzeBox - The new official Uzebox emulator
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: CUzeBox - a new Uzebox emulator in progress
I've managed to get cuzebox built with working audio for SDL2 under Windows 10. In order to achieve that, I had to manually set the following environment variable:
So my environment is sorted now, but I'm wandering if it isn't worth including this step in the build configuration.
Slightly off topic, but just to add some context. I'm busy switching my development environment from OSX to Windows 10. So I'm building and installing all the tools from scratch. It's been an interesting adventure so far Right now I can build all the emulators and tools. I can also build the actual games successfully. Now all that remains for me is to see if I can make use of Atmel Studio 7. Apart from the SDL issue I've had here, the only other major hassle I've had up to this point has been that 'WinAVR-20100110' builds overly large hex files that don't actually run on the emulators successfully. I had to use avr-gcc-492 instead. I believe it is actually mentioned elsewhere on the forums. Anyway I digress.
If I understand the SDL FAQ correctly, the default value of 'dsound' isn't supported by SDL2.SDL_AUDIODRIVER=DirectSound
So my environment is sorted now, but I'm wandering if it isn't worth including this step in the build configuration.
Slightly off topic, but just to add some context. I'm busy switching my development environment from OSX to Windows 10. So I'm building and installing all the tools from scratch. It's been an interesting adventure so far Right now I can build all the emulators and tools. I can also build the actual games successfully. Now all that remains for me is to see if I can make use of Atmel Studio 7. Apart from the SDL issue I've had here, the only other major hassle I've had up to this point has been that 'WinAVR-20100110' builds overly large hex files that don't actually run on the emulators successfully. I had to use avr-gcc-492 instead. I believe it is actually mentioned elsewhere on the forums. Anyway I digress.
Re: CUzeBox - a new Uzebox emulator in progress
I made an update: now by holding down AltGr, you can direct keyboard input to Player 2's SNES controller. This allows testing JAMMA games and two player stuff without having an actual game controller.
I don't really understand those environment variables. They should be present to allow configuring SDL externally, so all SDL applications would behave the same. Configuring it from within a game defeats their purpose, so CUzeBox shouldn't touch it. If I interpret the FAQ right, however, it seems like an SDL1 application and an SDL2 application can't coexist on the same Windows system if they both expect their environment variables being provided by the OS.
If the situation is really such a crap, then probably the best thing an application could do is querying the value of the environment variable and set it before starting SDL if it is known to not work on the system it is running on (so it would also be a platform specific piece of otherwise unnecessary bloat).
Binaries are accessible on my site:
http://files.jubatian.com/cuzebox_linux_amd64.tar.bz2
http://files.jubatian.com/cuzebox_windows_x86.tar.bz2
http://files.jubatian.com/cuzebox_windows_x86.zip
I don't really understand those environment variables. They should be present to allow configuring SDL externally, so all SDL applications would behave the same. Configuring it from within a game defeats their purpose, so CUzeBox shouldn't touch it. If I interpret the FAQ right, however, it seems like an SDL1 application and an SDL2 application can't coexist on the same Windows system if they both expect their environment variables being provided by the OS.
If the situation is really such a crap, then probably the best thing an application could do is querying the value of the environment variable and set it before starting SDL if it is known to not work on the system it is running on (so it would also be a platform specific piece of otherwise unnecessary bloat).
Binaries are accessible on my site:
http://files.jubatian.com/cuzebox_linux_amd64.tar.bz2
http://files.jubatian.com/cuzebox_windows_x86.tar.bz2
http://files.jubatian.com/cuzebox_windows_x86.zip
Re: CUzeBox - The new official Uzebox emulator
Haven't been able to find the answer to this anywhere, but is there a shortcut key to disable the CRT style scanlines? (so produce a crisp pixel image)
Re: CUzeBox - The new official Uzebox emulator
No (except for the low quality setting), but if you prefer to develop without them, you can edit the guicore_render_2x() function in guicore.c: it is currently on line 127. Replace that to "col | guicore_amask" to remove the scanline effect. (On a CRT, you should see scanlines as Uzebox doesn't do interlacing. When recording video, scanlines are not present either)
Re: CUzeBox - The new official Uzebox emulator
Is there any progress on the UART emulation?
Re: CUzeBox - The new official Uzebox emulator
Sorry, I really put that aside as I find it hard to gather any interest in stuff running on a PC (which also sets me back in creating an emulator for the 2x1284 system), I really want to rather tidy up my video modes nowadays looking forth towards some game ideas. Anyway, soon you will get Mode 72 in Master.
Re: CUzeBox - The new official Uzebox emulator
I updated the binaries accessible from the top post, now they contain the version which has the SD card CMD59 fix (which is required to run Artcfox's 8 way scrolling demo).
Re: CUzeBox - The new official Uzebox emulator
Thanks!Jubatian wrote: ↑Wed Apr 11, 2018 6:23 am I updated the binaries accessible from the top post, now they contain the version which has the SD card CMD59 fix (which is required to run Artcfox's 8 way scrolling demo).