Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411990 Posts in 69441 Topics- by 58486 Members - Latest Member: Fuimus

June 17, 2024, 12:33:42 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Some questions regarding Lua, Python and Ruby
Pages: [1]
Print
Author Topic: Some questions regarding Lua, Python and Ruby  (Read 3625 times)
PGGB
Level 8
***



View Profile
« on: January 09, 2009, 06:59:51 AM »

Hello everyone,

after developing mainly in Delphi(which sadly restricts you to Windows and has some other quirks) and having learned some C (which is crazy hard compared to Pascal >.>) I was looking for a better language for game development.
I basically narrowed it down to Lua, Python and Ruby as indicated by the thread title. The basic idea for Python and Ruby was to use the RAD capabilities of those languages to speed up the development and rewrite the resource-heavy parts in C or C++ as to not get hindered by the low general speed of those interpreted languages.

This leads me to my first question:
Since you generally embed your Lua code into the C code I guess that you first have to write the game base in C before you can start hacking in Lua. Is this correct or can I get a similar working approach as mentioned before?

Also when the low speed of the interpreted languages is mentioned it seems that someone is also quick to mention the workaround by rewriting parts in C, yet I've never seen/heard of people who actually use this extensively in one of their projects. Is this really feasible and do you know how easy/good it works in either Ruby or Python?

Last question would be to people who have used Ruby themselves (if there are any Roll Eyes):
the only gaming-related library I found is Rubygame which seems to be only developed for Linux. Am I wrong or are there any other viable libraries?

That kinda wraps it up. I hope you can help me with some of the questions.
Gentlemen?  Gentleman
Logged
increpare
Guest
« Reply #1 on: January 09, 2009, 07:11:15 AM »

Hello everyone,

after developing mainly in Delphi(which sadly restricts you to Windows and has some other quirks) and having learned some C (which is crazy hard compared to Pascal >.>)
No it's not!  It's more or less...exactly the same (syntactically anyway)... .  I started off using Delphi Smiley

If you are looking to do cross-platform stuff with pascal, check out freepascal, or gnupascal I think?  I used fpc to write a linux mud server ages ago.

Quote
Since you generally embed your Lua code into the C code I guess that you first have to write the game base in C before you can start hacking in Lua. Is this correct or can I get a similar working approach as mentioned before?
You might want to check out love though, which is a lua framework for gamesmaking.  No non-lua coded needed for it.  It's almost cross-platform; hopefully will be totally cross-platform soonish.

Quote
Also when the low speed of the interpreted languages is mentioned it seems that someone is also quick to mention the workaround by rewriting parts in C, yet I've never seen/heard of people who actually use this extensively in one of their projects. Is this really feasible and do you know how easy/good it works in either Ruby or Python?
Check out balding's quest on this forum for an example of something heavily scripted (in lua), which still has a lot of low-level c stuff going on for the more processor-intensive bits.
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #2 on: January 09, 2009, 07:22:57 AM »

Hello everyone,

after developing mainly in Delphi(which sadly restricts you to Windows and has some other quirks) and having learned some C (which is crazy hard compared to Pascal >.>)
No it's not!  It's more or less...exactly the same (syntactically anyway)... .  I started off using Delphi Smiley
C++ is pretty similar to Delphi. I'd skip C straight away and go to C++. Delphi's a pretty good starting language imho, I too started with it (ignoring "lesser" platforms I may have dabbled in before hand).

Quote
Also when the low speed of the interpreted languages is mentioned it seems that someone is also quick to mention the workaround by rewriting parts in C, yet I've never seen/heard of people who actually use this extensively in one of their projects. Is this really feasible and do you know how easy/good it works in either Ruby or Python?
Check out balding's quest on this forum for an example of something heavily scripted (in lua), which still has a lot of low-level c stuff going on for the more processor-intensive bits.
I tend to think if you are running into speed issues in your scripting language, you are doing it wrong. You should have outsourced the work to C++ already. I don't know Ruby or Lua, but Python has a strong amount of C++ extensions that it interoperates with already. Though it is not likely that you actually need tight coupling between the C++ and the scripting anyway, I should imagine an API is sufficient.
Logged
PGGB
Level 8
***



View Profile
« Reply #3 on: January 09, 2009, 07:35:57 AM »

