uxn32
uxn32 copied to clipboard
randrew
Commandline arguments do not work
Varvara software like Adelie has to be run with commandline arguments (in Adelie's case, that would be a file to load). The suggested way to do this in the Adelie documentation is to list both Adelie and the file as arguments for the uxn emulator (uxnemu adelie.rom slides.txt). However, uxn32 ignores all arguments in the command uxn32.exe adelie.rom slides.txt and just runs the loader.rom if present, or otherwise just presents a blank screen.
Yeah. This is because parsing commandline arguments while supporting Windows 95 and Windows 98 requires a ton of code that has to be copied and pasted from some other project. On Windows NT (2000, XP, etc.) you can use some OS-supplied procedures to do it. Even though I don't advertise it, Uxn32 works on Windows 95 and 98. So if I want to add commandline argument handling, I will have to drop support Windows 95 and 98. I'm considering doing it, because I think the commandline arguments are more useful.
Also, for anyone reading this and wondering "why does command line arguments even require parsing?" it's because on Windows, which is not designed around command line use, all arguments to a process are passed as a single string with a very delicate and weird quotation escaping format.
Would it be possible at least to add a menu item/dialog box for adding commandline arguments to the image/ROM the loader is loading?
That's not what I meant, but it looks like there's a workaround: According to Devine themself, the commandline arguments are just loaded in as the first line of the console. This means that, because of what looks to be a different bug* in Uxn32, with Adelie you can just enter the filename in the console and press return and it will work.
* The bug in question is that the program doesn't terminate when a non-null byte is written to .system/state (device 0x0f), which it's supposed to. By not doing this, it means that adelie keeps reading from (and writing the same error-message to) the console despite the error and thus will continue once the filename has been entered. Since this bug is only coincidentally making the workaround possible, I suggest not relying on it though.
Ah, that's a pretty funny workaround.
I'm not sure if the .system/state thing in Uxn32 is a bug. Uxn32 doesn't implement the same debugging facilities as the SDL2 Uxn emulator. I think Uxn32 had Beetbug already by the time that .system/state 0x0f abort/print-stuff-to-stderr thing was added to the SDL2 Uxn emulator, and it was mostly used for debugging, not terminating the application as a matter of course. So, I didn't see a reason to implement it in Uxn32.
Writing nonzero to port #0f should terminate the program (on systems where this is possible, which includes all systems that Uxn32 will work ok); that is the official specification.
(I don't like the name .system/state and think that it should be called quit, but it does not matter what it is called.)
(The #0e port is used for debugging, not #0f. It should not be a problem to ignore the #0e port, if you do not want to implement it.)
@dheadshot I've added support for command line arguments. Here's a preview build: https://github.com/randrew/uxn32/releases/tag/1.9a1 Could you give it a try for me and let me know if it works for you OK?