Appveyor builds: The texture atlas must use at least 2048 as size (1024 was given)

[wl-zocker]

Windows 10, r7715 (using the install file from appveyor, master-222):

When I start Widelands, the window flashes open and I get this in stderr:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Caught exception (of type '10WException') in outermost handler!
The exception said: [C:/projects/widelands/src/graphic/build_texture_atlas.cc:121] The texture atlas must use at least 2048 as size (1024 was given)

This should not happen. Please file a bug report on version master-222(Release).
and remember to specify your operating system.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The stdout ends after the graphics report.

Is there some option I can modify?

[SirVer (sirver)]

Widelands requires a texture size of 2048x2048 at this moment because we require that all terrain textures fit into one texture atlas, and this is the smallest size that accomodates that. We have been requiring this since r7294, so this is not terribly new though.

Could you output the full graphics report that is printed at startup? I am mostly interested in the GL driver version and hardware.

The opengl 2.1 specification that we adhere to allows for max texture sizes to be 64x64, but I never encountered a card that supported less than 4096x4096. What graphics card is that?

[wl-zocker (wl-zocker)]

Both master-222 and master-231 (which both crash on start-up) show this in stdout:

Graphics: Try to set Videomode 1366x768
Graphics: OpenGL: Version "1.1.0"
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 1024
**** GRAPHICS REPORT ****
 VIDEO DRIVER windows
 pixel fmt 370546692
 size 1366 768
**** END GRAPHICS REPORT ****

Interestingly, r7712 which I downloaded from Tino's site and which shows the graphic glitches (bug 1535732 - just for future reference), but works in general, prints this in stdout:

Graphics: Try to set Videomode 1366x768
Graphics: OpenGL: Version "2.1.0 - Build 8.15.10.2900"
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 8192
**** GRAPHICS REPORT ****
 VIDEO DRIVER windows
 pixel fmt 370546692
 size 1366 768
**** END GRAPHICS REPORT ****
SoundHandler closing times 1, freq 22050, format 32784, chan 2
SDL_AUDIODRIVER directsound

Notice the different OpenGL lines. This seems to be a general difference between Tino and appveyor (I quickly tested some other revisions I found).

Some for information about my graphic card attached.

[wl-zocker (wl-zocker)]

Sorry, I didn't mean master-231, but _widelands_dev_widelands_disable_gl_depth-231.

[SirVer (sirver)]

Tino, do you have an idea what could be going on here? My understanding is that the max texture size is a function of hardware and driver - and I have no idea how building could affect any of these?

[Tino (tino79)]

Me neither. It definitely looks like different hardware, no idea why different libraries should report different OpenGL capabilities of the same hardware/system drivers.

On my system master-222:

$ ./widelands
Set home directory: C:\Users\mit\.widelands
Widelands executable directory: C:\bin\Widelands
Adding directory: C:\bin\Widelands.
selected language: (system language)
Graphics: Try to set Videomode 800x600
Graphics: OpenGL: Version "4.3.0 - Build 10.18.14.4139"
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 16384
**** GRAPHICS REPORT ****
 VIDEO DRIVER windows
 pixel fmt 370546692
 size 800 600
**** END GRAPHICS REPORT ****

BZR7712:

$ /c/data/wl_x64/src/widelands.exe --datadir=/c/data/bzr/widelands/working
Set home directory: C:\Users\mit\.widelands
Adding directory: C:/data/bzr/widelands/working
selected language: (system language)
Graphics: Try to set Videomode 800x600
Graphics: OpenGL: Version "4.3.0 - Build 10.18.14.4139"
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 16384
**** GRAPHICS REPORT ****
 VIDEO DRIVER windows
 pixel fmt 370546692
 size 800 600
**** END GRAPHICS REPORT ****

Let's try a appveyor build with more recent libraries: https://ci.appveyor.com/project/widelands-dev/widelands/build/Bug_1536377-241

But i am not sure if the build succeeds because the upgrading takes very long on each build.

[wl-zocker (wl-zocker)]

