Tux

Thanks ! Yeah this pkgbuild system is very reliable ! That's what they use in mingw32 and mingw64 too (the pacman tool to handle all the windows packages).

There was really no need for a video here. I am sure I tested this once and it worked, but I moved the test and it got corrupted where I moved it, and since I never use this mouse wheel, I never noticed ! Sorry, my bad. It's an easy fix at least (2 lines). If you want some more technical detail : it's because sdl2 uses a strange struct for its event where all the parts are not defined at the same time but only when a specific event occured. Here the data of the mouse wheel was overwritten by the data of a mouse's button test... ! It's a test that didn't test the mousewheel event because previously there was no need, the mouse wheel was a mouse button event... ! Anyway it's fixed. Nope, not here. But from your screenshot, it's because of the insanely long path name you have, and the default small size of the window. Now maybe I should choose fullscreen as the default setting since the fullscreen is now reliable even in windows... Here it's the old default safe setting : a 640x480 window to be sure everyone can display it... Now maybe the size of this path isn't taken enough to choose the font's size, but I am not sure anyway it could display all this length in a 640x480 window. Try a fullscreen and talk again... Already told, already replied, for now it's almost never used, I defy you to tell me in which game it's used for now, since you can't answer don't bother and leave this option alone. I have some plan for it, but it will take time. I am sorry I don't see it neither. Already discussed, you didn't reply what I posted last time... ! Tss, it's just that the minimum allowed font size is now 10 points. It doesn't change anything for people who keep their config from one version to another, which should be your case normally. Same comment as up there : Raine can't do any magic, it can't display things properly if it doesn't have enough room for that. Go to fullscreen it will make things easier. This title is way too long anyway, but I chose to keep the original here, if you want I can put "kof98" instead, this way you won't complain ! Yeah it's generic, it's the inputs for "2 players 6 buttons" configuration which was changed (for cps2). I didn't try to test all the games, but you found something very specific here, it's rare to see a behavior like that on an unmapped input. edit : on 2nd thought I added some code to cope with these too long titles for the display area, I hate dealing with this stuff, but it will make things easier later so it's a bad for a future good... ! You'll be able to test that again in 640x480 and it should work. No magic here, it cuts the strings in this case.

I'd say the video driver is the main cause here, but you might want to visit this page to update your xp as much as possible, it won't hurt : https://retrosystemsrevival.blogspot.com/2019/12/unofficial-cumulative-windows-xp-update.html

Yeah and I am always happy to keep as much compatibility as possible, but it's an extreme case here since I can't even test it... I can test the dos version, it works fine in doxbox and even better in dosemu, but no 3d in xp anymore for me ! And mer-curious for info, you don't even need a specific distribution for old hardware in linux, the kernel by default supports almost anything. They removed some old code about the 386 lately because nobody could maintain it anymore and it was making things unnecessary complex, so you might have problems if you try to make it run on anything less powerful than a pentium (but I think a pentium is the absolute minimum for linux on my side, unless you are doing something very specific, like a text mode only terminal). After that you just need to be reasonable and not try to install the latest 3d desktop with all the fancy effects, and choose something small and fast instead, but you are free to try anything !

So you say you are the 1st one to be able to run this correctly in xp ? Congratulations then ! (on my side there's nothing I can do, I can't even reinstall virtualbox-6.0.x, it's incompatible with current kernels in linux, I could try to install it in windows, but I am not that motivated, it would require to move also the xp image, too much trouble). Good news anyway !

It's mainly something to fix the little problems of 0.92... The dlls change again to address the incompatibility with xp of the previous set in 32 bits (there seems to be other problems with xp related to the 3d, but at least it's not a stupid message from microsoft to tell you are not allowed to run this in xp anymore !), and it's changed too for the 64 bits version because it allows me to make both versions the same way, + it's almost half the size of the previous archive. The only dlls packages listed in the download page are the ones required for the latest version, so just update and it should be ok. Except that, mostly fixes for 0.92 as I said. The key codes change again, we switch to all scancodes to be able to have default keys which don't change with each international mapping, but you have nothing to do here, it will overwrite all the keyboard configuration if it reads an config file from the previous versions. The joysticks use some saner defaults too but for them I didn't overwrite the config sections in case you have something fixed on your side which is different from the default. The famous bug found by mer-curious which prevented special moves from the right side in msh is fixed, and there was again a problem with merged inputs which should be fixed for good this time. Also you have the option of integer scaling in opengl. I tested it, and I am not convinced, there's no real improvement in the scaled image for me, but I left the option, you can test it and report in the forum. (The option is in "renderer options" for opengl). Also sdl is updated to 2.0.18, actually they mostly add new functions, it's very different from sdl-1.2 which was frozen in time, for now I don't use them, but updated anyway... http://raine.1emulation.com/download/latest.html