You might want to check out love though, which is a lua framework for gamesmaking.  No non-lua coded needed for it.  It's almost cross-platform; hopefully will be totally cross-platform soonish.

Check out balding's quest on this forum for an example of something heavily scripted (in lua), which still has a lot of low-level c stuff going on for the more processor-intensive bits.
Thanks this is both very interesting.

Hello everyone,

after developing mainly in Delphi(which sadly restricts you to Windows and has some other quirks) and having learned some C (which is crazy hard compared to Pascal >.>)
No it's not!  It's more or less...exactly the same (syntactically anyway)... .  I started off using Delphi Smiley
C++ is pretty similar to Delphi. I'd skip C straight away and go to C++. Delphi's a pretty good starting language imho, I too started with it (ignoring "lesser" platforms I may have dabbled in before hand).
Well I find it somehow more difficult anyway. May just be that I'm not as used to it though. Tongue I learned C to try some low-level stuff in Linux and since I didn't want to do anything big entirely in C anyway I never really felt the need of C++. Wink
Logged
cpets
Level 0
**


View Profile WWW
« Reply #4 on: January 09, 2009, 10:10:53 AM »

Lately I've been using python with pygame and opengl bindings. The gl bindings can be crazy slow, but they're a good place to start. Where performance has been a problem, I've written rendering routines in cython (http://www.cython.org/). Cython lets you write code that looks like python, add some type annotations, and then cython translates to C and compiles with all the python goo so that you can use it like a standard python module. I haven't seen how well this works on a full production level, but it's been great for smaller game projects.
Logged
J.G. Martins
Level 2
**


AKA anvilfolk


View Profile WWW
« Reply #5 on: January 09, 2009, 11:01:57 AM »

Whoa, seriously, OpenGL bindings slow? How come? It should just be an interface to the library, hence providing hardware acceleration. I'd appreciate it if you could elaborate on this, since this is one of the things I've thought about using.

Thanks!

