PNO - Threads and other evils

[Zeriab]

The "Script is hanging" error on start up happens because the game is trying to connect to a host that doesn't exist (aka bogus IP). There's nothing that can be done about it except completely rewriting Ruby's socket class because it simply takes a while until the timeout of the socket is exceeded. And I'm not gonna do that because it might turn out that I actually have to go as deep as messing with Windows' API to actually fix that irrelevant problem. When you set up the servers in the game properly, it's not supposed to ever happen anyways.

Isn't that problem easily solved by having a thread controlling the socket and a thread controlling the rest?
Of course you may hit the problem with the Ruby interpreter pausing during Win32API calls, but that's a RMXP specific problem rather than a Ruby problem.

Either way this game really looks good :3

[Blizzard]

I can try that. I know that I wasn't able to get it running the last time. :/ Maybe I'm smarter now. xD

[Zeriab]

I know it's a breeze in Ruby, but you may be hindered by RMXP. Either way let's hope you are able to do it now that you have gotten even smarter

[fugibo]

Isn't that problem easily solved by having a thread controlling the socket and a thread controlling the rest?
Of course you may hit the problem with the Ruby interpreter pausing during Win32API calls, but that's a RMXP specific problem rather than a Ruby problem.

Either way this game really looks good :3

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

Ruby threading is EVIL I say, EVIL!!!!!!!!!!!!!!!!!!!!!!!!!!
AND IT ISN'T THREAD-SAFE!!!!!!!!!!!!!!!! GAAAAAAAAAAAAAAAAAAAAAAADDDDDDDDD!!!!!!!!!!!!!!!!!!

But what you'd do is

SOCKET_THREAD = Thread.start do
  while Thread.current["playing"]
    <update_socket_code, but DON'T TOUCH ANYTHING GLOBAL OR USING ANY SINGLETONS, IF POSSIBLE>
    Thread.current["<thread_variable>"] = <value>
    *repeat above line as many times as you need*
  end
end

# Scene Menu, dadadada....
def main
  # stuff
  loop do
    <update_events_and_such_from_the_variables_in SOCKET_THREAD["<variable_name>"]>
  ende
end

[Zeriab]

Of course it isn't thread-safe. Ruby is slow enough as it is.
Ruby for versions before 1.9 have their own scheduler for the threads. It's only at 1.9 that support for native threads have arrived. I haven't really tried it so I don't how the threading is. I only know for 1.8.1 & 1.8.5. You can always require 'thread' for the thread support classes such as providing semaphores and queues for inter-thread communication.

*hugs*

[fugibo]

Of course it isn't thread-safe. Ruby is slow enough as it is.
Ruby for versions before 1.9 have their own scheduler for the threads. It's only at 1.9 that support for native threads have arrived. I haven't really tried it so I don't how the threading is. I only know for 1.8.1 & 1.8.5. You can always require 'thread' for the thread support classes such as providing semaphores and queues for inter-thread communication.

*hugs*

The thread-safe part was mainly me complaining. It makes Ruby extraordinarily sucky for a game engine. But, oh well

And 1.9 brings a lot of new stuff, like YARV. Fun stuff, too!

[Zeriab]

What are you talking about?
It's that the intention in RMXP is to only use a single thread for Ruby.
Besides it would be insane to have a completely thread-safe game engine. It would be far to slow.
It's only sharing of resources and communication between threads that should be designed to be thread-safe.
It's much worse that Graphics.update pauses all threads rather than just the thread calling the method and likewise with Win32API calls.

I wanna try 1.9 because I fear I may start using 1.9 specific stuff in RMXP Script.

We are going off topic so I we either should stop or take it elsewhere >_>

[fugibo]

What are you talking about?
It's that the intention in RMXP is to only use a single thread for Ruby.
Besides it would be insane to have a completely thread-safe game engine. It would be far to slow.
It's only sharing of resources and communication between threads that should be designed to be thread-safe.
It's much worse that Graphics.update pauses all threads rather than just the thread calling the method and likewise with Win32API calls.

I wanna try 1.9 because I fear I may start using 1.9 specific stuff in RMXP Script.

We are going off topic so I we either should stop or take it elsewhere >_>

<FINAL POST> If you could use Ruby in one thread and still have it use resources from other threads, it'd be a different story, but it can't. You can't use any resources outside of the Ruby thread from within Ruby, which kills its usage as a game engine. It's still possible to multithread the engine, but it's not as effective as it could be.

