• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
FGFS

link libpng

15 posts in this topic

Hi
I try to package (Linux/c++/rpath) some libs with my app, as I doubt sdl1.2 will be around for very much longer. Now libsdl_image depends on libpng, but all I find are symlinks back and forth libpng12.so.0 etc. and only a libpng12.a but no .so (only symlinks on Ubuntu).
How to link to .a or where to find the .so? Do I need to include that at all? Is it enough if I pack/ship with my app only libsdl_image as there are also other libsdl dependencies like tiff etc. Are those dependencies only needed to compile libsdl?
Many thanks

0

Share this post


Link to post
Share on other sites

Hi
I try to package (Linux/c++/rpath) some libs with my app, as I doubt sdl1.2 will be around for very much longer.

 

Why do you think so? While I don't anticipate any new development on SDL 1.2, I also don't see it being killed anytime soon.

0

Share this post


Link to post
Share on other sites

It happens often, for ex. I need an older python for Blender 2.49 and I'm pretty sure that I won't find that package for Ubuntu 14.04 anymore.

 

Even if I don't ship them for now, I want to have them ready. Thanks for answering my dependencies question.

0

Share this post


Link to post
Share on other sites

It happens often, for ex. I need an older python for Blender 2.49 and I'm pretty sure that I won't find that package for Ubuntu 14.04 anymore.

 

Even if I don't ship them for now, I want to have them ready. Thanks for answering my dependencies question.

 

You're comparing apples to oranges here. Supporting a number of different Python releases is one thing, supporting two SDL versions is another thing entirely.

 

Blender 2.49 was released almost 5 years ago, SDL 1.2.15 is deprecated - time to consider upgrading.

 

As for your thanks, take the time to thoroughly read How To Ask Questions The Smart Way. If you're the TL;DR kind of person, at the very least read the On Not Reacting Like A Loser section and learn to become appreciative of people who get out of their way to try and help you.

0

Share this post


Link to post
Share on other sites


You're comparing apples to oranges here. Supporting a number of different Python releases is one thing, supporting two SDL versions is another thing entirely.

If I may throw my two cents into here, SDL 1.2 and SDL 2 have a decently different interface, from what I could tell reading about v2. Likewise, Python <= 2 and Python >= 3 have some significant differences that cause applications to fail to run across multiple versions, and they get installed in parallel to combat this: on my machine I have python2.6, python2.7, python3.3, python3.3m, python3.4, and python3.4m installed (the m variants using a different ABI, causing another incompatibility).

 

So, I'd say there are some similarities between needing to support a particular version of one and needing to support a particular version of another.

 

As for why, I don't have the explanation, and it wasn't provided. I assume it's a good one. In the case of Blender, as noted before, different Python versions aren't 100% compatible, so if someone wrote a good Blender plugin a long time ago and never updated it, you wouldn't be able to update Blender (or use a new Python version) and still use the plugin. It sounds as if his application is already done, so upgrading to SDL 2 is a little work-intensive.

2

Share this post


Link to post
Share on other sites

Seems you can't understand my question.

 

Rather you don't understand the internet.

When you ask a question on this forum, it doesn't go into an oracle that takes your question as input and outputs an answer. Other users - human beings - will read it, and you can get a detailed answer, a comment, or even no answer at all. You're not entitled to an answer. Get over it.

 

I stand by what I said: SDL 1.2 isn't going away anytime soon. There are many games and applications which rely on it. On top of that, SDL 2 was released less than a year ago; packages don't get deprecated so quickly in Linux distributions.

1

Share this post


Link to post
Share on other sites

 


You're comparing apples to oranges here. Supporting a number of different Python releases is one thing, supporting two SDL versions is another thing entirely.

If I may throw my two cents into here, SDL 1.2 and SDL 2 have a decently different interface, from what I could tell reading about v2. Likewise, Python <= 2 and Python >= 3 have some significant differences that cause applications to fail to run across multiple versions, and they get installed in parallel to combat this: on my machine I have python2.6, python2.7, python3.3, python3.3m, python3.4, and python3.4m installed (the m variants using a different ABI, causing another incompatibility).

 

So, I'd say there are some similarities between needing to support a particular version of one and needing to support a particular version of another.

 

As for why, I don't have the explanation, and it wasn't provided. I assume it's a good one. In the case of Blender, as noted before, different Python versions aren't 100% compatible, so if someone wrote a good Blender plugin a long time ago and never updated it, you wouldn't be able to update Blender (or use a new Python version) and still use the plugin. It sounds as if his application is already done, so upgrading to SDL 2 is a little work-intensive.

 

 

