Tux

Tsss... if you have read the thread until the end, it turned out it was just a window manager problem in linux combined with the video card driver, it was fixed in git, but not in any official binary yet (at least for what I could test, this guy didn't reply to say if tests on his side were ok, that's why the issue is still opened). 2ndly as I already told you, I can't reproduce your white screen here on my desktop, it happens only in windows and I had it a long time ago while setting up the 1st versions using sdl2, but I have not seen it since then here. So I believe it's more related to some video driver/video card issue, and anyway since it can be worked around easily and is impossible to reproduce for me for now, there's no point. For the notifications I had telegram but only in linux, I downloaded the windows one, and in the parameters screen for notifications you can simulate notifications on your screen, that's what I did, raine playing in the background visible, the telegram window on top and the notifications which appear when you move the mouse over their displayed screen. No blinking, no white screen, nothing. Well since you use something to also capture some video, maybe it doesn't help. Why is everybody thinking this "real fullscreen" is like a super holy solution ? The only reason previously to have this "real" fullscreen was because that was the only way to have double or triple buffered display, it's not the case anymore with sdl2 it works perfectly in a window. So this fullscreen windowed mode gives a few advantage, you can't display a window on top of something using this "real" fullscreen, here you can without any problem which makes things easier for debuging or checking something else. The windowed fullscreen is actually a better solution, especially for lcd screens, the real one tries to change the screen resolution to match the window size, you don't want to do that on a lcd screen, that's why version 0.50 was created, and it was a very long time ago now... In the end, this is something really easy to test by modifying the source and testing by yourself, too bad you don't compile, you would have seen by yourself it's not the right solution ! Sorry about your driver glitches, but I can't do much about that, as far as I know at least... !

this is really going nowhere. 2nd screen is just what is displayed when the settings of the autofire have been saved and reloaded, and it works at least on the game I tested, I never bothered to find why the display order changed by the way, and I don't plan to. You tried that on kof98 apparently, it's not exactly the ideal game to use autofire, the autofire is done for shoot'em ups usually... ! I guess you would need to at least remap the autofire button to something else so that you can continue to use the normal button without autofire and switch to autofire only when really needed. kof98 is made to use combos, not pressing the same button as fast as possible, it wouldn't make much sense here. Try that on a shoot'em up, it will be easier !

I don't understand everything here, but the 2 pictures are equivalent, it's just the the order of what is displayed which is different, but the information is the same.

Well just tested with ddonpach using the keyboard, no problem, ddonpach is good to test that because continually pressing the fire button create a concentrated shot as opposed to the effect of the autofire (rapid shots). Tested with autofire directly assigned to button1, and with autofire using its own input, both on the keyboard, no problem (tested with the linux version, I won't even test with wine for that). By the way I got a report that fullscreen in the linux version was broken for quite a few window managers in linux, I didn't know that, it seems reports come very slowly for that, it's fixed in git for next version (at least for openbox which I tested directly and probably for kwin).

The 7z code in raine is very old, 11 years already, and the distributed code changed quite a lot in all these years... Since the performance of the 7z archiver didn't change a lot in the same time, I didn't expect a big improvement for the performance, but I was curious to try to update this anyway... In the end it was long, complicated, and for almost no improvement for the performance, quite disappointing ! I'll keep the update anyway, maybe I missed something in it, and it's probably better to have some more recent code. Things to notice : by default 7z archives are solid, but for some big rom archive, making it solid gains about 1% only in size, almost nothing. The time to decompress is almost the same for solid and non solid archives, but if the archive is not solid you get a real progress bar when loading the rom. If it's solid, then the whole archive is processed for the 1st file, and then the rest goes so fast that the progress bar becomes totally useless ! So it's probably better to create non solid archives (-ms=off when using the 7z or 7zz command line in linux).

It's smaller, but probably not faster, mpg123 is very concerned about speed too, it's full of assembler code inside so I doubt it's slower ! But I reverted to the old mp3 driver anyway... ! (I kept the mpg123 code commented in case it's useful again one day !)

