Tux

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.

On 2nd thought, since it's very rare why don't you try to resurrect the demos ? Load your savegame, get ready to reproduce your problem when you are ready to do it, press shift F2 to start to record a demo, it will ask for a name, and place it by default in subdirectory named from the current game name, here it will be savegame/kof94. Choose a name, type return, now it will record in real time all your inputs. When you want to finish, just press esc to call the gui and quit (I think it's enough to just call the gui, but I am not sure, if you quit you are sure the recording is really stopped for good). If everything goes well I'll be able to replay your demo to see your impressive moves and the association problem in the end ! I just tested on bublbobl, and except yet another bug linked to the intro behind the menu and the multi z80 configuration of this game, it worked well. I'll push a fix for this now, but it's specific to games with multiple z80 only, so it's not relevant for you here.

Yeah yeah yeah goes too fast for me. I found pulstar is a type 2 like no other, the only one where in its arrays type 2 are not songs, it's type 4 for this game, and it's the only 1 I have seen so far behaving like this. Except that it accepts all the usual commands like a normal type 2, the difference is just how it classifies its songs, and they start at 80h instead of 20h. It won't be committed for now because I'll test the whole list finally. Ok, committed, a new variant variable to identify these special "type 2", the list of neogeo games which are type2 as comments, a fix for pulstar and ssideki, and I think that's all. (plus of course now the games having 2 bytes for command 14h and those having only 1 byte are clearly identified and separated !). I'll try to see your kof94 thing tomorrow or maybe later, but it seems tricky !

kof95 doesn't seem to have the same 14h command, the signature on which I identify the roms is not always respected, sometimes they made changes and didn't change this signature, it didn't happen a lot though, but this time here it does. AFAIK the other type 2 games take an argument on 2 bytes, kof95 takes only 1 byte here. It's fixed in git, I leave you testing that... Sadly I don't have a precise list of which neogeo games are type 2, to check if some other take this argument on only 1 byte... ! More than 100 games to test, some volunteers ? (plus it requires a debug build to find out which type of association it is...). edit : took the time to test quite a lot of them, in fact the vast majority of type 2 take this argument on 1 byte ! I stopped at pulstar for now because it's detected as a type 2 although its songs can't be tested in the gui for some reason ! I'll continue later. So far the roms which take this argument on 3 bytes are at least : aof3, magdrop3, neocup98, nitd, preisle2, wakuwaku7 what a mess... !

Already told you : if you pass a zip on the command line, it assumes it contains the files extracted from an iso for a neocd game (and so if it doesn't find an ipl.txt in the zip it will output an error). If you want to run an arcade game and not a neocd game, you must pass a name instead, not the zip file, but if you do that on the command line avoid -nogui for now (the fix is committed to git).

Anyway just tested in windows 10 to be sure it works, it does, here is a screenshot to prove it : (tested also with the iso contents extracted to a zip without a cue file).

exact command line ?

well it works for neocd games ! It's not windows specific this time. And it works if you don't put the -nogui. For now, just don't put the -nogui thing, I'll fix it later... !

- An amazing bug was fixed which made it impossible to run a game from the command line in windows... and it's been here for very long. Does it mean that nobody use frontends with raine anymore in windows ? - Big acceleration in the console for mouse tracking (which displays some underlying text in reverse video), and scrolling speed once the window has reached its maximum size (actually you don't even see it scrolling anymore, but the result seems good). Also added some colors and sorted the commands for the help command. - Improvements for the sound associations for real bout fatal fury and samurai shodown, hoping it didn't break any other game... !!! Get it from there : http://raine.1emulation.com/download/latest.html edit : I forgot to commit the sound association fixes to git, so they were not included in the linux binaries. I just rebuilt them because of that, 0.94.4a, linux only, windows had them.