Tux

cubeb ? cubeq ?

Some unexpected problems in windows, as usual I would say, a solution is in progress but it takes time... I won't have finished before the end of the week ! (for the gory details, for some reason when calling SDL_OpenAudio the callback is never called, and when calling SDL_OpenAudioDevice, SDL_PauseAudio is ignored and I must use SDL_PauseAudioDevice... ! These 2 combined made me search for a long time ! Apparently everything needs to be migrated to the new audio device api in windows, when there's no need like that in linux... ! I'll do more testing later...) after a new session, all this mess was because the default sound driver in windows is something called "wasapi". Clearly it sticks to the device preferred setting and refuses to convert anything, for me that was 48000 Hz, samples in floats of 32 bits ! Simply unthinkable, I would have to rewrite a big part to handle this kind of samples... Forcing the directsound driver goes back to what we had with sdl-1.2, much better. There was also some allergy between direct3d and opengl : start raine in windowed mode with a game like gunbird. Start the game, then go to fullscreen while the game runs using the keyboard shortcut. Call the gui... and bam ! Message CreateTexture(D3DPOOL_DEFAULT): INVALIDCALL and return to desktop... ! There is a solution to that, thanks to people on the net who had the same kind of problem, there is a hint to tell sdl2 to use opengl instead of direct3d for its rendering : problem solved ! Still a few things to look into tomorrow, but it's starting to look good... And I think the new dlls will actually make a bigger archive because the mingw32 libs use all the optional libs, which would be totally useless here, but now they must be present on disk, so there is a ton of useless stuff to add... ! At least it simplifies a lot the installation when programming raine, binary packages are convenient... !

Yeah might be a way to do that...

Bad day for those who have some complex key configs, most of the key configs have changed, which means you need to update almost everything ! More keys are handled though... The joystick buttons seem to be the same though... Except that most of the work is done, opengl works fine (got a lot of trouble with DrawPixels and the overlay text in opengl which conflict with the sdl2 renderer), as expected the emulation of neogeo rasters is back to normal. Didn't test emudx yet. Still a few obvious fixes to make in the gui, and the console is totally broken, so it's not over, but most of the hard work is probably done now !

1st successful link, lot of things broken inside of course... sdl_sound was merged into raine for sdl2, that's what the authors seem to want, and it was impossible to get a 32 bits package out of their build system (+ no package in mingw32/mingw64 !).

I think this time it should work, I have a working test program for the gui (even if it's basic) and I am making good progress for the rest, even if it's awfully long to do... A patch of almost 900 kb so far, and it's not over, still quite a lot to do ! Things to expect : - no more normal blits ! This sdl2 is really different, there is almost no way to have direct access to the screen pixels like before, it's possible but not accelerated, so advised against. I'll keep the code, might be useful later to combine a scaler with something else, but for now they are gone. Those still in love with normal blits after all this time will have to stay with an old version... ! - the yuv overlays are gone too. For them it's because they have become useless : they were 1st done as a 1st approach to scaling to fullscreen in any resolution without opengl. Well today it's very hard to find a computer without opengl, and the picture with yuv overlays is not so good, so for now they are leaving too, but they are still supported in sdl2 if they are needed one day... So the only 2 rendering methods for now are opengl like before, and sdl2 native which uses either opengl or direct3d behind the scene, but is a lot easier to handle than native 3d programming. What's better then ? Well small things mainly, except in windows where the gui had become unusable without opengl blits, at least it will fix this mess for sure. Except that yes the gui can be rotated when rotating the screen, very easily, even if it's not done yet. Detects when a joystick is plugged or unplugged without relaunching, and it should be easier to assign a joystick to some specific inputs (will test that later). SDL_sound doesn't require any external lib anymore which means less dlls in the archive, good thing. Since everyting is 3d now, we have real hardware transparency, so it's easy to have some animation working in the background instead of a static picture like before. This is already done in the gui test program, just for fun ! There might be some better ways to render emudx games too since flip and rotation are supported in hardware now, will have to experiment. One of the biggest reason to upgrade for non windows users is simply the fact that this sdl2 is actively maintained contrary to sdl-1.2... Ah also it might allow to make an android version... well it would be a non asm version of course, but it should work. Also I hope to still be able to build the sdl-1.2 version at the end, just in case it's needed. I did this kind of update once when moving from allegro, but it was not so violent at the time, sdl-1.2 like allegro was using bitmaps to access the screen. It's not the case anymore in sdl2, and it changes a ton of things. For the gui, it can't update just a portion of the screen, so the whole thng needs to be redrawn all the time, it's very fast so it's working well, but it completely changes the way it works internally. Anyway I hope to see the end of it soon, since there should be bad weather in the following days, I hope to finish it then !

I had this autofire button configured for months, so it would be an extremely rare occurence... screenshot useless in this case. It's probably not random, but good luck to find the cause in this case !

It doesn't make much sense to play with the windows version in wine, I use it just to quickly check if it works that's all. For info it's not the emu which crashes, it's the x server. You should just not use these opengl blits in fullscreen with this version, they are here for the real windows only.

Just tested with sonicwi2, added 3 autofires because I had already 1 for p1 a, configured their buttons, quit, relaunched, everything is here with the right speed setting for the autofire. Did you use the command quit to quit and not closing the window ?

Nice find, well there's probably something weird here, but I can only confirm I have the same problem, for now I can't really look into it, deep inside sdl2 now... ! All I can say is samsho4 has correct soft dips. Ok, I took the time to look into this : it's probably a bug from samsho3 neocd, I guess they were mainly interesting by the Japanese strings, but not so much by the international ones. The specs say these strings should be 12 characters long, padded with spaces, apparently they used tabs sometimes to separate theirs, and maybe a / too in one of the bottom choices. Anyway, I added something to cope with at least the tab, which makes most of the strings readable, much better like that, now you just have to wait until I get something out of the sdl2 build (for now, just a very basic gui test program, but it's a start at least !).

