The MiniGL thread

@Raziel
Okay, as far as I can see the following happens:

1. if there's an NPOT texture incoming, then the game creates an empty texture with the next power of two edge size. So e.g. a 200x100 texture would become 256x128. So far so good.
2. but the game doesn't scale the texture data accordingly but simply puts the tex-data unscaled at position 0,0.
3. and because the texture was created as an empty texturem, a huge part of it is actually undefined!

Now take all that and add a slightly false texture-coordinate generation, voila: you have a randomly colored (fully black or white are eventually most likely depending on driver) line like the one you see.
And yes, the wrap-mode doesn't really have the expected impact here, because we are in mid of the texture data, not at the edges (although a GL_REPEAT most likely makes things even worse here).

You could now try to locate the texture coordinate generation code for that sky-cube and fix it.
Or as a simple slow and dirty workaround you could try adding the following code after line 96 - and eventually improve it later

@Daytona675x

Thank you, i'll try that later

Funny you should assume i could "improve" anything, i couldn't even find the culprit in the first place if my life depended on it

@Raziel
Did it work?

@Daytona675x

Sorry, i didn't want to draw any more of your time away from the important stuff.

Yes, that fix makes the visible borders go away, but it also slows down the game a lot.

@Raziel

Do you have a Linux system? To me it sounds like issue would be reproducible on other systems as well. If I remember correctly it's possible to configure ScummVM's OpenGL context (maybe ResidualVM too) in such a way that it's forced to use POT-textures.

@Capehill

Unfortuntely not, but i could provide the build and the data files for testing

@Raziel

Maybe you can request the main developers to test with power-of-two textures?

@Raziel
Quote:


Quote:
Please do this:

- remove the slow texture-filler I gave you
- check file myst3/gfx_opengl.cpp
- line 263 and 264 contain the wrong coordinate calculations
- actually the whole source is full of them, but for your problem those are the relevant lines as far as I can see
- replace those two line by those here:

- maybe an uv_mod of 0.5 yields better results (it should but sometimes I mess the details of those coordinates systems up myself )

@Capehill
Quote:
Yes, it should, it's a typical classic OpenGL pitfall. However, most systems support NPOT, that's why it probably wasn't noticed earlier.

@Daytona675x

Thank you, that fixed it too.

Using 0.5f instead of 1.0f gives me an instant lockup of the whole system (when i start the game).
Actually so bad that it takes at least 5-7 minutes to bring it up again.

Nothing on console or serial.
Seems to be locking up the gfx hardware as numerous (unsuccessful) tries to boot the system up again are stopping at a message that there was no VGA device found (on serial).

I need to turn the whole thing off, let it sit there (power plug out the socket) for some minutes to be able to restart it again.

Not sure if my gfx card is dying (otoh i know this deep lockups from the very first time i got the X1000).

It still is slower than without the patch, but faster than the patch before

@Raziel
in this universe it is exactly 100% absolutely totally for sure and without any possible fraction of a theoretical doubt impossible that this change

- has any impact on stability, neither positive nor negative
- has any impact on performance, neither positive nor negative
- and in both cases the value of the constant, be it 1.0f or 0.5f, cannot produce any other possible difference than a tiny difference in the filtered output at the cube's problematic edges, no more no less

Something else must be broken on your end. It can not possibly have anything to do with this change.

@Daytona675x

I believe you...

There is a slim chance that i caught that dreaded "locking up on me on closing a SDL window" bug exactly five times in a row.

Jump from SDL2 topic: http://www.amigans.net/modules/xforum ... id=113935#forumpost113935

It seems that MiniGL doesn't support glGetIntegerv(GL_DOUBLEBUFFER). It would be seemingly simple to add, something like:

Quote:

I can make a BZ ticket if feature seems worth adding.

What is current state of this?

I installed minigl from post 92. It seems to have some problems with shadows at least with Shogo.

@utri007
The state is wip, other things to do.
Simply use the version from os4depot for now and eventually update when you hear that we're done.

@Daytona675x

Are you interested results?

@utri007

Does the pope have a balcony?

As Raziel reported earlier in some SDL thread, he has a problem when game's Image C++ namespace collides with some Amiga definition. It can be reproduced with an example like:

-- clip --

#include "GL/gl.h"

namespace Image { };

int main(void)
{
return 0;
}

-- clip --

Defining __USE_AMIGAOS_NAMESPACE__ gives only more compilation error.

The issue happens because "mgl/context.h" includes "intuition/intuition.h". As far as I can see, including "intuition.h" is unnecessary. MiniGL compiles without it. I suppose it has been included because of Screen/Window pointers but on the other hand, why? Context.h doesn't need to know how Screen/Window fields look like.

@Raziel: as a workaround, you can comment out that include line in "mgl/context.h" and try again your project.

References:

http://www.hyperion-entertainment.com ... -kc/include/mgl/context.h
http://www.amigans.net/modules/xforum ... id=113800#forumpost113800

@Capehill

Will try.

Do the SDL change need to be in place too?

@Raziel

Only in case of SDL1 and if SDL_syswm.h is included - you can see the include tree in compilation error.

So we have 2 issues: one caused by SDL1 and other by MiniGL.

@Capehill

Ah, understood, thank you for the explanation