HD4350 and similar videocards do not render textures on 32 bit systems

[ShadIK02]

Hello everyone!

The situation is following: I build 32 bit clien of OpenMW 0.47 (tes3mp 0.8.0) and keep getting this errors: (screenshot)
(Same deal with OpenMW 0.47 from official github.)

I understand, that 32 bit support comed to it's end, but I still want to figure this out, if is it possible to fix this. Some people want to continued plaing on our server with tes3mp 0.8.0, and I willing to help them.

For the time being we use tes3mp 0.7.0 (OpenMW 0.45) and everything seems to work fine on primary old PCs (7300 GT, 9600 GT, HD4350).

[AnyOldName3]

Have you tried a 64-bit build? I doubt very much that there's any good reason to be using a 32-bit one as even if your OS is 32-bit, it shouldn't be.

[ShadIK02]

Yes, 64-bit version does the same. But believe me - 32-bit is necessary evil. The thing is, that we have a large stack of player with old hardware, and they are using 32 bit, not because they want, but because their rig sucks. I don't need help with building, I just need to understand the root of problem, and how can one solve it on 64-bit, also.

[AnyOldName3]

How sucks? A first-generation netbook or something from the 90s? Otherwise they should be on a 64-bit OS.

As for the actual issue, it'll help a lot if we ignore TES3MP for now and fix 0.47 first. Is this an issue with completely default settings?

[ShadIK02]

Not the 90s, of course, maybe computers from 2006-2010, with 2-3GB Ram and old video cards.

Yes, I understand that in this case we will ignore tes3mp.

And yes, these problems occur on the default configuration

[AnyOldName3]

2006 machines with 3GB of RAM would benefit from a 64-bit OS. They might not have had one preinstalled when they were new as 64-bit drivers were less reliable back then, but those issues should have been sorted out long ago.

Can you send the openmw.log after starting OpenMW, getting as far through starting the game for something to go wrong, and then quitting, please? https://openmw.readthedocs.io/en/latest ... paths.html should help find where it's kept.

[ShadIK02]

Yes, of course.
There is a similar error in tes3mp:

Code: Select all

Warning: detected OpenGL error 'invalid framebuffer operation' at after RenderBin::draw(..)

And there is such an error in tes3mp, but we are not talking about it yet, I understand):

Code: Select all

RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd7
PixelBufferWin32::init(), pbuffer created with different size then requested
	Requested size (13302,1602)
	Pbuffer size (8192,987)

[AnyOldName3]

That looks pretty cursed. Can you run this and share the report it generates? https://www.realtech-vr.com/home/glview

[ShadIK02]

OpenGL Extension Viewer 6.3 & Aida64 Reports (if needed)

[AnyOldName3]

So those two apps are both able to create a working OpenGL context (or at least not notice that it's not working), so in theory, we should be able to, too. There's a sensible range of sensible surface formats reported, but somehow we're not getting one, hence the

Code: Select all

[15:53:50.623 W] Warning: Framebuffer only has a 0 bit red channel.
[15:53:50.623 W] Warning: Framebuffer only has a 0 bit green channel.
[15:53:50.623 W] Warning: Framebuffer only has a 0 bit blue channel.
[15:53:50.623 W] Warning: Framebuffer only has 0 bits of depth precision.

warnings in the log.

They were actually added with the intent of detecting when we'd only got a limited-colour framebuffer, but they're noticing something much more problematic.