All Activity

1) autodetect as default : we used the other way for years and you are the 1st to have a problem with that, I think we can keep the old default for now, I prefer to see precisely my soundcard name when I go to options. 2) your haunting black border : well not for me in linux. Maybe it's windows only... I am terribly tempted to simply stop to support windows, what a marvelous idea it would be ! I might try that in windows later, but for now in linux : 1) removed my config file, started raine, went to fullscreen loaded dino, took a screenshot of the title screen, then quit 2) run raine again in the same config, loaded dino, took the same screenshot, got exactly the same picture, end of the test for now. ... and same result in windows, same picture in both case (compared the files they are identical). got it, I hadn't the latest binary in windows, it's still the same old problem because I changed the way to get the screen coordinates, in windows we get the height of an invisible windows title bar added, not in linux. 1 line fix, a function name instead of another, but it's really annoying. At least the site is fixed, back with some disk space, you can get the ultimate test binary there : https://raine.1emulation.com/archive/tux/raine.7z

Thank you so much for providing this new test build, Tux! I tried it here and everything seems rightly fixed. The sound device auto-detection works perfectly between different sound output devices set in the Windows desktop. So my problem is finally solved! My last request related to this new feature is that the "Auto-detect" option became the default option in Raine for new configuration files. This way users wouldn't have to worry about setting this up and possibly coming across the "no sound" issue which happened to me when switching between different devices. The "Auto-detect" option may also work in your mini PC as well as in every other context by default, so I suppose it's safe to have it as the default option at least in new configuration files, no? This way Raine would also follow what other emulators do in relation to this option. Please let me know what you think about this suggestion. Except that, I think I may have found the last bug related to the "black frame/black border around the game picture" issue. Yes, I found a new way to trigger it. Here is how to reproduce it: - run Raine and toggle full-screen mode either by using Alt+Enter or the Full-screen option in Video options menu; - save your configuration by using the Quit function; - reopen Raine and load a game; - when you leave the GUI, you may notice the game picture has now the black frame/black border around the game picture; Comparison screens: Normal picture: Black frame/black border around the picture: Here's a quick video of me reproducing it in case you need: https://drive.google.com/file/d/1vh9lk3wqSkwDFQGNJQgehMButhUbzzRd/ I came across this bug by trying to create a "perfect configuration file" without even loading a game first. So I went to full-screen and quit to save the configuration, then when I came back to finally load a game, I noticed the black frame around the picture was surprisingly back! Anyway, you should be able to reproduce it easily in your setup hopefully. The black frame may be less noticeable if you use a 16:10 aspect ratio monitor, but it will be there too. Thank you so much again for your various recent improvements in Raine emulator.

Duplicated again due to the forum bug...

It's a miracle we can still post to the forum with a full disk, maybe the database uses another disk ? Anyway here is a mega.nz link for now : https://mega.nz/file/OYVAXI4b#uMADM9P6tyzFjRN3kUj90s1spQKI-B188WSJmvIBYDE

Thank you so much for your explanation on this issue. I suppose this would be hopefully the last nuisance related to the new window manager, no? But it can surely wait for another time when you finally think about how resolving this... Thank you for this fix too. I'll be sure to check if everything is OK as soon as you are able to share a test build here. Thank you so much for your reconsideration of this request. I'm glad you could find a solution for that without much work I hope. I'm looking forward to testing this new feature in a test version soon. If the forum doesn't return to operation soon, you could try dragging and dropping the zip file in a GitHub comment, such as in here: https://github.com/zelurker/raine/pull/75 Thank you again for your willingness in fixing all these recent reported issues in Raine.

Oh, ok I surrender, I added an Autodetect choice for the soundcard in the gui, and I fixed the detection of the sample rate which was linked to the sound driver instead of the soundcard... ! You won't have a test binary for now because after the forum, it seems the ftp is broken for now, I can't send raine.7z ! (deleted the file to avoid any mistake). It's still a rare case in my opinion, but it's quite interesting to see how it can be done without having something too big. Since I had to fix the sample rate detection too it's a little longer than what I anticipated but it's still ok, and maybe someone else would use that ! Notice that the behavior is the same as before : if you don't choose "Autodetect" explicitely and you have no config file, then it will detect the soundcard only once, there's no reason to detect it all the time except on a crazy laptop changing its output device all the time ! Difference from before : now if you change the soundcard in sound options and the sound card driver has a preferred sample rate, you'll see this sample rate selected in the options in real time. Not all drivers have a preferred sample rate, if there is none the frequency is not changed. By the way the error on the server is because of a full disk !