And lol, I don't think 1.9 has that much new except for a few standard libraries being introduced, and you're already used to not using any Ruby libraries in RMXP (screw you, lack of support for Ruby extensions!)

[Blizzard]

ACTUALLY global data access in threads can be used without problems if you know how.

$clients = {}
server = TCPServer.new(host, port)
Thread.start (server.accept) {|tcp_connection|
  c = Client_Connection.new(tcp_connection)
  $clients.each_key {|connection| connection.send(0, "Entering: " + c.id.to_s)
  $clients[c.id] = c
}

[fugibo]

I meant from the C side, where you can do actual game stuff X_X

[Zeriab]

Requiring .so files solves that problem.
Yeah it has been disabled in RMXP -_-

Either way can you make it work Blizzy? Can you prevent time outs :3?

[Blizzard]

I meant from the C side, where you can do actual game stuff X_X

You have libraries with fully implemented semaphore and mutex handling (even though implementing a simply mutex yourself takes like 20-30 lines of code in bad good old C).

@Z: Sure.

EDIT: .so == Unix type .dll

[fugibo]

I meant from the C side, where you can do actual game stuff X_X

You have libraries with fully implemented semaphore and mutex handling (even though implementing a simply mutex yourself takes like 20-30 lines of code in bad good old C).

@Z: Sure.

EDIT: .so == Unix type .dll

Yes, which has been disabled. Unfortunately, there's an entire standard library full of extensions which exist in .so form, not .dll.

[Blizzard]

True. :/ This is probably because the intended RGSS to run on Windows so they didn't see any reason to leave the support for .so files. They probably didn't know .so's run fine on Windows. Stupid Enterbrain.

[fugibo]

I don't know if RGSS is even based on real Ruby -- take the infamous ASCII and/or bug, for example.

Also, teh hawtness. If only it were cross-platform )=

[Blizzard]

It is. RGSS is based on Ruby 1.8.6 if I remember right. It's a modded version though. RGSS means Ruby Game Scripting System after all.

RPGXP's script engine doesn't use a proprietary simplified language, but the powerful scripting language Ruby. Ruby's official Website is http://www.ruby-lang.org/.

Ruby is freeware developed chiefly by Yukihiro Matsumoto, and its capabilities are more than sufficient to script a large-scale game. However, since it was originally conceived to be specialized in text handling and the like, it's a challenge to develop a game using Ruby alone. That's why RPGXP uses RGSS (the Ruby Game Scripting System) to adapt Ruby for use in game development. See the RGSS Reference for details.

The language can be referred to as "Ruby" or "ruby", but not as "RUBY".

[Ryex]

what is a thread? is it like starting another process and running it through the processor separately but at the same time?

[Blizzard]

Yes, something like this. While two separate processes have access to different parts of the memory and both have their own memory, threads are within one process. They are branches that are being executed. The CPU switches about 10000 times between threads in one second. That was a program seems to be running more than just one piece of code parallelly. Imagine a server that runs a thread for each connected client. Usually multi-threaded applications are hard to debug because you need to take care of global memory access because two threads accessing and writing at the same memory location will nullify the action of one of them. It's undeterministic which will succeed so usually various mechanisms are used to ensure that threads work properly (i.e. locking of resources so only one thread can currently access that memory location).

As I said, it's not really running at the same time, but it's being simulated quite well.

[fugibo]

Yes, something like this. While two separate processes have access to different parts of the memory and both have their own memory, threads are within one process. They are branches that are being executed. The CPU switches about 10000 times between threads in one second. That was a program seems to be running more than just one piece of code parallelly. Imagine a server that runs a thread for each connected client. Usually multi-threaded applications are hard to debug because you need to take care of global memory access because two threads accessing and writing at the same memory location will nullify the action of one of them. It's undeterministic which will succeed so usually various mechanisms are used to ensure that threads work properly (i.e. locking of resources so only one thread can currently access that memory location).

As I said, it's not really running at the same time, but it's being simulated quite well.

Unless, of course, you're using a multi-core process/multiple processors -- those due run simultaneously in real-time. However, since the most cores the average PC has is 1-2, and only one of them, threads can still be ran on one-core at times. Yay for 8-core Nehalem, though!

[Blizzard]

True. Multi-core processors and multi-processor PCs do run threads at the same time.