All Activity

Thanks again!! 👍

MAMEUI64 0.271.0 has been released. Available at https://messui.1emulation.com The software listed in \hash\more now number 45425, spread over 144 lists. Changes that didn't get into MAME: - Hitachi bml3, Amstrad cpc and clones, Fujitsu fm7 and clones: improved cassette motor handling - i8275: don't crash if double spaced rows requested - pecom32, pecom64: fixed cassette reading; fixed shift key interfering with tape loading; adjusted cpu speed; system can now run the items in the software list. - partner: fixed crash when floppy drive accessed - homelab: fixed buffer overrun in the quickload; homebrew games can now be run.

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.

WinArcadia 33.42 (Windows XP/Vista/7/8/10/11): 28 October 2024 DroidArcadia 3.1 (Android): 26 July 2024 AmiArcadia 33.42 (AmigaOS 3): 28 October 2024 AmiArcadia 33.42 (AmigaOS 4): 28 October 2024 AmiArcadia 33.4 (MorphOS): 8 October 2024 Super Bug Advance 1.3 (Game Boy Advance): 11 September 2009 AmiArcadia and WinArcadia are multi-emulators/assemblers/disassemblers of these machines: * Emerson Arcadia 2001 console family (Bandai, Emerson, Grandstand, Intervision, Leisure-Vision, Leonardo, MPT-03, Ormatu, Palladium, Poppy, Robdajet, Tele-Fever, Tempest, Tryom, Tunix, etc.) (c. 1982); * Interton VC 4000 console family (Acetronic, Cabel, Fountain, Hanimex, Interton, Prinztronic, Radofin, Rowtron, Soundic, Voltmace, Waddingtons, etc.) (c. 1978); * Elektor TV Games Computer (1979); * PIPBUG- and BINBUG-based machines (Electronics Australia 77up2 and 78up5, Signetics Adaptable Board Computer, Eurocard 2650, etc.) 1977-1978); * Signetics Instructor 50 trainer (1978); * Signetics TWIN minicomputer (1976); * Central Data 2650 microcomputer (1977); * PHUNSY microcomputer (c. 1980); * Ravensburger Selbstbaucomputer aka 2650 Minimal Computer trainer (1984); * Hofacker MIKIT 2650 trainer (1978); * Astro Wars, Galaxia, Laser Battle and Lazarian coin-ops by Zaccaria (1979-1981); * Malzak 1 and 2 coin-ops by Kitronix (c. 1981); * AY-3-8500/8550/8600-based Pong systems (Coleco Telstar Galaxy, Sheen TVG-201, etc.) (1976-1977); and * VTech Type-right machine (1985). Features include: ReAction GUI, load/save states, windowed and full- screen modes, CPU tracing, trainer, drag and drop support, graphics scaling, automatic load/save of configuration/game, keyboard/joystick/ gamepad/paddle/mouse/trackball/Vision-dapter support, autofire, turbo mode, gameplay recording/playback, sprite demultiplexing, help windows, source code, real-time debugger, frame skipping, redefinable keys, save screenshots (9 supported formats), REXX port, network play (IPv4 and IPv6), real-time monitor, locale support, game selection sidebar, text-to-speech, printer output, artefacting, support for ZIPped games, clipboard support, palette editor, tone retuning, high score management, force feedback, sprite editor, 3D, assembler, disassembler, CALM support, Scale2x/3x/4x and HQx filters, animation recording (5 supported formats), sound recording (8 supported formats), horizon dejittering, tape decks (4 supported formats), RetroAchievements support, printer emulation, floppy disk drive emulation, screen editor. The supported languages are currently English, Dutch, French, German, Greek, Italian, Polish, Russian and Spanish. Changes since V33.41: Summary: * Miscellaneous improvements and bug fixes. Details: wa: adjust sound subwin: adjusted gadget layout slightly. incorporated Samir's latest Italian translation. aa: quit confirmation subwin: localized keyboard shortcuts. twin: printer subwin: "save graphics as..." commands now preserve ribbon colours. coding guide, gaming guide: changed links to point to HTML version instead of ASCII version. selbst: fixed: window height was being miscalculated when "blanking areas?" toggle was on. selbst: added support for "Settings|VDU|Blinking cursor?" toggle. phunsy: fixed: when "blanking areas?" and "show LEDs?" toggles were both on, it was corrupting part of the display. wa: printer subwin: adjusted gadget layout slightly. fixed: wrong localized message was used when adding a conditional I/O watchpoint. http://amigan.1emu.net/releases/ http://amigan.yatho.com