Centering the window : of course raine keeps as many coordinates as it can, it's since we added all these windows statuses which created so many problems ! So it knows where to position precisely a window when exiting from fullscreen to return to its previous state, but if the physical screen changed and now the resolution is not the same anymore, then it will mess things up. There's not much which can be done about it, it's obliged to reduce the size to stay in the screen, but then should the position be changed too and how ? For now it isn't touched, it's the safest way, it would really become crazy to try to adjust position when the size has changed too. The black screen in windowed mode : yeah my fault, I didn't get the right values for the desktop resolution, now I ask the desktop resolution for display 0, hoping we will never handle more than 1 physical display because I don't plan to use more than 1 here. autodetect sound all the time : yeah but it would force to have a special value which says "detect the soundcard but don't store the result, just stay in autodetect", so it's a little tricky, and not necessary in most setups, your setup when plugging a new dispaly changes the soundcard priority is quite original. And always detecting the soundcard is not a good idea neither in the case where you run without a desktop, which I do on the mini computer, it has a bare environment, no desktop, and in this case it can get some rather crazy value for the detected soundcard. Now I admit that if I was to use regularly raine on that machine, I would put a window manager, at least for fullscreen, here it's bothersome... ! Anyway since it takes you only a few seconds to adjust manually, it's the easiest solution for now.

Hello Tux! Thank you so much for your fast reply, as always. Quote from Tux: For the 1080p -> 1366x768 not sure what happens, I might do some tests later. edit : after testing, it's minor, it's just about the placement of the window, not sure there is something to do about it, it's after resizing the screen so that it fits in the new resolution, so no wonder it can change the position while doing so. And it can be fixed manually without too much trouble, or just stay in fullscreen, so really minor. Thank you for your investigation. I agree with you. I only see this as a real issue in case someone switches from a big display resolution to a smaller one, for instance, switching from a 4k display to a 1366x768 or a 1280x720 monitor would possibly be difficult to manage the floating window depending on where it would show in the new smaller resolution, because the window could be even barely seen. It's interesting that when you first create a config file in full screen and then return to window mode, the window is perfectly centered. But if you take this same configuration to a different display with different resolution, then something happens and it can no longer position the window in the center when leaving full screen mode. It seems Raine saves some kind of memory of the first full-screen resolution in the config file, and then it does not adapt/update it to other display sizes... Except this, I've finally a new bug to report. It was maybe created after you fixed the game picture in different display sizes. So, here's how to reproduce it, using the latest test build: - run Raine without a configuration file; - load a game in windowed mode; - there should be no game picture when you leave the GUI; - if you try to go full-screen the game picture will be distorted. - if you return to windowed mode, the distortion will be retained until you show the GUI again; See all this happening here: https://drive.google.com/file/d/1wu1Kstf732xAX-3OdInWXy0hnSi9Zz_Q/ Hopefully you'll be able to reproduce and fix this too. You are correct, I understand this can be done. My feature request was with the thinking of letting this process automatic by default. If we have a "default/auto-detect/auto-select" parameter available, we can enjoy the game play without worrying about this kind of particular configuration. But without this option we need to set the sound output device every time we save the configuration file with the computer speakers, and then switch to a second or external sound device such as the one in HDMI TVs. Currently the auto detection only works in these conditions: - you don't have a configuration file created yet; - you have your computer/laptop hooked to an external display with built in speakers; - in Windows desktop you have set the display speakers as your sound output device; - you run Raine and visit the Sound Options menu or load a game and then save the configuration. In this situation the auto-detection works perfectly. Raine detects the sound device I'm currently using in Windows (in my case, the Samsung TV speakers). The auto-detection also works if: - you have a configuration file created while Windows sound output was set to the TV speakers. - you disconnect your computer/laptop from the TV and and Windows now reset the sound output to the computer speakers; - you run Raine and visit the Sound Options menu or load a game and then save a configuration file. In this case the sound output auto-detection also works and is updated to the current sound device set in Windows, which in my case is Realtek HD Audio (the only one available). The sound device auto-detection won't work in the following situation: - you have saved your Raine configuration file while having only one sound output device available in Windows (in my case, Realtek HD Audio). - you hook your computer/laptop to a TV display and have the TV speakers set as default sound output in Windows. - you run Raine and load a game or visit the Sound Options menu. In this case the auto-detection doesn't work, Raine keeps set to the Realtek HD Audio device and does not detect Windows is now using the TV speakers. As you said, you can fix this by going to the Sound Options menu and manually selecting the TV sound output device listed in Raine. If a "Default/Auto-detect/Auto-select" setting is implemented, there will be no need for that. Raine will behave as exactly as every other emulator, it will feature a seamless switch between different setups and sound output devices in Windows desktop. If such an option couldn't be added at all, then Raine on the other hand could try to always auto-detect/auto-select the sound device currently set in Windows desktop and use it instead of picking the one previously found in the config file, that is, it would always refresh it when necessary. I think one of these approaches would finally provide a seamless experience with using Raine in different contexts, making it more user-friendly in terms of important settings to be manually configured by the user. Anyway, I hope I may have clarified a little more my idea in relation to this feature, if you happen to reconsider it eventually someday. Thank in so much again for your continuing improvements in Raine.

