rbSFML

[Groogy]

Long time since I was at this forum

Well I need a project to work on in between my assignments while at my university so I choose this if the previous maintainer don't mind.
Anyway I started today and already got the sfml-system library done. I will try to make the library conform with the conventions of the SFML library as much as possible but I will also let the library conform to the Ruby conventions. I can't estimate any time as of when this will be completed but I can estimate that I'll work around 1-2 hours each day with this between my assignments.

The task list for rbSFML can be found here: http://taks.groogy.se

Any updates to the library will be edited into this post.

Example code:

Code: [Select]


require 'sfml/system'
require 'sfml/window'
require 'sfml/graphics'
require 'sfml/audio'

app = SFML::Window.new [800, 600], "My Ruby SFML"

# Load a sprite to display
image = SFML::Image.new
image.load_from_file  "cute_image.jpg"
sprite  = SFML::Sprite.new image
 
# Create a graphical string to display
arial = SFML::Font.new
arial.load_from_file "arial.ttf"
text = SFML::String.new "Hello SFML", arial, 50
 
# Load a music to play
music = SFML::Music.open_from_file "nice_music.ogg"
# Play the music
music.play
 
# Start the game loop
while app.open?
  # Process events
  while event = app.get_event
    # Close window : exit
    if event.type == SFML::Event::Closed
      app.close
    end
  end
 
  # Clear screen
  app.clear
 
  # Draw the sprite
  app.draw sprite
 
  # Draw the string
  app.draw text
 
  # Update the window
  app.display
end


These classes has been excluded from the library:

Code: [Select]


Thread
Lock
Mutex
Randomizer
Sleep
Unicode
RenderTarget ( Not the same as SFML::RenderTarget )

Why these has been excluded is because the core of Ruby already does these for us. But I also want to go into more detail on Thread, Lock and Mutex. It's true that Ruby does provide this functionality for us but it's still incomplete. The threading in ruby works natively but ruby got a global lock which will always only let one thread run at the same time. So this also made my choice, since if we allow SFML threading it might mess up the internal workings of Ruby. So my choice is to wait with implementing this and let Ruby's threading "mature".

[Laurent]

Wow, this is truly amazing

if the previous maintainer don't mind

I think we can safely assume that the last maintainer has left a long time ago. Anyway, you can send him an e-mail if you want (sean.p.oneil@gmail.com).

Anyway I started today and already got the sfml-system library done

Are you working on SFML 2 or SFML 1.6? You should start with SFML 2, working on SFML 1.6 would be a waste of time.

I will try to make the library conform with the conventions of the SFML library as much as possible but I will also let the library conform to the Ruby conventions

That sounds good. Ruby conventions should have the priority, don't hesitate to transform things if you can make them look more natural.

Thank you very much for your work

And if you need a write access to the SVN, let me know.

[Groogy]

I'm working on SFML 1.6 but thanks for letting me know. I'll switch over to 2.0 if you feel that's better. And making the library both support the convention of SFML(which I feel looks better) and Ruby is easy since Ruby supports something called Aliasing which makes one method/function have several names.

And if you need a write access to the SVN, let me know.

That would be perfect. We use SVN on my university for the game projects. Send me a mail/message with the specifics and any other information you need me to know.

[Laurent]

And making the library both support the convention of SFML(which I feel looks better) and Ruby is easy since Ruby supports something called Aliasing which makes one method/function have several names.

Is it really a good thing? Is this kind of technique widely used in Ruby?

That would be perfect. We use SVN on my university for the game projects. Send me a mail/message with the specifics and any other information you need me to know.

You must have an account on sourceforge.net, and send me your login by e-mail.

[Groogy]

Code: [Select]

Is it really a good thing? Is this kind of technique widely used in Ruby?

It's widely used in the standard library for like arrays so you can both call on "size" and "length" on them but it still calls the same method.

Sent you a mail with my login
Just gonna compile together my SFML 2 snapshot now.

[Groogy]

The development is a bit halted at the moment as we're reaching the deadline for our game project at the university. And my group are putting down finishing touches on the story of the game and bug fixes. So I got a lot to do until Friday.

Anyway I hope having the Window module finished by Monday and will begin with Graphics when I get time again. When the Window module is done you are free to test it and play around with it. Though you'll only be able to do graphics trough OpenGL at that point.

I'll still need to figure out how I'll make the inheritance hierarchy work when it comes to the Graphics module which includes multiple inheritance which I'll have to solve for Ruby somehow.

[SOLVED] I won't do it at all

[Groogy]

I hope it's okay Laurent that I write updates here? Not cause I think many is interested yet but it's a good reminder for me what I've done so far.

Anyway, sfml-system and sfml-window is complete and rdoc documentation has been generated for them and is located in their folders on the SVN servers. They are finished enough to be used now I believe. I have a window-demo.rb file under testing/ which tests them and so far it has worked. What I have not tested is to actually render something directly trough OpenGL but it should work, I don't see any reasons why it wouldn't.

Anyway if you only want to use SFML to open a OpenGL context then the library is pretty much done for you

[Laurent]

I hope it's okay Laurent that I write updates here?

Of course it is ok

rdoc documentation has been generated for them and is located in their folders on the SVN servers

You should never add generated stuff to the repository. It doesn't have to be there, since it's generated from files already versioned. It wastes space and makes commits/updates bigger than they should.
The same applies if you have some compiled rbSFML libraries, never add them.

[Groogy]

You should never add generated stuff to the repository. It doesn't have to be there, since it's generated from files already versioned. It wastes space and makes commits/updates bigger than they should.
The same applies if you have some compiled rbSFML libraries, never add them.

Aight will be removed. I just looked at the snapshot which has a doc folder so I just guessed you had it there too ^^