I suggest you try it to see the effect anyway, quite impressive. Try with dimahoo, which looks really "slim" on a horizontal screen, then rotate the screen and behold ! By the way most of the vertical games are shoot'em up that's right, but not all of them. I just added an option to be able to add -rol and -ror on the command line when using -gl to display games rotating on the left and on the right, which gives as non shoot'em up vertical games : - pacman, all its clones, including miss pac man & cie. - arkanoid 1, 2, & returns. About returns it's been broken for quite a few versions, I just noticed it yesterday while checking for this windows asm compatibility. It's fixed. - block block, which I never played - bomb jack twin - Don Doko Don (platform) - Donkey Kong (better with emudx graphics, which are broken with opengl blits in windows, too bad !) - Drift Out - Exciting hour / matmania which is one of the rare games I played a lot with my cousin in the arcades, back in the day, a wrestling game... ! - fantasia (!) - frogger (same comment, better with emudx graphics) - gal's panic - Grand Cross Pinball - Kiki Kai Kai / knight boy - Liquid Kids - Maze of Flott - Mercs (although it's a commando like game, so shoot'em up but not in space !) - Pengo - us classic golf (not as good as the neogeo version) But yes, the vast majority are shoo'em ups, some very good ones being vertical indeed ! And while testing yesterday, I finally understood why there was no progression in the dialog when loading a rom from internet archive : it's because of their server which doesn't send the size of the file before the download. So I added a workaround by taking the list of the files in an index file, and getting the sizes from there. It works, the progression works again, useful for such a slow download, at least it proves that it works and it's not frozen !

You meant p3_b1b2 & p4_b1b2 I suppose ? Because you succeed to have 3 or 4 people playing at the same time on the same computer ? Lucky you ! I found out lately my flat screen can be easily rotated on its side for vertical games, then just update the rotation setting in video option to have rotation = 90, and suddenly the vertical games look a lot more impressive ! Less people, but still impressive ! (ideally we should also rotate the gui in this case, but it was hard to do with sdl-1.2, maybe easier with sdl2, we'll see...). For your special move working on the left but not on the right, don't hold your breath, it's ultra low priority for now, I'll have another look at sdl2, hoping that I am not pissed again at what I find... !

1) still not that, the player plays again, hint : renderer options. But it might be a better idea to just forget about that, it's risky business to disable opengl blits now, there will eventually be a better option one day... 2) default inputs change inputs for all the games which use these defaults, if you never switched any game to custom inputs then it's all the games, that's what you want from what you said... !

1) I never said to change the video renderer... ! 2) edit default inputs or switch to custom inputs and do what you want... experiment...

As I said, with opengl blits the neogeo games using rasters are broken. You can try to disable these opengl blits but it's very hard to use the gui without them in windows currently, so do it carefully, preferably in windowed mode only. After changing the setting in video options / Renderer options just quit raine and relaunch.

After some investigation, this address is a lot less interesting in windows than in linux. In linux all these asm functions go to the same area, which makes sense. In windows, following their motto "why make things easy when you can make them much more complex", they used multiple regions to store these functions, sometimes a region contains many functions, but sometimes only 1. You can get the address of the region using VirtualQuery, but after some tests I need 4 VirtualQuery calls (followed by 4 VirtualProtect calls) to get the same result as what I did here in 0.91.21 in a single VirtualProtect call, and in both cases I can't be sure I didn't forget anything ! So for now I'll keep the single VirtualProtect call, at least it's shorter ! I tested taito f3 (68020), matmania (6502), 68000 + z80 (neogeo/cps1/2), and dondokod for the rotating layer which also uses some asm code from memory. And thanks !