Hello again Tux! I think you may have misunderstood my bug report about this issue. My complaint is not related to the black bezels eventually shown in the screen to fit the monitor's aspect ratio. The issue is that the bezels are being created only when we enable full-screen through the GUI. If we enable full-screen by Alt+Enter, the bezels don't show, which I think should be the normal behavior. That is, something in the GUI is producing extra bezels, something wrong is happening in the GUI that produces these extra bezels in the screen. This is the issue I have been experiencing and reporting through this thread in the recent posts, and this is what should be fixed in my opinion. I have asked you before to reproduce this issue and you said you were unable to do it, or perhaps you were unable to notice it? Anyway, I'll describe the procedure once more, this time as objectively as I can. Please pay very close attention to the details below: My setup: Windows, Raine 0.96.12a with no config file. Open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (no black bezels on top and no extra bezels on both sides): Open the program -> load the game -> go to the Video Options -> set full-screen mode to Yes -> hit Esc to return to main menu and Esc again to show the game picture. Resulting picture in full-screen (bezel created on top and extra bezels added on both sides): 1) Can you spot the difference in the picture? Pay very close attention to the bezel created on the top of the screen and the extra bezels created on both sides. 2) Why is this happening? Results with a 4:3 game (not really necessary to support my report but can help you to better notice it): Same procedure: open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (no black bezel on top and no extra bezels on both sides): Open the program -> load the game -> go to the Video Options -> set full-screen mode to Yes -> hit Esc to return to main menu and Esc again to show the game picture. Resulting picture in full-screen (bezel created on top and extra bezels added on both sides): 1) Can you spot the difference in the picture? Pay very close attention to the bezel created on the top of the screen and the extra bezels created on both sides. 2) Why is this happening? My setup: Windows, Debug Raine with no config file. Open the program -> load the game -> hit Enter in the "Reclip screen" prompt window -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (bezel created on bottom of the screen and extra bezels added on both sides): Now in full-screen hit Enter in the "Reclip screen" prompt window to make it go away. Resulting picture (bezel swapped from bottom of the screen to the top and extra bezels kept on both sides): Conclusion: Alt+Enter toggle method does not work in the debug build because this build has a prompt GUI window that shows when the program goes full-screen mode (the "Reclip screen" info), resulting in the production of the bezels. The "Reclip screen" prompt triggers the creation of a bezel either on top or bottom and extra bezels are added on both sides of the screen. Why is this happening? Your setup (based on the video capture you shared in the thread): Windows, Raine 0.96.12a with no config file. Open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode. Resulting picture in full-screen mode (expected results: no black bezel on top and no extra bezels on both sides): (Incoming picture...) Open the program -> load the game -> go to the Video Options -> set full-screen mode to Yes -> hit Esc to return to main menu and Esc again to show the game picture. Resulting picture in full-screen (bezel created on top; apparently no extra bezels added on both sides): So you do have the issue in your setup too apparently, you just didn't realize it. This is a guessing, but I can't prove it because your capture does not depict the game screen in full-screen mode using the first method (the Alt+Enter toggle). You need to follow my procedure in Windows (open the program -> load the game -> hit Esc to show the game picture -> hit Alt+Enter to switch to full-screen mode) and see if the screen will have a bezel added to the top or not (it should not, according to my testings). I would be very thankful if you could make this final effort in this issue and make this test using the first full-screen method in Windows. It would be extremely uncommon to have this issue only in my setups. It's not a major issue though, because it only happens in some situations (in a debug build or when enabling full-screen through the video options menu), but if you reproduce it you could finally understand what is causing it and possibly fix it. Thank you so much again for your time and attention. PS: 1) I have the same results in 3 monitors, one is 1600x900, the other is 1366x768 and finally one is 1920x1080 (a TV). They are all 16:9. I wish I had a 16:10 to test on it... 2) I don't know the technical terms for that, but perhaps something in the GUI should be triggering some kind of zoom effect and/or repositioning effect in the picture? This could be causing this "borders effect" to show...

