Tux

No, there's no good reason to re-add it. The main reason why most games prefer desktop fullscreen games is probably because there are less issues when alt-tabing out of the game and you can have some windows visible on top of the game screen without issue, which is impossible with the real fullscreen, it's totally exclusive and it can have sync issues sometimes. The desktop fullscreen is the modern way to do that, the real fullscreen was the old way. Glad to see it's finally fixed, it was the most annoying series of bugs to fix, especially when you think that it was not even related to real emulation ! Most of the fixes are short, it's not complex code, but you just need to guess what needs to be done, there are more comments in the code and in the git log about all that.

Alright fixed normally, and finally it was not a dll problem, just the usual kind of bug you get when you mess too much with windows statuses, and it could happen in linux too (the small screen in fullscreen). Test when you can the good news is the new dll is not needed anymore, you can delete it if you still have it, it's a return to the normal build process from linux ! http://raine.1emulation.com/archive/tux/raine.7z

Yeah it's the quarter picture I got because of the dll problem, I guess I didn't get the right one then... I'll see that later. But all this mess is a windows non sense, I just loose time here, had to reboot an incredible number of times while testing things since I couldn't reproduce the bug in linux and windows didn't have any decent dev tools installation yet. What a waste... Did I mention I really hate windows now ? Anyway since I got this thing working here it's probably a detail to pinpoint so I'll finish this.

Ok, did a minimal fix, you can test it at the usual place : http://raine.1emulation.com/archive/tux/raine.7z This forced me to reinstall the dev tools in windows, which showed me that the compilation of the 32 bits version was broken in mingw32, so nobody did that clearly ! Actually I had never reinstalled these after upgrading my windows disk which is now a ssd about 1 year ago or so. Anyway the fix is at 2 levels, it forces the desktop size to the video mode size instead of looking at the usable area, but except that I got a stupid game screen in the lower left part of the screen when I was in fullscreen, only for the 64 bits version, so it forced me to make the binary in mingw32 and not in linux as usual, there is clearly some dll problem, probably specific to windows 10/11 somewhere. So this archive is bigger, it includes a new libcrypto-3.dll which was not required before. Also since the bug is saved in the config file, the fix can work only if raine is not started in fullscreen with a broken config file, if it's the case you need to return to some windowed mode and switch again to fullscreen, or delete your config file. It seems to work for me, I guess I'll have to make something more official after that mess... Problem is that it probably breaks compatibility with old windows version for good this time. It's not my fault, it's the way windows is made, they willingly make things harder and harder to stay compatible with old versions. edit : and uploaded a new dlls64-0.96.7z with an updated SDL2.dll, 0.28 was becoming quite old. This should still be compatible with all 0.96 versions, and the libcrypto-3.dll is only in this raine.7z package for now.

Ok, it happens, windows only of course I would have spotted this long ago in linux, it's not so old it started around 0.96.10, because of the windows tricks which was probably the worst idea I ever had ! It's even worst that what you say because once the video is broken this way, it's saved in your config file and you'll find the same broken video next time you launch raine. It's easy to fix manually though, it's just screen_y in the config file which gets a bad value, just put your real screen height here and it will work, at least until you return to the windowed mode before switching again to fullscreen this way. It's not easy to fix because this has become an intricate mix of craziness to work around the strange behavior of windows, my 1st attempt to fix it triggered an even worse bug. So for now either switch back to 0.96.9 or before, use the keyboard, or switch to linux ! For info the size of the black border on top is exactly the height of the title bar for a maximized window, it's a windows bug you see here, it doesn't happen when using the same binary in wine in linux. I am tempted to remove all this windows craziness, but even that has become complicated for now, so for now it will just remain as it is for now, I might return to it later, I already lost way too much time on that.

As I already replied a million times (it feels like a million times at least), I will keep this short : not here. So remember this clause which tells that free programs are given without warranty even though they are supposed to work the same way everywhere ? You are in the 0.1% cases where it doesn't work the same way, absolutely no idea why, sorry for your case, but obviously I don't have that and no idea how you can have it since as I already told, using the gui or alt-return calls exactly the same code ! So, sorry for your niche case, I'd advice you to use the keyboard in this case even if it doesn't seem to make much senses. If you ever find out why you have such a curious behavior, post again, otherwise you can stop, it's useless.

