rbSFML

[TricksterGuy]

That could be it! I'll have a look at where make is looking for header files and/or my system.

Thanks!

[Groogy]

If you look at the output of extconf.rb then you see that it didn't find sfml-graphics.so or sfml-window.so

Also I've used Ruby1.9.2 when working with this code, I have no idea if it will work for anything older.

And sure, I wouldn't mind a rake file that does it for you. I'm also thinking of adding a sfml-all package that requires all SFML packages for you.

[Groogy]

Apparently there are several parts in sf::RenderWindow and sf:RenderImage that needs a specialized function for their functions inherited from sf::RenderTarget. IF you don't get the behaviour you expect from them then please tell me and I'll add that function.

Trickster, do you have SVN access? Just wondering, if you find one of them you can add it yourself.

[TricksterGuy]

Apparently there are several parts in sf::RenderWindow and sf:RenderImage that needs a specialized function for their functions inherited from sf::RenderTarget. IF you don't get the behaviour you expect from them then please tell me and I'll add that function.

Trickster, do you have SVN access? Just wondering, if you find one of them you can add it yourself.

So I have tested it with one of the samples from my old bindings (there were very few changes I had to make which makes me happy)

The actual code I have to give credit to the people who created Allegro.
(please excuse any weirdness with this code)
What this should do is produce a flame effect on the screen although its kinda slow.

Code: [Select]


require 'sfml/system'

require 'sfml/window'

require 'sfml/graphics'

include SFML



HOTSPOTS = 10

WIDTH = 128

HEIGHT = 64



class Game

def initialize

@screen = RenderWindow.new

@screen.create([WIDTH, HEIGHT], "Flame")

#screen .width and .height return 0
 or some weird value.
@buffer = Image.new

@buffer.create(WIDTH, HEIGHT)

@sprite = Sprite.new

@sprite.image = @buffer

init_palette

end



def run

@temp = Array.new(WIDTH, 0)

@hotspot = Array.new(HOTSPOTS) {rand(WIDTH)}

loop {break if update == false}

quit

end



def update

return false if @screen.input.key_down?(Key::Escape)

draw_fire

update_fire

@screen.draw(@sprite)

@screen.display

end



def quit

end



def init_palette

@palette = Array.new(256)

@palette.fill(0, 64) {|c| Color.new(c * 4, 0, 0)}

@palette.fill(64, 64) {|c| Color.new(255, c * 4, 0)}

@palette.fill(128, 64) {|c| Color.new(255, 255, c * 4)}

@palette.fill(Color.new(255, 255, 255), 192, 255)

end



def draw_fire

@temp.fill(0)

0.upto(HOTSPOTS-1) do |c|

(@hotspot[c]-20).upto(@hotspot[c]+20) do |x|

if x >= 0 and x < @buffer.width

@temp[x] = [@temp[x] + 20 - (@hotspot[c] - x).abs, 192].min

end

end

@hotspot[c] = (@hotspot[c] + rand(8) - 3) % @buffer.width

end

@temp.each_index do |i|

#p "#{i}, #{@screen.height - 1}, #{@palette[@temp[i]]}"

@buffer.setPixel(i, @screen.height - 1, @palette[@temp[i]])

end

end



def update_fire

0.upto(@buffer.height-2) do |y|

0.upto(@buffer.width-1) do |x|

c = @palette.index(@buffer[x, y + 1])

c -= 1 if c > 0

@buffer[x, y] = @palette[c]

end

end

end

end



Game.new.run



RenderWindow#width and RenderWindow#height do not work as expected.

and I do not have access to fix this myself and commit the changes (I can checkout though if thats what you mean)

[Groogy]

Nah I was wondering if you had access to commit those changes
Anyway I'll add the getWidth and getHeight specialization.

And you said the code ran kind of slow? Your still using Ruby 1.8.x? If you change to 1.9.x does it still run slow? And if it do can you benchmark to where the performance is down? I might be able to improve it.

Also I recommend that you use for in instead of the Integer#upto method. Just write intead:

Code: [Select]

for index startIndex..endIndex
  # Code
end


It encapsulates the block you pass on and it's easier to read ^^

[TricksterGuy]

oh, its a kinda slow way to do the effect last time I ran it. (ignore me )

However, I can't get the window to display on my computer. You other samples work fine. (it does create a window but it is minimized and when I click on it nothing comes up)

May be an error on my part!

[Laurent]

RenderWindow#width and RenderWindow#height do not work as expected.

