LÖVE

Have any of the developers heard of SFML? It's a C++ library similar in abilities to SDL, but totally object-oriented of course. I also hear it's faster than SDL.

I've heard horror stories about it on #ludumdare

Really? What do they have against it? I've heard it wasn't so good back in the days of 1.2 or 1.3.

I've heard about SFML on two fronts:

• It's the library used in M.A.R.S.
• I also know that it has a ruby interface, but I don't know how it compares with other ruby libs like gosu or rubygame (by the way, let me know if you investigate those).

Yeah it's got a Ruby interface, but it's ooold, as in 1.2 (current version is 1.6, and I think they're about to release 2.0). However I recently heard someone is going to create a new interface for 2.0.

I've heard of rubygame, but haven't checked it out all that much. I had a quick look at the gosu docs, I certainly don't think it's better with SFML in features. Some things that gosu doesn't seem to have (that SFML does) is sound input, threading, and networking (HTTP, FTP, and sockets).

I've heard that Ruby (1.9 included) is too slow for game development, mainly because of it's mark/sweep garbage collector. Have you experimented using Ruby for game development?

BlackBulletIV wrote:Have you experimented using Ruby for game development?

Not yet. I can say that ruby 1.9.2 feels faster than 1.8.7. Don't know how it would handle with games.

I believe that the main reason why ruby is slower than others is because of its "everything-is-a-method" approach. Didn't know that the gc was so important.

The article I read on the topic was this: http://gafferongames.com/2009/01/11/rub ... velopment/

That guys says that 1.8 didn't have native threads nor a bytecode interpreter. Everything being a method would slow it down, I'm not sure how much, but the garbage collector is important. Because of it's mark/sweep approach Ruby will be running nicely until garbage collection kicks in (usually about every 5 seconds). Mark/sweep is a two pass operation, and it doesn't run in the background; so when GC kicks in, there's a big slow down.

This guys says that it needs an incremental GC, like Python. Because Python uses reference counting, it can destroy objects incremental, in other words, when they have no more references. But that makes the C API a pain the... yeah (ever taken a look at the Python/C API, it's a nightmare!).