I tried https://ci.appveyor.com/project/widelands-dev/widelands/build/Bug_1536377-244/artifacts, but still get the same output to stdout and stderr.

[SirVer (sirver)]

The only remaining idea I have is that our gl driver loading is not working - if we sometimes get GL 1 and sometimes GL 2.

Two ideas about this:

1) We can try https://wiki.libsdl.org/SDL_GL_LoadLibrary instead of relying on Glew and load each library function individually.

2) Maybe we can use glbindings instead of glew.
Tino, can you try building on windows with USE_GLBINDING=True for cmake? That will use https://github.com/cginternals/glbinding which is better than glew.

[kaputtnik (franku)]

From wl-zocker dxdiag output:

Driver Date/Size: 3/11/2013 14:50:30, 8369024 bytes

Is there a newer driver available?

[wl-zocker (wl-zocker)]

I did not find a newer driver for my 1st generation processor [1] and Win10. Maybe I am searching in the wrong way, maybe a too uncommon combination. The Intel driver update utility just states "no drivers for your device found".

[1] Processor: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz (4 CPUs), ~2.5GHz

[Tino (tino79)]

Ok, we have a working windows build with gl tracing available:

https://ci.appveyor.com/project/widelands-dev/widelands/build/window_glbindings_build-313/artifacts

Start with --debug_gl_trace=yes to enable tracing output...

[wl-zocker (wl-zocker)]

I get still in the error in stderr, this is in stdout:

Graphics: Try to set Videomode 1366x768
glGetString(GL_VERSION) -> "1.1.0" [GL_NO_ERROR]
Graphics: OpenGL: Version "1.1.0"
Graphics: SDL_GL_RED_SIZE is 8
Graphics: SDL_GL_GREEN_SIZE is 8
Graphics: SDL_GL_BLUE_SIZE is 8
Graphics: SDL_GL_ALPHA_SIZE is 0
Graphics: SDL_GL_BUFFER_SIZE is 24
Graphics: SDL_GL_DOUBLEBUFFER is 1
Graphics: SDL_GL_DEPTH_SIZE is 16
Graphics: SDL_GL_STENCIL_SIZE is 8
Graphics: SDL_GL_ACCUM_RED_SIZE is 16
Graphics: SDL_GL_ACCUM_GREEN_SIZE is 16
Graphics: SDL_GL_ACCUM_BLUE_SIZE is 16
Graphics: SDL_GL_ACCUM_ALPHA_SIZE is 0
Graphics: SDL_GL_STEREO is 0
Graphics: SDL_GL_MULTISAMPLEBUFFERS is 0
Graphics: SDL_GL_MULTISAMPLESAMPLES is 0
Graphics: SDL_GL_ACCELERATED_VISUAL is 1
Graphics: SDL_GL_CONTEXT_MAJOR_VERSION is 2
Graphics: SDL_GL_CONTEXT_MINOR_VERSION is 1
Graphics: SDL_GL_CONTEXT_FLAGS is 0
Graphics: SDL_GL_CONTEXT_PROFILE_MASK is 2
Graphics: SDL_GL_SHARE_WITH_CURRENT_CONTEXT is 0
Graphics: SDL_GL_FRAMEBUFFER_SRGB_CAPABLE is 0
glGetBooleanv(GL_DOUBLEBUFFER, 0x24fa80) [GL_NO_ERROR]
Graphics: OpenGL: Double buffering enabled
glGetIntegerv(GL_MAX_TEXTURE_SIZE, 0x24fb3c) [GL_NO_ERROR]
Graphics: OpenGL: Max texture size: 1024
glGetString(GL_SHADING_LANGUAGE_VERSION) -> "nullptr" [GL_INVALID_ENUM]
Graphics: OpenGL: ShadingLanguage: "(null)"
glDrawBuffer(GL_BACK) [GL_NO_ERROR]
glDisable(GL_DEPTH_TEST) [GL_NO_ERROR]
glDepthFunc(GL_LEQUAL) [GL_NO_ERROR]
glEnable(GL_BLEND) [GL_NO_ERROR]
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) [GL_NO_ERROR]
glClear(GL_COLOR_BUFFER_BIT) [GL_NO_ERROR]
**** GRAPHICS REPORT ****
 VIDEO DRIVER windows
 pixel fmt 370546692
 size 1366 768
