rbSFML

[vivo]

I again Groogy, more reports:
when I try the applyTransform method from a RenderTexture instance I get:

undefined method `applyTransform' for SFML::RenderTexture(0x0, 0x94c92c0):SFML::RenderTexture (NoMethodError)

All I want is to get a mirrored texture from another one, do you know an easier way to do it?

[Laurent]

applyTransform is not part of the public API.

[vivo]

so is it internally called by RenderTexture when you for instance call the scale method?

How would you do the trick?
I've tried with scale (-1,1) without success

[Laurent]

Setting the scale of the sprite that draws the render-texture contents to -1 should work.

[vivo]

Thanks, done

[Lupinius]

I'm back, using Archlinux this time. When trying to compile I get these errors:

Code: [Select]

[eric@Brictop Groogy-rbSFML-afda8ca]$ rake
Compiling ext/System/main.cpp
In file included from ext/System.hpp:33:0,
                 from ext/System/main.cpp:22:
ext/System/Vector2.hpp: In function 'VALUE rbVector2::ToRuby(VALUE)':
ext/System/Vector2.hpp:119:92: error: taking address of temporary array
ext/System/Vector2.hpp: In function 'VALUE rbVector2::ToRuby(const Vector2i&)':
ext/System/Vector2.hpp:133:76: error: taking address of temporary array
ext/System/Vector2.hpp: In function 'VALUE rbVector2::ToRuby(const Vector2u&)':
ext/System/Vector2.hpp:140:76: error: taking address of temporary array
ext/System/Vector2.hpp: In function 'VALUE rbVector2::ToRuby(const Vector2f&)':
ext/System/Vector2.hpp:147:76: error: taking address of temporary array
In file included from ext/System.hpp:34:0,
                 from ext/System/main.cpp:22:
ext/System/Vector3.hpp: In function 'VALUE rbVector3::ToRuby(VALUE)':
ext/System/Vector3.hpp:120:56: error: taking address of temporary array
ext/System/Vector3.hpp: In function 'VALUE rbVector3::ToRuby(const Vector3i&)':
ext/System/Vector3.hpp:135:79: error: taking address of temporary array
ext/System/Vector3.hpp: In function 'VALUE rbVector3::ToRuby(const Vector3f&)':
ext/System/Vector3.hpp:143:79: error: taking address of temporary array
rake aborted!
Command failed with status (1): [g++ -march=x86-64 -mtune=generic -O2 -pipe...]

Tasks: TOP => default => all => system
(See full trace by running task with --trace)
I did not follow all the instructions from the rbSFML page (I'm using the SFML version from my packet manager), but this does not look like it is the problem here.

[Groogy]

I'll look at it as soon as I get time, I hope tonight.

[Groogy]

That problem on Archlinux was weird, should work. Anyway not hard to fix. Will get around to it. Sorry for the delay but it is summer

I am having another problem which I need Laurents help with. Setting parameters on shaders in C++ and examples work just fine but somehow for me in Ruby it doesn't. I only get "Parameter "<name>" not found in shader" though it is clearly there and the names are copy pasted and is 100% correct. I don't do anything funky in the binding I just convert the Ruby string to a C++ string before passing it to SFML. So technically it should work unless I am doing something wrong with the conversion. So I tried forcing the parameter name in the Ruby binding code to something specific to see if it works but it still says it can't find it.

I've tried binding before setting parameters and I've tried moving the parameter set to after something is rendered. But still no prevail. I've searched the forum after similar problems or solutions but found nothing. So wondering if you are aware of any potential problem I can have stumbled upon?

I know the shader compiles and works because I am rendering with it and is seeing the effects from it.

I am trying with a uniform vec2 uniformTest variable with the @state.shader.setParameter("uniformTest", SFML::Vector2.new(0, 1)) code in ruby which becomes this : shader->setParameter( "uniformTest", sf::Vector2f( 0, 1 ) ); for C++ but it don't work.

There is clearly a problem on my end but can't find it =/

[Groogy]

Never mind! I am sorry... seems to be if I don't use the variable GLSL optimizes it away and you can't use it. So doing a simple "Test if this works" steps made me see an error that didn't exist.

[Groogy]

I'm looking at the problem that occurred in Arch Linux and fixed that. But afterwards I had a lot more problems with it not being able to find types I was including and so on. Have no idea why Arch would have such problems with my source, works perfectly in all other distro's I tested.

[Groogy]

Managed to fix it after a good night of sleep

[vivo]

Hello! It has been a long time since the last time I post here. I'm surprised that there has been no activity here... I've found ruby a great language for developing games, really friendly 
BTW, I wanted to announce here that that the Ruby Adventure Game Engine it's almost finished, it's my first project in Ruby, SFML and even games :-P but I think the final result it's not bad at all, at least for being a first iteration. I'll post a link to a github project when the doc is ready and fix a few issues of the engine (maybe a mounth?) in case anyone wanted to use it
regards

[Groogy]

Well since I got a contract with Packt Publishing to make a book for them I've had little to no time to work at rbSFML at all. But in April I'll be free again and fix a lot of stuff. I will also consider to create a branch for OpenGL in the rbSFML binding so doing require 'sfml/opengl' will be possible since the only binding for OpenGL that exists are out of date. But this is not a promise and only an idea and it might not even be "officially supported".

[vivo]

I appreciate your altruistic work here, I haven't tried any 3D aspect but I must say rbSFML actually works great with 2D graphics.
What kind of book are u writing?

[Groogy]

"SFML Game Development" with 2 other authors. DevilWithin/Grimshaw and Nexus on this forum. Also Laurent is keeping an eye on it and comes with suggestions from time to time.

It just teaches some techniques in game development and uses SFML as the technology to do it. Though it is in C++.

Also the OpenGL extensions primary goal is not to be used for 3D really. Though it would be nice and cool. It's to allow you to extend SFML yourself in Ruby code like how you can do in C++ with sf::Drawable and so on.