Crash After Compiling

[JdH]

Is the windows SDK still up to date?
Compiling was fine.
I tried to run the compiled game, but it always crashes (as a difference to sometimes crashes for the 0.4.4R4 installation).
Perhaps some dependency dlls have changed? Or am I missing an important step before launching the compiled game?

[Geoff the Medio]

The SDK hasn't changed.

Define "it always crashes"? Crashes how?

Are you using the Visual Studio run button? If so, see: viewtopic.php?p=70451#p70451

[JdH]

Thanks, working a lot with Visual Studio. I know those pitfalls.

Well, I already created a patch for my problem.

PS: the crash has nothing to do with compiling. It is(was) a crash running the game.

[Geoff the Medio]

Please edit your post / signature to say that you release code changes under the GPL 2.0 or later.

[JdH]

Done, me thinks.

[Geoff the Medio]

Do you know what you're doing with that GL call? It seems like it might be necessary to pass in the pixels pointer to create the texture properly... It is used later in subsequent calls to the same glTexImage2D function, but it looks a bit odd, so maybe it's OK, though?

[adrian_broher]

Do you know what you're doing with that GL call? It seems like it might be necessary to pass in the pixels pointer to create the texture properly... It is used later in subsequent calls to the same glTexImage2D function, but it looks a bit odd, so maybe it's OK, though?

GL_PROXY_TEXTURE_2D is not a texture target but a way to query if the given implementation supports the texture configuration. It should not read from the data parameter but the nvidia implementation seems buggy and reads anyway if data is not 0. Passing 0 isn't explicit promoted in the manual but if it fix the issue I don't see a problem with using this fix.

https://www.opengl.org/sdk/docs/man/htm ... ge2D.xhtml

If target is GL_PROXY_TEXTURE_2D, GL_PROXY_TEXTURE_1D_ARRAY, GL_PROXY_TEXTURE_CUBE_MAP, or GL_PROXY_TEXTURE_RECTANGLE, no data is read from data, but all of the texture image state is recalculated, checked for consistency, and checked against the implementation's capabilities. If the implementation cannot handle a texture of the requested texture size, it sets all of the image state to 0, but does not generate an error (see glGetError). To query for an entire mipmap array, use an image array level greater than or equal to 1.

Use the GL_PROXY_TEXTURE_2D, GL_PROXY_TEXTURE_1D_ARRAY, GL_PROXY_TEXTURE_RECTANGLE, or GL_PROXY_TEXTURE_CUBE_MAP target to try out a resolution and format. The implementation will update and recompute its best match for the requested storage resolution and format. To then query this state, call glGetTexLevelParameter. If the texture cannot be accommodated, texture state is set to 0.

This should also fix bugs like viewtopic.php?f=25&t=8846 or viewtopic.php?f=28&t=9069 and the same line is also included in the current release branch so we SHOULD include it for 0.4.4 release because it will affect a lot of NVIDIA users if the driver behavior changed recently.

[JdH]

Passing 0 isn't explicit promoted in the manual but if it fix the issue I don't see a problem with using this fix.

https://www.opengl.org/sdk/docs/man/htm ... ge2D.xhtml

But have look way down:

data may be a null pointer. In this case, texture memory is allocated to accommodate a texture of width width and height height. You can then download subtextures to initialize this texture memory. The image is undefined if the user tries to apply an uninitialized portion of the texture image to a primitive.

So it is somewhat promoted.

This should also fix bugs like viewtopic.php?f=25&t=8846 or viewtopic.php?f=28&t=9069 so we SHOULD include it for 0.4.4 release because it will affect a lot of NVIDIA users.

Indeed. That the error I tried to fix on my machine, just with an other image file involved.

[Geoff the Medio]

...so we SHOULD include it for 0.4.4 release because it will affect a lot of NVIDIA users if the driver behavior changes recently.

I am very reluctant to delay v0.4.4 for what appears to be an external driver issue. Perhaps it can go in a v0.4.4.1 update after a few weeks' testing.

[adrian_broher]

But have look way down […] So it is somewhat promoted.

