Tux

You owned a 3do ? Just heard of it, never seen one ! It was quite famous in its time... Sorry been quite busy lately, didn't have any time or motivation to do new stuff for now, will probably return to it later... !

I don't know, I didn't write this driver, and I don't know this particular game ! I guess Antiriad didn't have any special interest in this game and just never tried to add it that's all. Is it specially interesting ?

It was simply because you keep on reseting your config file and you forgot to disable speed hacks. Speed hacks are disabled by default now (for neogeo/neocd), so that I don't loose time again on something so stupid. (and since the windows binary I use for quickly testing in linux doesn't really have a stable config, it also allowed speed hacks, and I didn't realize it was the problem here before quite a long time !). By the way I found a small problem I didn't expect : there was no sound during the neogeo logo while the game is booting, it's related to a very old change which was not supposed to have this effect (related mainly to the 6502 !). I fixed it, hoping I didn't add more problems, but afaik it should be better. This one is quite technical, it's related to the way the scanline counter is read during a "normal" frame, that is a frame which doesn't use scanline interrupts.

Looks like yet another windows specific bug ! It gets tiresome isn't it ? No idea where it comes from for now, I get different results and I don't know what changes them, sometimes the screen is all black when pressing start, sometimes it's only the sprites. No idea ! Easy solution : linux version ! I don't know what this craziness is again, it happens even in debug mode... ! Interesting question also : is it new ? The important part is "no recent game yet", this text has not been updated but there is nothing in options to change that now, it's outdated. No need to care about that, you can see it only when you have played no game or when you remove your configuration which never happens for normal players. Maybe, just add https in front of the links then ? I'll change that just to be sure. In this case it's an over reaction from firefox, the fact that it's https doesn't change its contents. I hadn't noticed I had inverted them. It was because it's generated from a script usually, but the x at the end of 92x made things unusually complex and it didn't go as I wanted so I found it was faster to manually enter the links and here is the result... I guess I'll spend a few minutes on this again then... ! edit : reverted to the old system, the links are relative (except to github of course), so you'll get https if you display the page in https, the problem is probably because I posted the link to the download page in http and not https, try this one instead, but it's just a stupid warning from firefox here (that's called too much security when it becomes that stupid) : https://raine.1emulation.com/

No the sound driver won't go away, there are cases where it can be useful. The reason why the frequency can change is that when the driver is changed raine asks if the driver has a preferred audio sample rate, and if there is one, it chooses it. It just means your ds4 prefers 11 KHz ! By the way 11kHz is not so bad if you stay on digital sounds, that is sound where devices use wav like sounds. It gets worse if generating sounds, for most "midi" music it becomes generated sound. Anyway it's quite rare to have a sound driver with a preferred frequency, even more when this frequency is < 44100. For me here I have only one which has a preferred frequency, and it's 48 Khz ! You should just have paid more attention, but as I said the sound is not so bad in 11 KHz if you stay in some specific games, and by chance the kof games are in this category. It's funny to see how people get attached to 44.1 Khz as a kind of grail these days. I learnt not too long ago that the "chromium tapes" we had been using in my childhood and which were considered top quality at the time, rendered sound at around 33 Khz only if I remember correctly, and we would never have guessed that at the time... !

Didn't I mention that this file is very sensitive to what's inside and is not supposed to be edited by hand, even less copy a file generated by something else here ??? No other comment about that, the parsing would fail at the very 1st line of your file here ! Easy fix : just don't do that ! (usually people start by choosing a window size, usually fullscreen and don't ever change after that). I'll look into that later...

Yeah well if I had someone who took care of the windows build and wanted to fix this kind of details, it would be no problem, but as a matter of fact I have only me, and really I can't care less about xp now. And the drawback for other users is that from memory it's the access to some function which is impossible because it's a kernel function, and of course the xp kernel hasn't been updated for ages, and this particular function is about the timing for threads if I remember correctly it's in winpthreads.dll and the said function isn't even used directly in raine, so it's minor, but now sdl2 uses threads and it's probably a good idea to let it use the time granularity it wants. So except if someone comes with a super new argument, we'll leave things as they are. The old dll pack, 0.92x still works with xp for those who are interested, and sdl2 isn't even too old in this one because I updated it not too long ago. There is a libmuparser.dll which is not necessary anymore but it's not a problem. So xp compatibility officially stops here because not enough people care, and it's becoming too bothersome to maintain without anybody to help.

if you were wondering what the small bug fixes were, these were : - an old bug in sdl2-2.0.20 which obliged me to make a workaround seems to have disappeared, the checkboxes are all green again in the windows version of raine (there was exactly 1 white line before to work around this bug, it was barely noticeable). - move "preload ips" to the game selection dialog, idea from mer-curious and he was right on this one. - the crash when there is an empty ips folder and you select anyway "preload ips dat file" and then click on the ".." which appears is fixed, you won't even see the .. now, you'll just get an error message telling the directory is empty !

