Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Tux

Raine 0.64.12 : finally fixing the shaders

Recommended Posts

Ok, sorry for the very long delay, I didn't think I would actually fix this...

In case someone still reads this :

 

I finally got curious about this bug and actually took the time to read the output of raine when the shaders didn't work with the new nvidia drivers, and there was actually something weird to read ! It was all because there was a bug in nvidia drivers <= version 355.11 which made them to return a buffer of 1 byte for the info log of the shader program when there was nothing to report ! I made a workaround for this and totally forgot about it, but it failed when nvidia fixed this and now the buffer has correctly 0 bytes when nothing to report... !!!

 

Anyway it means shaders now work correctly for any nvidia drivers, and it could probably affect some other video cards as well.

Those not using shaders don't need to update, this 0.64.12 only fixes shaders, and the fix is very short !

 

http://raine.1emulation.com/download/latest.html

Share this post


Link to post
Share on other sites

Hi. Could you compile Raine to 64 bit version of Windows 7? I use Raine 32 but changs after I change a game (no audio and freeze). Windows 7 64 home premium. I7 4790k and ssd disk + hard drive 2 tb.

Share this post


Link to post
Share on other sites

Nope raine can't be compiled in 64 bits because of all the assembler there is inside (actually I made once a very limited 64 bit version, but it supported only a very few z80 games, and it was not using the normal cpu emulators).

 

But for info I use it in windows 7 64 bits and on a 64 bit linux system without any problem, so the cause of your crashes/freezes is elsewhere...

Share this post


Link to post
Share on other sites

Hi!

 

Thanks for the update, shaders (3X scanline) work like a charm now on my GTX 660 with drivers 365.19!

 

Everything is perfect with this emulator now, except maybe 1 thing: The GUI/menu is reported by "video info" to be in 16 bit while the gaming is done in 32bit color. I can see that by the fact that as soon as I launch Raine32, my task bar switch from my regular 32 bit windows dark theme to the light blue 16 bit Windows theme. Then, when I select "play game", the screen switch back to 32 bit. As soon as I press escape to go back to the GUI, it switch back to 16 bit color again.

 

Interestingly enough, if you switch back and forth from full screen to windowed and full screen again, it temporarily fix the issues and the GUI is in 32 bit. Until you paly 1 game and get back to the GUI, in 16 bit again.

 

I tried to decompress the latest version of Raine32 into it's own folder and used the default configuration, just to be sure in case of a wrong/corrupted configuration. Same thing. Also, I double cheeked that Raine32 was NOT running in compatibility mode making sure "disable desktop composition" was NOT selected.

 

It's not a huge deal, I still can play all the games in the correct 32 bit mode, but the constant back and forth from 16 to 32 bit every time I access the GUI introduce an annoying delay and screen flashing from my LCD switching from one color mode to the other. The issue is not discernible in Windowed mode, but I use Raine32 in full screen.

 

 

My specs:

 

Intel 2500K

16GB RAM

GTX 660 with latest drivers

3 X LCD 1680X1050 (2 X DVI, 1 X HDMI to DVI)

Windows 7 64bit, Aero ON.

Edited by ramonz

Share this post


Link to post
Share on other sites

Bonjour Tux, super bonne nouvelle que tu aies corrigé le pb des shaders. merci

 

j'aimerais te signaler qu'hélas Samurai Spirit RPG French ne fonctionne pas.

 

Lorsque l'on fait "nouvelle partie" le jeu boote sur la lecture audio de CD :(

Share this post


Link to post
Share on other sites

greatxerox : confirmed, thanks for the info, it's probably recent I played the french version for quite a while. Please post in English in the forum so that the others can read it ! I'll have a look at that asap, probably something very stupid. EDIT : it was again because of the garou fix, it's fixed now.</p>

 

ramonz: thanks, I didn't know that, I don't test much in windows, and in linux the desktop isn't affected. I used 16bpp for the gui only because it uses standard blits so it's faster. I guess I can leave it in 32 bits to avoid this. Making an opengl gui would be even better, but it's not that easy, so I'll probably just switch it to 32bpp for now if the desktop is in 32bpp. EDIT : it's because of a windows specific bug, luckily it's commented in the source, it's because when using the windib driver in fullscreen mode, when leaving opengl and or double buffer, the gui screen is not fully restored when it should. It happens only in windows and only with this driver. As a workaround I found that changing the color depth forces the full restoration of the screen. I wasn't aware that changing the color depth of 1 application changed the color depth of the desktop ! Oh windows is full of stupidities, really tiresome... Well for now I don't know how to fix it. I'll think about it..

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...