Would it be possible to package the /SDL-1.2.15/lib/x86/SDL.dll file from http://www.libsdl.org/release/SDL-1.2.15-win32.zip (the development version) inside the zip file that contains the pre-compiled uzem.exe that you build for Windows?
I sent a copy of my WIP to someone, and pointed him to the latest pre-compiled Uzem that is linked to from the Uzebox homepage, but he wasn't able to get it to run until he also downloaded the development version of SDL-1.2.15-win32.zip and copied the SDL.dll into the same folder as uzem.exe. On the wiki page it mentions mingw and libsdl as build-time dependencies, but it doesn't mention that libsdl is also a runtime dependency (obvious to us, but maybe not to someone who just wants to casually try out Uzem).
Another option would be to statically link with libsdl, though that would require a bit more effort than just packaging SDL.dll along with the executable.
Emulator - get latest release here.
Re: Emulator - get latest release here.
Hmmm, I thought it was already statically linked! Seemed it got lost along the way somehow. Will have to add it back.Another option would be to statically link with libsdl, though that would require a bit more effort than just packaging SDL.dll along with the executable.
Re: Emulator - get latest release here.
Guys, it's been a while with no activity on uzem so I'll assume we can merge back that branch now...?
Re: Emulator - get latest release here.
For my part I put Uzem kind of aside for now. I am happily using what I have for graphics mode development (with the timing printout hack I mentioned a few times which works very well in Linux using a console, allowing tracking problems in a video mode quite accurately). I just mentioned since the quest for speed eliminated a graphical feedback (in a commented out blob of code) which might or might not have been relied upon by others. Otherwise functionality seems to be intact. Even the half-carry flag (I know since Mode74's sprite engine actually uses that flag quite extensively!).
Re: Emulator - get latest release here.
I say merge it back. I could certainly use the speed improvements on my laptop in the default branch.
Re: Emulator - get latest release here.
Allright, I've managed to find time and sit down and go trough that merge and solve a bunch of conflicts. So Uzem 2.0 is officially released!
See the main post for the latest details and executable.
Many thanks to Artfox, Jubatian and CunningFellow for their awesome work on this release!
See the main post for the latest details and executable.
Many thanks to Artfox, Jubatian and CunningFellow for their awesome work on this release!
-
- Posts: 1488
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Emulator - get latest release here.
Awesomeness
Does this one have the scanline/HSync measurement tools ?
Does this one have the scanline/HSync measurement tools ?
Re: Emulator - get latest release here.
Eessshhh...I think that was removed during the work. But Jubatian has some sort of hacked version to do that. Perhaps that could make it in the official release.CunningFellow wrote: Does this one have the scanline/HSync measurement tools ?
Re: Emulator - get latest release here.
I also wanted to say great work all involved, on a critical part of the Uzebox project. Uzem is definitively better than it used to be due to your recent technical contributions and/or wizardry and it's impressive to say the least.
Re: Emulator - get latest release here.
It is nothing fancy, just this. The problem is that you can only use this in Linux unless in some manner you can bring a console alive in Windows (I have no Windows at all, so I really don't know what to do about that).uze6666 wrote:But Jubatian has some sort of hacked version to do that. Perhaps that could make it in the official release.
The console in general is exceptionally useful for debugging: if your code does something dubious, you can always print stuff from the emulator to see what happens. I generally don't need it, I just have the affinity to spot the problem area when something goes south. But I used that hack excessively, and it was very useful to have it the way it is. If needed, I could redirect the output to file, and see what was up, it is also very useful to give a clue when something completely falls apart (and so lines pop up with 10K or so cycles depending on what tipped over miserably).
So if someone came along and rammed Windows down my throat (if that happens, I am so going to fire up my C64 and write my own AVR assembler and editor...), my solution would be somehow figuring out how to get console, then forgetting about any other alternative.