**** END GRAPHICS REPORT ****

I hope it helps.

[wl-zocker (wl-zocker)]

And for comparison, the stdout for r7745 from Tino's site. Some numbers are different, and the lines ending with [GL_ ...] are missing.

[SirVer (sirver)]

Thanks for the feedback!

Tino, can we get a rundown of the library versions used on appveyor vs your builds on your machine?

Maybe we are victim one of these bugs:
https://bugzilla.libsdl.org/show_bug.cgi?id=1554
https://bugzilla.libsdl.org/show_bug.cgi?id=2329

I also filed our issue on the SDL tracker:
https://bugzilla.libsdl.org/show_bug.cgi?id=3248

[Tino (tino79)]

Libs on appveyor see log: https://ci.appveyor.com/project/widelands-dev/widelands/build/window_glbindings_build-313
For SDL2 these are pretty recent, because i submitted new buildfiles to the mingw64 package repository of msys2 just last week.

For my builds i use Nuwens distro 13.4 : http://nuwen.net/mingw.html
Additional self compiled libs:
SDL2 _image 2.0.0
SDL2_net 2.0.0
SDL2_ttf 2.0.12
libpng1.6.20
gzip 1.6
ICU 56.1
freetype 2.6.2
gettext0.19.6
libiconv1.14

[SirVer (sirver)]

Tino, is it possible to swap out the static SDL library on appveyor vs the one you are using in a hacky way for testing? I could image two ways of doing that:

1) do not link SDL statically, instead ship the dll and swap out the DLL vs the one from the official package and see if that changes things.
2) just before linking on appveyor, wget/curl some hacked in path to download the static library that you use on your local machine and see if it runs then.

I am pretty confident that we have a SDL bug here, but that would narrow it down to certainty. The SDL bug tracker seems pretty dead, so I am not sure if and how we get feedback there.

[SirVer (sirver)]

Friendly ping? Did we make any progress on the open questions in this bug?

[SirVer (sirver)]

I have a second report of this bug on windows with tino's nightly builds using a build in Intel card. The laptop can be switched between nvidia and build in intel.

[GunChleoc (gunchleoc)]

I have a setup like that on my Windows machine as well, but unfortunately my particular Intel does not display this bug.

[GunChleoc (gunchleoc)]

@wl-zocker: I tried an ugly hack. Could you please test for us?

https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1536377_texture_atlas_size-896

[wl-zocker (wl-zocker)]

I get an error on startup and the window stays black.
I get this in stderr.txt:
terminate called after throwing an instance of 'WException'
  what(): [../src/graphic/gl/utils.h:73] Could not create GL buffer.

stdout attached.

[GunChleoc (gunchleoc)]

The hack doesn't work then :(

Thanks for testing. I really want this fixed so that you can play again.

[GunChleoc (gunchleoc)]

Could you please test this one?

https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1536377_texture_atlas_size-900

I have relaxed the size requirements for the Texture Atlas there, but we need to know if everything still looks OK.

[wl-zocker (wl-zocker)]

Still the same as in #20.

Thanks for all the time you invest to make Widelands playable for me again. I already miss it a bit.

[kaputtnik (franku)]

If i search for "glGetString(GL_SHADING_LANGUAGE_VERSION) -> "nullptr" [GL_INVALID_ENUM]" i found

https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1565685/comments/10 ff

and a solution in

https://chromium.googlesource.com/chromium/src/+/4af61ccffa3d1af66d2f5c8df0028187ccfadd27%5E!/#F0

Maybe this helps :-)

[GunChleoc (gunchleoc)]

We don't do anything with that parameter. I think the real problem is here:

glTexImage2D(GL_TEXTURE_2D, 0, 6408, 41, 42, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0x50062a0) [GL_INVALID_VALUE]

