Tux

No luck for you this time, both are working fine here with the latest released build (0.64.8-3). For dstlk with 64 Mb of ram avsp with 128 Mb of ram. No idea what your problem is, but it's working here. These 2 games were also affected by the stupid bug which affected cybots, but the same fix works for all of them.

In this case I doubt triple buffer would ever be fixable. But notice also that it slows things only if you enable vsync, and it's not really required for most games (it's about removing distortions which appear mainly during horizontal scrolling). At least with some normal display, but even on my old 17'' crt I didn't have any distortion with most games while not using vsync. Also about speed some neogeo games probably use more than 256 colors, watch the Pal: display in the rdtsc display (f11 3 times), if it's not 0% it means there are more than 256 colors to display and it becomes unefficient in 8bpp. But of course 16bpp will probably be slower in dos. It's very different with modern rendering... ! EDIT : I just added the ability to save frame_skip setting in games.cfg, but actually the ability to save screen settings in games.cfg is disabled by default and there is a comment in the changelog from antiriad who says he didn't like it. Since this setting has remained disabled for ever actually, I'll keep it disabled by default and you'll have to edit raine.cfg to set manually save_game_screen_setting = 1 (it should already be inside with = 0). (I have no idea why he didn't like it, and nobody never needed to use it in all this time so I don't feel like investigating now). For now it saves most screen settings but not frame skip so you'll need an updated binary for that... I added the setting to save per game screen settings to the gui, but not the allegro gui !

Ah it's your choice. I guess the very vast majority of filenames are those used by mame... That's all, zip 7z and uncompressed of course.

1) I know it was related to some hacks in allegro, but I don't remember how it worked exactly, I would have to make some tests. To make sure it works as intended, test with 0.28, that is the last closed source version and with this one you are sure to have correct allegro hacks. 2) Yeah frame skip by game is reasonable also. For "neo geo rasters" I am not sure because I doubt you could make them work well in any game on such hardware, so a global setting makes sense here. For "no frame skip" well it's cheating in this case because the game slows down and can't maintain the speed at which it was intended !

Ah, you just meant you didn't understand what it stands for ! These are just the possible names for the zip archive (or 7z, or directory) !

Good luck then !

I can't find any "archive ()" in the listinfo output... even tested in windows, but no luck. Could you give the few lines around it then ?

Ok, just added the option to change the language in the "Options" menu, but in linux it requires the locale of the desired language to be installed. I guess in windows all the locales are already installed anyway. For poedit, it's very easy, just drag and drop raine.pot on it, you'll get a big button at the bottom "start a new translation", click on it and you should find your way from there ! EDIT : sorry for b2b5 & b3b6 : b1, b2, b3 ar mapped on byte 0 when b4, b5, b6 are on byte 2, so you can't map any combination between these 2 groups, it must always be on the same byte. For b1b2, I can do it though !

Toi much translation work ? Take care !

That's what I call pushing your luck... By the way remember that some neogeo games are really hungry for memory, thiere are some games which require more than 64 Mb of ram !

with all the bug reports from the other thread your dos version should now be 0.64.8-3 ! The last bug fix is about listinfo, if you don't use listinfo you can ignore it !

Ok, for the bad link, sorry that's partly because I did this in a hurry last night, and partly because the new setup in this server forbids to use rsync with ssh. with rsync I would sync my directory in a blink of an eye, but with the ftp we have now it would be too slow, and so I have to upload the files one by one, and mistakes happen sometimes... For the weird listinfo, well thanks to take a look ! Clearly this function has not been used by anyone for quite some time now, it's a good thing that somebody finally cares ! For info it was not that the rom names were forgotten, it's rather some special loading commands like FILL or REGION_EMPTY which were not understood correclty by listinfo. I updated the binary again, it's now 0.64.8-3. And this time I'll test the links !

New dos version there : http://raine.1emulation.com/download/latest.html 0.64.8 brings nothing new for the dos version except these fixes for problems which were there since 0.64.0 actually !

I had not thought about making it a per-game setting, good idea in your case of course, I'll have to have a look. By the way I think you probably have the bug found by the guy in the 0.64.8 thread (not tested yet), try to launch cybots for example, it should freeze at start. I'll post an update later then...

I am cursed ! Anyway thanks for the list, I can confirm for at least cybots, I'll look into this... EDIT : it's fixed ! It was a crazy day, 30th december of 2014, I was crazy enough to try to clean up the memory map of cps2 and thought it worked... Of course there were lots of games that I didn't test, too many of them, and you just found them ! It takes removing 6 comments on 6 lines to make it work again... Oh at least it took 8 months to find the problem ! Oh well I might make another binary later then ! (tested the 3 games, everything is fine now). Ok uploaded the fix, it's now 0.64.8-2 ! (only on the name of the archive, not the version reported in the about dialog). Thanks again !

Too many bugs in 0.64.7, so here is a quick fix for : - no more stdout.txt file generated when launching the program - the shaders don't turn the opengl interface to black anymore - controls using the command.dat graphics can be changed again (0.64.7 was just exiting in this case). Also the command.dat graphics are a little better, and I managed to add 1 last shader, not totally sure it renders correctly though... And added a few combination controls to cps1 and cps2 (not a lot). Thanks to the testers who quickly spotted the problems !

