Intel HD graphics 4000 and Raine

[mer-curious]

Hum sorry mer-curious if you had read carefully, I :mentioned that this crash is very probably because of your setup and I can't reproduce it, and indeed, captcomm works without problem here, I even tested it in wine (to run windows programs in linux) to be sure and it's ok.

You'll probably be happy to know that wine emulates the disappearing gui too when being in fullscreen. Well I can't fix it anyway, I remember posting something to the sdl mailing list about it long ago, never got any reply and they released sdl2 since then but it's too much trouble migrating raine to sdl2.

Well, I have two Windows 7 setups, one with a discrete graphics card and other with an intel embedded card and none crashes by loading the roms and showing the GUI later on. That's why I supposed it's Windows 8 specific and therefore you wouldn't be able to reproduce it unless you tried an 8 installation. Of course I could also try downgrading to 7 in this new laptop I'm playing with but I don't have any problems with Windows 8 except for this little nuisance in Raine. As I guessed before, it should be related to Windows 8 onward lacking support for 16 bit color depth (and the compatibility modes don't help much here). What boggles me though is how the emulator only crashes by loading roms (and I mean any roms, not just Captain Commando) and not the NGCD ISOs. With the NGCD ISOs I just have the "no GUI" behavior as you described. But if I press like "Q" on the keyboard I can still safe-close the program. If only we had a keyboard shortcut for safe-close the emulator regardless of showing the GUI we could workaround that issue in these later OSs, whilst we do not thoroughly investigate the cause (SDL, Raine, Windows 8 etc). I suppose it would be possible to have such a workaround like that since we do have a similar shortcut for "quit w/o saving", no?

 

But you were right on 1 point, I should release a last binary,

So, I've tested version 0.63.14 and the crash is still there unfortunately. If you don't mind me posting my feedback here, this version has some problems which are not present in version 0.63.13:

- Raine is initializing in fullscreen mode by default

- the default roms directory points to an address not present in my PC (z:\home\...). It should first start from the executable directory, no?

- the default renderer is no longer "opengl", but "normal blits".

- the renderer option is never saved by quiting the program. It always returns to "normal blits".

 

Anyway, if that was really the last version, I'll have to stick to version 0.63.13 for the time being.

 

I wish you all the best in your new interests and endevours! Thank you again for your help and time!

Edited October 24, 2017 by mer-curious

[Tux]

The weird config is because it got a config file in its 7z by mistake, sorry for that.

For the crash sorry, I am not going to install win8 in a virtual machine just to investigate about this. That's also part of the reason I stop here, I would need someone who really likes to program in windows to address all the windows specific issues, but strangely nobody wants to do that ! For me sdl-1.2 works fine, I have absolutely no issue in linux, so well, I am just fed up with all this !

Game over !

 

EDIT : I just re-uploaded the 7z for 0.64.14 without the config files this time. They were created by mistake while I was testing it and I didn't even notice that (games.cfg and raine32_sdl.cfg).

Edited October 24, 2017 by Tux

[mer-curious]

Thanks for the fix, Tux! I'm glad it wasn't the last version at all, lol!

The weird config is because it got a config file in its 7z by mistake, sorry for that.

For the crash sorry, I am not going to install win8 in a virtual machine just to investigate about this. That's also part of the reason I stop here, I would need someone who really likes to program in windows to address all the windows specific issues, but strangely nobody wants to do that ! For me sdl-1.2 works fine, I have absolutely no issue in linux, so well, I am just fed up with all this !

Game over !

 

EDIT : I just re-uploaded the 7z for 0.64.14 without the config files this time. They were created by mistake while I was testing it and I didn't even notice that (games.cfg and raine32_sdl.cfg).

