Tux

Wrong directory, my bad !!! 1st time I did that, I must be tired, it's fixed. I didn't look into releases on github, but 2 binaries to release on 1 site is already enough to make a mistake clearly, so I'll avoid to make things even more complex. It would be nice if there was an automatic way to generate a binary package on github, but with all the dependancies and the fact that it's in windows, it's unlikely.

There was a big bug related to cheats in 0.94.6, some games lost most of their cheats because of it, so that's the main fix of this version, and if you don't use them you can skip this update if you like ! Still about cheats the mouse didn't work in the cheats dialog and for some reason it took more than 1 year to get noticed, I know I use mainly the keyboard in raine, but it's strange nobody reported it earlier ! And the new kof clones get some cheats too. Except that mer-curious continued his quest to fix the texts of the interface, since I didn't update the translations accordingly yet you might see some english text appear in some places if using one of the translations. That's all, get it from there : http://raine.1emulation.com/download/latest.html

No you didn't understand, it was about all the same dates which showed up for you, and a little less for me but here too. This is obviously a bug because these files were accessed by something else than raine, here windows probably while copying things. So it won't try to guess the last usage date of a game from the access time in savedata for windows from now on, but if you initialized it already, it will stay, this stat is saved in the stats file in savedata, remove the file if you want to restart from scratch. Yeah just seen that, it's merged. Which shows that you probably didn't use the cheats a lot until now, and that I actually always used the keyboard ! Nice find, no idea why the mouse doesn't work, it's right that this dialog is quite special, probably something it doesn't like there, I'll have a look later... edit : it's fixed in git, the stupidest bug ever, a 1 line fix, it's there since march 30th, 2021 ! (it was added because if there is a comment for a cheat which is too long to fit on the status line at the bottom of the screen you have to click on it to see the whole comment in a message box. It's the handling of that click that totally broke the mouse in the dialog !). Lol, yeah I had missed it. Very minor issue in the game yes, but in the code probably not, the raster stuff is always a real mess, so considering that it's extremely minor in game, I'll pass for now, thanks ! (fbneo didn't have too much trouble to make it work, it's the mame code without modification for that !).

To make a precision : it's not exactly windows itself, it's the fact that these access times are updated too easily : - you make a copy/archive of the whole raine directory -> all the files inside savedata will have their access time set to current time - even worse : there is a symlink emulation in mingw64 by default, you want to make a symlink of savedata to a distant location : here again it's treated as a copy, so all the files inside will have their access time set to current time. I don't make often copies so I thought I would have at least some reliable data here, but no, this access time is changed too easily without noticing. So yeah the best is probably to just disable that for now, you'll start from an empty list, it avoids unnecessary questions.

Well you must have some data files from these games in savedata, and they were accessed all at the same time, which is quite surprising indeed ! I didn't check that in windows, but I assumed it worked the same, I'll go checking it to be sure. Why have a static display ? It wouldn't change anything to the sorting, it's still the date the thing was played which is stored, it just displays the time difference between now and this recorded time. Before you report it : there is a bug with cheats in 0.94.6, because I added something to the console to have comments starting by ; or # anywhere in the line, except that mame enclosed a lot of # between " in its cheats, so these are strings and should be ignored. I didn't think about that. Because of that, a lot of cheats just disappear, like all P2 cheats for kof99. It's fixed in git. After checking : it seems windows is totally crap to handle the access time, so the best solution is simply not to initialize at all the recent games in windows, and just ignore their crazyness. This code will be removed in next version, sorry for inconvenience, I should have tested that, but I don't like very much testing in windows... !

- Finished galaga, savegames are more reliable and added a cheat to select the starting stage - revamped the "most played games" in the game selection dialog, now you can choose between "most played" and "most recent", which opens a new dialog with all the games you played. The list of "most recent games" is initialized the 1st time from the dates of the game files in savedata, if you kept them. - 5 new kof hacks found by ffman1985. These are quite good hacks, it's for kof super fans only of course, and most of them can't be found in the internet archive (but kof2000ps2 can !). - a few fixes for the console - mer-curious changed a few texts around the interface, and I updated the translations so they continue to work anyway. Hey, it's been quite a long time since I had 2 people contribute to a version, thanks guys ! Find it there : http://raine.1emulation.com/download/latest.html

I don't think it's mandatory to create a branch for a pull request although it's often done... sound_options.cpp ? Well that's what happens with so many PR, I might have missed one. Well I checked your patch-1 branch, it was about gui.cpp, and your main branch doesn't contain any commit from you, so I don't know where this commit is. It's good, I could retrieved your changes from github, you just won't see your name in the from for the commit, but I cited "mer-curious" in the comment, and updated the locale files too. And the reason why I missed is because I merged all this manually because there were too many, I saw they were named as patch-1, patch-2, etc... so I didn't try to check, I just got all these patches, and missed this one because it was named differently. Next time make all your edits in the same branch then make a pull request for this branch alone, it will make things easier, if there is a next time !

Well it would have been better to have 1 pull request only for all these changes, which would make only 1 commit to merge, but considering the conditions in which you did that, I guess I have no other choice than to accept that... ! There is a magic command for that when the files are on your disk : grep, it goes like this : cd source/sdl/dialogs grep -i "load game" * -> game_options.cpp: TMenu *load = new TMenu(_("Load game"),menu); -> game_options.cpp: { _("Load game"), &my_load }, This is in the description of a control, so it's in source/sdl/control.c. What do you want it for ? Or just don't change it, I am not going to look into 2 places for the savegames ! Ok, I'll go looking at this ton of pull requests then... ! Merged all this manually to be able to merge all these commits in just one, I made the mistake of merging the 1st one from the interface, so the repository had a commit that I was forced to overwrite shortly after, but anyway. Also updated the locale files so that all the translations continue to work. I should at least update the po files to merge the new strings, but I forgot everything about these commands, I guess I should investigate one day...! Anyway it's merged. (and congratulations for your impressive determination to have this done !)

Wow, it's rather bold to want to try to make a pull request without compiling... you are sure you don't want to compile, even without understanding the c code it should be possible and would make things easier for you. Anyway if you want to try, from memory steps are : 1) take a github account, I think you said you already have one to post comments 2) go to the raine page, and click the "fork" button on the top right, it will propose a name for the copy of the repository on your account, you can accept it, you have a copy in your account now. 3) go to the freshly made copy, and clone it to your disk, I don't think you can edit files directly from the interface of github at least, that's the point where it's much easier if you have the tools for that, usually it means installing git, which is installed by default if you install mingw32. After that you open a terminal, type git clone address where address is the address you get when you click on the big green button "clone" from github on your fork page. Visual studio probably also installs its version of git, but I find there are too many options everywhere in visual studio and it tends to be messy. 4) do your changes. Here again, it's easier if you have some dev tools, I use vim usually in linux but there are other tools in windows for that, I think visual c++ has a good interface to git, but I don't like to use it so I can't tell. These tools make things easy to locate something specific in the sources to change it. Without them, well the main menu is in source/sdl/gui.cpp, and all the other dialogs are in source/sdl/dialogs (the file names tell what is inside !). Your changes are only about changing some strings so it's possible to do it without compiling, but it's bold for sure. 5) commit your changes, it's about using the git commit command, it will ask you a description, validate the description, and it's good. Then git push to push your changes to github, they increased security on github recently so they require ssh keys or other strong methods of authentication for that, they have a dedicated page to explain that. 6) if you reached this point, it's done, you can use "pull request", I don't remember if it's on your fork or raine page, it must be on your fork, it looks at the recent commits and proposes some defaults to you, add eventually some description and it's done. It would be quite a feat if you succeed to do that, so I'll be forced to accept it of course ! There are ways to view files from the interface but I don't think you can edit them from the github interface, but maybe I missed something. Good luck, if you fail I might look into this later... but if you succeed, you should really follow the tutorial on how to compile to be able to compile your version... !

