Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / Draw on another window
- By Wurstinator Date 2010-04-14 12:55
Hi :)
I'd like to know if there is a way to get a window by its handel and draw onto it with Gosu::Image#draw.
I am trying to get some multi-core working in Ruby. The first process shall be the main process and calculating everything. It executes a second process when started which shall draw everything on the window.
Is there a way to do this? :)
- By jlnr (dev) Date 2010-04-15 11:37
No, that does not work at all :)

What you can do to support multiple processors is use Ruby 1.9 with native threads and offload all the calculation into a second thread. All Gosu calls have to be made on the main thread though (i.e. rendering).
- By Wurstinator Date 2010-04-15 19:29
"What you can do to support multiple processors is use Ruby 1.9 with native threads and offload all the calculation into a second thread. All Gosu calls have to be made on the main thread though (i.e. rendering). "

Uhh... what? ^^'
I always thought as Ruby only works only inside the Ruby compiler its threads only use one core?!
- By lobo_tuerto Date 2010-04-15 20:59
Ruby 1.8 used "green" threads, that means they were simulated inside the Ruby process.

Ruby 1.9 on the other hand uses OS threads, so it's supposed to take advantage of multiple cores.
- By Wurstinator Date 2010-04-15 22:24
I think I am doing something wrong :|
http://img255.imageshack.us/img255/5381/screenxk.png

50 % CPU usage (1 of 2 cores) with 3 Threads...
- By jlnr (dev) Date 2010-04-16 17:56
Which version of Ruby is this?
- By Wurstinator Date 2010-04-16 18:33
1.9.1
i386-mingw32
- By jlnr (dev) Date 2010-04-17 04:23
Huh. Well, then I think it's a Ruby problem, not a Gosu problem. Any way, different *processes* require more complex communication than that because they usually don't share any memory, and if you forced them to, then the two separate garbage collectors would probably cause havok. You would have to use sockets or something painful like that.

I would go look around for a solution to your basic Ruby threading problem first :)
- By Wurstinator Date 2010-05-10 15:07
Sorry, for not answering for some time.
I found out that Ruby 1.9.1 is able to support native threads but it only uses one because of the global interpreter lock because some C functions are not thread-safe.
Sadly, there is no alternative for Windows yet, so I just have to wait for a better threading version of Ruby to be released.
- By erisdiscord Date 2010-05-11 05:59 Edited 2010-05-11 06:02
Well, MacRuby has a more sensible threading model (no GIL), and now they are working on support for C extensions, so there's a chance Gosu would work there—but that won't help you on any other platform, sadly.

I think jruby supports proper threading also, but I don't know about C extensions. I think it doesn't support them—can anybody confirm? There's Ruby FFI for that, of course, but that won't help with Gosu. I bet somebody clever could do it, but I'm not that clever. Wouldn't it be nice if FFI could speak C++? :)
- By jlnr (dev) Date 2010-05-11 09:02 Edited 2010-05-11 09:04
Wurstinator, are you sure it does not work if you don't use C functions on another thread? If you just move the Ruby-only game logic to a different thread and let Gosu do its thing in the main thread, it might work. But I have no experience with this.

Gosu is not thread-safe itself right now BTW. There are some #ifdef'd locks in the texture allocation. If you want to allocate textures outside of the main thread to keep the game going, that can be enabled easily. But drawing from several threads is not supported, so even if you get multiple threads working, leave everything Gosu-ish on the main thread please :)
- By Wurstinator Date 2010-05-11 20:37
@ erisdiscord: Yes, I heard of FFI but as you said, most gems do not support it.

@ jlnr: I nearly know nothing about C so I cannot tell you why something is threadsafe and something other is not.
The problem is, that the developers of Ruby disabled the possibility to use parallel threads with the GIL. So maybe it wouldn't throw errors your way, but it just can't be done (only if you modify the interpreter).
- By jlnr (dev) Date 2010-05-12 03:16
OK I see, I thought the GIL had been limited to C calls but now that I think about it, nearly everything in Ruby would have been a C call anyway.

Does your game happen to be multiplayer anyway? ;) I know many old id games had the main game running as a server and in singleplayer you basically just connected to yourself. That's really the way I'd do it with two processes (using sockets).
- By Wurstinator Date 2010-05-14 11:49
Multiplayer? :o

No, I wanted to use one process / thread for things like AI or pathfinding :)
Up Topic Gosu / Gosu Exchange / Draw on another window

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill