SDL2 not linking correctly in OSX version (And a fix)

[shayneoneill]

When using the demos with the OSX version, I get the error;-

OSError: dlopen(Tilengine.dylib, 6): Library not loaded: @rpath/SDL2.framework/Versions/A/SDL2
  Referenced from: /usr/local/lib/Tilengine.dylib

This is from the python bindings, but similar issues emerge with the C examples.

My copy of SDL2 is in the standard /usr/local/lib location (Which is where homebrew puts it. Ignore fink and macports, homebrew is more or less the standard these days).

So heres a fix!

install_name_tool -add_rpath /usr/local/lib /usr/local/lib/Tilengine.dylib

Perhaps putting this in the makefile with an $SDL_PATH type option to let folks change that for unconventional installs might be the way to go.

[megamarc]

Thanks for checking it! The error you see is because I have installed the official SDL2 framework from their website, which goes to /Library/Frameworks. Its path seems to be hard-coded into the final executable by the linker when using the -framework SDL2 switch, so it expects to find it there. As I don't know if end users running tilengine have SDL2 as a macOS framework or as a unix shared library in /usr/local/, there must be a way to make the library search on both places, and not to force people to have an explicit version. I'll done a bit of research about this

[shayneoneill]

Yep, looks like your right about the official distro putting it in a different place than homebrew.

Ok looking here: https://ubuntuforums.org/showthread.php?t=1573787 It seems that it might be possible to specify multiple rpaths. Thats a linux link, but the wording of install_name_tool man page seems to imply that it might be the case also for osx..

Off topic, I note that the examples seem to show significant tearing on my mac, even with the vsync hook turned on. Does the library have any facilities for double buffering or anything like that?

[megamarc]

After reading this SDL section, it's clear that one must choose between the macOS path (link against Framework) or the unix path (link against a .dylib). It's not possible to have both at once.

Homebrew looks like a great idea, as Darwin is a heavily stripped-down unix that lacks so many standard components. But if I link against the .dylib, I'll force users to install a package manager and then install a package, whereas if I link against the framework, users will just have to download and install a friendly .dmg file that weights one mb. I don't know how fragmented is the developer community in Mac, the amount of devs that just work with frameworks vs the ones using (or willing to use) Homebrew. Maybe I should release both versions, and let the end user choose...

In regard to the screen tearing, I'ts the SDL and video driver that manages this. Tilengine itself just sees an array of pixels. This is the source code of the windowing component, you can bypass the built-in one and use the source as a basis to implement your own, changing function names of course so they don't clash.

[adtennant]

@shayneoneill I've created a Tilengine Homebrew Tap that solves this problem.

[shayneoneill]

Thats a fantastic solution. Good work

[ignasigarcia]

Hi everyone!

After running install_name_tool -add_rpath /usr/local/lib /usr/local/lib/Tilengine.dylib

...I get this error:

python [master●] % python test.py
Traceback (most recent call last):
  File "test.py", line 1, in <module>
    import tilengine as tln
  File "/Users/tasillo/Dev/Tilengine/samples/python/tilengine.py", line 567, in <module>
    _tln.TLN_EnableInput.argtypes = [c_int, c_bool]
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 378, in __getattr__
    func = self.__getitem__(name)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 383, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: dlsym(0x7fada7f053c0, TLN_EnableInput): symbol not found

Any ideas why this symbol is not found? Thanks!

PS: I've also installed the Homebrew version but did not fix it.

[megamarc]

It seems that the tilengine.dylib binary is not up to date; the python binding is looking for a function that was recently added but can't find it. I'll check that everything is up to date in the repository. Have you downloaded the whole project from GitHub, or one of the packages from itch.io?

[ignasigarcia]

Thanks for checking it @megamarc!

I've used the whole project from Github.

Thanks!

[ignasigarcia]

Hey @megamarc,

Any luck with that function on the Python binding?

Thanks!

[megamarc]

Sorry for the delay, I've been busy last week. I've clean rebuilt and commited the binary library, size is different now so I suspect last build was broken. I've tested inside my virtual machine environment and everything seems ok now. Can you please confirm this?

[ignasigarcia]

Thanks a lot @megamarc! Worked like a charm.

I'd like to make an Axelay fan game and your library is perfect for that. You even added an example in Python on how to do the vertical levels sky effect. Brilliant!

Moltes gràcies!

[megamarc]

De res :-)

Despite popular belief, 3D levels in Axelay didn't use Mode-7 at all, they used just raster effects altering vertical start position to fake the rolling effect. That's why the scaling was only in vertical direction and not in horizontal, but it gained two parallax layers that was not possible with regular mode-7. It's the same technique used in MegaDrive's Sonic 3D Blast bonus levels: https://www.youtube.com/watch?v=RFx1XFzbICg

[ignasigarcia]

Amazing! Thanks for the video and the explanation @megamarc ! Really appreciate it.

I wanted to assist to the latest RetroGaming BCN event where you did a presentation but unfortunately I couldn't. Maybe next time!

Thanks for your help man

[megamarc]

Thanks for your interest and enthusiasm! I appreciate it. I hope there will be future retrogaming events where I can participate again.

By the way, we're both catalan, feel free to PM me and see if we can collaborate in your project!

[ignasigarcia]

Thanks a lot @megamarc , dully noted! :)

I will keep you posted on the progress. Thanks!