Ok captcomm fixed, it was a typo error, thanks for the info ! (and it didn't make it to 0.91.21 !)

Always the most recent version to use with the latest version, dates are displayed in format year/month/day beside the files so it shouldn't be that hard to guess... !

I'll look for the b1+b2 bad mapping, it's probably something stupid that nobody detected until now. For the assignment mess when you plug a new controller, well there are functions to simplify assigning a given controller to some inputs in sdl2, so if I fix that now, I'll have to redo it differently in sdl2, and really when I see how the windows version is getting broken lately, it would really be a good idea to get at least a basic sdl2 version working... So no promise, and it will probably get delayed then...

Tsss, shortly after 0.91.20, but big fixes again... The biggest one is about the 32 bits asm functions which suddenly started to crash in windows. I didn't know because I test in linux and wine doesn't care about the memory regions protections ! What probably happened is that this new protection came with the update of gcc, like what happened in linux. The difference is there is no /proc in windows, making things more messy. If someone knows how to get the base address of the region containing a given function, tell me ! For now I just used some rough approximation... Anyway normally all this asm code works again, assuming I didn't miss anything. The other big one is that I broke the init of all the neocd games in 0.91.20, sorry, it was easy to fix, but it made a lot of games unloadable ! And the last one is the return of the opengl blits : to fix the asm code I needed to test this in the real windows, and the gui is becoming almost unusable without this feature. So it's back, but this time it's optional, you can disable it in video options / Renderer options / Opengl blits. Like last time, it breaks emudx games and neogeo games using rasters, so it's not an ideal solution, but it's better than nothing, especially if you want fullscreen ! The real fix to that would be sdl2... ! They are enabled by default in windows, and it's saved in the configuration of course. And I also added some test before saving the neogeo backup ram because mine was probably saved at a bad time and it corrupted it. You'll see a warning if it detects it can't save the backup ram. Afaik, it happens only from the test mode. http://raine.1emulation.com/download/latest.html

These are rasters glitches, which are really hard to fix, and since I find these games uninteresting, motivation is super low... But this is open source, anybody can fix things and send patches, I'll accept them !

I was about to protest about the lack of details, but I was able to reproduce that very easily ! Yeah, it's because of a different way to call the same thing : for Musashi it's GetContext, for starscream it's SetContext !!! I made the mistake to try to simplify some piece of code and put GetContext for both, it can't be done ! Oh well... !!! It's a 1 line fix (3 actually because of the #if which goes with it), so I'll probably just make a new win32 binary for that... At least it shows that some people are still able to use the 32 bits binary in windows ! It's related to the neocd init, so it's likely that no neocd game will work with the current raine32 binary, I'll try to upload a new archive for that then... sorry ! Ok, you'll get a 0.91.21 for that tomorrow, which takes also back the opengl blits for windows but optional this time and enabled by default in windows, and it also add a verification before saving the neogeo backup ram... but it's too late to release now, going to bed !

Ok, after testing : the 32 bits versions crashes all the time, could be some new security feature related to asm. But even the 64 bits version is very fragile, when the game has started calling back the gui usually closes the program. Best results with 0.91.18, that is the last version which used the opengl gui (with the known limitations known that the emudx games don't work, and the neogeo games using rasters neither, but it's much better than this crashing disaster we had here !). Since even the 0.91.18 32 bits version crashes when loading a game it must be something related to rights executing asm code (self modifying code). I might have to investigate about this... Well try 0.91.18 64 bits, if you are willing to go with the limitations, I might make a 0.91.20 using the same tricks...

I love this precision : 32 or 64 bits, which romset for example, at which point ? cps1 or cps2 ? There is an option to disable speed hacks for neocd/neogeo, not for cps1/2, it wasn't necessary so far... It's obvious this kind of behavior is not normal and has not been found yet, there are 1070 romsets in raine if I remember correctly, plus I almost never play with it anymore except to code, and it's only in linux, so the chances to find what you are talking about by chance are more than slim ! If you saw this with the 64 bits version, the 1st thing to try is the 32 bits version, as said too many times already, the 64 bits version is still experimental even though it's working better than what I expected already, big bugs are still found in it, like what was found for 0.91.19. (and I almost only use the 32 bits version here !).

After some tests, in normal play the backup ram is "locked" at the end of each frame, meaning it can be saved or removed without problem. The only place I found where it's not the case is in the service mode ! Here the card is left unlocked, maybe it's how I saved mine at a wrong time. Anyway I added some test to prevent that, the emu now displays a message box to warn if the backup ram is still unlocked and refuses to save it in this case. I'll see how it goes, but it's probably better this way. I could fix the stuck backup ram manually by removing a duplicated entry, I just removed the 1st one, and it was back to normal again... The format is documented here : https://wiki.neogeodev.org/index.php?title=Backup_RAM (it was byteswapped when saved by raine, I changed that so that you can edit it more easily in a hex editor in this kind of case, it's able to read the byteswapped format of course but it will save differently now).