Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange squares instead of stars in the goals point #170

Closed
apoleon opened this issue Jan 4, 2019 · 58 comments

Comments

Projects
None yet
6 participants
@apoleon
Copy link

commented Jan 4, 2019

This was reported to Debian as https://bugs.debian.org/871223.

It is reproducible with Git master. Instead of stars there are now squares inside the goal point.

neverball1

It can be seen here in this picture which shows the start menu but it can also be observed inside the game. Could be some kind of OpenGL issue. I am running Debian Testing/Buster, Gnome3 (Wayland), 64bit, Mesa18.2.8. Graphic chip Intel HD 4000

@parasti

This comment has been minimized.

Copy link
Member

commented Jan 5, 2019

The star particles in the goal visuals and coin pickup visuals are drawn using the GL_POINT_SPRITE OpenGL feature. It is my experience that when it doesn't work, the problem is always a breakage in the graphics driver. It may even be resolved by now and you might just need to wait for the update to propagate.

@apoleon

This comment has been minimized.

Copy link
Author

commented Jan 5, 2019

Thank you for the explanation. I always suspected this might be a driver issue. Fortunately it is only a minor glitch.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2019

I've had Neverball look like this as long as I have been playing. I'm on Intel HD 4000, Mesa 18.2.2. Also tested with LIBGL_ALWAYS_SOFTWARE=1 and same issue. I guess I always just assumed it was intentional... Is there a way to force the GLES renderer to test it?

@parasti

This comment has been minimized.

Copy link
Member

commented Jan 15, 2019

You should be able to enable GLES support by compiling with make ENABLE_GLES=1. Not sure if it works, though.

@apoleon

This comment has been minimized.

Copy link
Author

commented Jan 15, 2019

I believe you meant ENABLE_OPENGLES=1. AFAICS the include files for GLES/gl.h were once provided in libgles1-mesa-dev on Debian systems but they were superseded by libgles2-mesa-dev, the 2.x version of the API. I don't know if changing the include to GLES2/gl2.h will work at all

@parasti

This comment has been minimized.

Copy link
Member

commented Jan 16, 2019

You are correct, it is ENABLE_OPENGLES=1.

As far as I can tell, libgles1-mesa-dev is fine and well on Debian, and is the version that should be used.

@apoleon

This comment has been minimized.

Copy link
Author

commented Jan 16, 2019

Unfortunately libgles1-mesa-dev was removed from Debian. The successor is libgles2-mesa-dev and it provides different include files. I don't know if they are compatible. In any case I would have to patch neverball to make it work.

@parasti

This comment has been minimized.

Copy link
Member

commented Jan 23, 2019

It seems libgles1-mesa was removed from Debian testing, but is back in Debian unstable. Which is the correct thing to do, because GLES1 and GLES2 are two different APIs.

Any distro that "supersedes" a well maintained GLES1 API with GLES2 because "it's the next version" is out of touch with reality. Might as well supersede C with C++.

@camthesaxman

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2019

I remember having this issue earlier. I believe some of the data files in the Debian package were wrong. Whatever the case, building my own version from source worked and did not have this issue

@apoleon

This comment has been minimized.

Copy link
Author

commented Mar 14, 2019

How can the data files in the Debian package be wrong? How did your build differ from the Debian one?

@parasti

This comment has been minimized.

Copy link
Member

commented Mar 14, 2019

Your local build must have been linked against a different OpenGL renderer than the Debian package. I don't know how that could happen. In any case it would be very complicated to create this particular graphical effect via a Neverball data modification.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 14, 2019

Or, maybe the issue was unintentionally fixed since 1.6.0?

@apoleon

This comment has been minimized.

Copy link
Author

commented Mar 14, 2019

Nope, I have packaged the latest Git snapshot of Neverball for Debian and the glitch is still present. I believe this is really a driver issue, unfortunately.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2019

https://stackoverflow.com/questions/16005871/textured-point-sprites-in-opengl-4-3

"However this function seems to no longer be supported and the standard texture environment doesn't seem to work."