Nope, you misunderstood, now that this 64 version is made using pure C everywhere, nothing forbids to use this code in 32 bits, gaining an absolute portability. I don't do it for the pcs, because I like my asm, it was a lot of hard work after all, even if it creates problems sometimes (use of VirtualProtect in windows to allow self modifying code to work without crashing !), but it's easy to do.... !

Yes, said on the topic for raine 0.92, it's now possible. But you are wrong, the 32 bits version is still full of asm everywhere, video functions, cpu cores, plus small pieces of asm everywhere, but the 64 bits version had to do without this, so it's not the sdl2 version which made it portable, it's the 64 bits version. But sdl2 is more widely ported, and it's probably easier to make an android version with it. If someone wants to try that, he's welcome to, I'll eventually try that one day but I am not in a hurry for that (I don't think an android device is the ideal console for arcade games, lacks real controls, you would need at least some kind of real joystick, the virtual ones would probably lack too much precision for most games).

Easy : it's an UNINITIALIZED input, the previous game just initialized it... ! No no, I won't include different default inputs based on how many buttons are used. The current idea can be used for any game with up to 6 buttons, seems good enough. If someone wants something different, customize default inputs or switch to custom inputs is enough...

And finally found after a long search ! It was one of these bits from the input ports which looked like they were unused, so usually I don't even bother to tell they are unused since we have all the controls mapped in the test mode. Well there was no input directly linked to this one, but if it became active, it prevented this special move from the right side!!! I don't know exactly which bit did that by the way, because I cleaned up quite a few of them, but it can be found for someone interested... maybe there was a reason for that, something which was connected to test special moves ? The big surprise is that it happened for you in windows and for me in linux, everyone could do it. It was just an uninitialized input, and its bit turned active which should have had no effect normally, but it had this very weird effect. It's a good lesson for me, next time something so weird happens, I'll start by double checking the input ports... ! While looking into this I had a closer look at how the rasters work in cps2, and they are probably easier to emulate than the neogeo ones finally... just an impression, but anyway I am not sure I want to dive into this now. Anyway good thing to finally have fixed this !

You can try if you want, it still accepts the same old command line. I suggest to install mingw32 not to become crazy with the command line in windows, but it's manageable even with cmd. You don't even have to put a rom in the roms directory, it will try to download it if it can't find it, but without any working gui, it's going to be very hard to use it ! Something like "raine32 bublbobl" should give some result... if you are lucky ! I can't test at all this xp version here, or I'll have to install an old version of virtualbox for that, with the current version all I get is a completely white window which closes after a few seconds (no 3d support at all for xp currently, it was removed from virtualbox). Yeah the only output with sdl2 is 3d, either opengl or direct3d, and for now it's opengl for everyone. Yeah I know it can be surprising for a 2d emulator, but since these days everything is 3d and these cards have a tremendous power, it's possible to use them even for 2d, and use them well ! Also for info there is very good support in linux for the old hardware, contrary to what there is in windows. It takes a while to get used to it, but it will work much better than what you have here in the end !

As I said it was worth a try, but it's probably too old the 3d tricks inside, there is not much to do here, sorry !

no cps1 & cps2 share the same driver there are very little differences between the 2 actually... Ok, I could reproduce the problem even if I can't do it 100% of the time on the left, I am also at 0% on the right, which is very puzzling ! No idea for now... What I did to test that : a 2 player game with shuma gorath against himself, so I switch the gamepad to test 1 or another, and I have the cheat "infinite timer" if I need more time... And very strangely at a time every tlme I loaded my savegame the left shuma did this famous move as soon as it was loaded when I am sure I did the savegame with nobody moving ! I overwrote the save in frustration, but maybe I should have kept it to understand what happens here... (actually it was not in frustration, it was because for some reason the change in commands had made that one of the joystick buttons was also a button to create a new savegame... ! Normally there is no joystick button mapped there, so no idea how it happened to be here, but my save was destroyed anyway!) something very strange for sure, but it's not easy to track these special moves ! It's not the speed hack neither...

Alright finally taking a serious look at your sonic boom mer-curious... Just for info there is no "sonic boom" in the moves in the command.dat, bad start... ! And even on the right side I have some trouble to do it, it worked well previously, then I reloaded and can't redo it ! Oh well, I can already tell it's no buffer overflow, investigating the speed hack but I'll have to stop for now, more later... For the keyboard sorry, the whole key sections will be reset again in the next version : I switch all key codes to scancodes, that's because your idea of using qsd as default buttons changes with international mappings. To avoid that we need the scancodes. Which changes all the key codes again !

For the keyboard, sorry this version has a bug which makes remapping keys almost impossible, that's what happens with work-in-progress version, specially now. Default mappings might work though.

Yeah good idea. The latest binary shows in the about dialog "compiled on nov 29 2021, 23:01:59", and in "renderer options" you can enable/disable the integer scaling for opengl, it's disabled for default. And I just checked that the picture is scaled to the maximum possible ratio if it's disabled. If it's the latest binary, with opengl rendering and this integer scaling disabled and your picture is still cropped, I suggest you throw the computer to a deep trash somewhere !

For the picture it's normal, it's the integer scaling in action, redownload the latest binary as I said, the one from 23:44, and it should fix that. For the menus there is probably a bug lurking somewhere, related to the length of your path here, I'll check that later. For the controls I am not sure there's something to do... Testing this version on other os, I tried it quickly in my win10, but didn't try any joystick, but there's probably no problem here... It was an interesting experience to try to make this work on xp anyway ! And it's good to have some smaller dlls again anyway !

You have better luck than me on my vm, Oracle removed the 3d support for xp, so my xp image is suddenly a lot less interesting... ! No idea for the controls... ! It might be something else lacking in xp, or not that stable, not sure for that. For now the controls are totally broken if recompiling for sdl-1.2, I tried that earlier, there might be a way to improve this, but it would be crazy to make an xp specific binary... I re-uploaded a binary at 23:44 because I had left the testing of integer scaling enabled in the previous one, which made the picture a little special... Retest this binary on the one with the font problem, if it doesn't work at least you saw it working in xp !

Ok, I built a new binary without this stupid dependence The others can test this if they want too, it's an updated binary with a few fixes, and the dlls are smaller since they are no longer the precompiled ones from mingw32. dlls : http://raine.1emulation.com/archive/dlls32-0.92x.7z binary : http://raine.1emulation.com/archive/raine32-0.92x.7z What was running the computer with your font problem by the way ? You might want to test that on it too...

Good info indeed, that's some incompatibility added by microsoft for no good reason except another way to push people to update... I would say win7 was quite good, there's no good reason not to update xp to win7, except if it's a very old machine with nothing inside. In this case, it's probably a bad idea to use this sdl2 version, remember it relies heavily on some good 3d acceleration, not sure you would get that in your xp... Anyway I'll take a look to see if I can remove this stupid dependency (that's not from raine, it's from one of the dlls, the function is probably not even used anywhere). The dll in question in libwinpthread-1.dll, a kind of system dll, hard to do without it... ! The irony is that for this version I decided to use mingw system to build the windows exes instead of my usual cross compilation, thinking it would increase compatibility... apparently it's the opposite ! Well in this case I'll try to cross compile sdl2 to test, but no promise it will work...

I don't see why, but I should be able to test that in a virtual machine... I think opengl works in xp virtual machines... I won't test that now though...

In options ! Very hard to find ! "Min font size" and colors, then bg color. The game selection dialog has always had a transparent bg ! You sure it's not some kind of shader ? There is nothing relating to filtering in the cps2 driver anyway, sure about that, the drivers are totally separated from the core in raine, that's why I could change the lib it relies on twice already... The only filtering options are in video options / renderer options filtering is the last option of the dialog, linear creates this smoothing a little fuzzy effect, and nearest makes the pixels more visible. By the way I tested this "anisotropic" filtering, a failure, it doesn't seem to change anything for the 2d rendering I am using. What would be interesting to try eventually is an integer scaling multiplier. Previously it was used only in the normal blits, but since there are no more normal blits, it could be interesting to try to render the same way. I'll try to add something like that, at least to see how it turns out... So what you say is that your filtering is on nearest usually, and it changes to linear when you load a cps2 game ?!!! It would mean a rather massive buffer overflow somewhere, unlikely at this point, but... I am quite frustrated for now, I can't use the lib I usually use to detect these buffer overflows, totally incompatible with opengl, I'll have to make some tests with eventually the old version with sdl-1.2... You are crazy ! Or there is some kind of buffer overflow somewhere... but don't hope too much about that, it's rather unlikely, but I'll try to check anyway... Yeah the standard mapping asd which is used by almost any game to move in 3d these days, and 3 keys below that for the other 3 buttons. Not a bad idea, it's better than the vbn which was in the middle of the keyboard, and you can use the 3 buttons config as well as the 6 one. Ok, will give it a try... ! As for the keyboard, I didn't map buttons 4, 5, 6, I decided if someone needed them he would customize them ! But ok, I'll try to make something saner, but 6 buttons configurations are not ideal with these pads, I guess you are forced to use the left and right "shoulder" buttons for the 2 last buttons then... Yeah I know this one, but I couldn't reproduce it enough to fix it for good, it's on my wanted list... !

Well nothing interesting in your logs, but it's not the usual kind of problem neither. It's probably something very stupid. I can confirm that on my side if I rename the font to something else it prints it can't find it in stdout and uses the raster font instead, it's not the case for you apparently. And you have the same problem in 32 & 64 bits ! No idea, I would need someone who knows how to use a debugger for that, or at least a way to reproduce this without renaming the font to something else, without that I can't do miracles, I'd say just forget it, you just won't be able to use it that's all ! Yeah I just tested the 64 bits version in a blank new directory by downloading dlls64-0.92, then raine64, extracting all this in the same directory -> no problem. I can't do anything more here.

I remember seeing something like that while testing stuff with fonts and the normal truetype font could not be loaded. Normally it should be able to use a raster font when it happens, but it was broken, and I didn't try to fix it since everybody is supposed to have this tt font... But with a "blank" installation, it shouldn't happen. Try to run from a command line, redirecting output to a file : raine > log and look into the log to see if there is something interesting... Anything special, it's some usual windows ? EDIT : yeah I confirm I can reproduce the 2nd picture by renaming the Vera.ttf file to Vera.ttf0, but no idea where the 1st on 2 columns comes from... !

Not so fast for me, it was long, but yeah it was time to slow down and to get some feed back... missed it ok... You can also lower the transparency for the background color, or increase the min font size (I should increase the default value here). I have an idea of another presentation for the game selection dialog, but I didn't want to do it now, I wanted a 1st release as fast as possible, and it was long enough... How did you learn to identify "bi-linear filtering" ? And where do you see it exactly, behind the main menu or after that using play ? It was supposed to be alt+return, something went wrong in the encoding of default keys, I'll have a look... I think it's more probably a timing issue, there is no way an emulator would change how the inputs are from the left side or the right side... I didn't map everything, just started with button 1 on ctrl, then mapped some buttons where it seemed logical. Stopped around caps lock which I used as a test. v, b, n were really not convenient as default button inputs, but you can't map 6 buttons starting on ctrl clearly. The current mapping is fine for 3 buttons configs or less. I am open for suggestions here... ?! What's wrong with that ? I mean if you don't want to use the dpad, just don't use it. Did you use for something else ? As it is now you can't remap it anyway. I'll need more details on that one. I didn't test the analog inputs, they should be redone differently anyway. I don't see if you noticed, but the window handling changed a little too, it should keep the size and position of the window better, even quiting the emulator in fullscreen, in sdl-1.2 you had to use a hack for the window postion and it was done only for windows, now there is a real function for that and it's done for everyone... Thanks for the quite lengthy report already anyway ! I have noticed another problem with the merged inputs, in popbounc again, I am on it, but more slowly... ! EDIT : ok, fixed the mousewheel, it has a separate event now to be able to handle horizontal scroll wheels... ! I just ignore that, I only handle the vertical one, avoiding all the fancy stuff. By the way the reason I didn't notice that is that I don't use the mouse wheel and almost never use the mouse in raine, it's really more efficient to use it with the keyboard, just type the 1st characters of a game to go to it in the game selection dialog, and the 1st characters of any menu item anywhere in the interface, blazingly fast... ! That's also why I use the english version of the gui (too many menu items start with the same letters in french !) and why the menu item to change controls in english is called "inputs" and not "controls" ! Also fixed the modifiers for the emulator keys, and at the same time the handling of scancodes - the keys which don't have a symbol and just a scancode, the left gui or windows key is in this case but since it opens the windows menu by default it's harder to use !). If you want to have the right default keys for the emulators you'll have to delete the section in your config file or restart with a new one. The number of keys with only a symbol has been dramatically reduced in sdl2, the gui keys, the menu one on the right if you have it, + the multimedia keys, but everything standard has a symbol (a sym code) now. And fixed again the problem about merged inputs for popbounc, is it the last time ? Actually this thing was a trap from mame, that's something I wouldn't have used in the inputs because too many possibilities of errors, but they used that in mame in their inputs and since I imported quite a few definitions from them, I thought it was a good idea at the time, without thinking too much about it... ! Oh well, now I think I have rounded it quite well, but it took me some time for sure, it looks innocent, but it's more complex than what it seems... ! And in the end, it's not a bad idea, just a dangerous one !