Seems like not all textures will fit in 1024x1024. I'll add some log output to verify.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd368638%28v=vs.85%29.aspx

Miss you too, wl-zocker.

[kaputtnik (franku)]

The latest build is running here, except the known failure with the texts. Added the log for comparison.

I have just started widelands and opened the options menu and then the editor.

[GunChleoc (gunchleoc)]

New build is ready:

https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_bug_1536377_texture_atlas_size-904

I hope that the log output will give me some insight on any further workarounds.

[wl-zocker (wl-zocker)]

I wish you good luck :)

[GunChleoc (gunchleoc)]

I think I found the bug - the texture width and height need to be power of 2. I will fix up a few images and trigger a new build to verify.

[GunChleoc (gunchleoc)]

When the next build is done, could you check if the line abuve "Adding tribes/images/atlanteans/roadt_busy.png to atlas" still shows [GL_INVALID_VALUE]?

[kaputtnik (franku)]

> I think I found the bug - the texture width and height need to be power of 2. I will fix up a few images and trigger a new build to verify.

Then frontier_00(_pc).png (10x20px) would work, but it don't:

glTexImage2D(GL_TEXTURE_2D, 0, 6408, 10, 20, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0x4fd28f0) [GL_INVALID_VALUE]
Adding tribes/images/atlanteans/frontier_00.png to atlas
glGenTextures(1, 0x4fc4f74) [GL_NO_ERROR]
glBindTexture(GL_TEXTURE_2D, 238) [GL_NO_ERROR]
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 9729) [GL_NO_ERROR]
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, 9729) [GL_NO_ERROR]
Texture::Texture2 internalformat = 6408, 10 x 20
glTexImage2D(GL_TEXTURE_2D, 0, 6408, 10, 20, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0x4f6da90) [GL_INVALID_VALUE]
Adding tribes/images/atlanteans/frontier_00_pc.png to atlas

I assume that all images with transparency makes problems, because images without transparency are working.

[GunChleoc (gunchleoc)]

I think you misunderstood - it's power of 2 (2, 4, 8,16,32...), not divisible by 2 (2,4,6,8,10,...).

https://gamedev.stackexchange.com/questions/26187/why-are-textures-always-square-powers-of-two-what-if-they-arent

https://stackoverflow.com/questions/13461808/opengl-power-of-two-textures

The buggy driver is reporting an outdated version of GL, so it seems that it requires textures that are power of 2 in size. I would like to verify this - creating a workaround for that is huge tough - e.g. if we add some blank space around the road textures, it will make them display smaller. And I don't even want to think about adapting the font renderers.

[kaputtnik (franku)]

Thanks for clarification :-)

As i understand this right, the texture atlas is the problem? If so and we had no texture atlas for a long time without such problems, the 'easiest' solution is maybe to avoid using the texture atlas for systems with old hardware. Just thinking for my self ;)

Changing all the images isn't a solution here.

[GunChleoc (gunchleoc)]

Yes, I have been pondering this as well - the problem might have occurred with the Upgrade to Windows 10 though resulting in a buggy driver (or no specific driver available, using a fallback driver), rather than with the introduction of the texture atlas.

[SirVer (sirver)]

The true problem and bug here is that the same computer reports OpenGL 3 on Tinos builds, but OpenGL 1 on the appveyor builds. Trying to make our code work for OpenGL 1 even though we have no evidence of a computer that can only work on OpenGL 1 is the wrong approach.

Unfortunately, I have no clue why the appveyor builds only find OpenGL 1.

[Tino (tino79)]

My builds still do not use GLBindings but GLEW. I am using this MinGW distro: http://nuwen.net/mingw.html
Every additional package i've build from scratch, building only static libraries. The widelands executable gets also linked statically.

In contrary on Appveyor we use msys2 https://msys2.github.io/ and fetch all packages pre-compiled and widelands gets linked dynamically.

[GunChleoc (gunchleoc)]

I am wondering whether we can hack the GL configuration if it reports version 1, since it's very unlikely that the graphics cards won't support anything else. Fixing the actual bug is beyond my capabilities, so I'd like to at least have a workaround.

[SirVer (sirver)]

I think it likely that the game *actually uses* OpenGL 1, not only believe it does. All the status reporting at the start of the game are really low-level. Therefore it is not likely that you can work around this, the only fix is to make the game use OpenGL 3 again.

[Miroslav Remák (miroslavr256)]

Wl-zocker, have you tried the OpenGL3 branch? https://ci.appveyor.com/project/widelands-dev/widelands/build/_widelands_dev_widelands_opengl3-536

[wl-zocker (wl-zocker)]

Yes, I tested it already three months ago. stdout attached; stderr:
terminate called after throwing an instance of 'WException'
  what(): [../src/graphic/build_texture_atlas.cc:121] The texture atlas must use at least 2048 as size (1024 was given)

[SirVer (sirver)]

I do not see us making progress on this anymore - we can call it "fixed" by saying that the RC's and the official release are made by Tino and not by appveyor - therefore this issue should not hit us.

How to fix the nightlies for windows is a different question though - I am not convinced it needs solving and definitively not for b19.

I'd vote for closing this bug as "wontfixed". If this does not find a majority, I'd like to remove the b19 tag since this is a blocker.

[SirVer (sirver)]

Btw, I am pretty sure we are victims of this issue: https://bugzilla.libsdl.org/show_bug.cgi?id=2329

It contains this statement:

"And using the precompiled .a lib from libsdl.org works too... so i'm guessing it wasn't built on XP and there hasn't been proper testing with XP. :)"

Tino, is it possible to use the artifacts from libsdl.org directly instead of those installed by the mingw64 packages?

[GunChleoc (gunchleoc)]

+1 to #41 - if this will be the only bug left over to block us, retarget at least.

[Tino (tino79)]

Please give https://widelands.8-schuss.de/Widelands-bzr8063-nomusic-win64.exe a try.

I did (following the suggestion from #42):
- ninja clean
- downloaded https://libsdl.org/release/SDL2-devel-2.0.4-mingw.tar.gz
- Linked against the SDL static libraries from this archive
- Complete rebuild

[kaputtnik (franku)]

This has to be tested by wl_zocker, because i didn't have a 64 bit system (and ran into this issue at all). Maybe sending an email to him? At least it would be nice to have wl_zocker on board again...

[wl-zocker (wl-zocker)]

I am still subscribed to this bug, just write explicitly when you need me.

I tested the version from #44, stdout.txt is attached; stderr.txt is empty.

I only checked the splash screen, which shows me the lower half of "continue", and the main screen, which shows me absolutely no text (all buttons empty).

I also enjoyed playing Widelands, but this bug makes it really hard :(

[SirVer (sirver)]

Thanks for testing, wl-zocker! That helps quite a bit.

Tino, it seems like the libraries from SDL.org did the trick. is there a chance to use them on the appveyor builds? I would also be fine checking them into the repository if that helps.

[kaputtnik (franku)]

wl-zocker: At least this bug (Texture atlas size) is solved with the last test?

And the remaining bug for you (and others) is bug 1535732 (Texts not displayed correctly with the new font renderer) ?

[wl-zocker (wl-zocker)]

No. According to my comment #2, Tino's builds have always been fine (with regard to the texture atlas). I've just installed the latest (I guess) appveyor build [1] and I still get the error in stderr and OpenGL Version 1.1.0. So nothing is solved

[1] https://ci.appveyor.com/project/widelands-dev/widelands/build/master-1126/job/fuk3g70u284o2870/artifacts

[GunChleoc (gunchleoc)]

Since we can release without AppVeyor builds as long as Tino is available, I am rescheduling this.

[GunChleoc (gunchleoc)]

The attached branch will show a basic error message box and then exit.

Did the update to glbinding version 3 help?

[GunChleoc (gunchleoc)]

Since we don't know how to fix the graphics driver problem, we are now showing a basic message at startup so people will know that they can't play.

[GunChleoc (gunchleoc)]

Fixed in build20-rc1