It seems that maybe it's time to use a supported GL function for this? For the record, I tried the normal renderer, llvmpipe, and softpipe. I also tried limiting what version of OpenGL Mesa reported, but it didn't help. (It seems Neverball doesn't even check the reported GL version? I set GL to report 1.0 and neverball ran normally...)

Of course, you can keep a fallback to GL_POINT_SPRITE for ancient hardware, but it seems like GL_POINT_SPRITE on newer hardware is a no-go.

If someone wants to, they could open a bug in Mesa, but a fix will probably be really low priority.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2019

@rlk

This comment has been minimized.

Copy link
Member

commented Mar 15, 2019

I find that the Ubuntu package shows squares instead of stars on my Intel Iris 540. Building from source (NOT in GLES mode) shows them as stars, which is a little surprising given that the two binaries appear to link the same libraries.

The stars don't spin properly, but at least they're stars.

The best strategy for the future is indeed to transition away from the use of point sprites. The game didn't use point sprites originally, but they were added many years ago when the ES port was done. Everything was converted to batched VBO rendering, and hundreds of individually transformed particles are impossible to batch. This was all necessary to get it to run smoothly on the under-powered phones of the day.

I think the approach I'd take is to somehow move all aspects of particle animation into the vertex shader, and using a time uniform to set it in motion. This way, all particles could be rendered in a single batch of textured squares, instead of a single batch of sprited points.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 15, 2019

Hmm... A couple of things from the apt changelog that stood out to me:

  * Enable mouse grab in window mode again and make the cursor invisible in
    fullscreen mode. Append -DNDEBUG to CPPFLAGS to achieve this. Thanks to
    Filipus Klutiero for the report. (Closes: #755760)
  * Enable Oculus Rift support and build-depend on libopenhmd-dev.
    (Closes: #845657)

I wonder of one of these affects it? Also @rlk were you compiling master or 1.6.0? It's possible that there was some sort of change in master.

@parasti

This comment has been minimized.

Copy link
Member

commented Mar 16, 2019

If ENABLE_HMD has been used, there might be some weird interactions between the fixed-function path and the shader path. Needs to be confirmed for sure. If you can get that code to compile. It's kind of old.

@parasti parasti added the gl label Mar 16, 2019

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 18, 2019

@parasti @rlk https://bugs.freedesktop.org/show_bug.cgi?id=110116#c8

Seems this is a weird issue that only reproduces under certain circumstances... Maybe I'll do some tests myself soon.

@parasti

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

There's some kind of misunderstanding there. The screenshot posted in that comment does not show the problem. It's a graphical effect that @rlk created and that was only used for a short while. The effect is based on texture matrix manipulation and does NOT use point sprites. It is entirely different from this bug that we're discussing here.

Just to clarify, ENABLE_HMD enables VR support. It is not used by default. It takes form as ENABLE_HMD=libovr or ENABLE_HMD=openhmd on the make command line.

@DenKos363

This comment has been minimized.

Copy link

commented Mar 19, 2019

Hey, I am Denys, from freedesktop. I am agree that screenshot with issue - not 100% the same, I put it just as example of case, when this effect was broken and then fixed - in game, not in driver. If these issues don't relate one to another - ok, no problems. Still I made more checks (part 1 and 3 of my answer).

About ENABLE_HMD - could you clarify please, how I can build from source with this flag? What I tried - I got a build script from deb package =>

dh_auto_build -- CFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong -Wformat -Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong -Wformat -Werror=format-security" FCFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong" FFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong" GCJFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong" LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro" OBJCFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong -Wformat -Werror=format-security" OBJCXXFLAGS="-g -O2 -fdebug-prefix-map=/home/den/Downloads/neverball_1.6.0-8.debian/debian=. -fstack-protector-strong -Wformat -Werror=format-security" \ DATADIR=/usr/share/games/neverball \ LOCALEDIR=/usr/share/locale \ ENABLE_HMD=openhmd \ executables

Then I tried to build from source using same flags =>

CFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" \ CXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ FCFLAGS="-g -O2 -fstack-protector-strong" \ FFLAGS="-g -O2 -fstack-protector-strong" \ GCJFLAGS="-g -O2 -fstack-protector-strong" \ LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro" \ OBJCFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ OBJCXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ ENABLE_HMD=openhmd \ make -j4

And still - it worked fine. To my mind, these flags were overwritten during building and were not applied. But I am not sure in this on 100%.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

@DenKos363 You put the make -j4 on the end of the command? Try this:

make -j4 CFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" \ CXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ FCFLAGS="-g -O2 -fstack-protector-strong" \ FFLAGS="-g -O2 -fstack-protector-strong" \ GCJFLAGS="-g -O2 -fstack-protector-strong" \ LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro" \ OBJCFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ OBJCXXFLAGS="-g -O2 -fstack-protector-strong -Wformat -Werror=format-security" \ ENABLE_HMD=openhmd

However, I seem to be unable to reproduce the issue using master or self-built 0.6.0 thus far. I wondered if this is not a GL issue, but a loading of assets issue, so I compiled as normal, then overwrote the generated binary with the one from the installed package. The squares showed up, so it's definitely linked to that specific binary somehow.

It may be an issue with the package being compiled for older libraries, and having trouble with operating with the newer libraries, or alternatively, the compiler version may affect things.

Here's an apitrace with my self-built 1.6.0:
neverball.trace.zip

@parasti

This comment has been minimized.

Copy link
Member

commented Mar 19, 2019

Any differences in the ldd output for both binaries?

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 19, 2019

Debian package version:

qwerty@qwerty-Inspiron-3520:~$ ldd /usr/games/neverball
	linux-vdso.so.1 (0x00007fff1b3a6000)
	libopenhmd.so.0 => /usr/lib/x86_64-linux-gnu/libopenhmd.so.0 (0x00007f38c8550000)
	libSDL2_ttf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0 (0x00007f38c8348000)
	libvorbisfile.so.3 => /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 (0x00007f38c8140000)
	libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f38c7e10000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f38c7b84000)
	libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f38c791c000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f38c76ea000)
	libphysfs.so.1 => /usr/lib/x86_64-linux-gnu/libphysfs.so.1 (0x00007f38c74c1000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f38c7123000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f38c6d32000)
	libhidapi-libusb.so.0 => /usr/lib/x86_64-linux-gnu/libhidapi-libusb.so.0 (0x00007f38c6b2a000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f38c6922000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f38c6703000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f38c644f000)
	libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f38c6224000)
	libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f38c601b000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f38c5d14000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f38c5b10000)
	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f38c58c0000)
	libsndio.so.6.1 => /usr/lib/x86_64-linux-gnu/libsndio.so.6.1 (0x00007f38c56b0000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f38c5378000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f38c5166000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f38c4f5c000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f38c4d59000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f38c4b49000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f38c493e000)
	libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f38c473a000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f38c4534000)
	libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f38c4332000)
	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f38c4123000)
	libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f38c3f1b000)
	libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f38c3cdc000)
	libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f38c3aab000)
	libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f38c37f5000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f38c35d8000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f38c89de000)
	libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f38c33c0000)
	libpulsecommon-11.1.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so (0x00007f38c3142000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f38c2ef5000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f38c2ce0000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f38c2ab8000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f38c28ae000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f38c26a8000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f38c24a0000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f38c2282000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f38c1ffe000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f38c1df4000)
	libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f38c1b7b000)
	libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f38c1975000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f38c1771000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f38c156b000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f38c1345000)
	liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f38c1129000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f38c0e0e000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f38c0bf4000)
	libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f38c097d000)
	libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f38c06d4000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f38c04b9000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f38c02a4000)