Testing... The forum is broken somehow. I cannot post a specific reply. It seems that if I insert a quote or link it blocks me from posting, I get a 500 internal error or 504 time out error... Very weird...

* AppleWin 1.30.20.0 [Apple2] - https://github.com/AppleWin/AppleWin/releases * Raine 0.97.2 [Arcade] - https://raine.1emulation.com/download/latest.html * XRoar 1.7.1 [Dragon64 / Tandy CoCo] - http://www.6809.org.uk/xroar/ * MelonDS 1.0 RC [NDS] - https://melonds.kuribo64.net/downloads.php

No I think it's enough for the sound. It works well enough for me. There was an autodetect for sound in the old dos days for those who didn't know which sound card they had, but the time was very different ! Since then it never came back, and you can easily do without it even now, if you forget and find you have no sound, you can restore your sound by a quick visit to sound options, so it's not worth the trouble adding an explicit autodetect choice in my point of view. For the 1080p -> 1366x768 not sure what happens, I might do some tests later. edit : after testing, it's minor, it's just about the placement of the window, not sure there is something to do about it, it's after resizing the screen so that it fits in the new resolution, so no wonder it can change the position while doing so. And it can be fixed manually without too much trouble, or just stay in fullscreen, so really minor. Cool, I finally see the end of it ! For the config not updated if you just run and quit, normal, it does nothing related to the sound in this case, you have to either load a game or go to sound options.

Hello again Tux! Thanks a lot for this new test version. I tried here the config file last saved using the built-in monitor in my laptop in my TV and finally the game picture is properly resized to the bigger screen. Also, if you save the configuration in the TV and return to the built-in laptop monitor, the screen is perfectly resized again to the smaller screen. So the switch is finally seamless now! The only minor issue still related to the window manager at this point is this: - if you leave full-screen mode in my 1920x1080 TV, Raine window will be perfectly centered in the desktop area, as you see here: - now if you use this same config file in my 1366x768 laptop built-in monitor, this is what happens when you leave full-screen mode: You see that the Raine window is no longer centered in the new 1366x768 desktop area. It looks like it is still trying to center the window in the original 1080p display resolution, which was the one I first created the config file in. It's a minor issue compared to the others I've reported so far, but I'm reporting it again in case it could be easily fixed by you...? As for the sound output device changes, here are my results: - if you just open Raine and close it by the Quit function the config file won't be updated. You need to either run a game or visit the Sound Options menu and then Quit to save the config file with the new string naming value. - if you switch from using the built-in computer speakers to the external TV speakers (which Windows does automatically when you hook the computer to an external display with built-in speakers such as a TV), Raine still can't auto-detect and select the new sound device set in the desktop by Windows. It will retain the previous configuration found in the config file, which in my case is the Realtek HD Audio output, and for that there will be no sound. I suppose the next step in this matter would be to implement a "Default/Auto-detect/Auto-select" setting in Sound output device in Raine as we have with most emulators out there. This way the switch between internal and external sound output devices and even between additional sound devices installed in Windows would be seamless in Raine. If I had selected that option in Raine the program would simply automatically use the sound output device set in my desktop when using the TV, which in my case is the NVidia High Definition, set by Windows as default. I don't know how difficult would this be for you to implement this though. Hopefully SDL2 will have such a feature and let you do that eventually. This new setting would end the problems with switching between sound devices in Windows. Anyway, I'm already glad that Raine usability has become more seamless between different devices, which is a context more common nowadays with HTPCs, mini PCs, laptops and other portable Windows devices with external display connectivity being available in the market. Thank you so much again for the time working on these little improvements in the emulator.

