No, it doesn't print anything on the console.

No, it doesn't print anything on the console.

Hm Windows is odd, really odd piece of beast ... Some kind of odd output buffering it uses according to some google searches by me. Please be so kind to do again now with the same URL as I've posted in my previous post (I've put some windows specific output buffering settings now, suggested by some MSDN resources ...). Also please try this: xep128-entermice.exe -h

So it prints the help (note, xep128 uses the standard UNIX notion for options ie minus sign, not the CP/M inherited then DOS then Windows / stuff) or not, also that it prints anything in case of "normal" emulation start, without command line parameters. Thanks a lot in advance.

Still no help string nor text. Sorry.

Windows is very odd, again, no wonder why I don't want to use it Ok, thanks for the tests, I will ask a Windows programmer I guess

If it has been built as a GUI application (-mwindows with MinGW), then it does not print anything on the console, that is a normal "feature" of Windows. On the other hand, when compiled and linked as a console application (by removing -mwindows), it will always create a console window when run, which can be annoying. If a Windows GUI application is run with Wine, then the console output is not lost.

Yes, thanks, I've just tried to get some information ... It seems a GUI application can "mimic" stdio with freopen("CONOUT$", "w", stdout); though it's not a true one, as it cannot be piped etc, and can only be seen if app was started from a cmd window. At the other hand, it seems there is some kind of AttachConsole() and AllocConsole() stuff where you can manually "play the game" to create console, forward stdio there etc. Confusing for me, enough ...

The only difference is, when I type the option "/h" or "/?", a little window opens warning about the use of "-" instead of "/". Nothing more, sorry. Still no help text nor debug messages.

Only two details I have  noticed: when XEP opens its window there is a little blink, a window of  the same dimensions opens, then immediately it is closed but then the definitive XEP window appears.

About your little warning window, there are two in reality, I have to click two times the OK rectangle in it. If I move it to other zone of the screen and click on the OK rectangle, the second little window appears on the original place waiting me to click OK again.


EDIT: The immediate mode has the same blink.

The only difference is, when I type the option "/h" or "/?", a little window opens warning about the use of "-" instead of "/".

I did that because you mentioned that you tried to your /? But you tried -? and -h as well (and from cmd/console window, not in "Run ...", by typing there xep.....exe -h), and still no content? Very odd. I asked some windows experts and I tried to use native windows console management functions to attach to parent's console if exists (so if you start xep128 from a cmd window already) or create a new console if it's not the case. It seems somehow I would have had Windows to test myself otherwise this topic will be looooong and boring to ask you every time to test

Nothing more, sorry. Still no help text nor debug messages.

No debug messages, that's OK, now only help should have be seen (I only tried that for now!). But it's possible the console is there just disappears because end of the program? It may be even that blink you talked about! The odd thing that you started xep128.exe with -h option from a cmd window, it should attach that console and print there, instead of creating a new console ...

Windows is really ugly btw, its API too brrrrr ... It's a great thing that I don't need to interact with too many native Windows things thanks to SDL ... It seems Windows has some braindead policy to make a strict difference between "console" and "GUI" mode apps. And GUI mode apps does not have console, and extra tricks needed if you still need it ...

About your little warning window, there are two in reality, I have to click two times the OK rectangle in it. If I move it to other zone of the screen and click on the OK rectangle, the second little window appears on the original place waiting me to click OK again.

Hmm, that's "normal"l, though a bug of mine It's because the windows console attach function (which does not seem to work anyway ...) put the warning at the begining, but again with the normal command line parser finds the same problem So two windows actually after each other, that's why you need to click twice, thanks for notice!

EDIT: The immediate mode has the same blink.

Immediate mode? What do you mean?

I have an idea. You can open a window to print debug text if it is set in the config, just like you print it to a file.

Well, there are multiple problems here. First, it does not seem even if I can open a console by will Second: if someone wants to use command line, he wants to see the help. But if help can't be seen only with a complex switch then it's a chicken and egg problem Now I only try to make help visible but even that does not work, since Windows treats Xep128 as a "GUI mode app" and does not want to provide console ... The debug messages are not so important, what you can see (well, would see ..) on console, that's even stored in debug file if requested, so that's not the main point. The main point is the visible help message *and* later some console based monitor for the emulator.

Some slavery remains between the little warning window and the console, because if I close the console while showing the warning window and then I click OK, another console is opened, but blocked, and I have to force it to close.


I hope this helps you...

At the other hand, I "fired my Raspberry pi up" and tried to compile Xep128 on it (with SDL 2.0.4 which has support). Guess what, without a single bit changed in the source it compiled and worked! However the CPU usage is about 80% and audio is not even enabled (I can't test now, only HDMI is connected to my monitor). The high CPU usage is not so much surprised with that ARM CPU I guess ... Xep128 does not even emulate EP too well eg no interlace only 25FPS screen refresh etc, I am afraid Raspberry PI is just too slow for a decent emulation At least on the model 1 B+ ... I guess it would run better on later models, especially with the new model 3 ... But it's also true that still it's "real-time" just at the edge of the hardware performance ... and no optimization is done for the given CPU ...