You're becoming dumber and dumber here... ! Of course there is a black border on top OR on the sides, re-read what I have told for ages this is the normal behavior !!! When the game screen is scaled the same ratio is applied to the horizontal part and the vertical part, since the ratio of our modern screens don't match what they had for these games most of the time you get a black border somewhere, but it's done to fill at least vertically or horizontally the screen so you can't have both at the same time. There are options in the renderer option to play with this but if you want to keep the original screen ratio you shouldn't touch them. Of course the ctrl-s can't work correctly when the resolution is displayed, this is a debug feature, it's displayed just before the frame is drawn, you could have guessed that ! And finally for your video : bad choice of a game : if you play it in a window, you'll notice the top part of the screen remains black during the demo, it's a game which plays with borders on top and on bottom, I guess it's to look like a movie, take a game like bublbobl which is a real 4:3 game. You even saw the prompt telling you the coordinates of your game screen : 63x0, meaning 0 pixels from top and still you could see a black border on top, that's because the game displays it that's all ! And all these posts for nothing then... ! At least I hope you have understood now... ! I think you can delete the build which displays the game screen coordinates it shouldn't be useful after that.

Shortest reply ever : no (for everything) And I wouldn't have seen these black borders in all that time ? Tsss !!! Ridiculous ! I had fun with my own capture tool, obs because the windows bar is allergic to opengl programs clearly, it's a 16:10 screen, 1680x1050 so you don't get the same ratio as on yours, but you don't get any fucking black border (at least not on the right and on the left) : https://mega.nz/file/XUdCXQYQ#HWL-VxqTM1OGbnosgtW_XCVi4He7mT00rHfmX7yE4UQ and finally a last build which will display numbers for you each time it calls the function to resize the game screen, it will tell you the resolution (of the window, or the screen if you are in fullscreen), and then x, y, w, h of the game screen. Don't use that as your main raine binary because it's probably annoying to get this message box all the time ! This way you can post just screenshots, if you have a software black border then you should see x > 0 and y > 0 from this function, if one of them is at 0 then everything works normally. Still the same link : http://raine.1emulation.com/archive/tux/raine.7z

Maybe it's just a sync problem when you choose the real fullscreen mode, normally these modes have nothing special for sync, but except that... But anyway knights is a 16:9 game, 384x224 it's 1.71 16:9 being 1.78), but I guess you took care not to use real fullscreen modes here again didn't you ? Anyway if the scaling parameters are normal it tries to apply the same scaling value to w and h so that at least one dimension takes the whole screen. For knights it's normally the horizontal screen which is full, there is a very thin black border on the top. That's why it's impossible to get a black border around the whole picture here, it's either w or h which is maximized. Unless your super windoze chose a video mode with some sync problem which forces black borders, use desktop fullscreen only, it uses the same sync as the desktop so there should be no black borders, and I really don't understand how you could miss that you were using real fullscreen modes, if you want to do it from windowed mode you have to choose left in the gui... anyway removed soon if I make another binary one day. (or you have something which reports a wrong resolution, I never heard of that). For the gui screenshot I might be able to add some code to be able to take a screenshot from raine (I guess just make the same keyboard shortcut to work from the gui), but you can't do much for the way windows does things here. And the reason I disabled maximized -> fullscreen is because it becomes almost impossible to restore the window for maximized state in windows, so it's still the case. And for the print screen key not working, it might be microsoft's way to try to discourage the use of opengl programs in favor of direct3d, except that it's stupid since if you want to be able to run your program on something else than windows, direct3d is not an option ! edit : another "confidential" binary for you to play with, it recognizes the 1st 2 emulator keyboard controls from any gui dialog, the 1st being screenshot, and the 2nd switch to fullscreen. Which means that poor windows users who can't take a screenshot using the print screen key will now be able to use the standard raine key for that at least ! And you'll be able to switch to/from fullscreen using your chosen key, alt-return by default. By the way real fullscreen is removed. By the way the code to take a screenshot from the gui is shamelessly copied from the old dos allegro version with minimal modifications : png instead of pcx, and calls ogl_save_png in the end to save the picture (same thing as the game drivers). Contrary to the allegro version, you'll get a message box telling you the filename of the screenshot when it's done. The link is still the same : http://raine.1emulation.com/archive/tux/raine.7z