* Qemu 9.1.1 [PC] - https://download.qemu.org/ * WinUAE 5.3.1 [Commodore Amiga] - https://www.winuae.net/download/ * Flycast 2.4 [Arcade] - https://github.com/flyinghead/flycast/releases * Denise 2.4 [Commodore Amiga/C64] - https://sourceforge.net/projects/deniseemu/files

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.

Hello Tux! Thanks a lot for your fast reply. I didn't understand your answer exactly. You mean that you are not going to re-add the real full-screen mode? Maybe not, because it only happens when you enable full-screen through the Video Options menu, and maybe only in Windows...? If you use Linux most of the time and set full-screen by using Alt+Enter, the chances to notice the thick borders would be very rare I guess... As for myself, I only stumbled upon this issue recently when trying to fix all the window manager bugs, which is a feature added recently... But I haven't tested old versions of Raine to check when this issue was introduced, or if it was always there... Yes, you don't have a thick border on the sides of the screen, but you do have one on the top, which I also have in here. Take a look: This is from your video capture. It would be necessary to compare this screen with another one using Alt+Enter in your setup to set full-screen mode. If my guesses are correct you should also have a game picture without this thick top border, which is also what happens to me here. Thank you for trying to troubleshoot this problem. I downloaded the test build and here is the screenshot for when I am in windowed mode: And here it is when I toggle full-screen in the Video Options: You see that the CTRL+S feature doesn't work correctly when this "Reclip screen" prompt is showing in full-screen. But from this screenshot we can also notice a thick border in the... bottom? That's why my guessing is that the GUI is interfering with something in the game screen, which would explain why the thick bezels only show when I toggle full-screen using the Video Options menu in the GUI. Anyway, I have captured a short video showing my testings with this most recent build, take a look: https://drive.google.com/file/d/1H_1XOFgp_C51VhbITHQS54_blXaIJKU-/ By the end of the video (around 1'20~1'24) you'll see that I enable full-screen mode using Alt+Enter, and curiously the thick borders will also show in this situation (!). If you pay attention the "Reclip screen" prompt also shows there, so I'm really suspicious that something in the GUI is causing the display to show these thick bezels when we go in the game screen... Hopefully you will unveil this mystery eventually... Thank you so much again for your time and work put into this issue.

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

Hello Tux! Thanks a lot for your fast reply and for providing another test build. Yes, I made sure I was using the full-screen (desktop) mode option in the Video Options menu when I took the screenshots. But the thick black bezels also happen with full-screen (real) mode, so I don't think the issue is related to the full-screen (real) mode at all... I suppose it is related to the GUI or Video Options menu because the thick bezels only show when enabling full-screen mode (either real or desktop) through the GUI. If you enable it by using Alt+Enter, the bezels are normal (as you see in the comparison screens provided in the previous replies). I've tried here your latest test build and unfortunately the thick borders are still an issue with this version. On the one hand this is bad because the problem is unresolved, on the other it is good because it reveals the full-screen (real) mode is OK, so maybe it could come back. It's a feature that is not very used by people who come here in the forum but it could have its use cases for someone at some context eventually... I have tried to reproduce this issue in my laptop too and it consistently happens there. In the laptop I have Windows 10 22H2 version and in my desktop 21H2 (the long-term support version). Both machines have Intel processors with Nvidia graphics chips, the laptop is from 10 years ago but the graphics drivers are from 2019 I guess; and my desktop has more recent parts and the graphics drivers are from 2023 (I don't play much PC games so I don't bother updating very often...). Anyway, if you really followed my instructions on how to reproduce the issue in Windows and you can't really have the thick borders there when enabling full-screen mode through the Video Options menu, then I may need someone else to confirm that the issue is not within my setups. I may send ffman1985 a message and see if he can test that. Meanwhile the solution is to just use Alt+Enter to avoid the thick bezels, but it would be good in the long-term to have the full-screen options in the Video Options menu working as good as the keyboard short-cut. If you need more details on how to produce this issue or to test new preview builds, I'll be very happy to help. Thank you for adding this feature. I tried it here with the latest test build and it's already working, take a look: Now I can take a screenshot in the GUI. By the way, I've noticed taking this screenshot that when we are showing the Video Options menu the game screen is shown correctly without the thick black borders. You can see in the screenshot above that there are no thick black bezels in the top, left and right of the screen, which should be the correct display of the picture and what happens when we enable full-screen through Alt+Enter. But if we enable it through the Video Options menu, then the thick bezels will strangely show... Anyway, hopefully you will reproduce this and figure it out eventually... Thank you so much again for your time and work. PS: here's a short capture I took to better illustrate the issue commented above: https://drive.google.com/file/d/1wPVP-ykHzIpzxOLCJ014Rx4_qqhjE5X5/

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