Locally compiled 1.6.0:

qwerty@qwerty-Inspiron-3520:~$ ldd ./Neverball/1.6.0/neverball-1.6.0/neverball
	linux-vdso.so.1 (0x00007ffe08bfb000)
	libopenhmd.so.0 => /usr/lib/x86_64-linux-gnu/libopenhmd.so.0 (0x00007f6f12dfa000)
	libSDL2_ttf-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0 (0x00007f6f12bf2000)
	libvorbisfile.so.3 => /usr/lib/x86_64-linux-gnu/libvorbisfile.so.3 (0x00007f6f129ea000)
	libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f6f126ba000)
	libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f6f1242e000)
	libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f6f121c6000)
	libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f6f11f94000)
	libphysfs.so.1 => /usr/lib/x86_64-linux-gnu/libphysfs.so.1 (0x00007f6f11d6b000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6f119cd000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6f115dc000)
	libhidapi-libusb.so.0 => /usr/lib/x86_64-linux-gnu/libhidapi-libusb.so.0 (0x00007f6f113d4000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6f111cc000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6f10fad000)
	libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f6f10cf9000)
	libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f6f10ace000)
	libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f6f108c5000)
	libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f6f105be000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6f103ba000)
	libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f6f1016a000)
	libsndio.so.6.1 => /usr/lib/x86_64-linux-gnu/libsndio.so.6.1 (0x00007f6f0ff5a000)
	libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f6f0fc22000)
	libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f6f0fa10000)
	libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f6f0f806000)
	libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f6f0f603000)
	libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f6f0f3f3000)
	libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f6f0f1e8000)
	libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f6f0efe4000)
	libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f6f0edde000)
	libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f6f0ebdc000)
	libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f6f0e9cd000)
	libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f6f0e7c5000)
	libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f6f0e586000)
	libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f6f0e355000)
	libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f6f0e09f000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6f0de82000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6f13288000)
	libusb-1.0.so.0 => /lib/x86_64-linux-gnu/libusb-1.0.so.0 (0x00007f6f0dc6a000)
	libpulsecommon-11.1.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-11.1.so (0x00007f6f0d9ec000)
	libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f6f0d79f000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f6f0d58a000)
	libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f6f0d362000)
	libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f6f0d158000)
	libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f6f0cf52000)
	libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f6f0cd4a000)
	libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f6f0cb2c000)
	libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f6f0c8a8000)
	libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f6f0c69e000)
	libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f6f0c425000)
	libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f6f0c21f000)
	libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f6f0c01b000)
	libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f6f0be15000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f6f0bbef000)
	liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f6f0b9d3000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f6f0b6b8000)
	libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f6f0b49e000)
	libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f6f0b227000)
	libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f6f0af7e000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f6f0ad63000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f6f0ab4e000)

