Slow math in Ruby

[Groogy]

Keep in mind while reading that I'm doing this to challenge myself.

Alright while I wait for the new Graphics API comming out I'm faking perspective on the CPU with Ruby which is really really slow as it seems. My minimum platform are also pretty slow so it kinda backfires on me.

Here is what I am currently doing:


And the framerate of 600 FPS is what I've reached after micro optimizing the shit out of my perspective algorithm. And I'm out of ideas on what I can improve more. If I comment out the update on my tiles I will reach up to something about ~1300 FPS(I'm still looping trough them).

I want to see if someone else might find what I can improve in order to not have such a huge performance penalty? Maybe someone can break out parts in the math that's not needed or something I don't know. It's not really a language specific question.

Here's my perspective faking:

Code: [Select]

class Tile
  def update( camera_position )
    x_movement_factor = @position.z * ( camera_position.x.to_i - @position.x * Tile::Size ) / Tile::HalfSize
    y_movement_factor = @position.z * ( camera_position.y.to_i - @position.y * Tile::Size ) / Tile::HalfSize
    x_movement_factor = @max_movement_factor if x_movement_factor > @max_movement_factor
    x_movement_factor = @min_movement_factor if x_movement_factor < @min_movement_factor
    y_movement_factor = @max_movement_factor if y_movement_factor > @max_movement_factor
    y_movement_factor = @min_movement_factor if y_movement_factor < @min_movement_factor
    @sprite_origin.x = HalfSize + x_movement_factor
    @sprite_origin.y = HalfSize + y_movement_factor
    @sprite.origin = @sprite_origin
     
    x_scale_factor = 1.0
    y_scale_factor = 1.0
    if @max_movement_factor != 0
      depth_factor = 1 + @position.z * 0.25
      x_scale_factor = depth_factor + x_movement_factor.abs / @max_movement_factor.to_f
      y_scale_factor = depth_factor + y_movement_factor.abs / @max_movement_factor.to_f
    end
    @sprite_scale.x = x_scale_factor
    @sprite_scale.y = y_scale_factor
    @sprite.scale = @sprite_scale
  end
end


Of course when the support for Vertex Shaders come this won't be a problem but would still be nice to have some ideas on how to maybe optimize other areas in Ruby more.
Any ideas you have can come in handy. Any idea you have that can make math calculations in Ruby faster is a plus.

[Laurent]

Excuse me but why are you already thinking about optimizations? 600 FPS is huge. Write more code, add features, instead of wasting your time

[Groogy]

Yes it is an big amount. But I am only doing calculations for 162 tiles and it impacts my performance massively. If I add so I have 10 layers in the world I will get an FPS around ~200 but this is only 540 tiles. But for real-time case I would need 4096+ tiles. Modified my tilemaps to contain that amount and the resulting framerate was ~38. Commenting out the rendering sets the framerate around ~50.

So I am not optimizing to make it more efficient. I am optimizing in order to get it to work ^^
Will probably try and make something equivalent in C++ just to see the difference.

[Groogy]

Alright some improvements and corrections. The calculations were quite faulty but it is all now correct and gives me 100% accurate modification of scale and position. Also became a bit more optimized. I still feel that something is off but it might just look that way because I don't have any walls to compare against.



And I added the complete code here: https://legacy.sfmluploads.org/code/111
If anyone wants to do something similar in their games.

I have tested all the way from 1 in depth to 12 depth(levels, floors whatever you want to call it) and the result is accurate and precise. Albeit slow on Ruby I guess but this calculation should be easy to move to the GPU with Vertex Shader I think and then it won't cost a thing =)

In the above image I have 12 depth which gives me 648 tiles.

NOTE: In this code I multiply the changing factor with 3 per depth which means that each "wall" will become 16 * 3 big. By changing this number you can regulate the difference between the "floors". I tried with 4 but it looked really weird as the bottom had a huge wall while the top was only a small spring.