Bang, Iccuslus suddenly exited from hibernation and fixed sdl_sound... ! See there : https://github.com/icculus/SDL_sound/commits/main almost 1 month later, but better now than never of course... Now I hesitate : is it better to remove the new mp3 dll and return to the old decoder and just forget all that and stay with what we have ? Well luckily only 1 version used the new dll, and it was included in the raine archive, so removing it now will have no consequence. So I guess it's probably the thing to do, the mp3 decoder used in sdl_sound is still smaller and maybe faster... Oh at least I'll have to try it first. Apparently the bug was that when the decoder returned something less than the expected bytes to read (which happens for the last block), it was understood as eof (end of file), and so the last block was not handled. Oh well... He finally closed the bug thread on github with this fix. edit : yeah, the fix works !

No it's not a unibios problem, it just displays a nice screen instead of just crashing here, the error shows the pc has just gone out of bounds, it should not have this value, it's an emulation problem, which is a little surprising since fbneo is based on mame, I didn't think they touched the emulation part very much, but I don't know it (no linux version !) For tmnt, I didn't even look ! It's probably not an easy one considering konami reputation, but no idea. For now I am looking at other things for a little while, I don't spend all my time in emulation...

It's a misconfiguration at the server level, mime types configuration, with wget you get this : --2022-03-04 14:09:08-- http://raine.1emulation.com/archive/raine32-0.93.4.7z Résolution de raine.1emulation.com (raine.1emulation.com)… 216.245.218.214 Connexion à raine.1emulation.com (raine.1emulation.com)|216.245.218.214|:80… connecté. requête HTTP transmise, en attente de la réponse… 200 OK Taille : 2902845 (2,8M) [application/x-troff-man] (the text is in french, sorry, but the mime type appears between () at the end : application/x-troff-man, it's a man page indeed, but it's not my fault). On my side, it's a simple <a href link, produced by some basic html file, I don't touch the mime type configuration... And, from there for example : https://github.com/mime-types/ruby-mime-types/issues/32 the mime type should be application/x-7z-compressed it's minor though, even the most basic browser would kinow how to download this, whatever the mime type is.

Yeah sorry I should have fixed that the 1st time. The reason why there is the option for neocd/neogeo is that it's a single driver for roughly 100 games, so the search for these speed hacks is generic there, and sometimes it can fail to find something good. You are right it's usually not really necessary anymore nowadays but it's in the spirit of raine, optimize as much as possible, just because doing it is great ! It would have been nice to have the option for all the drivers, for those who prefer to play with a choppy animation when the game is overloaded with sprites, but it's tedious to do it now, so maybe one day, but not for now... Except for neogeo where the driver sometimes fails to find the right spot, these hacks are made to end the emulation of the main cpu when it just waits for the vbl, instead of just wasting cycles looping for a vbl which won't come because it requires an irq. It saves some cycles, but on modern hardware, it's around 1 or 2% usually (on an optimized build, more on a debug build in C), but it's the right thing to do (mame prefers to emulate these wait cycles, because it's more accurate).

neocd/neogeo options / allow speed hacks : no And you'll probably need to reload the game after that because the speed hack installs itself very fast ! They'll be disabled by default for this game in next version.

Yeah yeah the pack was made hastily, I doubt any direct3d shader would work since raine uses opengl, although maybe ? (seems unlikely though !). So yeah some shaders are broken, they were clearly not even tested, just assumed to be compatible. For the glsl shaders, yeah good idea, but I am no shader expert, I already had some trouble to add the old shaders support, so... ! But I agree, it would be a good idea ! (actually the name is bad, all shaders for opengl use what is called glsl).

make sure you disable speed hacks for this game, I thought they were disabled automatically but apparently not. I just tested the neocd version with this shader, apparently it's ok...