They're same except for some addresses (or whatever those hex strings are).

@DenKos363

This comment has been minimized.

Copy link

commented Mar 20, 2019

in my case I am getting quite similar outputs, except this one:

libphysfs.so.1 => /usr/lib/x86_64-linux-gnu/libphysfs.so.1 (0x00007ffaa6da7000)

Left part - built from ubuntu repository, Right part - built from source, using fixed make command (thanks @qwertychouskie)
https://www.diffchecker.com/Dqgqp4sL

And result is the same - "repository" app has issue, source app - doesn't.

@parasti

This comment has been minimized.

Copy link
Member

commented Mar 20, 2019

Then it must be a compile-time issue, right? Maybe something in the headers on the Debian build machines? If nobody can actually reproduce it via source for further debugging, then I say we're done here. Running out of ideas.

I see you're testing "1.6.0-8", but my findings show that Debian testing/unstable has a "1.6.0+git20180603-1" packaged. Does it have the same issue?

@DenKos363

This comment has been minimized.

Copy link

commented Mar 20, 2019

I see only these branches in debian repository:
2038 git checkout upstream/1.6.0+git20180603
2043 git checkout debian/1.6.0+git20180603-1

Compiled both of them (using suggested here approach #170 (comment))

Both didn't reproduce the problem.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented Mar 20, 2019

I have apitraces for the bad version (https://bugs.freedesktop.org/attachment.cgi?id=143684) and the good version (https://bugs.freedesktop.org/attachment.cgi?id=143734), and apitrace diff trace1.trace trace2.trace shows the GL differences between the two. Unfortunately I don't know OpenGL so it's a bunch of gibberish to me :) @parasti / @rlk Maybe one of you can tell what's going on :) There were a couple of chunks not present in the bad trace that were in the good trace, maybe that's it.

Anyways, the solution may be to ping Debian/Ubuntu maintainers to do a rebuild of the package.

Actually I wonder if it is a problem when compiling against the Debian version of Mesa, as on my system I am using the ubuntu-x-swat/updates PPA for stable Mesa updates.

@apoleon Since you seem to be the only one to be able to reproduce this issue on a fresh build, can you:

  • Try building with Clang instead of GCC to see if it makes a difference
  • Post which mesa packages you have installed, and their versions
@apoleon

This comment has been minimized.

Copy link
Author

commented Mar 20, 2019

I've just rebuilt the game on Debian unstable but the result is the same. I don't think it is related to the compiler and Debian uses GCC as the default anyway. By the way I don't think it is a good idea to compare different versions of the game on different platforms. Although Ubuntu is a Debian derivative, the versions of libraries can differ depending which version of Ubuntu you compare with Debian unstable.

Here are some tips how you can quickly find out the version of Mesa yourself. Go to

https://tracker.debian.org/pkg/neverball

The versions paragraph on the left side shows all the different versions of Neverball in Debian. Then click on neverball below "Binaries":

https://packages.debian.org/unstable/neverball

Apparently it depends on libgl1 provided by libgl1-mesa-glx. Mesa has version 18.3.4 and libgl1 is built by src:libglvnd version 1.1.0. but as you can see here

https://sources.debian.org/src/neverball/1.6.0+git20180603-1/debian/control/

I don't explicitly build-depend on mesa. It is pulled in by one of the other build-dependencies.

@DenKos363

This comment has been minimized.

Copy link

commented Apr 12, 2019

@apoleon did you have a chance to check interpreter versions for both cases?

@camthesaxman

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

This is definitely an issue with data files. The neverball-common Debian package is missing all of the material files in data/geom. Only the .sol files exist. https://packages.debian.org/stretch/all/neverball-common/filelist

If anyone is having this issue, check if you have /usr/share/games/neverball/geom/goal/goal.png. If that file doesn't exist, then replace it with the file here. https://github.com/Neverball/neverball/blob/master/data/geom/goal/goal.png

I can even reproduce this on Windows by deleting all of the .png files from the geom directory.

neverball_missing_pngs

@parasti

This comment has been minimized.

Copy link
Member

commented May 17, 2019

What the hell? You might be onto something here.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented May 17, 2019

Confirmed! Thanks for figuring this out. Now to figure out why the Debian package doesn't include this file... @apoleon Any ideas?

@apoleon

This comment has been minimized.

Copy link
Author

commented May 18, 2019

@camthesaxman Thanks for the hint. I can confirm that just installing the png files in data/geom makes the stars visible again. However this is a bit confusing because it has always worked this way before. In Debian we compile the sol files from source, the .mat, and .obj files are source files and not needed at runtime.

I don't know what has changed but creating a proper install target in your Makefile would certainly help to prevent such issues. Five years ago I filed #90
that helps to split the compilation into a data and binary part. Ideally the build system should take care of the installation step too, so that downstream maintainers just have to execute those targets and be done with it.

In any case thanks for solving this issue.

@parasti

This comment has been minimized.

Copy link
Member

commented May 19, 2019

Having an install target is the opposite of an "ideal" scenario for us. It's both a maintenance and compatibility burden. Putting things where they are supposed to go is what downstream is supposed to do. My 0.02€, for what it's worth.

@parasti parasti closed this May 19, 2019

@apoleon

This comment has been minimized.

Copy link
Author

commented May 19, 2019

Having an install target is good practice and there are many positive examples of upstream projects, games and applications, that have implemented one. It shouldn't be the task of downstream projects to figure out how a program is supposed to work.

@camthesaxman

This comment has been minimized.

Copy link
Contributor

commented May 19, 2019

@apoleon What about packaging all of the data files into a .pk3 archive like the Windows distribution does?

@parasti

This comment has been minimized.

Copy link
Member

commented May 20, 2019

@apoleon I think that's unwarranted. There is nothing obscure about how Neverball works. We have an executable and a data directory. You can put them anywhere. And that's it. That's nearly the simplest possible setup for a game.

The complexity comes entirely from downstream distro requirements. Distros want neverball and neverputt packaged separately, they want to split up data into three different packages, they want to remove the .map files from data, and so on. That's fine, but that complexity is entirely up to them, not us.

@apoleon

This comment has been minimized.

Copy link
Author

commented May 20, 2019

@apoleon I think that's unwarranted. There is nothing obscure about how Neverball works. We have an executable and a data directory. You can put them anywhere. And that's it. That's nearly the simplest possible setup for a game.

I didn't say that Neverball was obscure. I just replied to your comment that taking care of the installation process was entirely downstream's task. If you take a look at similar sophisticated games like Megaglest, Freeorion or Extreme TuxRacer then you will notice that they all provide common features to install their game data. The only thing downstream distributions have to change is the installation path prefix (because FreeBSD installs ports into /usr/local while Linux distributions prefer /usr/. Not one of those games makes me find out what files I have to install.

Your custom Makefile can be improved. If you think everything is fine and you don't want to put any work into a proper build system, then it's your choice. But please don't blame Linux distributions.

@camthesaxman
I could live with pk3 files too as long as you still provide all the source files and we can still build all the data from source, bundling everything into a pk3 file works too. That is not the problem. The build system should be adjusted then as well. Just for the record, Neverball in Debian didn't really change in the past five years because there were no new releases. It would be possibly interesting to find out why the stars feature was working in the past without the png graphics. Do I care to install them? No. Do I care to install the map files if needed? No. Would a proper build system have avoided such an issue in the first place. Absolutely yes.

@parasti

This comment has been minimized.

Copy link
Member

commented May 20, 2019

@apoleon I'm sorry, but you should have a look at what Debian does vs what is written in our install.txt file. Here is what the install command for our game data would look like:

cp -r ./data /opt/neverball/data

And that's it.

Megaglest does the same thing with their data except via cmake. I could not figure out what Freeorion does. Extreme Tux Racer uses autotools with around 100 Makefiles in their source tree.

Debian does not do this. I feel I have to repeat this because it seems to be getting lost: they do not copy the game data directory from a to b. Instead they split the game data into 3 different packages, by listing each file into a particular manifest. That was their decision, which I am completely okay with. But they did it, out of their own initiative. When files go missing, that is up to them, because they decided to take up that maintenance work. It has literally nothing to do with our build system. Is our build system perfect? Of course not. But it also has nothing to do with the topic at hand, whatsoever.

@apoleon

This comment has been minimized.

Copy link
Author

commented May 20, 2019

Debian builds the game data from source. How can you otherwise ensure that you get reproducible results and that your build process actually works and people can modify your software? The issue reported in this bug report highlights a flaw in your current build process and workflow. The /opt directory is meant for the installation of add-on application software packages. Data files of system packages should be installed into /usr/share according to the FHS. Your build system is insufficient.

@parasti

This comment has been minimized.

Copy link
Member

commented May 20, 2019

@apoleon Answer me this: why do you (Debian) build three packages instead of one? You build (Debian builds) neverball-data, neverputt-data and neverball-common. Why? Our build system doesn't do this. Our build system doesn't require you to do this. Nothing requires you to do this.

@qwertychouskie

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

@apoleon cp -r ./data /opt/neverball/data was literally just an example, it could just as easily be cp -r ./data /usr/share/games/neverball/data. Can you please just tweak the Debian package building script to add the missing PNGs and be done with it?

@apoleon

This comment has been minimized.

Copy link
Author

commented May 20, 2019

My last reply to this thread. We build -data and -common packages because those packages are architecture independent, that means the content can be built once but used on any supported Debian architecture. Shipping twenty-four different neverball-data packages which all contain the same data, just doesn't make any sense.

@parasti

This comment has been minimized.

Copy link
Member

commented May 20, 2019

@apoleon The entirety of Neverball data is architecture independent. In fact, Debian used to ship Neverball data as a single package. This changed for one reason only: to split neverball and neverputt into different packages (which, again, is not required by us or our build system). It had nothing to do with portability.

@qwertychouskie Debian has already fixed this issue, it'll just take a moment for the package to propagate.

@apoleon

This comment has been minimized.

Copy link
Author

commented May 20, 2019

@parasti You misunderstand the meaning of architecture-independent in the context of Debian. Your data files do not differ if I compile them on x86_64, i386, armhf or mipsel. A png file is the same on every architecture. This is simply a matter of disk space and performance optimizations that happen across the whole distribution. We ship > 60000 source packages. If you duplicate neverball-data which is uncompressed 87,9 MB large on 24 different architectures, you waste a lot of disk space for no reason because this package just contains data files. That is why we ship only one -data package but 24 different neverball packages, because the program itself, the binary, differs on various architectures, obviously.

All we asked for in #90 was to create different targets for data and executables. Your non-standard build system just makes it harder for downstream projects to make such optimizations and if you don't care, I don't care either. Bye.

@parasti

This comment has been minimized.

Copy link
Member

commented May 20, 2019

I'll stop here, because all my verbiage is obviously not getting thru.

In debian/neverball-common.install, replace this monstrosity:

data/geom/back/*.sol     usr/share/games/neverball/geom/back
data/geom/beam/*.sol     usr/share/games/neverball/geom/beam
data/geom/beam/*.png     usr/share/games/neverball/geom/beam
data/geom/flag/*.sol     usr/share/games/neverball/geom/flag
data/geom/flag/*.png     usr/share/games/neverball/geom/flag
data/geom/goal/*.sol     usr/share/games/neverball/geom/goal
data/geom/goal/*.png     usr/share/games/neverball/geom/goal
data/geom/jump/*.sol     usr/share/games/neverball/geom/jump
data/geom/jump/*.png     usr/share/games/neverball/geom/jump
data/geom/mark/*.sol     usr/share/games/neverball/geom/mark
data/geom/vect/*.sol     usr/share/games/neverball/geom/vect
data/geom/vect/*.png     usr/share/games/neverball/geom/vect

with this:

data/geom     usr/share/games/neverball

The patch in issue #90 has nothing to do with this. This would have still happened.

Edit: I'm talking about this file: https://salsa.debian.org/games-team/neverball/blob/1f359cf91dbc1ba7c004c49925a734433de4ed95/debian/neverball-common.install

@apoleon

This comment has been minimized.

Copy link
Author

commented May 20, 2019

This would not be necessary if you provided a proper install target. Neither the mat nor obj files are necessary at runtime. You don't make a distinction between architecture-independent data files and your binary files. Your build system is the reason why we have to do this.

@parasti

This comment has been minimized.

Copy link
Member

commented May 20, 2019

No, material files and .obj files are supposed to remain. Same for .map files. We want them distributed to our users. If that is against Debian policy, that's not our problem.

@camthesaxman

This comment has been minimized.

Copy link
Contributor

commented May 21, 2019

Why do we need to include the .obj and .map files if they can easily be obtained from the source code?

@parasti

This comment has been minimized.

Copy link
Member

commented May 21, 2019

Because Neverball mapping is a first-order activity that must come as part of the game. We want people to look under the hood and get curious. We want people to be able to start mapping the moment they install Radiant. I personally worked to make this process as straightforward as possible. Introducing people to mapping with "download the source code" is not that.

@camthesaxman

This comment has been minimized.

Copy link
Contributor

commented May 21, 2019

Ok, I see. Yeah, a lot of the common objects like railings and posts are used by multiple maps and they need to be available for users to make custom maps with them.

@rlk

This comment has been minimized.

Copy link
Member

commented May 22, 2019

I'm just getting caught up here, and I'm stunned by this discovery. This is an OLD bug. Well done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.