Gosu 0.9.2 released

By jlnr (dev) Date 2015-05-24 19:10 Edited 2015-05-24 19:17

Note: SDL_GetGlobalMouseState is only available in SDL 2.0.4, which is still not out by now (pending tickets: https://bitly.com/sdl204-todo). So it probably only fixes mouse_x and mouse_y if you use brew install sdl2 --HEAD on OS X.

Next up: Updated Ruby.app for OS X, if I don't receive any bug reports for 0.9.2 in the next days. Then CMake build files, and I'm playing around with RubyMotion as well.

By jlnr (dev) Date 2015-06-14 21:36

Ooohh, SDL 2.0.4 is coming closer! Can't wait: http://forums.libsdl.org/viewtopic.php?t=11294

By lol_o2 Date 2015-05-25 11:06

So I tested all this 2.2 compatibility etc. The new Gosu works with 2.2.2, seems to be backward-compatible and even "compiles" with Ocra.
Then I tried Ashton:

C:/Ruby22/lib/ruby/gems/2.2.0/gems/gosu-0.9.2-x86-mingw32/lib/gosu/swig_patches.rb:63:in unsafe_gl': There is no rendering queue for this operation (RuntimeError)
        from C:/Ruby22/lib/ruby/gems/2.2.0/gems/gosu-0.9.2-x86-mingw32/lib/gosu/swig_patches.rb:63:in gl'
        from C:/Ruby22/lib/ruby/gems/2.2.0/gems/gosu-0.9.2-x86-mingw32/lib/gosu/patches.rb:108:in block (2 levels) in <class:Window>'
        from C:/Ruby22/lib/ruby/gems/2.2.0/gems/ashton-0.1.6/lib/ashton/gosu_ext/window.rb:37:in gl'
        from C:/Ruby22/lib/ruby/gems/2.2.0/gems/ashton-0.1.6/lib/ashton/shader.rb:105:in enable'
        from C:/Ruby22/lib/ruby/gems/2.2.0/gems/ashton-0.1.6/lib/ashton/shader.rb:68:in initialize'
        from D:/Ruby/Gry/Projekty/Mariovania/data/scripts/system.rb:850:in new'
        from D:/Ruby/Gry/Projekty/Mariovania/data/scripts/system.rb:850:in initialize'
        from Mariovania.rb:69:in new'
        from Mariovania.rb:69:in <main>'

Looks like the shaders (and probably other GL things) are broken. It may be Ashton's fault though. Anyways, I'm not using it currently very much and if I do, I can just stick to older versions. It's not super important or something.

By jlnr (dev) Date 2015-05-25 11:11

Awesome, good to know that Gosu by itself works.

I'd love to fork and fix both Ashton and Releasy, but before I get to Gosu 1.0 or so, I don't see it happening :(

By lol_o2 Date 2015-05-25 11:15

Ashton has many thing to be fixed anyways. It's both terribly broken and irreplaceable :(

By lol_o2 Date 2015-05-25 11:47

I forgot to report this, but fullscreen doesn't always look good. I assume that what it currently does is scaling each draw call individually. On some resolutions (like my 1366 x 768 with 640 x 480 game), artifacts are very likely to appear when drawing small tiles. Isn't it possible to draw everything normally and THEN scale up to the screen? (this would also probably fix one problem with Ashton)

By jlnr (dev) Date 2015-05-25 11:54

I guess it would be possible to render to a texture and then scale it up, but I still haven't looked into render-to-texture at all.

My expectation was that it should actually look better if you render it at a higher resolution directly, but I'm not sure if that's true.

What kind of artefacts, by the way? Are you using the :tileable parameter to ensure crisp tile boundaries?

By lol_o2 Date 2015-05-25 12:09

(Since I can't take screenshots on full-screen, I had to draw this manually, lol)

Top image shows how it looks in windowed mode. The bottom shows "fullscreen" one (but actually it should be stretched). These are map tiles, each of them has a background, borders and corners drawn individually. Each border is 12x2-sized image! In fullscreen, they scale up wrongly so edges of each border/corner is blurred, leaving space.
This happens also with tileability set to true. Retrofication fixes this, but then the fonts and most graphics look terrible O_o. It probably all depends on scale ratio. With my laptop it's 1.6 for this resolution, so pixels are unequally stretched.

By bestguigui Date 2015-06-08 15:33

Hi and great job there ! Thank you for this major update that allows to get rid of the Gosu::Window reference !

Just one issue from now : since I updated the gem, I now have a couple of white frames at first when I run the program. I didn't have that problem before updating.

Do you have an idea ?

By jlnr (dev) Date 2015-06-08 16:01

Thanks! Does it happen only in 0.9.x, or also 0.8.x? Do you have an example script for me to try?

By bestguigui Date 2015-06-08 16:09

Only on 0.9.x. Here is the smallest code I could provide...

require "gosu"

Gosu::Window.new(320, 240, false).show

I get a white screen at the beginning.

By lol_o2 Date 2015-06-08 16:27

I noticed it just now. It's so short that you can blink and miss it. It's probably window loading or something, not a big deal. At least for me.

By bestguigui Date 2015-06-08 16:32

For me neither, of course. But if it can be fixed sometime, it's better. "Glad" to hear I'm not alone with that, it's often the case with my poor computer :(

By jlnr (dev) Date 2015-06-08 16:31

Cool thanks, will take a look. Maybe it's an SDL issue anyway :)

By bestguigui Date 2015-06-14 11:35

Hi !

I have another issue : when I use mouse_x= and mouse_y= to place my pointor, only the second called method is taken.

For example the following code :

require 'gosu'

class Window < Gosu::Window
def initialize
super(640, 480, false)
end

def needs_cursor?; true; end

def update
self.mouse_x = self.width / 2
self.mouse_y = self.height / 2
end
end

Window.new.show

will put the mouse pointor on the horizontal left but centered vertically... I now have to use the deprecated method set_mouse_position(x, y) instead if I want to set the mouse where I want.

By jlnr (dev) Date 2015-06-14 21:35

Ouch! It's on my list. Hopefully updating to SDL 2.0.4 "soon" will fix the issue :)

By jlnr (dev) Date 2015-07-20 22:38

Nope, this was an error on my side - will be fixed in Gosu 0.9.3 (ASAP), no need to wait for an SDL update.

By jlnr (dev) Date 2015-06-15 08:17

I've tried to reproduce this issue but it all looks good here. Does this gist work for you?

https://gist.github.com/jlnr/a42235af10f75159f2d9

It is creating a 12x2 sized image (pure white) and drawing it all over the screen. Or is it because your borders are separate images?

By lol_o2 Date 2015-06-15 08:33

This code seems to work.
In my game I'm using 16x16 tiles for all parts and they are drawn using draw_rot to produce borders/corners all around.
Here's the image with all tiles: http://i.imgur.com/vMfp6nS.png (it's white on transparent background)
First tile is background (drawn on bottom with color), fourth tile is border (drawn up to 4 times with draw_rot) and eighth one is corner. Unfortunately, I don't have much time to do testing this week.

By jlnr (dev) Date 2015-06-15 08:53

I see. I've been meaning to finally replace enable_undocumented_retrofication with a new flag during image creation, e.g. Image.new("tile.png", :retro => true), same for load_tiles etc.; would this help?

(It's gotten a lot easier to actually implement this based on the new interface :) )

By lol_o2 Date 2015-06-15 09:06

Yeah, if I could set retrofication for single images it would help.