Hello Tux! Thank you again for providing a test build. I tested it here and I no longer have the broken scaled window after leaving full-screen mode from the GUI. I think I understood what you did. I was activating "full-screen mode (real)" and then leaving this mode, that's how I was producing the broken scaled window issue again. I tried it here with the first test build you provided and it's indeed fixed for "full-screen mode (desktop)" even if enabling and disabling through the GUI. So it seems all the issues with the window manager are finally gone in Windows? Now I was wondering if the forbidden function of "maximized window -> full-screen mode" could have also been fixed after these recent changes? If so, the function could be enabled again, no? Thank you for your testing. I'm surprised that you couldn't reproduce it there. Here it is very consistent and with every game I try, no matter if it is from CPS1, 2 or NeoGeo. Thick black bezels with CPS1 game Knights of the Round: Normal black bezel: Think black bezels with NeoGeo game Art of Fighting: Normal black bezel: It is more difficult to notice in NG games because the game is originally in 4:3, but you can still notice we have a black bezel produced in the top of the screen. I use here the ever most default options in Raine, I download the zip for the 64 bit version or Raine 0.96.12a, include the required DLLs and do what you see in the video captures (run the game, enable full-screen through the GUI, and then thick bezels appear in top, left and right of the screen). Maybe you forgot to enable full-screen mode from the GUI option in your testings...? Expect that, I don't know what could be causing this... I don't have the most recent Nvidia drivers installed, but this is not likely to be the cause I guess... Hopefully you'll reproduce it eventually as well as you have with the print-screen bug. Thank you so much for your testing and thorough explanation. PCXS2 is another emulator in which the print-screen key is broken. I don't know why they haven't fixed it yet since they have a few more contributors than Raine, but maybe it's something with SDL2...? I think it's nice to have this function working because pressing a dedicated key for that in the keyboard is much more intuitive than learning a screenshot keyboard shortcut for every program you have in the PC. But if it's too difficult to resolve it can be left for another time... Thank you so much again for your time working on these recent issues and for your attention in the forum.

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 :

Hello Tux! Thanks a lot for this fix and thanks for providing a preview build. I tested it here and it indeed fixed issue number 1! I understand, issue number 2 seems more complicated indeed. I can still reproduce it even with the preview build you provided above. Here is how I do it: in a new installation of Raine (without raine.cfg file), load a game and enable full-screen in the GUI. You should see thick black bezels around the screen, more noticeable in the top. See a comparison here: Full-screen mode through Alt+Enter (normal bezels): Full-screen mode through GUI option (thick bezels in top, left and right of the screen; bottom seems normal): Aside from that, I've noticed that if you leave full-screen mode through the GUI option the window will be uncentered again and the full-screen size will be preserved in windowed mode, see below: You can see all this happening live in this capture I've just made with the preview build: https://drive.google.com/file/d/1T4hwJhWrpnQ1BfjptXQX8ZEzQhU5cId3/ My guessing is that issue number 2 is related to the fact that the full-screen option in the GUI may work differently from the one with Alt+Enter, so the scaling fix that worked for exiting full-screen with Alt+Enter didn't work for exiting full-screen using the GUI option. Maybe this could help you figure it out once and for all...? By the way, I think I may have found a new issue in Raine: I was trying to capture screenshots using the print-screen key in Windows and noticed it is broken. I hit print-screen key to capture something and the result is totally different from what the screen is currently showing, take a look: Case 1: I hit print-screen key when Cadilacs and Dinossaurs was showing the 3-player demo in the stage, and this is what the capture shows: I entered full-screen mode using Alt+Enter here, and the capture showed the game logo, not the 3-player demo stage which I was displaying at the time I hit the key. Curiously this capture is also showing thick bezels in top, left and right of the screen, which happens when entering full-screen from the GUI option... Maybe those video issues could be possibly related...? Case 2: I hit print-screen key when Cadilacs and Dinossaurs was showing the 3-player demo in the stage, and this is the result of the capture: This time I entered full-screen mode using the GUI option, and I was also showing the 3-player mode stage demo. Instead I got this capture which is a mixture of GUI and game screen in a smaller resolution... Anyway, I'm not sure if you were already aware that the print-screen key was broken in Windows, so I decided to report it again since I came across the issue recently. I was trying to capture the difference in the bezels. I ended up playing the videos in a video player in full-screen and then finally using print-screen key to make the captures properly to show you the differences. I'm glad I could think of this solution. Thanks again for the preview build. I believe a build bot would be good for these cases in which you try a fix that needs testing. Even if it worked only for 64 bit versions, it could be useful in the future, especially if/when Raine starts receiving more contributions from different people in different moments. Thank you so much again for the work put into fixing those window issues. Hopefully this will improve the quality of life of the program. PS: I am willing to test another preview build if you need.

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 !