Nope, sound_card becomes a string value in the config file for sdl versions from now on, the old config file is converted on the fly so you don't have to edit it manually. Actually sdl2 accepts only a soundcard name when opening a soundcard, not an id, so it's easier this way. While testing I stumbled upon the case where you get a strange soundcard name with trailing spaces, in this case the trailing spaces are removed when reading from the config file which added another case to fix... ! Anyway it should work in all cases now, hopefully ! Test your thing... same link.

Hello Tux! Thanks a lot for this fast fix. Hopefully it will be the last correction related to the window manager. If you would like to provide a test build, I would be glad to test it again. Thank you so much for that too. I thought of still preserving the numbers in the config file and only changing the look in the graphical interface. So, in the config file, 1 would be the default/auto-detect sound card (it will always use the one selected as default in Windows desktop), value 2 would be the first sound output device reported by driver and manually selected by the user, 3 would be the second sound output device found and manually set by the user, and so on... I think if you keep the numbers in the config file you may preserve compatibility with the current config files. For example, in my case I saved my Raine configuration in my laptop disconnected from the TV, so it had only one sound device available and the value set in the config file was 1. That's why I don't have sound when I reconnect the laptop to the TV, because the Samsung TV speakers are identified by Raine as the second output device, which was supposed to be value 2 in the config file. But if value 1 becomes default/auto-select, I suppose the compatibility will be preserved in my current config file when switching between sound devices in the desktop (which Windows automatically does when you hook the computer to a TV, for example). I'm not sure how difficult would it be to implement this though, but it seemed a good solution to have the default Raine configuration to be set as "Default/Auto select/detect" for the sound device, which is what happens with most emulators I've tried. There are some emulators such as Dolphin which don't even let you select the sound output device, they simply use the one set in the desktop. Anyway, I will also be glad to try any approach you make in this regard in Raine. The idea above was just a suggestion.. Thank you so much again for your time and continuing work.

For the smaller screen : yeah it can be done, I thought about it after posting this binary, easily done. For replacing 1 soundcard by another one : not convenient for now, it obliges to change a number by a string as a setting, and for now I prefer to avoid it, so I think it's going to be my limit, you'll have to live with it ! edit : actually it might be possible to do something for the soundcard too, it's not convenient because it breaks compatibility with the dos version, but it shouldn't be too complex to do, I might have a closer look later.

Thank you so much for this new test build, Tux! I have tried it here and the issues are finally gone! The game picture is perfectly resized now to match the smaller monitor resolution, and the sound is no longer stopped if you visit the Sound options menu. Everything fixed correctly. Yes, I understand, I'm sorry for the extensive reports. It's just that sometimes I think that a video may illustrate better what I write with words. Anyway, I still have some things to report about these issues. I saved my configuration file on the desktop/laptop monitor and then thought of switching back to my Samsung 1080p TV to see if everything would be working fine when going back to the big screen. Here is what I've found: 1) The game picture will retain the smaller resolution from the monitor and show it in a frame in the bigger resolution screen, take a look: https://drive.google.com/file/d/1Tv4p5PJjDWXKVTBUrd0uPvjPA-C669b_/ This is my laptop monitor configuration (1366x768) running in my desktop monitor (1600x900). You notice that the frame is not so big because the resolution difference is not big either. And this is my laptop monitor configuration (1366x768) running in my 1080p TV screen (1920x1080): https://drive.google.com/file/d/1wMUdgELxPv_LX-pZxZqwWZtmFOFWrY5d/ Notice that the black frame is now bigger because the resolution difference is bigger. I suppose that if I used this same configuration in a 4k TV there would be an even greater frame difference. Maybe this escaped from your testings in this test version. Hopefully it will be easy for you to fix it... 2) The program no longer auto-detects the Samsung TV speakers set as default in the Windows desktop, so I have no sound in Raine, as you see here: https://drive.google.com/file/d/1OBhQiy9V20TV6uDv7_JrGoM5hH39RyZA/ You see that even if you visit the Sound options menu, it will stick to the Realtek HD Audio sound output, even if in Windows desktop I have set the Samsung TV speakers as default. I was wondering how you could fix this and thought of maybe doing what most emulators do: add a "Default" sound output device value to the sound device setting. See this option in Duckstation: Now see it in PCSX2: So this could maybe be the solution for this problem, no? It would allow the program to always detect the default sound device which is being used by the Windows desktop, be it the internal PC speakers (in my case, Realtek HD Audio), the external display speakers (Samsung TV) or others. If the user wanted to set a different or specific sound device, then he/she could select it by the list reported in Raine. The Default sound device value could be 0 or 1 in the config file, and then the other sound devices could start at 1 or 2, 3, 4 and so on. Let me know if this could be a good idea to fix this issue. Anyway, hopefully this can be the beginning of the end of these sound device and window manager issues in Windows... Thank you so much again for your continuing work in the emulator.