Yeah it's very tiny indeed, I wouldn't have thought about using the loop in play track to change the setting when returning to game... Well considering that before this version returning to game would simply stop the current track which played, it's already a huge improvement that it does not stop anymore ! Actually the loop trick you find is the "exploit" of a bug, I forgot to restore the loop status when returning to game, so here it just takes the last loop status... ! Ok well I'll restore it from the track setting next time and not from the last value it had.

... and if you had read the announcement with attention you would have noticed the advice to go to options / colors / revert to to restore the colors to their preferred theme (blue by default). Before you ask, the effect is not immediate, you need to close the dialog and open a new one to notice a change, so after choosing which colors to revert to the easiest path is to just quit and reload the emu.

This binary is only about the sound associations, particularly those related to kof2001, so if you are not interested in this, you can skip this one because it changes the colors encoding so if you load it with a previous config file you'll need to use the "revert to" command from the colors menu in options. It also includes a new dll for libmpg123, which is included in the archive for this version, it will go to the dlls package soon for the next versions. You can see the details of what happened (and eventually get the audio tracks from mer-curious !) from there : http://raine.1emulation.com/download/latest.html

And finally updated the playing function from the "manage associations" dialog to handle the loop, and if you entered the sound commands dialog with a track playing, it's restored when you leave. And a new binary is on its way... !

Well it does a lot of rom bank switches while on this screen, a few / frame, which is a little weird, I wonder what it needs to fetch while on a selection screen, but anyway the bank switches are just emulated by a pointer which changes, it's extremely fast, and you can see that with the profiler %, they remain low. I thought maybe some kind of weird input which is checked, but it's neogeo, meaning all the games use the same inputs normally (cartridges !). So for now no idea... For the fix for sdl_sound, I just reverted to the decoder used in the 1.2 version, which worked well, so it means you wouldn't have this bug in the 1.2 version. I think it's quite unlikely to see that fixed, the author seems to have mostly abandoned the project, plus the bug is not in sdl_sound itself, it's in the decoder he chose, which is too experimental. It was convenient though, very small and very fast, so can be merged without needing an external lib, libmpg123 which I use now is huge in comparison !

And finally found a workaround for your weird colors in game in windows after displaying the sound association dialog : it can't be fixed, because it's totally crazy ! Actually the color you see is the color used by the lines of the cross to indicate a loop is enabled. Here you couldn't even see the lines since their alpha was 0, but the color indexes still counted ! So the only way I could find to work around it is to make sure the last line drawn here is white, this way there is no color applied to the game bitmap and everything is fine ! I am glad it's windows specific, because it doesn't make any sense ! So you'll notice now there is 1 green line and 1 white line for the cross... temporary workaround until someone finds something better ! The fix is in windows only of course, I keep the normal cross otherwise. I think that's the end of the fixes for your problems, I had a quick look at the slowdown in the game menu, and no idea for now !

The invisible cross in the loop checkboxes was simply a bad handling of its colors, it's because the colors changed their encoding in sdl2, I tried to keep some compatibility with the old ones, but it's the last problem here, I switch to the new colors, so next time you'll run raine, you'll have to use the "revert to" option in the colors menu (from options). The sound which loops badly is specific to the mp3 format, at least for me, I don't have it in wav or ogg format. This has been reported there : https://github.com/icculus/SDL_sound/issues/27 The problem is that the author doesn't seem to react much. So for now the best solution is to use ogg or wav instead of mp3, it's not specific to the vbr contrary to what I thought 1st, it cuts the end even with a plain 128k mp3 ! It's possible the problem doesn't happen in the sdl1.2 version, they changed their sound decoders in sdl2_sound, and might have chosen wrongly the mp3 decoder here. It's fixable since it's open source, but it's not an easy task ! Just checked : it also works correctly with flac, it's really specific to mp3 for me. Ok problem fixed by taking back the old mp3 decoder we had for sdl-1.2, and which used mpg123 (it uses minimp3 here). It works, but it requires to link with libmpg123, which means 1 more dll for windows, yeah !!!