Sigh, as I already said, I don't get your black borders in dino ! For info the code to toggle fullscreen from the gui and from keyboard is exactly the same, it's not twice the same code, it's really the same code called from 2 places, and fullscreen from the keyboard is always desktop fullscreen, so I don't know how you got a fullscreen with black borders and 1 without, I can't do it, even in windows. For info here it's always without borders. Now it took me a while to understand how you could get this maximized window in the middle of the screen while exiting fullscreen from the gui : it's because you used the REAL fullscreen, 1 I should have removed completely since all the game these days use desktop fullscreen anyway, and when you see the insanity in windows you understand why !). So this part I can fix again, it's again some windows insanity : yesterday I just avoided to send 2 commands to place the window and scale it when exiting normal fullscreen in windows. Well if you don't send these 2 commands when exiting REAL fullscreen then you get this maximized window in the middle of the screen ! It doesn't make any sense, I know, this is microsoft's world... ! So I made a workaround by having a variable to keep the previous value of the fullscreen state to decide if I send these 2 commands or not. I made this fix, but it's probably better to remove this real fullscreen mode completely and just don't use it, so far there is no good reason to keep it. For your print screen game, I don't play this kind of game, print screen is the window way to take a screenshot, if it doesn't work in windows I can't do much about it. The raine's key to take a screenshot is ctrl-S by default but it doesn't work from the gui. The print screen key is not broken for me actually in windows, it did its job correctly last time I tried it, but I am not going to reboot again just to test with dino during its demo mode (typing this mail in linux yeah). I updated the raine.7z file, get it from the previous link. edit : I also have the print screen problem, it doesn't seem to like the gui fullscreen mode, oh well... ! a side note about the gui screenshots not working : in the old allegro version and even the sdl1 version, the gui was rendered to a bitmap, and then the bitmap just displayed on screen, so it was very easy to save a screenshot of it. With sdl2, it's totally different, the game screen is rendered to a special streaming texture which is updated for each frame, and the gui is just drawn on top of it. So there is no single bitmap to get the picture from, that's why I didn't bother to make the screenshot function to work, since the ingame function works, it's enough. Anyway in linux (using windowmaker here, I didn't try any other window manager though), you can take the screenshot correctly in the same situation, but there's no insanity here like in windows ! Proof :

And an update on this too, I recently bought a new one, chose one recommended by tom's hardware : Nacon EVOL-X Really good compared to the piece of crap I had previously, you sense some resistance in the joysticks moves which is very nice (more precision and durability probably), and even in the cross. Really not comparable to what I had before. Worth mentioning : it's for the xbox one apparently, it requires that the pc sends some initialization command through usb otherwise the gamepad remains inert (and its power led is off). It's done automatically by windows since they push to have xbox controllers to become standard on pc, but it's not in the mainline linux kernel yet, so you have to use an alternate driver for this one, I got xone-dlundqvist-dkms-git from arch, works flawlessly with that.

The forum seems mostly broken, I can edit the previous message but not post the changes ! so here is the last part : edit2 : for the 1 there is a quick fix indeed, just don't try to position or scale the window when exiting fullscreen in windows. Now I didn't test this thoroughly, it just works in the case no config file -> fullscreen -> windowed mode. For the 2nd case, I don't have it, don't know what you did with your parameters, and I don't really want to know neither. Here is a very last build just to close this for good, and no I didn't experiment with automatic builds because it would be messy to build the 32 bit version probably, might be possible for the 64 bits version only but it takes time to check this. http://raine.1emulation.com/archive/tux/raine.7z (it replaces a previous raine.7z from 2022).

Yeah all this because they forgot a credential in an open server and it stayed there for years until this stupid group decided to use it... Millions of credentials stolen after that, what a mess... ! Anyway, I guess it should be fixed soon now. For switch emulation those interested kept the binaries already, and suyu is still maintained. I might take a look at your window problem later at least to check if it's so easy to fix, but I doubt it. edit : of course it doesn't happen in linux, at least not in window maker which I use. Now seeing why this stupid windoze broke things again will take more time, so maybe later !

Sorry for your bugs, I told you it was all a bad idea and I wanted to remove all this crap in the last version, you refused, too bad ! Now most people don't change the video mode often so I don't think there is a lot of people who has any problem with that except you ! And sorry but I don't plan to make any update on this front any time soon, although I committed some small change lately because I found a problem in galaxian when in debug mode, but only in debug mode ! For the git commit, it's just to avoid a warning, a single click or the press of the esc key should be enough, but I accepted the commit anyway, but you'll have to learn how to make your own version if you want a binary here, it's not complicated, you don't need to know how to write C code to compile it. Thanks for the retroroms.info info (!), I used it to check your patch works, I confirm it does. archive.org should be back to normal very soon now, it was already announced a few days ago, probably for this week then... Now I have read the hackers who did that were pretty crazy, it was to protest against the usa, archive.org is free, but they say it's American, so it's evil... ! I didn't think there was a big security hole in archive.org, but you don't always get this kind of rights because of a security hole... anyway they said they took their time to reinforce the security of archive.org so it will come back better than ever ! (sorry lost the link about all that, it was from slashdot). The latest part of this story : https://it.slashdot.org/story/24/10/20/1733227/internet-archive-users-start-receiving-email-from-some-random-guy-criticizing-unpatched-hole

Oh, let's keep it for the record then, in case someone with enough skills and curiosity wants to try it !