For the translations you don't enable them manually, they detect the language on your system and if some translation is available it's displayed. I am thinking about maybe adding a setting to keep english for those who are used to the short cuts because it changes all of them of course. Since you don't have a spanish or a french system you can't see anything... maybe it's time you contribute a few strings from your language to see the difference! For your crash no idea, I have messed a lot with the inputs since the release and no problem so far, I can always test in a new folder... EDIT : actually it's not a crash, it's easy to reproduce, it just quits because it doesn't recognize the new input (command.dat is interfering here). You are probably the only one who found this because most people use the old config and so they don't need to remap all the controls all the time ! I thought I had tested this, but I have forgotten, thanks for noticing ! By the way : I have added 3p and 3k for cps2, mainly because they are already in the listings of the command.dat inputs, but it's impossible to add 3k for player 2 in cps2 (at least for ssf2, but probably for all the games using these 6 buttons) because the wiring of the game is crazy and the 3 last buttons are not mapped on the same byte. There is at least a limitation in raine for combinations, the inputs must be mapped in the same byte (1 bit / input). Oh well, it will be harder for player 2 ! EDIT : for now, just cps1 2 buttons added B1+B2 (actually there is a 3rd button for final fight, but it's unused ?) for cps1 6 buttons added b1+b2+b3 (3p) for cps2 6 buttons added 3p and 3k that's all for now. Actually from the command.dat there are very few 2 buttons combinations, so it seems overkill to map all possible 2 button combinations when there are so little actually used. Also fixed the mapping of new inputs of course and improved the representation.

I like its style, it was drawn by Antiriad by the way, it's based on the default allegro style but with some improvements. But it's really absolutely horrible to program ! Anyway glad everything works now !

I guess you are talking about game specific settings ? Yeah they are saved in games.cfg in sections using the short names of the games, no need of the source filename for that. Nobody had the need to use the driver name here instead so far, so... ! For stdout.txt, no I don't like it so I won't keep it like that, but it's something you easily forget, and I need to make a new binary to fix that, not just update SDL.dll, so it will be for next version... Actually I try to use gentoo ebuild files to avoid to forget the settings when recompiling now, but it was my 1st try using this, so of course I forgot about stdout.txt. It's updated to remove it now.

Ah yes, spoke too fast, sorry the config is not read and restored for neogeo in dos. I guess I'll need to make an update then... EDIT : it's done, I added 2 checkboxes to the game setup dialog for that, the 2nd one is a bonus to allow/disallow speed hacks, you shouldn't have to touch this one, but anyway... Who would have believed I would update the cursed gui in 2015 ? I still hate updating this code, but since these were only 2 ridiculous checkboxes, I did it... And this time the config is saved and restored. EDIT 2 : and re-uploaded the dos 0.64.7 with this update. Since it's something already available in the normal 0.64.7 version, there is no need to change the version number !

The 16bpp that you see is only the tip of the iceberg, there are a few settings which are changed when going to the gui , for example if you keep double buffer then you have to draw the mouse pointer yourself or otherwise you can't see it anymore ! Another solution for me would be to create a full opengl gui, which wouldn't be a bad idea, but it isn't super easy neither ! So the best fix for now is really to use a standard window !

Of course it can be done, but you are right, we shouldn't add too many combinations, I'll test this and see how it goes. How do you find the command.dat inputs in the controls menu now ? By the way there seems to be a small bug with the new shaders code, it makes the overlay interface strings black if using the opengl overlay interface, which makes them unreadable. Maybe it doesn't happen for all video cards. For now just don't use the opengl overlay interface if you use this.

Yeah I know it'a actually the main problem of the gui in dos, most of the time adding a single button is a mess, where it's extremely easy to do with the modern gui. I'll see if something can be done without too many problems. Meanwhile you can do it by editing raine.cfg, normally you have a [neocd] section in it now, this setting is "disable_irq1", so to disable rasters you must have : [neocd] disable_irq1 = 1 By the way I re-uploaded the dos 0.64.7 version without the 44100 Hz hack, so you should be able to use 44100 Hz now if you re-download it (but it will be slower so it's probably not a good idea).

Yaah it's a sdl-1.2 bug normally you shouldn't see any switch change (these modes use the same timings so there should be no switch at all). The best fix in the lonng run is to use sdl2, but it's easier said than done for now, maybe later. Meanwhile use a fullscreen window instead of fullscreen, eventually without borders, it will feel like fullscreen but without the annoying switch.

Actually it does but I rebuilt sdl lately and forgot to remove their defaut setting which sends all output to the stdout.txt and stderr.txt files in windows. So you'll get the output of -listinfo in stdout.txt. If it's a problem I'll rebuild sdl with the correct configuration this time... For the source file, true, you have to use -lsf with a game name for that. Does it matter to have this for the whole listing ? Also I slightly modified the output of listinfo a few versions ago to include the region of the roms, it shouldn't change anything since it's at the end.