Or just give up this xp compatibility for good ? Who still uses xp today, except maybe in some remote world places where they don't have much choice ? I forgot which dll it was exactly, and I was almost sure it would be good this time. I am tempted to just drop that, you are the only one who asked about xp, it was fun because it was not too hard to do at the beginning but it starts to be an annoyance now, and if you are the only one testing it, and just for testing, it's not worth it. If anybody else is interested in xp support, post, and explain why you are still using xp today, otherwise I'll just drop that, and good riddance !

There are the git changes log, a little technical but manageable... Otherwise just the posts I make here.

This one kept me busy for a few days, the windows version looses time in the conversions between double numbers and ints. It doesn't happen in linux, and I don't know the exact reason, it's probably related to mingw32, but anyway the fix is to merge muparser into raine and change its base type to "unsigned int". The consequence is that float numbers are not recognized anymore in the console, I'll just hope that no script used them, but I don't think any did. It goes with a dll update, a few dlls were updated including sdl2, so it's advised to update for all windows users, the new packages are dlls32-0.95.7z for 32 bits and dlls64-0.95.7z for 64 bits. The linux version didn't have this problem, but since I don't want to maintain 2 different versions the merge is done there too, and so raine doesn't need muparser to be installed anymore in linux. We get a very small speed improvement in linux too because it allowed me to make a few more optimizations since no type conversion is needed anymore now. Except that there were a few small bug fixes for the recent 0.94.12b, but the really big thing is the merge of muparser inside raine and the gain of speed it brings. https://raine.1emulation.com/

Yeah quiet around here these last days for a change... ! I finally found the reason why the windows version was slower for scripts, and I have a fix, I sent it by pm to ffman1985 so that he checks it, but he hasn't been reading his messages for 2 days ! Oh well, at least you are in linux, so you don't need this fix, the linux version doesn't have this problem. It's a crazy story about double to int conversions, I assumed they took almost no time with modern cpus, and it's the case in linux, but that's the very reason the windows version is slower, and I can't explain why, but it's a fact. The solution : merge muparser into raine (the doc encourages people to merge it in their project), and change its base type from double to unsigned int. It works, and I finally get the same speed in linux and windows, the only drawback is that float numbers are not recognized anymore in the console but it shouldn't be a problem normally. I didn't decide yet what to do if he doesn't come back in a reasonable delay to test this, since it's a windows problem only I can just ignore it, or release it without any more testing, or simply commit it to git and start to work on something else. I think I'll probably choose the last option.

You compile from git, so do it for your version, you just have to delete or comment out the line "stop_scripts()" in source/emumain.c After that you can eventually commit it to be sure you'll keep it : git commit source/emumain.c it should stay for long, this area of the sources is not modified often.

As discussed earlier after you asked that for the hidden scripts and I replied it should be done for all the scripts because it's what a reset is supposed to do. There might be some way to make some chosen scripts resistant to that, but I am not sure it's a good idea, it would add to the complexity without any obvious benefit, a reset should stop anything related to the current emulation and return everything to its default state, that's how it works.

I was gonna quote your 1st message but it's just impossible, you can't insert a reply in the middle, and you can't delete the end of the message, if you do it restores it in place of what you typed in the end, this stupid editor just made me loose a few minutes for nothing. Anyway !!! 1st point about your crash which annoyed me on the .. : yeah it annoyed me because the function has become quite complex after all and it's quite irritating to see some testing stopping here, but anyway in the end I found a c++ way to fix that in just a few lines without too much fuzz so you'll just get your error message now. 2nd point move the option to the game selection dialog : agreed good idea, it's done and pushed to git, but I think the 2 above options always appear even if there's no data, and I don't plan to loose some time trying to hide them when there's nothing. It won't crash anything, you'll just get your error message if you try them and there's no data, so there's no problem here.

I guess without power supply your frequency is lowered to save power, and everything slows down, all easily. Tower here, so stable, but running by default à 1.5 Ghz, the frequency increases only if the cpu load average increases, and raine stays very low on the low average usually, even with your script running it stays at 1.5 GHz.

And I still didn't understand how you got 2 kof97 directories, I can't reproduce that here... About your strange looking window with the big blue area : it's because you are again at the minimum window geometry, 640x480, I should include a setting just for you that would forbid this setting, but anyway... ! It's just that this area reserves at least 224 pixels in height so that the pictures would still look like something (most have a size of 304x224, a few rare ones are bigger, for those they are resized to fill in the blue area). Anyway this blue area doesn't look so big if you have a "normal" window area which would be much bigger than that !

Well I tested, and I am not really convinced, you see the effect of rnd(), the %Misc varies now, but it's not really faster... I return to the normal script for now... (I prefer stable numbers which can be read easily, and the numbers are < 10% even in debug mode here, so it's not worth something like that).

And you just won a hotfix release : 0.94.12b. Mostly for using SLASH[0] instead of '/' to separate directories otherwise it isn't compatible with windows, but except that I had the time for : - Fixed a few stupid segfaults in the console due to the recent script changes - I had forgotten to include some cheat file for the new kof2002 clone, it's fixed. - while I was at it I added an experimental script to block the selection timer in kof97 since it seems it's impossible to find an ips which doesn't conflict with the training mode to do it. It works, but once you have selected your character you must disable the script otherwise the game will never start ! That's all : http://raine.1emulation.com/download/latest.html Notice that for windows their \ doesn't make any sense to separate directories, in normal scripts \ is used to quote the following character (block its interpretation). But it dates back from the dark ibm days when they wanted to make a bad machine with a bad OS so that people would not like it and would buy the super big machines from ibm instead. It failed, and after that they had to maintain their crap for many years, and they never dared to change their mind about \ to separate directories... !

for the last message it might be windows specific, I'll have to check in windows. For the 1st I didn't understand half of what you did, but it looked like you tried hard to break the dialog, and you succeeded in the end. I don't really want to make something unbreakable... ! For now I'll slow down, but I'll start by checking your 2nd error, there might be a 2nd release because of that (a b version).

Frequency in a random number ?! Sounds odd to say the least, I'll take a look later... !

Yeah this version is mainly about the support of these ips files found on the net, the best source so far was found by mer-curious, see his topic on the subject in the forum if you are interested. So the dat files and the ips must be placed in an ips directory that raine will create next time you run it, or you can create it yourself (for linux it's in ~/.raine/ips ). The format is the one already used by these packs of dat files you can find on the net, subdirectories with the short name of the game containing the dat files + ips files related. A word of caution : it's the crazy bootleg world, some patches are not stable alone, and you add to the risk if you enable more than one, raine will warn you about conflicts it finds while applying the patches though. So the 2 ways to apply them are through the command "preload ips dat file" which appears at the top of the main menu if no game has been loaded. It opens a file selector where you can select any dat file you want to add for a particular game in the ips directory. Your choice is saved in this same ips directory in an ini file with the short name of the game. You can either return to this function later to uncheck the dat files you chose if you don't want them anymore or just delete the ini file. Raine will check for conflicts when you load the corresponding game and will warn about them at the end of loading. And the other is once the game is loaded, it can be applied only to code roms, from ips files only, not dat files, and it works only when the rom patched is in the right format, it's very specific and it was the only thing I wanted to add at first before being convinced to add the rest. Except these ips features, you'll find : - a new kof2002 clone, kf2k5uni which was mainly added to test an ips dat file... ! - a new setting to choose to have the profiler (f11 key) to display its % based on sdl2 performance counters instead of the rdtsc. It's a good option if the frequency of your cpu changes all the time, it's a good try if you have doubts about the results anyway. - a new script command : stop, see help in the console for details. That's all ! http://raine.1emulation.com/download/latest.html

Hey good news, one of the conflict resolved itself during the night ! I was just getting tired last night and forgot to check the patches applied to the same rom ! So you keep only the 1st one, the time and training conflict. Ok I think it's finished now... ! And I looked a little more in this conflict : there are 2 parts, the 1st part is harmless, code in common, but the 2nd part is not. Now in this case the patch which "wins" is the one which is applied last, here it's the time patch, so I guess a part at least of the training is broken if you keep this time patch. If you want to change the order of the patches just change the order of the lines in the ini file, notice this ini file doesn't like to be edited by hand, don't leave anything like an empty line when you save it !

The checking code is in place, and too bad for you, it finds 2 conflicts in your collectio The 1st one is between the infinite time and the practice mode, I tested ingame and both seem to work which is rather surprising, I might look better into this one, the 2 might have some code in common then (the checker just checks if they write to the same place in rom, it doesn't check what is written). And the 2nd one is about the bonus characters, it's a pack, and there is a conflict between the 5th and the 6th, it's in the sprites rom so it might create graphical glitches. It's for 2 characters only though. If you reply no to the dialog it quits immediately, which might not be my best idea here, maybe just a message at the end with the list of conflicts would be enough. Notice that it gives the name of the ips file, most of the time without extension because there is no extension given in the dat file, but at this point the name of the dat file is lost, so you have to find it by yourself. I hope the screenshots will show, but they should... Also I added some support for the crc given in most dat files because sometimes the rom name is bad and in this case you can recover with the crc, what we already do when loading a rom so it's not really a surprise (found an example with 2-flash.dat which is a variation on the infinite time you used, this date shares the same patch as your dat so it has the same conflict, but it also has the bad rom name which can be recovered if using the crc !). I think it's not bad for a release, but it's too late for that. And I'll replace the dialog by a list of conflicts at the end of loading tomorrow... ! Notice these guys must like instability to add the ability to combine these patches when 1 patch alone is often not perfect and without a way to check for conflicts... !

And now I have the info in text and picture in the status bar at the bottom of the screen, this part was easy. Now it would be cool to add some code to check if there are conflicts between the selected ips, but I'll keep that for tomorrow... !