I'd say it's too bad you can't make a pull request on git, because all these changes are minor and wouldn't require any coding skill, they just require time and determination. For me all of this is minor, I might take a look, but it's quite boring, so motivation is very low. Plus changing a string here might break the translations, even if it's probably minor. I was right to sleep on my changes for the "most recent" and most "played" games, I have some new idea on how to initialize the "recent games" the 1st time. I didn't do it first for the very rare cases where there might be a bad disk cache and initialization takes too much time. But it can be safety be done when raine is launched, and these settings updated only if there is not any info on "recent games" already saved, so even if there is a slow down it will happen only once, and here it's not even a slow down, I guess it will go unnoticed everywhere... So this option will disappear from the gui, and it will become automatic, much better ! edit : just did that, and fixed the category alignment issue you found. I had thought about that when creating the dialog first, and never looked at it twice actually, I just reserved the max width for it based on the longest game category we had, it doesn't show that much because it's a variable width font. Anyway now it just uses the actual width of the current category to display instead of that. Notice that for the info on the left there uses a margin, but I forgot the margin for the right aligned info ! I guess I'd better leave it like that for those with small screens anyway, eventually remove the margin on the left.

Ok, it's done, the list directly in the header of the game selection dialog is gone, instead you have now "Recent games" and "Most played games". It displays the list in 2 columns with the times / number of times played on column 2, which means you won't see any of this 2nd column if using a vga window because these game names are way too long !!! But since the list is sorted, and you'll probably want the 1st entries anyway, it's ok even without seeing the times. Switch to fullscreen if you want to see them. Also added an option to initialize the "recent games" from the access time of the files in savedata. It's the access time which is tested (last time the file was read), in a file selector it's usually the modification time you see, which is older. And if the time becomes > 1 year, it counts in years and does not display days or times in this case because they don't have much meaning anymore. This should finish this option for good this time, but it's right it needed some improvements ! It's pushed to git. edit : on 2nd thought, limited the names of the games in these 2 dialogs to 40 characters max, much better readability. Also the desktop is also resized now on windows resize events (the reason why the drawing was not updated behind the dialog after your window resize).

