registry = ipsRegistry::instance(); $this->settings =& $this->registry->fetchSettings(); } public function getOutput() { return; } public function replaceOutput($output, $key) { require_once( IPSLib::getAppDir('ibprobattle') . '/sources/battleHooks.php' ); $this->battleHook = new battleHooks( $this->registry ); return $this->battleHook->statsTopicView($output, $key); } } ?>registry = ipsRegistry::instance(); $this->settings =& $this->registry->fetchSettings(); } public function getOutput() { require_once( IPSLib::getAppDir('ibprobattle') . '/sources/battleHooks.php' ); $this->battleHook = new battleHooks( $this->registry ); return $this->battleHook->statsTopicViewJS(); } } ?> Raine 0.64.12 : finally fixing the shaders - Raine - 1Emulation.com

Jump to content

Welcome to 1Emulation.com
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account
Photo

Raine 0.64.12 : finally fixing the shaders

- - - - -

  • Please log in to reply
5 replies to this topic

#1
Tux

Tux

    Author of Raine

  • Emulator Author
  • 194 posts
  • Gender:Male
  • Location:Nantes, France

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.1emulat...oad/latest.html



#2
silvertrix

silvertrix

    Newbie Poster

  • Members+
  • 6 posts

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.



#3
Tux

Tux

    Author of Raine

  • Emulator Author
  • 194 posts
  • Gender:Male
  • Location:Nantes, France

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...



#4
ramonz

ramonz

    Newbie Poster

  • Members+
  • 5 posts

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, 18 May 2016 - 04:19 PM.


#5
greatxerox

greatxerox

    Newbie Poster

  • Members+
  • 6 posts

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 :(



#6
Tux

Tux

    Author of Raine

  • Emulator Author
  • 194 posts
  • Gender:Male
  • Location:Nantes, France
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..




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users