Yes, it's a pitty we don't have more Windows users helping developing Raine. But I don`t think we really need a Windows programmer to work on this very little suggestion I've been talking about alongside this thread. Therefore I would be really glad if you or someone else could add that precious keyboard shortcut for safe-closing the emu as a temporary workaround for the crash in Windows 8+ setups (when running roms). But I see you're not in the mood now, so nevermind. At least it's now registered here for you or someone else to take a look at in the future maybe.

 

As for the revised version 0.64.14, I've tested it again and now Raine doesn't start in fullscreen by default and the roms are now pointing to the executable directory, so that's fixed! But the default renderer is still "normal blits" instead of "OpenGL", and since OpenGL implementation OpenGL was the default one, no? Also, the renderer setting is never remembered after quiting the emu, it always returns to "normal blits", which I suppose isn't the expected behavior, is it?

 

Anyway, I think you should create a new topic for this new release, because there's some (little) progress that should interest other Raine users, and it's the very first release of 2017! Here in this thread it's quite hidden. Then maybe you should change the internal version number to avoid any misunderstandings?

 

That's it for now! As always, thanks for your attention!

[Tux]

Nope, a keyboard shortcut to work around a crash is not acceptable.

Well this thing works flawlessly in my win7, so either it's in win8 itself or in the video driver.

Anyway forget about your unsupported 16bpp idea, 16bpp is supported by 3d cards for opengl, so it's supported everywhere and even if it were not you would get a distorted display at worst, not a crash.

Sorry I won't try win8, and I don't want to install win10 neither, maybe I'll have to do it one day if I upgrade my hardware but for now I don't really need more power and since I foresee a lot of problems with win10 I much prefer to stay on my aging hardware for now ! (maybe one day wine will be advanced enough so that we trash windows completely, but sadly it's not the case yet !).

So well no solutions for you, use another emu or some hardware more compatible with what I have, these are the 2 only reasonable options !

 

ps : if it doesn't choose opengl by default it means it detects a problem like opengl not accelerated.

By the way you can try to switch to normal blits or yuv overlays at least to be able to use the quit command so that your config is saved once.

 

ps2 : with your description, maybe these crashes are because you use a crappy software opengl emulation which doesn't even do its clipping correctly so that out of screen operations end in memory and crash everything. In that case you really have some super crappy hardware because I had a laptop with an intel 945gm inside for 7 years (and it was using some software opengl emulation) and it didn't work that bad, but then again it was in linux, I almost never used it in windows... !

Edited October 26, 2017 by Tux

[mer-curious]

So, I've tested version 0.63.14 in my two Windows 7 setups and they perform pretty much the same as my Windows 8 setup regarding to the video settings starting with "normal blits" as default and not remembering the OpenGL renderer option after quiting the emu.

Here's a screenshot for the OpenGL video info reported by Raine for my 3 setups:

Win 7 (discrete gfx card)


Win 7 (embedded intel express)


Win 8 (embedded intel hd 4000)


So, I suppose there's indeed something not right in version 0.63.14 because this didn't happen in version 0.63.13. In that version the default renderer was always OpenGL (since OpenGL implementation I guess) and the OpenGL renderer option was saved with no problems. But you are right, if I select YUV overlays and quit that option will be remembered, but then Raine will report "no hardware support for YUV overlays" when I open it. That happens in the 3 setups above:

 

By the way, I can save my settings in Windows 8 too. The whole issue is if I load a rom and hide the GUI/show the game, then I will no longer be able to change or save any settings during that session because the program will crash as soon as I hit Escape. Except this the program works normally in Windows 8. That's why I thought a keyboard shortcut for "Save and quit" the emu would be an acceptable workaround since you can't test Windows 8+ for the time being. And once we already have a shortcut for "Quit w/o saving" in the option menu, I don't think there would be any problems by adding a similar option. Perhaps "Ctrl + Q" could be a good shorcut for safe-quiting the emu?

Yes, I could use other emu, but I really like Raine. It's simple and has some features which are not present in other emus, like the NG roms sound associations. So I would like to keep using it for a while, even if I had to workaround a crash, lol!

But anyway, thanks for commenting on my suggestion and again for your time!


PS: my Windows 8 display drivers are quite up to date (July 2017), but I should try another version as soon as intel releases a new one.

[Tux]

Sigh I really didn't want to update this code, but with your habit which I never understood to always unpack new versions to a new dir you found a bug you shouldn't have found if you just uncompressed new versions to the same directory overwriting the old one like what everybody else does... !

I owe you some apologies, it was not because of some crappy hardware after all !

 

Anyway windows didn't keep its opengl setting when intiializing, it was related to a change for osx to allow non accelerated displays for opengl, and I didn't notice this because linux doesn't initialize the display the same way (and in windows I just read my old config file with proper opengl setting and this way it seemed to work too !). At least it shows yet another time why it's crazy to maintain 3 different os targets alone !

So... ! you get yet another binary, this time it correctly displays "0.64.14", and I have included some forgotten cheats about the wrestle game I don't like !

 

Notice : in linux sometimes the gui isn't displayed when I run a game in fullscreen, but it's a sdl-1.2 bug related to double buffer, so fullscreen only, it can be worked around by using a big window instead of fullscreen. Well I don't have this bug in windows 7, there I can use fullscreen without problem, but anyway if someone has the problem, just use a windowed mode then !

 

This should be the end for this version this time !

Sorry for your crash I can't do anything about it, I am not crazy enough to try to setup a virtual image with win8 just to investigate about this... !

Edited October 27, 2017 by Tux

[greatxerox]

hey Tux ! thank for this release

[mer-curious]

Hello, Tux! Thank you so much for your update! Now OpenGL works normally in version 0.64.14.

So I've started playing some games again and found some graphical glitches in KOF96 and The Last Blade 2 in case you wanna have a look later.

In KOF96, we have these weird rectangles in some demo scenes as the ones below:

1

savestate: https://mega.nz/#!R1M1HRRa!QtoHC11j8NQlnl_LLQyLbOYJJgiBnBeINtKWo3km29E

2

savestate: https://mega.nz/#!lxcGhKRB!jRvjTcAykpoWNwd1z1TMVo6UrJ4HPybBWLcLSXoT9NA

Notice that in the second screenshot above we can also see a transparent rectangle where it shouldn't happen.

In The Last Blade 2, we have a strange scene with the eyes of the character showing without his face. The screenshot is from the NGCD game. The glitch doesn't happen in the NG rom version. Take a look:

NGCD

savestate: https://mega.nz/#!l8tAybjT!xBph2-9BdfzskOwN34j3ZpOR4CYOA_6qJRZ6LAqVKP0

NG rom

savestate: https://mega.nz/#!ogtQTSrZ!0mN6WtA_c0ftMl3N5wnUDeDYlVkpSM7XUPBOZeBNFrc

You can use the save states above to try to reproduce the glitches and see if there's anything you could do about them for now or for the future. As you can see, they are not hindering the gameplay at all.

Thank you so much again for your time.


PS: the glitches happen in both 0.64.13 and 0.64.14 versions. The screenshot were taken using my Win 7 discrete gfx card setup.

[Tux]

Nice glitches, I think I like them ! Can't access your link anyway !

[mer-curious]

Nice glitches, I think I like them ! Can't access your link anyway !

Weird. I can download normally through Windows browsers, but Android browsers fail to load the Mega website too.

 

So I've put the four savestate files in a zip and uploaded to Google drive. See if you can download it now:

https://drive.google.com/open?id=0B87M_Nn3cWIFUFlXZGZBb2twRlU

 

Thanks for your reply!

[Tux]

I bet it's the forum fault, some "working only in windows" feature again ! (I use regularly mega in linux without problem).

Anyway your link to google drive is better, more saves. I might take a look later, but don't hold your breath !