- the confusing look at reduced size : well it's mainly because there are games which are way too long, the solution would be to cut some part of ti, but anyway since the most important part is at the beginning it's still usable. - the times you don't like : no luck, I quite like them. Yeah what is counted is more the game usage than the actual play time because it's impossible to know when the player is actually playing, but I find the info quite fun to have sometimes. For me my current record is 1 hour 29 on battle bakraid, it's because of the time when I searched for its hiscore, it took more time than what I thought !!! Also if you reach 24 hours, it starts to count the days, let's see if someone reaches such an insane time... ! (well when you see the insane records some people have for the official hiscore records, yes they spent some insane amount of time on these games for sure !). But yes I agree, an option to choose between recent games and most played could be handy, I'll try to add that for next time (but of course since currently the time a game was last played is not tracked this will start from scratch next time). The effect misaligned because you changed the size of the window while the dialog was already opened : yeah super minor glitch, might take a look or not, it's super minor at this level, most people will never see that.

Hummm, don't loose ? Well I took 5 minutes to loose in turfmast, bad choice it would have been faster in crossed sword 2 probably, and inserted a new coin when the countdown began, no problem, I was back in the game... ! That was with the standard neogeo bios because it's on a laptop, not my usual machine, default settings arcade of course. I'll test crossed sowrds 2 later... edit : And I don't have any "crossed sowrds 2", just a "crossed swords" that's all. And it was almost default settings, except speed hacks disabled in neocd/neogeo options because I think turfmast is unplayable if they're not disabled.

Yeah galaga after all this time, talked about adding it long ago, I didn't forget, it just took me very long to find the motivation. Read the details and how to have the explosion sound there : It comes with an update to history.dat and hiscore.dat, which makes the archive slightly bigger than usual. There is also a cheat file. except that : another fix for multiple cpu games which tend to hang (got the case with bublbobl, what a shame), I really hope it's the last time, it should. And another one for -nogui on the command line, when trying to load a neocd game (it worked with normal arcade games). This combination was probably not used by lots of people for sure. And a fix when taking screenshots from a window with an odd width (like 773), it could produce a very distorted image. I have no idea how my window reached such a width to produce this result, but at least it allowed me to fix one more bug ! And lots of improvement for the sound associations, new games supported, and improvements for quite a lot which were already supported, find the details in the forum if you are interested. There was also a fix for the automatic "skip silence" used for audio tracks which could eat the beginning of the actual track in some situations. (thanks to ffman1985 for all his tests and suggestions) Find it there : http://raine.1emulation.com/download/latest.html

You 're really a desperate case on this you know ? It doesn't have to be unzipped or anything, it's just exactly the same loading method as with the gui, which means the rom whose name you pass on the command line needs to be in 1 or the rom paths, otherwise you can also use -rp to change the 1st rom path on the command line... This is some super basic stuff, there is nothing complex to understand here... !

A very last time : if you pass a zip on the command line (or a 7z) it's to load a neocd game ONLY !!! If you want to load an arcade game, then you must pass the name of the game instead (short name preferably !).

It was originally an idea from Stephh a long time ago, to see if the emulation could be faster on raine for a game like this one ! It took me years to find the motivation to do it, but I decided that finally it was more than time for that. In the end it's a bad choice for a speed test because it's extremely sensitive to the nmi frequencies. Plus it's some old hardware, on modern hardware it's easy to emulate nowdays. Still these nmis gave me some trouble. In the end, it's still a nice game to have today, glad to have added it ! Ok, it's finished now, so the particularities of this driver : - in the original hardware there is a chip whose only purpose is to create the explosion sound, it's a kind of dsp on 4 bits, a rather complex chip if you want to emulate it accurately, all that just for a simple explosion sound ! Since I am not bent on accurate emulation and I prefer some simple code when I can add one, there are 2 ways to get an explosion sound in this driver, and none use this very special chip : - you can download a galaga explosion sample from anywhere, like there : https://freesound.org/people/SgtPepperArc360/sounds/341930/ (you need to be registered for that), then save the sample as "galaga_explode.wav" in raine directory (you can eventually convert it to mp3 or ogg to save space, the 3 formats are accepted). - or if you have the galaxian emudx sound file, it will take its explosion sample from there - if you have none of the above, you will just not hear any explosion sound, but you'll get all the other sound effects !

I don't know how to explain this to you after this !

At least try notepad++ if you want to use notepad... !

I am not going to complain at least you are using git, which is very rare around here ! Thanks for finding it too, but it was fixed in the long process sorting all these type2 games yesterday... !

And I can confirm it's already fixed in git, just update your git. The sequence is here : cmd 14 mode 0 cmd 5e mode 2 cmd 1c mode 0 cmd 25 mode 2 Before command 14h was taking 2 bytes as argument, so they were 5eh and 1ch here, leaving 25h alone, so it was taken as a song number. Except now 14h takes only 1 byte in the last version.

Well it's done on an old git, do a git pull to update your git and restart. Your version has a kof94 which takes 2 bytes as argument of the 14h command, it's 1 now. Since your 25h is just after that, it's probably the source of your bug, so you can assume it's already fixed.

It's called "random seed", the random numbers depend on an initial seed, if you restore this seed you have the same sequence of events, here it was missed. You can either try the debug build, or try a demo in 32 bits (I am not 100% sure the 32 bits version would work, but it's more likely than here). And it's hard to tell what was not saved here as the random seed... !!! I have no idea what this code uses as a random seed, but it's very strange that it's not saved... For now, absolutely no idea, it's probably safer to use the debug build in this case, it's likely the same behavior will also be in the 32 bits version, it looks like some external source of data which is not saved, although I have absolutely no idea what it is.

Like a savegame, except you use shift + f4 instead of f4. Thanks, I'll take a look... edit : well sorry but same thing as mer-curious. I switched to the japan aes bios since it seems to be the only way not to get this corrupted graphics, then I associated a song with 2bh which seems to be the background song during what you recorded, and then everything plays normally until the demo ends in pause mode, the song was never interrupted or changed. .. It's with current git version 64 bits, since this demo is for 64 bits, but it probably works the same with latest 0.94.4. So I don't know what you did to have a problem here... ! (and these demos are very convenient in this kind of case I should think about them more often !) The behavior seems to be strangely different with your custom rom, but it still doesn't change anything to the music. And if you want to reload the demo when it goes to pause, release the pause first, there is a nasty bug here if already playing a song. And I never see any 24h command on my side, so there is no switch to this song, something is wrong somewhere... ! I wonder if the 64 bits demos play correctly then, 1st time I see one actually, usually I use this in 32 bits (32 bits is way more convenient for debuging usually because you can compile without optimization but still have the speed of assembler). Assuming the demo has a problem since you can compile your own version we can try the other way around then : start by building a debug build (uncomment the line RAINE_DEBUG = 1 in the makefile), then uncomment the line 408 in source/sound/assoc.c which reads : printf("cmd %x mode %d\n",cmd,mode); to see the sound commands passing. Then run your debug build from a terminal (the mingw32 terminal in windows is ok) and do your testing. When the song changes call the gui to stop the game, you should see something about song in the output of the terminal, send the last screen of what was printed and it should be ok. Good luck, but I can't think of anything easier to reproduce this in these conditions. It might be a good idea to fix the demo anyway but we might loose too much time on it for now.