Hello Tux! Thanks for the fast reply! I think the window manager feature was a nice addition all in all and it is working fine, except for the two issues I reported in this thread. They are quite easy to reproduce in Windows, maybe not in Linux? But if you could try to program in Windows maybe it would be easier to fix them...? Now if it becomes something impossible to resolve then I also agree that they could be removed, even though this would mean discarding hours of work you put into it. Thanks for accepting the code in the project! No problem, I can wait for a next release. I was wondering if you have ever thought of a build bot for Raine... This is what most emulators do nowadays so users can experience the most recent changes in the code without waiting for an official versioning release. Yes, I was also surprised to see the site was down. I thought first it had something to do with Nintendo and their hunt for Switch emulators, but then it was apparently a hack attack as you said... Anyway, thank you again for your time and work.

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

Hello Tux! I've pulled a little request on Github to update Samurai Shodown 2 Perfect Edition to the latest version according to the FBNeo repository. Please check it and see if everything is right. Aside from that, it's been a little difficult to use Raine lately because of the remaining bugs in window manager in Windows, especially the first one I mentioned in this thread. I change from full-screen to windowed mode frequently so it's not so user friendly to have to move and resize the window in order to use the program after leaving full-screen. The second bug I reported is a new issue and it will only show when using the full-screen option in the GUI. Anyway, hopefully you will fix these too some day... Finally, sometimes I have the impression my records keep being overwritten in NeoGeo even though I have selected the per-game save option. I'll see if I can reproduce it safely in order to file a bug report for you to check it. Thank you so much for your work. PS: it seems archive.org is down due to a hack attack. If it doesn't work for you to get the updated roms for samsho2pe, you could try to get them from retroroms.info. It requires a quick registration though. Otherwise I can upload the changed files for you.

* AdvanceMAME 4.0 - http://www.advancemame.it/ * XRoar 1.6.6 [Tandy Color Computer / Dragon] - http://www.6809.org.uk/xroar/ * JGenesis 0.8.1 [Multi-system] - https://github.com/jsgroth/jgenesis/releases * DCMO5 (2024-10-15) [Thomson MO5] - http://dcmoto.free.fr/emulateur/index.html * GameEx 18.78 [Front-end] - https://www.gameex.com/news/

@StHiryu You need to set "mouse 1". I didn't need to use mouseprovider win32. The only difference on mameui is the system mouse pointer stays on, and isn't captured. You need to use full screen to fix that.

WinArcadia 33.41 (Windows XP/Vista/7/8/10/11): 18 October 2024 DroidArcadia 3.1 (Android): 26 July 2024 AmiArcadia 33.41 (AmigaOS 3): 18 October 2024 AmiArcadia 33.41 (AmigaOS 4): 18 October 2024 AmiArcadia 33.4 (MorphOS): 8 October 2024 Super Bug Advance 1.3 (Game Boy Advance): 11 September 2009 AmiArcadia and WinArcadia are multi-emulators/assemblers/disassemblers of these machines: * Emerson Arcadia 2001 console family (Bandai, Emerson, Grandstand, Intervision, Leisure-Vision, Leonardo, MPT-03, Ormatu, Palladium, Poppy, Robdajet, Tele-Fever, Tempest, Tryom, Tunix, etc.) (c. 1982); * Interton VC 4000 console family (Acetronic, Cabel, Fountain, Hanimex, Interton, Prinztronic, Radofin, Rowtron, Soundic, Voltmace, Waddingtons, etc.) (c. 1978); * Elektor TV Games Computer (1979); * PIPBUG- and BINBUG-based machines (Electronics Australia 77up2 and 78up5, Signetics Adaptable Board Computer, Eurocard 2650, etc.) 1977-1978); * Signetics Instructor 50 trainer (1978); * Signetics TWIN minicomputer (1976); * Central Data 2650 microcomputer (1977); * PHUNSY microcomputer (c. 1980); * Ravensburger Selbstbaucomputer aka 2650 Minimal Computer trainer (1984); * Hofacker MIKIT 2650 trainer (1978); * Astro Wars, Galaxia, Laser Battle and Lazarian coin-ops by Zaccaria (1979-1981); * Malzak 1 and 2 coin-ops by Kitronix (c. 1981); * AY-3-8500/8550/8600-based Pong systems (Coleco Telstar Galaxy, Sheen TVG-201, etc.) (1976-1977); and * VTech Type-right machine (1985). Features include: ReAction GUI, load/save states, windowed and full- screen modes, CPU tracing, trainer, drag and drop support, graphics scaling, automatic load/save of configuration/game, keyboard/joystick/ gamepad/paddle/mouse/trackball/Vision-dapter support, autofire, turbo mode, gameplay recording/playback, sprite demultiplexing, help windows, source code, real-time debugger, frame skipping, redefinable keys, save screenshots (9 supported formats), REXX port, network play (IPv4 and IPv6), real-time monitor, locale support, game selection sidebar, text-to-speech, printer output, artefacting, support for ZIPped games, clipboard support, palette editor, tone retuning, high score management, force feedback, sprite editor, 3D, assembler, disassembler, CALM support, Scale2x/3x/4x and HQx filters, animation recording (5 supported formats), sound recording (8 supported formats), horizon dejittering, tape decks (4 supported formats), RetroAchievements support, printer emulation, floppy disk drive emulation, screen editor. The supported languages are currently English, Dutch, French, German, Greek, Italian, Polish, Russian and Spanish. Changes since V33.4: Summary: * Debugger: PIPBUG: added support for "VIEW BASIC" command. * Miscellaneous improvements and bug fixes. Details: cd2650: fixed: last two sectors of 2nd track were not shown as reserved by floppy drive subwin and DIR command. aa: fixed: "tools|screen editor" menu item opened sprite editor instead. aa: fixed: "tools|sprite editor..." menu item did nothing. aa: fixed: sprite editor: set pixels were not being shown in grid. pipbug: debugger: 2650 micro basic: added support for "VIEW BASIC" command. localized various strings. incorporated Anthony's latest Greek translation. pipbug: added label and comment support for 2650 micro basic. http://amigan.1emu.net/releases/ http://amigan.yatho.com

Thanks Robert.

* DCALICE (2024-10-10) [Tandy MC-10, Alice32, Alice90] - http://alice32.free.fr/emulateur/index.html * Gopher2600 0.35.1 [Atari 2600] - https://github.com/JetSetIlly/Gopher2600/releases/ * Stella 7.0 [Atari 2600] - https://github.com/stella-emu/stella/releases * Pyboy 2.4.0 [Nintendo Gameboy] - https://github.com/Baekalfen/PyBoy/releases * Cemu 2.2 [Wii-U] - https://github.com/cemu-project/Cemu/releases * Extramame 24.10 [Front-end] - https://www.wintools.net/extramame/ * dgVoodoo 2.83.2 [Plugin] - http://dege.freeweb.hu/dgVoodoo2/dgVoodoo2/