Experiments with ruby-processing (processing-2.2.1) and JRubyArt for processing-3.0

Tuesday 9 April 2013

Should ruby-processing use regular jruby rather than jruby-complete?

Recently I've been corresponding with Alex Dean, who has come up with an interesting problem using the 'fisica' library with the development fork of ruby-processing here is sketch that illustrates the problem:-
#
#  Buttons and bodies
#
#  by Ricard Marxer
#
#  This example shows how to create a blob.
#

load_library :fisica
include_package 'fisica'

CIRCLE_COUNT = 20
HOLE = 50
TOP_MARGIN = 50
BOTTOM_MARGIN = 300
SIDE_MARGIN = 100


attr_reader :world, :x_pos

def setup
  size(400, 400)
  smooth
  @x_pos = 0
  Fisica.init(self)
  @world = FWorld.new
  world.setGravity(0, -300)
  l = FPoly.new
  l.vertex(width/2-HOLE/2, 0)
  l.vertex(0, 0)
  l.vertex(0, height)
  l.vertex(0 + SIDE_MARGIN, height)
  l.vertex(0 + SIDE_MARGIN, height-BOTTOM_MARGIN)
  l.vertex(width/2-HOLE/2, TOP_MARGIN)
  l.set_static(true)
  l.set_fill(0)
  l.set_friction(0)
  world.add(l)

  r = FPoly.new
  r.vertex(width/2 + HOLE/2, 0)
  r.vertex(width, 0)
  r.vertex(width, height)
  r.vertex(width-SIDE_MARGIN, height)
  r.vertex(width-SIDE_MARGIN, height-BOTTOM_MARGIN)
  r.vertex(width/2 + HOLE/2, TOP_MARGIN)
  r.set_static(true)
  r.set_fill(0)
  r.set_friction(0)
  world.add(r)
end

def draw
  background(80, 120, 200)
  fill(0)
  if ((frame_count % 40) == 1)
    b = FBlob.new
    s = rand(30 .. 40)
    space = (width - SIDE_MARGIN * 2-s)
    @x_pos = (x_pos + rand(s .. space/2.0)) % space
    b.set_as_circle(SIDE_MARGIN + x_pos + s / 2, height - rand(100), s, 20)
    b.set_stroke(0)
    b.set_stroke_weight(2)
    b.set_fill(255)
    b.set_friction(0)
    world.add(b)
  end

  world.step
  world.draw
end


def key_pressed
  save_frame("screenshot.png")
end
His experience which I have confirmed is that the FPoly setFill and setStroke methods were not recognized using jruby-complete. Something persuaded him to try using the installed jruby and the methods were no longer missing (anyway that was my experience, I'm not quite sure he might have had java issues on the Mac). Here is the sketch running on my linux box with jdk8 (works with jdk1.7.0_17 as well). Using the jruby-complete (ruby-processing installed) version it was impossible to get the methods recognized even using the usual java_send (reflection techniques).

Update 12 April 2013 Since then Jashkenas has given the all-clear to remove jruby-complete, since it was only included for exporting Applets. So I've been checking out what would happen, and this is what I've found:-

  1. The majority of sketches run OK, except java_args.txt will need changing from java args to jruby args, and there is a special command which allows args such as increasing memory to work (by starting a new proc).
  2. Some sketches fail completely these are mainly Shader examples (where the display is written directly to screen?, I've no idea why this should be the case).
  3. I think there may be version control issues and export app would no longer work.
  4. Currently I think I will retain jruby-complete (for reasons 2 & 3) but possibly make external jruby default (see next post for experiments on installing jruby on linux).


Further update 26 April having studied the java code for the fisica library I am slightly surprised it works at at all, there is a protected abstract class (probably a mistake) who's methods gets called (although these methods are declared public, I believe they should strictly be seen as protected since the class is not public). I'm not wasting any more time with despite nice looking examples.

No comments:

Post a Comment

Followers

Blog Archive

About Me

My photo
I have developed JRubyArt and propane new versions of ruby-processing for JRuby-9.1.5.0 and processing-3.2.2