Gosu's OpenGL implementation vs. Python's SDL

By misbehavens Date 2013-09-18 20:28

I've been thinking a lot lately about Ruby vs. Python. Not the languages, but their libraries and overarching philosophies that drive their direction.

Python's culture follows a philosophy that there should only be one way to do something; one tool for the job. For example, pygame makes use of a library called SDL (Simple DirectMedia Layer). It handles the 2D/3D graphics, sound, input, etc like Gosu does, but unlike Gosu, it is not a game library. It only has one job. As far as I know, SDL is the official Python library to use if you're dealing with graphics.

Ruby has a rich community of libraries (gems) and it seems there are new gems popping up every day. However, gem authors fight to gain popularity instead of contributing to an official library. Rails different in that it's sort of the de facto Ruby web framework which gives Rails the advantage of having lots of contributors because lots of people choose it. There are alternative frameworks in Ruby, but none as popular as Rails. I'd like Ruby to have the same success with a game engine, where people know of Ruby because it has a great framework for creating games.

Gosu doesn't currently support graphics on the Raspberry Pi (although I know work is being done to support that), but it got me thinking about whether or not Gosu is making the right choice in its custom implementation of graphics, etc. I see the value in creating/choosing a standard library that can be maintained by a large group of people, especially when it comes to graphics, versus multiple similar implementations that compete for contributors.

I came across a Ruby implementation of SDL but not sure how up-to-date it is (or if anyone uses it). Searching google, I found many Ruby OpenGL graphics implementations and game libraries that never saw much adoption and eventually faded into "no longer maintained" status.

I've never written any C or C++ code. Lately, I've been trying to get more experience in that area. There may be many others who use Gosu who also don't have much experience in that area which means there probably aren't many contributors/maintainers of the Gosu core. Are we happy with the core graphics implementation of Gosu? Do we feel that it has enough support to be maintained as the official Ruby graphics library? Should Gosu be split into two distinct libraries: the graphics library and the game library?

This is not meant to be negative criticism but more of a constructive discussion that leads to a better library for all of us Ruby developers. What do you think?

By erisdiscord Date 2013-09-19 00:59

Re separating "game" from graphics: AFAIK Gosu's rendering system is tightly integrated into the run loop. There's some stuff that has to happen before and after your custom draw method, and I think extracting that from the rest of the library would be difficult and not worthwhile. The architecture is what it is.

I think OpenGL is the best choice for graphics, even 2D. It's much faster than SDL's software-based rendering and it's much easier to do fancy stuff like rotation, perspective transformation and blending modes—not to mention the potential to use GLSL for advanced effects. Gosu doesn't directly support GLSL just yet, but there are already libraries like Ashton that support it as an add-on.

I don't have an answer or opinion for the other questions really.

By jlnr (dev) Date 2013-09-19 01:23

I think SDL always uses OpenGL for graphics now, but I'm not sure how/if they have managed that while staying compatible with their old interface, which was clearly geared towards software-based rendering.
Most people probably still use SDL only to open the OpenGL viewport though :)

By Spooner Date 2013-09-19 11:13

I'm working extensively with SDL2/Python at the moment and am finding it pretty good! The main advantage it has over CRuby/Gosu is no garbage collector stutter, bytecode distribution (to obfuscate code) and proper multi-thread support; on the other hand, Python is not nearly as nice to actually code in as Ruby!

SDL1 uses SDL_Surface, which is, by default run in software. Unity of Command used this system and this was plenty fast enough.
SDL2 uses SDL_Texture (hardware accelerated; opengl, directx or gles backend) and SDL_Surface (always software). You can also mix this with opengl or use just opengl with it, if you need the performance (you'd just use the non-graphics side of SDL then - window management, sound, input, etc), if you force it to use that rendering backend (for example, it will use directx on Windows by default). [EDIT: I'm using hardware acceleration throughout, but using high-level sprites for the interface (because that is easier and fast enough) and low-level opengl for the stuff that needs it (rendering the map/units).]

The "best" python SDL2 library (https://bitbucket.org/marcusva/py-sdl2) adds a lot of higher level structures over the rather horrid C SDL wrapper (like Sprite and Window classes), which make it actually a tiny bit higher level than even vanilla Gosu, though not quite as high level as Chingu/Gamebox though, but give it time!

By SPK Date 2013-09-19 18:40

^This. py-sdl2 is really cool.

But no matter how hard I try, I always come back to Ruby/gosu. :)

By Spooner Date 2013-09-19 18:43

I probably would too, but no-one wants to pay me to use Gosu :D

By jlnr (dev) Date 2013-09-23 07:19

https://www.ruby-forum.com/topic/4417257

I wonder if RGenGC will get rid of the stutter. I suspect that it is much worse on Windows too because it has never bothered me on OS X (obviously :)).

By Spooner Date 2013-09-23 10:05

It is noticeable on Windows compared to Linux. I've found it it only really noticeable when you are trying to manage smooth full-screen scrolling. I think in Smash and Grab, I turn off the GC while you are dragging the window, but leave it on when the background is static.

By jlnr (dev) Date 2013-09-23 12:09

That won't work for every game but…genius. :D