By the way, if you have any problem with RenderTargets, make sure that you properly deal with the multiple inheritance which is involved (ie. no direct/ugly cast RenderTarget <--> RenderWindow, since RenderTarget is not the first base of RenderWindow). Just a thought, maybe not related at all to your problems

And you said the code ran kind of slow? Your still using Ruby 1.8.x? If you change to 1.9.x does it still run slow? And if it do can you benchmark to where the performance is down? I might be able to improve it.

You shouldn't worry about that, the algorithm and functions used is what makes the application slow. It would be equally slow in C++.

[Groogy]

However, I can't get the window to display on my computer. You other samples work fine. (it does create a window but it is minimized and when I click on it nothing comes up)

May be an error on my part!

That's probably because of the OS I think. SFML doesn't have any thing that let's you minimize the window last I checked.

By the way, if you have any problem with RenderTargets, make sure that you properly deal with the multiple inheritance which is involved (ie. no direct/ugly cast RenderTarget <--> RenderWindow, since RenderTarget is not the first base of RenderWindow). Just a thought, maybe not related at all to your problems

I would but the Ruby API is written in C with no considerations to C++ so it internally uses ugly c-casts everywhere. And when I tell RenderWindow to include the the RenderTarget module it does a simple dump of all the RenderTarget methods onto the RenderWindow class. It's either that or make every method for hand for 3 classes (RenderWindow, RenderImage and RenderModule::Instance which is used internally with custom Drawables). Doing it this way actually takes of some work for me. I now just need to copy-paste the RenderTarget binding to the 3 classes when it occurs that it doesn't work normally and change the types there.

[TricksterGuy]

Ok so I have updated that test code

http://pastebin.com/1M2gNbYd

Now when I run this after I close the window I get the message
DRM_IOCTL_GEM_CLOSE 6 failed (region): Bad file descriptor
I have tracked this to the line where I create the image passing in a width and height.
I also tested your other demos and I get two of those messages when I close the program. (Various lines cause this one)

And upon search of this weird message (on google) I was linked to a post on this forum by you haha.


Also why is it a two step process to create an Image of a certain color why not overload the constructor to do this?

I'll be playing around with this a little bit more before diving in.

[Groogy]

Well I have no idea what to do. From what I could find on google is that it's Compiz. I don't get the message on my workstation. I get the message on my laptop where I do have compiz. Though I uninstalled compiz completely and I still have that message. But I noticed that my driver is really faulty. I get very very weird behavior on my home laptop. Though that particular Intel graphic chip is known to have crappy OpenGL implementation.

Can you try out making a C++ SFML application on the same computer and see if you still get the message? If you do then I'll have to look over the code.

[Groogy]

I think I already know the answer but just curious Laurent, You don't do this call manually?

Code: [Select]

ret = ioctl (fd, DRM_IOCTL_GEM_CLOSE, &close);
From this page: http://lwn.net/Articles/283798/

[Laurent]

What's that???
(sorry I'm at work, I don't have time to read this huge article )

[Groogy]

From what I understand, that's where it fails, when we try to close the file descriptor to a resource it apparently fails. Something like that I guess.

Anyway since you don't know what it is I guess it's Xlib that uses it and fails somehow for you.

*EDIT*
I tried myself with creating a SFML2 app on my home computer and I get that message there too. So now at least I know it is not the ruby bindings that is messing things up

Probably are something wrong with xlib on my computer at home and apparently Tricksters computer. Would be nice to know if this happens on other people with Linux or is it specific to us? If it is, what is the common between me and Trickster? If it is not and many linux users get the same message then it might just be that you've missed something with Xlib Laurent. This GEM thing seems to something Intel is developing to manage memory on chipsets. So I guess Trickster is also sitting on a laptop?

[TricksterGuy]

And you'd be right!

I am almost done with the Rakefile I am putting some finishing touches on it.

All you have to do is type rake and it will build the four .so files.
Then you can type sudo rake install to install the binaries.

There is also a documentation and a gem building task.
(rake rdoc and rake gem)

[Groogy]

I am almost done with the Rakefile I am putting some finishing touches on it.

All you have to do is type rake and it will build the four .so files.
Then you can type sudo rake install to install the binaries.

There is also a documentation and a gem building task.
(rake rdoc and rake gem)

Nice!
I don't know how Laurent feels about it but I wouldn't mind if you had SVN access so you could commit it yourself. But if he don't want too many people to have access then I can commit it for you.

Also I'll make the "sfml/all" option today so you don't need to require each one of the libraries if you want to use them all.