Non-RGSS Ruby Player [resolved]

[BlueScope]

I've been wondering about the following for a while, and while I'm aware this technically isn't the right place to post this, I think this is where it should be posted... maybe you get me here, maybe not... I'll just go on... :biggrin:

So yeah, since I've never been happy with RMVXP's limitations, I recently got more and more away from using the Database, never ever used the material editor or any of that stuff the program supplies, and work with custom scripts for everything anyway, I thought I might as well use 'plain Ruby', instead of the RGSS Player. However, knowing that Ruby itself is merely a command line application, I wonder how I'd actually manage to create a RGSS Player-esque interface, in other words, a window that allows me to draw graphics in (because from there, I can handle everything myself).
I know I'll have to include a Main-ish script snippet in the script library to actually get a non-self-closing interface, and the sentence before basically states I'll need a Graphics module - as that's one of two modules addressed in Main, I figure I'll need an Input module as well. Am I right with being able to get a base interface running as soon as I have these two modules ready?
The reason I'm asking this is that I simply have no idea about the base constructs, so I'm basically in the dark about what I need and what not, and I kind of don't want to start with something like Ruby/SDL, as that's just another bunch of pre-made scripts as RMVXP has... as far as the Graphics and Input modules go, I wonder if someone has written something in order to achieve exactly that.

I think I should be able to manage getting somewhere if someone points me to the right direction... :grin: (hopefully...), so thanks in advance for the help I can hopefully get here ^^

 

[DeM0nFiRe]

Well, your choices are basically to use something like Ruby/SDL or Rubygame or to write a new player yourself which means you need to write a renderer, you need write the windows code (which you can actually take care of by SDL or SFML), and you need to embed Ruby in it, and then you need to wrap all of your engine code for ruby.

All of the existing game libraries for ruby (like Ruby/SDL and Rubygame) are actually way to slow to even bother using for a tile-based game. I mean, I suppose I was using a Pentium 4 when I was doing my tests, but even still, they all used software rendering or they had too much on the ruby side so they were all too slow.

Writing a player yourself is quite an undertaking, though. You need C or C++, you need OpenGL or DirectX, you need to get Ruby playing nicely inside a C/C++ app (It will fight you the whole way, Ruby's not made for embedding) and then you need to wrap your engine (which will require some creative memory management since you'll have to clean objects from both Ruby and C/C++).

 

[BlueScope]

Hm, first understanding problem solved already... I assumed you could create a player window with Ruby alone, instead of having to implement it into another program... but that kind of speaks for Ruby/SDL then :p (as I don't have the slightest clue of C... and wouldn't really want to use it for that either way, as I was hoping to be able to create a Ruby-only application, if you get me)

So, do I understand you right in that using Ruby/SDL or Rubygame will supply me with the necessary base structures, as in the actual player? I didn't look too closely into it, I only know it has all the basic classes like Graphics, Input, the like... dunno about an actual player or anything though, don't remember seeing one.

And on a side note, I'm not necessarily trying to create a tile-based game, however, I'm not looking for something breaking down if I'm trying to show 20 graphics at the same time either ^^" which I guess is what you're saying more or less?

Thanks for your reply!

 

[DeM0nFiRe]

No, you can do 20 graphics at the same time. You just can't do 20 * 15 * 3 at the same time on a pentium 4. Even then, the way you fix that is by chunking the tilemap so you can draw it quicker, but it's still not super fast. In truth, responsible programming will get you through most of what you want, but it's just always nice when your tools aren't forcing you to optimize

 

[BlueScope]

Heh, yeah, I get you there. However, my goal somewhat is to write efficient code (because I want to, not because I'm forced to, but yeah... if I'm forced to, fine with me XD ). But yeah, I see where you're coming from.

 

[vgvgf]

I think this should be in viewforum.php?f=191

Have you tried Gosu? It's a nice 2d library, and it includes support for input and playing sounds and musics too. It's similar to RGSS, and easy to learn. There is some discussion of it on the other forum, and here is its web: http://www.libgosu.org/

 

[DeM0nFiRe]

Just a heads up, Gosu's a little bit more complicated to use (Not a big deal) and the license prohibits use in commercial projects (because it uses FMOD for audio)

 

[arev]

Actually the license doesn't prohibit commercial use of Gosu itself. FMOD on the other hand is a commercial product, but there are some posibilities to aply for an indie license. I'm not sure, but it was somewhere around $100. This being the only "engine" cost isn't that much if you want to make commercial game. Nvm.
I love Gosu, it's actually almost as easy to use as RGSS and isn't limited at the same time. Also, the engine is hardware accelerated - you can draw images as polygons to improve performance.

 

[BlueScope]

The question to me is, how far are all these packages capable of making games? I understand I won't be able to make full-scale stuff as I could with C, since it's simply the faster language, but where exactly between slow-ass RGSS Player and C constructs are we talking? (That's one of the questions I'm asking myself when I hear "It's similar to RGSS" ^^" )

As far as commercial goes, I don't really have any intentions of making games for money all of a sudden... however, you never know what's coming, right?

And well, as my first post states, I'd like to do most of the stuff myself as far as I can... I read that Gosu is primarily based on C++ - does that mean the source code won't be in Ruby, but in that? And if so, is there another package that has Ruby source?
I'm particularly concerned about this because of a sentence I read in this article, being:

You don't need to start a main game loop or set up an event queue in your application-level code because Gosu handles that behind the scenes.

That kind of sounds like RGSS Lite to me, where you can do more stuff, but still have some 'hidden methods' you can't directly effect?

Also, I tried to look for a x64 version of Ruby, but could find the slightest hint of that existing anywhere... same goes for Gosu now - or am I mistaken?


I guess I'm asking a lot of questions that might be stupid or not... thanks for all the input, though, I really apprechiate it!

@vgvgf: That indeed is a better spot.. I thought my only choice was between these forums and General Game Dev something, so I chose this over it... ^^"

 

[vgvgf]

Some say that RGSS uses gdi+ for graphics. If that's so, then it is slow because it's not hardware accelerated, and because gdi is slow itself for being software rendering.

Gosu is hardware accelerated, and when I said it was similar, I said that just comparing their API. So, it should be faster than RGSS, except for machines with old graphic cards, where that may not be true.

It's unlikely that you will find a graphics library written entirely or mostly in ruby, think of them just as "wrappers". C/C++ ruby extensions connect the ruby functions with the c/c++ ones and so they take advantage of c/c++ speed for calling graphical functions or implementing algorithms. For example Ruby/SDL, just wrapps the SDL C functions with ruby ones, it will be a bit slower, but not much slower.

That kind of sounds like RGSS Lite to me, where you can do more stuff, but still have some 'hidden methods' you can't directly effect?

Gosu is opensource, so you will be able to edit the c/c++ code if you need to do so, and I think the same goes for Ruby/SDL. However, they are more extense than RGSS, they haven't most limitations RGSS does.

 

[BlueScope]

Kind of sounds like Gosu would be a pretty good choice there... even though I don't think I want to do heavy processing, I definately don't want to address state-of-the-art machines only. And I definately see the purpose of writing it in C, which I guess will be a fair-enough thing to live with in exchange for all the gain... (plus I might as well learn some C on the way )

So, I'll have a look into it when I finally have some time... :|:

PS: I like how you - apprently automatically - used a code tag instead of

:p


EDIT: I got everything to work accordingly with surprisingly little effort... nice stuff to play with really, feels instantly more powerful :biggrin:
Thanks again for all the input on the subject!