And the magazines have finally been delivered! Time for a few group photos!

Ok, I'll take a look later, but there's no need to make a video all the time, just saying 1 load a game while being in fullscreen, the game starts normally while in the gui 2 go fullscreen -> the screen becomes blank It's shorter, takes less time, and is more efficient for everyone. I have tested this too fast, seeing that the gui seemed ok in fullscreen I assumed it was a windowed problem only. Later, then... edit : well sorry for my mistakes, I was half awaken when I did that and it shows, I went way too fast especially for the video resizing part. For the sound I didn't think just opening the sound options would make such a mess in such a case ! Anyway it's fixed again, you can have your test which was indeed useful here : http://raine.1emulation.com/archive/tux/raine.7z

Thank you so much for providing a test build! This may be useful to avoid several hot-fix releases in a short time. I made a quick test here with this test version using my current configuration file in Raine, that is, the one created with the desktop computer/laptop computer hooked to the TV to check if the problems have been solved. Here are the results: - the issue with the game picture not resizing appropriately for a smaller resolution display is still present in this test version. I no longer have a game picture out of bounds though, it is just a black screen now, take a look: https://drive.google.com/file/d/1vQ2OyXaRyxgjJy2nRgrpZk5R4uM0AKCM/ So the change you implemented did change something in this regard, but it is not perfect yet. Hopefully you'll be able to understand what is going on with this issue... - the issue with Raine not detecting the current sound output device and showing a "None" value in the Sound options menu has been partially fixed. This is what is happening now: 1) if you load a game before visiting the Sound options menu, the sound device setting will be normally filled with the current sound output device found in Windows, take a look: https://drive.google.com/file/d/1ly7fQTWlOnHFJwD27v0Yat66gf-X_0h3/ The sound seems to work normally in this case as far as I've tested. 2) if you visit the Sound options menu before loading a game, then the "None" value will remain set as the sound output device and there will be no sound during the game play. This will also trigger the "Z80 error/MVS slot check" error in KOF2000 as mentioned before. See here: https://drive.google.com/file/d/1jJInRBM7Z0bxba7P0vc2_sgxxN743pNk/ So, the change you have implemented did fix the issue with the sound device detection, at least partially. There is only the case that if you visit the Sound options menu before loading a game, it will trigger the issue and then the sound will be broken. In case of KOF2000 and possibly other NeoGeo games, it will also produce the "Z80 error/MVS slot check error". The Z80 error does not allow you to play the game, as you see here: https://drive.google.com/file/d/1o05mq-RM6tg0leivib5vXm4e9v9q7o4Z/ Hopefully this test will be useful for you somehow when checking those issues again. Thank you so much for your time and work.

There's a blast from the past. Glad to see you're still alive.