Though I'll in any case have to find a place to put it, I got my own web server I can place it if you don't want it on your. Rdoc documentation is like doxygen but for Ruby, it generates a web-page for you more or less.

[Laurent]

I just looked at the snapshot which has a doc folder so I just guessed you had it there too ^^

Nop, it just contains the files needed to build the doc

Though I'll in any case have to find a place to put it, I got my own web server I can place it if you don't want it on your. Rdoc documentation is like doxygen but for Ruby, it generates a web-page for you more or less.

Usually, the doc for bindings is put into releases archives but not online. Hmm and the SFML website is not ready for this; maybe we can talk about it again after I rewrite the website (before SFML 2 is released).

[Groogy]

Usually, the doc for bindings is put into releases archives but not online.

Like I said, I can put it on my web-server and just link to it from the forum, though might be annoying for users.

Hmm and the SFML website is not ready for this; maybe we can talk about it again after I rewrite the website (before SFML 2 is released).

Sure I'm just a bit eager to get people to use this. I love SFML and I love Ruby. And hope people will appreciate this combination as much as I do.

[Groogy]

Almost finished the Drawable mixin-module today. I said I wouldn't make it but it will make it easier for me to do a correct inheritance hierarchy when it comes to Sprite, Shape and so on. Plus it wasn't hard to implement, most functions were exactly the same so it was just a lot of copy-pasting.

The only thing not implemented yet is the Render function. Also there is a problem when it comes to actually using it for your own classes which might be dangerous.

The module will hijack your class new method in order to allocate a instance of sf::Drawable and then link the ruby object and Drawable object together. If you would under any circumstances write your own new method then the needed sf::Drawable object won't be allocated unless you call the function specifically your self(Doesn't know if that will work either). If you need to do something like that then I recommend that you instead write a wrapper class around the Drawable class where the wrapper class has the custom made new method.

Anyway the class should take your inheritance into consideration by calling super in it's initialization method. But if you write your own initialization method then you'll have to remember to call super yourself in order to set default values. But if you don't need to set any default values then you don't have to of course, the object is already initiated trough the new method.

[Groogy]

Currently working on RenderTarget. This will be a tricky one. This is mainly for the sf::Drawable::Render function's first argument. So the classes SFML::RenderWindow and SFML::RenderImage won't be inheriting from the class but SFML::RenderTarget will act as a temporary wrapper around the C++ instance so that the user can access the rendering functions. Also coincidental this will force the user to have the same functionality as in C++ when they are making their custom Drawable class.

Anyway otherwise just look at the SFML::RenderTarget class as an internal class and have "Look but don't touch" in your mind while using it.

[Groogy]

FINALLY! Finished the RenderWindow though I got some weird bug with it which I'll have to look into deeper. RenderWindow inherits from Window of course so it already got the RenderWindow#display function defined for it. But when I tried to override that method ruby crashed at exit whining about that the stack wasn't consistent any more. I don't understand, the sf::RenderWindow::Display function is inherited from sf::Window, could it be something there being the problem?

Also another problem I ran into was that I couldn't just simply have a generic function with a sf::RenderTarget pointer to either a window or render image but I had to have 2 separate functions for each separate type. Well the problem originated in that the sf::RenderTarget::Draw function wasn't virtual which I thought.

Everything works now and you can draw shapes onto a RenderWindow or RenderImage which is pretty cool. Though I'll commit all the new changes tomorrow at the university. I'd like to do some more tests before actually committing the new code.

*EDIT*
This is really bugging me so I can't go to sleep. How come then that this works:

Code: [Select]


void MyDrawable::Render( sf::RenderTarget& aTarget, sf::Renderer& aRenderer ) const
{
        aTarget.Draw( /* Something */ );
}

And this don't?

Code: [Select]


static VALUE RenderTarget_Draw( int argc, VALUE *args, VALUE self )
{
sf::RenderTarget *object = NULL;
Data_Get_Struct( self, sf::RenderTarget, object );
switch( argc )
{
case 2:
{
VALIDATE_CLASS( args[0], globalDrawableModule, "object" );
VALIDATE_CLASS( args[1], globalShaderClass, "shader" );
sf::Drawable *drawable = NULL;
Data_Get_Struct( args[0], sf::Drawable, drawable );
sf::Shader *shader = NULL;
Data_Get_Struct( args[1], sf::Shader, shader );
object->Draw( *drawable, *shader );
break;
}
case 1:
{
VALIDATE_CLASS( args[0], globalDrawableModule, "object" );
sf::Drawable *drawable = NULL;
Data_Get_Struct( args[0], sf::Drawable, drawable );
object->Draw( *drawable );
break;
}
default:
rb_raise( rb_eArgError, "Expected 1 or 2 arguments but was given %d", argc );
}
return Qnil;
}


It crashes when calling the sf::RenderTarget::Draw function, this really bothers me. How come it doesn't work here? What's the main difference that I do? Just ignore all the Ruby specific code. I've checked, the returned objects are correct, I get a sf::RenderTarget in the object pointer and a sf::Drawable in the drawable pointer. If I just change the type of object into sf::RenderWindow then it works without a problem.

*ANOTHER EDIT*
Aaah wait! I get it now I think! The Draw function used to be virtual but isn't any more and SFML2 isn't finished yet so this is still in progress. Aaah no sweat then. I thought I did something wrong... The horrible thought! Well it is working, not elegant but works currently so I can wait until SFML2 is actually finished and then remove the type specific functions or however it turns out.

[Laurent]

Aaah wait! I get it now I think! The Draw function used to be virtual but isn't any more and SFML2 isn't finished yet so this is still in progress.

Draw never was virtual. SFML 2 is not finished but it works 100%, there's nothing "half-done".