If the target is a *PROXY* it MAY NOT read from data. See the previous quote. The NVIDIA implementation DOES read from data anyway and crashes. So the note doesn't change anything. Well anyway, we could discuss now how to read the manual properly™ but I prefer fixing this, so if data = 0 does the job I'm happy.

[Vezzra]

I am very reluctant to delay v0.4.4 for what appears to be an external driver issue.

Understandable, but if I understand correctly in this case a substantial part of our potential players are very likely going to be affected. We are aware of the issue, we already know how to fix it, and as much as it annoys me to have to make yet another RC, it seems more reasonable to include the fix now than declare an official 0.4.4 release without it already knowing we'll have to make a bugfix release soon to address the issue afterwards.

Perhaps it can go in a v0.4.4.1 update after a few weeks' testing.

If I understand correctly, the underlying problem has been properly identified and the suggested fix doesn't seem to be very complicated. Why do you think a few weeks of testing would be necessary before being sufficiently sure the fix works as intended?

I could make RC5 on Thursday evening, then we have the whole weekend for testing, and (provided this time nothing else pops up) you can declare RC5 the official release on Monday or Tuesday.

[Geoff the Medio]

If I understand correctly, the underlying problem has been properly identified and the suggested fix doesn't seem to be very complicated. Why do you think a few weeks of testing would be necessary before being sufficiently sure the fix works as intended?

This proposed fix is completely untested. If it does cause problems, then that necessitates yet another RC build and delay, and as it's apparently a graphics-card and driver-version dependent issue, it could have different effects on different systems which won't be immediately apparent. Are we going to keep delaying this release indefinitely every time non-trivial another issue comes up (because they seem to keep doing so...)?

I could make RC5 on Thursday evening, then we have the whole weekend for testing, and (provided this time nothing else pops up) you can declare RC5 the official release on Monday or Tuesday.

I'd much rather have a test release immediately, with the change in place, rather than waiting several days for an RC build for the first test of it besides the few people able to apply the change and build it for themselves...

[adrian_broher]

Well, I have looked into the OpenGL specification and it doesn't promote anything about data in combination with texture proxies.

However most other web tutorials and other sources use data = 0 as the default when querying *PROXY* targets and I haven't seen any trouble or bug reports with that.

Also the FAQ from the OpenGL page does use data = 0 in the example provided. [1]

Anyway, I committed the fix as r7690 to trunk because it works-for-me. Feel free to cherry pick if you decided how to handle this for release 0.4.4.

[1] http://www.opengl.org/archives/resource ... m#text0120

[Vezzra]

This proposed fix is completely untested. If it does cause problems, then that necessitates yet another RC build and delay, and as it's apparently a graphics-card and driver-version dependent issue, it could have different effects on different systems which won't be immediately apparent.

Well, if the issue and it's fix are that problematic, declaring RC4 as final 0.4.4 now and providing a bugfix release later is certainly a reasonable option.

Are we going to keep delaying this release indefinitely every time non-trivial another issue comes up (because they seem to keep doing so...)?

No, of course not, following the discussion I just got the impression that this issue is a very serious one potentially affecting a very large number of players/systems, so all in all big enough to maybe warrant another RC build.

Ultimately it's your call if you think the issue is big enough to make RC5 or not. If you decide to go ahead and declare RC4 the official 0.4.4 release, I don't really have any objections, I just offered my opinion on the matter as far as I understood things.

I'd much rather have a test release immediately, with the change in place, rather than waiting several days for an RC build for the first test of it besides the few people able to apply the change and build it for themselves...

Would you prefer a test release based on trunk (I've seen Marcel already committed the patch), or should I merge the patch to the release branch and make a test release based on that? If you tell me soon enough (preferably within one hour of the time of this post), I might be able to get that out today (I've an appointment in the late afternoon and would have to to that before).

[MatGB]

Most of this is way over my head, but I'm very much inclined to agree with Geoff, declare RC4 the done deal, commit this to trunk, get a Test release out so it can be tested by those affected by the issue and if so then merge it to the release branch and release a bugfix release once we can confirm it's an actual bugfix.

But doing the latter will need more time than is ideal for RC4 as far as I can tell, and in the meantime if we think it does work then anyone with the issue can be directed to a Test release until the bugfix is done?