By jlnr (dev) Date 2013-09-19 01:17 Edited 2013-09-19 01:27

When I started porting Gosu to OS X, the SDL still sucked on Macs. And it was LGPL-licensed, which prevented it from being used on the App Store later on. That's why I have been eyeing glfw for a long time: Its only task is to set up an OpenGL window (and do some input), which is exactly what Gosu would use from the SDL too.

At this point I'm not sure if SDL 2.0 or glfw 3 would be the better choice as a base library, but I absolutely agree that I never want to touch any code again that uses the X11 API directly :) And both libraries would make it easier to port Gosu to new platforms.
I also don't think it has to be a sudden departure. The Gosu::Window implementations can just be moved onto a base library one by one. The whole Graphics stack does not really use anything that's platform specific, it just needs more #ifdef to switch between OpenGL and OpenGL ES functions now that it's supposed to support Android and the Pi.

But what is the game part of Gosu? Gosu provides no game logic because I see it as a media library like the SDL. In fact, Gosu was my attempt at writing something like the SDL, except based on OpenGL, because the SDL was still using DirectDraw in 2001 :) I have written non-game systems in Gosu that would otherwise have been built in Flash.

Good discussion in any case because I want to reduce/split up the work that I have to do to keep Gosu semi-alive. The first step was to move the Ruby.app wrapper on OS X into its own repository. That monster has sucked up countless productive days… and after I'd extracted it from the Gosu repository, I found out that wycats is working on a standalone Ruby.app too! So that might be something else that I can let other people build for me. :D

By Spooner Date 2013-09-19 18:25

I need to move to one of those OSX apps one day in Releasy :$. Give me a shout when you know which one is going to continue to exist because I'm lazy...

By jlnr (dev) Date 2013-09-20 05:02

My Ruby.app is just the old app spun into a new git repository. I might ping you or fork Releasy once I make two changes on my To Do list. It should be a seamless upgrade from the old .app. :)

By misbehavens Date 2013-09-20 21:53

Thanks for your feedback Julian! I wasn't aware that your plan for Gosu was to be a media library. The homepage mentions "Gosu is a 2D game development library". =] But it's good to hear from you your vision of the project. Along those lines, it seems like Gosu would need to work toward supporting 3D graphics if it were going to become a true media library.

I like the idea of splitting things into smaller pieces. I have tried digging through the Gosu github repo but I don't know my way around so I don't understand how things are organized and don't know where I can contribute. Having smaller repos, or even some sort of directory guide (or READMEs in each directory) would help to understand how the whole thing fits together.

I checked out GLFW and it looks nice (small and focused, written in C). I don't know much about the implementation of SDL 2.0 so I don't know how much junk is in there that Gosu wouldn't use. I leave that decision up to you.

I decided to start learning C (using http://c.learncodethehardway.org/book) since it's probably a good skill to learn. I think that will help me understand the project better and find ways to contribute.

By jlnr (dev) Date 2013-09-21 05:17

Gosu does provide 3D graphics…in the form of gl {…} blocks :) Everything beyond that, like support for model loading etc., would make the project impossible to maintain. Thankfully OpenGL is relatively portable across platforms.

Yes, I think I should extend the CONTRIBUTING.md file a little to explain the overall project structure. *makes a note*

By tangofoxtrot Date 2013-11-11 22:20

Misbehavens, I was unaware of this thread and not being aware of the state of gosu on the Rpi, naively installed ruby 1.9.3 and gosu. Of course, it didn’t work. My ruby threw a segmentation fault when it tried to open a window.

Like you, I would like to see gosu on the RPi. Our motives are different (I have a bunch
of time invested in ruby code that I developed on a Ubuntu desktop system, but must run on the RPi), but I totally agree with your sentiments regarding ruby and gosu.

I see that your last post was a couple of months ago. Are you aware of any ongoing work in bringing gosu up on the pi?

By jlnr (dev) Date 2013-11-12 21:23

I've bought an RPi just to port Gosu, actually, but I gave up after one day. These are the options I see:

• Someone ports GLFW to the RPi and I finally have a reason to port Gosu to be GLFW-based on Linux, allowing Gosu to be run on the RPi at the same time.
• Extend Gosu's messy X11 backend with a lot of #ifdef to make it work on the RPi
• Change Gosu to be based on the SDL on Linux

The last option is the obvious one, but I'll really have to swallow my pride because I much prefer GLFW's interface. :(

By Spooner Date 2013-11-13 14:08

I assume you mean SDL2, not SDL; it isn't bad at all on Linux, though for non-trivial use, I seem to have to use OpenGL anyway :/. The idea of having different backends is not a great one, since the things you are using are supposed to be cross-platform anyway :D Oh, the laughs we've had about your audio backends ;)

By jlnr (dev) Date 2013-11-13 23:01

Well, I was hoping that GLFW would be the portable panacea to open an OpenGL (ES)-capable window for me, but the RPi has proven that it isn't. :( I'm pretty sure that there will be new exciting problems once I start playing around with the SDL2...

By jlnr (dev) Date 2014-04-29 22:12

If you still receive notifications from this forum - please check out http://www.libgosu.org/cgi-bin/mwf/topic_show.pl?tid=1095 :)