Sadly no, it's an "update glitch" you could say, with sdl1.2 I could update just tiny regions of what is displayed, now I can't anymore, the whole thing must be redrawn, and it creates problems in this kind of case. My bad, I used audacity to load that, actually the track was playing fine, it's just you don't often hear tracks ending like that, so I confirm there is indeed a problem with the loop setting while using mp3 ! Maybe some other formats. Only way to fix it for now : convert to wav (using audacity for example !), and edit your games.cfg to use the wav version instead of the mp3, it will work flawlessly. Notice that I was stuck at an audacity v2.x, the latest one 3.1.3 has a nice loop button with a tutorial on how to make nice loops, but for this track it seems to loop perfectly without updating it (in wav !). I'll try to fix the mp3 problem later, it's odd we never noticed that earlier though, it's still sdl_sound, I don't think they changed the way they played mp3, so it's probably been there for quite some time... Yeah no worry, I'll have a look, I don't know yet what it is though. Yeah yeah but it's not easy usually !

I seem to remember you found something very similar in another kof game, and we never found the solution, and there was no over slow-down found. I might try to take a look, but not now... it's the kind of thing where I'll search for a long time, and it's probably not worth it.

I don't have this, only the associated track is played for me. There is a problem about the loop setting though, it plays in loop if there was a sample which was playing in loop when going to this dialog, which is not very reasonable. Tested on the intro song 21h of course, with a short wav sample looping, I hear only the wav file when doing "play track". Yeah you can't see if the box is checked or not, but it seems to accept a change of setting (the setting is correctly saved in the config file but you don't see it on screen). Yeah I know where it's coming from, it's annoying. Yeah well for now associate something which loops to the 1st song, 21h, and when the song starts ingame, go to play anything in this dialog, it should loop ! Yeah I know, it's ridiculous... ! Already replied. Its main purpose was to find the sound effects commands actually, starting a song the usual way, then testing what a given command does to it. I don't have that, I used a 1.79s wav, and it loops perfectly... After seeing at the end of the post that you posted directly your files : encoding problem apparently, I used 2 players to play the file, mpg123 and mpv and both stop before the end, so if it loops it creates this effect, normal. Maybe switching to cbr (constant bitrate) can work around this, or change the encoder. Actually I don't have any player which can play this file to the end, they all stop before it. Ok, bad news for you, you are by far the one who uses this function the most, and since you didn't test kof2001 thoroughly and neither did I, there remained bugs ! For the little story, like all the last games, its z80 rom is based on garou, but it's an evolution of it, and the 2nd array of offsets was wrong here, I was a little rusty for this stuff so it took me a little while to find something which works everywhere (assuming we don't forget another game). It seems to work now. I don't have this, but I don't even have the neogeo music playing for this game, probably a neogeo bios setting. I tried ingame, but it doesn't change colors... Might be windows specific ? Yep, windows specific, I can reproduce it in wine... ! Oh well... switch to linux ?

Test this is just to test a specific command, displayed in the field just before. Actually it's equivalent to entering a number in the field and just press return, it's tested as a sound command. Useful mainly when trying to understand how the song codes work for a game, it's normally useless for the games you are using, except when you already know a sound effect number and want to play it directly without browsing the others in the top menu. For the rest, I'll look later, I'm having a little break for now... !

Yeah, annoyed by a nasty thread bug in 0.93.2 for those who installed without a previous config file, so here is a fix. Not a few changes except that, 0.93.2 was only 2 days ago, but : - curl should now know how to download a parent set when needed (not totally sure it will work all the time, but it should). - A fix for the sound dialog which got some strange strings inside when you tried to change the driver - And all the rest are memory leak fixes, most of them harmless, but the file selector leaked quite a lot of memory and I hadn't noticed, since it's not used very much it was not a very big deal, but still it's better like that. these fixes are thanks to https://sourceforge.net/projects/memwatch/ Notice that this annoying bug could be worked around by simply quitting raine once using the quit command so that it writes its config file, so it was not so disastrous, but here is the fix anyway... ! http://raine.1emulation.com/download/latest.html