Also, Tyheam, maybe to start out you can just use a scripting language for smallerish projects, and when you feel confident enough you can move on to more low-level languages like C and C++ (I wouldn't go for C), and after that, learn about interfacing between them.

Apparently, Lua has some great interfacing thingies. I think there's stuff so that you can tell which C++ classes you want to export to Lua and all the work is done automatically Smiley If I'm not mistaken, DataRealms did that on Cortex Command.
Logged

Gold is for the mistress -- silver for the maid --
Copper for the craftsman cunning at his trade.
"Good!" cried the Baron, sitting in his hall,
"But iron, cold iron, is the master of them all."
--- Rudyard Kipling
Cray
Level 0
***

can't upload an avatar :(


View Profile WWW
« Reply #6 on: January 09, 2009, 12:11:36 PM »

Last question would be to people who have used Ruby themselves (if there are any Roll Eyes):
the only gaming-related library I found is Rubygame which seems to be only developed for Linux. Am I wrong or are there any other viable libraries?

There are a couple others Smiley

Haven't tried them out though, so no idea if they're any good
Logged

▓█▓ rpg maker vx
▓█▓ cemetery manager
cpets
Level 0
**


View Profile WWW
« Reply #7 on: January 09, 2009, 01:35:46 PM »

Whoa, seriously, OpenGL bindings slow? How come? It should just be an interface to the library, hence providing hardware acceleration. I'd appreciate it if you could elaborate on this, since this is one of the things I've thought about using.

I'm completely open to the possibility that I was doing something wrong, or using the wrong calls, or something; the documentation has a section on using arrays instead of lists and batch processing vertices, none of which I used.

That said, when I started noticing slowdown and profiled, the bulk of the time was spent in a routine which checked for gl errors and then translated them in to python exceptions. Maybe you can turn this off.

My quick solution was to copy and paste my gl calls in to a cython file, which worked pretty much without alteration and got me back to my target fps.
Logged
J.G. Martins
Level 2
**


AKA anvilfolk


View Profile WWW
« Reply #8 on: January 09, 2009, 03:20:46 PM »

That's weird. I find it hard that you'd be doing something so wrong that it'd get your program so slow... Besides, you profiled it!

Can you figure out if you had/have hardware acceleration at all? There might be something weird and you're using a software renderer. Or is it really just the exception thing?
Logged

Gold is for the mistress -- silver for the maid --
Copper for the craftsman cunning at his trade.
"Good!" cried the Baron, sitting in his hall,
"But iron, cold iron, is the master of them all."
--- Rudyard Kipling
cpets
Level 0
**


View Profile WWW
« Reply #9 on: January 09, 2009, 10:29:37 PM »

That's weird. I find it hard that you'd be doing something so wrong that it'd get your program so slow... Besides, you profiled it!

Can you figure out if you had/have hardware acceleration at all? There might be something weird and you're using a software renderer. Or is it really just the exception thing?

I am hardware accelerated, glxinfo tells me so. I'm not too surprised about it, really. I wouldn't let it stop you from delving in to the python/gl world, as it's been the most fun game programming setup I've had in a long time and there are easy workarounds.
Logged
mildmojo
Level 1
*


summer rain (soon)


View Profile
« Reply #10 on: January 10, 2009, 12:09:45 AM »

I haven't really seen anyone seriously discussing Ruby game dev here, which is too bad.  It needs some love.  The language is awesome.

I started with Rubygame, which is a really nice all-in-one library that leverages SDL, which works on most platforms.  You get graphics, sound, media handling, sprite management, input, and rudimentary framerate management all in one.  I do develop in Linux, but Rubygame worked fine in win32 as well.  Just 'gem install rubygame' in windows and you're pretty much good to go.  Doesn't play nice with cygwin Ruby, though; try the one-click Ruby installer instead.

Rubygame's use of SDL is a boon and a handicap.  One of the biggest problems is that there aren't prebuilt binaries readily available for all the SDL libraries it uses on all platforms (SDL_gfx.dll for Windows, in particular).  You can search around and eventually find them on 3rd-party sites, but it's non-trivial to try to build them yourself.

I was/am using the Chipmunk 2D physics library, and I quickly ran into limitations with sprite rotations.  The binding to SDL_gfx's rotozoom function creates a new SDL surface every time it's called, and I think with a few large physics objects on the screen, I was throwing surfaces away faster than Ruby's garbage collector could keep up.  Memory usage would skyrocket into hundreds of MB for a simple scene.  If you don't need to do rotations on every frame, you probably won't have that problem.

Rubygame 3--if it ever gets released--is supposed to be a major rewrite that uses OpenGL for graphics rendering.  That would probably cure the problems I was having.

There are other frameworks available, depending on how much you'd like done for you and how stable you'd like your library to be. 

The other big game dev library is Gosu, which is also cross-platform, and uses OpenGL as its rendering back end.  I tried it briefly, but something about it just didn't agree with me.  Others have had great luck with it; I've even read of 3D networked multiplayer stuff using eventmachine, but it's nothing I've experienced.

Shattered Ruby and Railgun, two Rails-ish approaches to game development, seem to have died on the vine.

My current favorite is GLFW (gem install ruby-glfw), a really lightweight cross-platform OpenGL wrapper that gives you input support, TGA texture loading, and some timer stuff, I think.  For the graphics, you basically call regular C-style OpenGL functions wrapped by ruby-opengl.  It doesn't abstract much of the graphics handling, so you'll need to learn OpenGL.  I've used the Ruby bindings for the nice FTGL OpenGL font handling library, too, though it was tricky for me to get it running in win32.

From my own experience, I agree with Boris above: if your interpreted program is slow, there's a faster algorithm you could be using, or you could sub out to a compiled language.  RubyInline looks like a stupid-easy way to write inline C/C++, and it looks like it may even be able to post-process some of your Ruby functions and turn them into C.

It's still tricky to distribute Ruby apps since the language lacks something nice like Python's compiler.  I'm using the cross-platform RubyScript2Exe (available as a gem), which traces your app and creates a self-extracting executable that embeds your code and a minimal Ruby distribution with the parts you need.  It's pretty transparent to the end user, but the community needs to find a better solution in the long term.

The site seems to be down right now, but people at the Rubygame Forums used to discuss Ruby game development in general. 

If you like, you can have a look at the Rubygame-based text adventure a friend and I put together for the Demakes contest (Road Trip: Southwest USA).  Though it's a text adventure, the console is drawn graphically in order to emulate the slower scroll of a 386.  The source is available and I'm pretty sure it's documented, though I wrote it in a week so it's probably not a work of art. 

Hope that helps.
« Last Edit: January 10, 2009, 11:49:42 AM by shrapnel » Logged

DEMAKE compo entry: Road Trip: Southwest USA
J.G. Martins
Level 2
**


AKA anvilfolk


View Profile WWW
« Reply #11 on: January 10, 2009, 07:38:18 AM »

Nice post Smiley

One thing though, regarding your rotation problem. As far as I know, it is common usage to pre-rotate what you'll be needing, say, on level loading times. The game comes with the single sprite, and then you just load that, rotate it X number of times (as many as you'll need) and store the rotated sprites too so you can use them throughout the level. Should be pretty straightforward to use Smiley
Logged