WinArcadia 33.6 (Windows XP/Vista/7/8/10/11): 20 November 2024 DroidArcadia 3.2 (Android): 20 November 2024 AmiArcadia 33.6 (AmigaOS 3): 20 November 2024 AmiArcadia 33.6 (AmigaOS 4): 20 November 2024 AmiArcadia 33.5 (MorphOS): 4 November 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.5: Summary: * Improved Galaxia emulation. * Added ASM and DISGAME CLI arguments. * Miscellaneous improvements and bug fixes. Details: arcadia,galaxia: ctrl+hover and help grid now take per-row/column scrolling into account. pipbug: now supports elekterminal page extension. arcadia,interton,elektor,zaccaria: screen editor: now explains special screen editing commands on status bar. cpu monitor: revised gadget layout slightly. debugger: fixed: messages about bitfields were not correct. debugger: fixed: I/O port watchpoints were not always being triggered. debugger: more detailed message when logging I/O port writes. galaxia: added emulation of throbber and squealer (dive) sounds. interton,elektor: screen editor: support for shift-0/1/2/4/8. interton,elektor: screen editor: spacebar now extends both halves of the grey cell. galaxia: adjusted colours. added ASM and DISGAME CLI arguments. wa: removed unneeded winsock2.h file. aw,galaxia: fixed: background starfield was not colourful. pipbug: guest controls subwin: implemented break key. -------------------------------------------------------------------------- DroidArcadia 3.2 is a port of a subset of the AmiArcadia/WinArcadia 33.6 emulator to the Android platform. The following machines are emulated: * 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); * Astro Wars, Galaxia, Laser Battle and Lazarian coin-ops by Zaccaria (1979-1981); and * Malzak 1 and 2 coin-ops by Kitronix (c. 1981). Features include: artefacting, autofire, force feedback, frame skipping, game help, gamepad support, high score management, horizon dejittering, locale support, save screenshots, saved states, sprite demultiplexing, tone retuning, trainers, support for ZIPped games, DIP switch editor. The supported languages are currently English, Dutch, French, German, Greek, Italian, Polish and Spanish. Changes since V3.1: Summary: Improved Galaxia and Astro Wars emulation. Details: galaxia: added emulation of throbber and squealer (dive) sounds. aw,galaxia: fixed: background starfield was not colourful. galaxia: adjusted colours. http://amigan.1emu.net/releases/ http://amigan.yatho.com

Oh well you can always test this binary, since normally it can now work around the issue of soundcard not present you shouldn't be able to reproduce this error with it. https://raine.1emulation.com/archive/tux/raine.7z

Hello Tux! This is really good news! I should be testing these workarounds as soon as a new version is released. Thank you so much for that. Hopefully those were the last issues related to the sound device detection and the window management feature... No problem, I cannot reproduce this issue in a normal installation either. It only happens when I have the configuration file created in my TV with my laptop or desktop computer and then try to use it with the monitor, that is, when you have the "None" value in the Sound options menu. If you have set the Unibios, it will show the "MVS slot check" error. If you have set the default Europe bios, it will show the "Z80 error". Just out of curiosity, I took the configuration file created in my laptop and tested it in my desktop computer and could consistently reproduce the error. Here's a capture showing the procedure I make, if you would like to try it once more: https://drive.google.com/file/d/1AhpKDgOwk9YeR_LdLURSosRSIqzbQCla/ As you see in the video, you need to visit the Sound options menu before loading the game to trigger the error. I have provided above the configuration file created in my desktop connected to the TV. Now I provide the configuration file created in my laptop when it was connected to the TV: https://drive.google.com/file/d/1AXfBp2K1VwRDILBorzrpnzZsNsdcXwxA/ I'm not sure it will make a difference in your testing, but since you couldn't reproduce it at all, maybe you could try it with this one too...? Anyway, I am already glad the other two issues have been fixed. Thank you so much again for your continuing work in Raine.

No idea how it was broken so I can't do anything about it, sorry ! I would love to have someone maintain the windows version, it would be a lot less troubles for me ! Actually there are very few patches between 0.97.1 and 0.97.2 of course since it's mainly about the sound problem alone, raine does nothing fancy in this version, just calling sdl2 functions which were not called before, so I guess your incompatibility comes from there. But as explained before there is nothing much to do about it after a certain point, Microsoft does this willingly, they do nothing to maintain their old versions, not even security patches, and keep on adding new kernel functions to the new versions which are then used by some libraries. After a while the new functions become unavoidable and you have an incompatibility.

hello just for your own information, the latest xp-compatible version (if you replace the dlls, of course) is 0.97.1 (the .2 version definitively breaks this compatibility). After so many years, someone had to let you know ^^.