Good point. That said, as for the Python/Blender argument: having 6 releases of Python installed is a mess. As for SDL, I don't think SDL 1.2 is going away anytime soon.

0

Share this post


Link to post
Share on other sites

As I recall, how SDL_image utilizes image libraries it is all down to compile flags.

In the SDL_image src directory, run
 

./configure --help

By default it dynamically loads them at runtime but you can also link them to SDL_image at compile time.

Also.. since SDL 1.2 is more portable. I predict it will actually outlive 2.0. Especially since it has a much more stable API and has no input from companies like Valve.
SDL 1.2 is currently the only version that Emscripten supports too and it is surprising how little interest there has been in a SDL 2.0 API.

 

If you are worried about future portability, perhaps avoid SDL_image completely and just use libpng to load in your images (which is what I do). A good example is (http://zarb.org/~gc/html/libpng.html)

Edited by Karsten_
0

Share this post


Link to post
Share on other sites

Thanks for all input. I don't recall why I didn't use libpng, probably because you have to link statically.

 

I'll try a vanilla Ubuntu 14.04 in virtualbox and see if I can get all needed dependencies loaded/packed from: . by using ldd *

 

So, I can also check for python 2.6 and if all goes right, finally replace 12.04.

Edited by FGFS
0

Share this post


Link to post
Share on other sites

see if I can get all needed dependencies loaded/packed from: . by using ldd *

 

Ah, since I believe SDL_image loads image libraries at runtime (they are not linked in statically or dynamically by default) it is unlikely that they will show up by ldd.

 

You might be able to use something like trace, gdb (or other debugger) to find what libraries have been loaded by a test application.

0

Share this post


Link to post
Share on other sites

In theory, you'd only need to add SDL_image and SDL to your linker.

If they are installed, you can use -lSDL2 and -lSDL2_image

 

If you are compiling it yourself, this command will probably work (given you have autotools and build-essential installed):

./autogen.sh && ./configure && make && sudo make install

It will compile and install SDL2, probably under usr/local. It would also work for SDL_image and SDL_mixer...

 

The libpng runtime come in every linux distribution I've ever used (save arch), so don't worry about it. Also, if someone is using an Arch or Gentoo or anything that doesn't come with the runtime libpng, they probably know what they are doing (and will understand the missing shared object error) and will be able to fix it themselves (basically a call apt-get or pacman).

 

But yes, unfortunately, linux does not link statically. This is a major pain when considering this kind of dependencies, but well, them's the breaks.

 

 


Also.. since SDL 1.2 is more portable. I predict it will actually outlive 2.0.

SDL1.2 is not necessarily more portable.

You can't use it on iOS in a practical manner, given the legal restrictions the LGPL license imposes. SDL2 is zlib, that is way more usable from a developer point of view.

 

There are also the more obvious reasons; SDL2 is fully hardware accelerated, it has a better API, supports OpenGL ES and 3+, to name a few.

So, I'd bet all my programming books that SDL2 will outlive 1.2 easily, the same way I did saying XNA would be discontinued.

@edit

SDL1.2 is already marked as a historical version, and looks like it hasn't been updated in over two years.

Edited by dejaime
0

Share this post


Link to post
Share on other sites


But yes, unfortunately, linux does not link statically. This is a major pain when considering this kind of dependencies, but well, them's the breaks.

 

I was thinking the other way round. If a lib update breaks compatibility, like python in the past and sdl 1.2 to 2, I can simply include the old dynamic lib and am not forced

to rewrite my app. As this would have been a lot of work for my sdl 1.2 app, I was right. tongue.png 

0

Share this post


Link to post
Share on other sites

 


But yes, unfortunately, linux does not link statically. This is a major pain when considering this kind of dependencies, but well, them's the breaks.

 

I was thinking the other way round. If a lib update breaks compatibility, like python in the past and sdl 1.2 to 2, I can simply include the old dynamic lib and am not forced

to rewrite my app. As this would have been a lot of work for my sdl 1.2 app, I was right. tongue.png

 

 

I just downloaded and installed Ubuntu 14.04 LTS, which was released last Thursday (Apr 17) and is supported for 5 years, on a VM.

 

Then I did a sudo apt-get install libsdl1.2-dev libsdl-image1.2-dev (libpng12-dev was among the dependencies), and built a simple program that loaded a .PNG file. Worked fine.

 

So it looks like SDL 1.2 will be around for at least another 5 years on a major distribution. All your work for being "right" was pointless.

0

Share this post


Link to post
Share on other sites

No, as I've said, I only wanted to have them ready and test if all would be fine. I won't include them in the next years.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0