Gold is for the mistress -- silver for the maid --
Copper for the craftsman cunning at his trade.
"Good!" cried the Baron, sitting in his hall,
"But iron, cold iron, is the master of them all."
--- Rudyard Kipling
mildmojo
Level 1
*


summer rain (soon)


View Profile
« Reply #12 on: January 10, 2009, 11:41:04 AM »

One thing though, regarding your rotation problem. As far as I know, it is common usage to pre-rotate what you'll be needing, say, on level loading times. The game comes with the single sprite, and then you just load that, rotate it X number of times (as many as you'll need) and store the rotated sprites too so you can use them throughout the level. Should be pretty straightforward to use Smiley

If you're trying to do smooth, infinite rotation (angle determined on the fly by a physics engine), doesn't that have the potential to be resource-intensive to do?  I'm imagining hundreds of copies of a sprite stored in memory.  You could use fewer, I suppose, and have sprites snapping or jittering between predefined angles when rotation speeds are slow.  I've seen plenty of that in top-down RTS games. 

I guess I changed my tools to fit my strategy rather than changing my strategy to fit the tools. =)  That strategy would work quite well if rotation speed was linear, I think.  Thanks for the tip.
Logged

DEMAKE compo entry: Road Trip: Southwest USA
mirosurabu
Guest
« Reply #13 on: January 10, 2009, 04:28:22 PM »

C++ is not crazy hard compared to Object Pascal. Smiley Maybe C is, but C++ comes with a lot of easy-to-use data structures unlike C. And the syntax is not much different than that of Pascal. And you can use even simpler C# ?

Regarding scripting languages, I've only used Python so far and that would be my recommendation. It's very easy to use and yet so powerful that at times I want to leave C++ behind myself and just stick with Python.

Further, there is that PyGame library which is basically SDL binding for Python. Then you have PyOpenGL if you want GL hardware acceleration.
Logged
Bad Sector
Level 3
***


View Profile WWW
« Reply #14 on: January 10, 2009, 06:11:21 PM »

If you are familiar with Delphi and want crosplatformness, i recomment FreePascal and Lazarus. FreePascal is a crossplatform compiler (supports Linux, FreeBSD, Mac OS X/Darwin, Mac OS classic, DOS, Win32, Win64, WinCE, OS/2, Netware (libc and classic), MorphOS, GameBoy Advance and Nintendo DS). It also has a turbo pascal like ide. Lazarus is a graphical IDE that looks like Delphi (the classic multiwindow look, not the crap/newer msdev look).
Logged

~bs~
nihilocrat
Level 10
*****


Full of stars.


View Profile WWW
« Reply #15 on: January 12, 2009, 11:25:04 AM »

Lua is best if you have a large C or C++ library which you want to wrap and don't need to leverage any libraries you don't already link to, . It is one of the fastest scripting languages out there, and really simple and no hassle at all to learn. Drawbacks are that it doesn't have "batteries included". It's a perfect fit for most games (in the big leagues at least), because they are going to be coded in C++ by default so the code you want to wrap is going to be sufficiently rich that you don't need a lot of the extra power or external libraries the other languages give you.

Python gives you a huge number of libraries and a more powerful set of operations in your scripting layer, including a very flexible OO model. Drawbacks: it's slooooooooooooooow, and while it's easy to learn the basics it can take a long time to get the hang of using some of the more powerful features, like 'special names' in classes.

Ruby, I have no experience with. Sorry.
Logged

PGGB
Level 8
***



View Profile
« Reply #16 on: January 12, 2009, 12:28:37 PM »

Thanks a lot everyone.
Learned a lot from everything and got a good impression.

Keep it coming! Smiley
Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic