Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu News / Gosu 0.8.0 released
- - By jlnr (dev) Date 2014-08-18 20:57
This is a pretty chaotic release and I expect things to break left and right, but here we go.

• Gosu now uses the MIT-licensed SDL 2 for all windowing code, on all three major platforms (OS X, Windows, Linux). This should make it MUCH easier to hack the C++ source, and it removes the burden of backward compatibility from my code (though not from. It has turned Gosu into something that I can finish, without fixing broken windowing code every year. So great.
• Most importantly, this fixes the Mac fullscreen bug :)
• Ruby/Gosu now uses rake-compiler to build the source gem for OS X and Linux. The biggest upside here is that Gosu's directory structure is now more in line with other Ruby C extensions.

Note: If you are on OS X, you will have to brew install sdl2 libogg libvorbis before installing the gem. On Linux, you'll have to install libSDL2-dev or a similarly named package.

Still left for me to do:
• Fix all the bugs that we run into with 0.8.0 in the next days.
• Update the change log.
• Update the "Getting Started" wiki pages.
• Build Ruby.app with Ruby 0.8.0 (preparations for this are in place).

Still way out of reach, sadly:
• 64-bit support on Windows
• Support for Ruby 2.0+ on Windows
• A fresh Android port based on the SDL 2 code
Reply
Parent - - By jahmaican Date 2014-08-19 07:43
Still way out of reach, sadly:
• 64-bit support on Windows
• Support for Ruby 2.0+ on Windows
• A fresh Android port based on the SDL 2 code


Now I'm sad.
Reply
Parent - By jlnr (dev) Date 2014-08-19 13:30
Ruby 2.0+ on Windows might only need a single rainy day to fix, but looking at the stack trace one post below, who knows what else is in the queue before that :)
Parent - - By lol_o2 Date 2014-08-19 08:28
I have an error while trying to load Song. (tried with Cptn Ruby, because most of my games use Ashton, which is also broken on 0.8)
Parent - - By jlnr (dev) Date 2014-08-19 13:36
Oh wow, I think my OpenAL32.dll was custom-built to avoid a segmentation fault. Updating it to an unmodified 1.16.0 yesterday was probably a really stupid idea. Thanks for reporting this. Can you please try to replace OpenAL32.dll in the gem directory with the 0.7.50 one? Does that fix the Song error?

Is Ashton broken or does it just not work because it has a dependency on Gosu 0.7.x? Error messages always help. These are probably all just one-line fixes that I forgot about :)
Parent - - By lol_o2 Date 2014-08-19 17:49 Edited 2014-08-19 18:11
Something is wrong with it. I copied OpenAL32 from 0.7.50 and got the same error. Then I deleted this dll entirely. The same error.
And I attached the Ashton error.
Parent - - By jlnr (dev) Date 2014-08-19 19:44
Ah yes, Ashton has a dependency on Gosu "~> 0.7.45", e.g. it won't accept 0.8.x. I don't plan on breaking backwards compatibility before Gosu 2.x, so I have suggested a more relaxed dependency on github: https://github.com/Spooner/ashton/issues/31

If you have a few minutes you should be able to test it locally and send a Pull Request to Spooner :) I'll go after the OpenAL issue first.
Parent - - By Spooner Date 2014-08-19 22:16
Upgraded Ashton to v0.1.4 with this improvement (also uses a newer, more stable, version of opengl gem).
Reply
Parent - By lol_o2 Date 2014-08-20 11:27
Something is wrong. When in fullscreen mode, drawing on Ashton::Texture produces some impossible glitches. It's best seen when running Ahston's 'texture_render_example' in fullscreen.
Parent - - By jahmaican Date 2014-08-19 19:17
Okay, I have some issues with 0.8 as well.

Song is broken the same way on my PC.

Trying to initialize the window with super screen_width, screen_height, true throws something like:
ai.rb:30:in 'initialize': Invalid virtual resolution. (RuntimeError)
(my screen res is 1920/1080). But then, in a project where I have a fixed size window as launcher and create a new fullscreen window like above from it, it works fine. It confuses me a lot.

Custom fonts refuse to work. @font = Gosu::Font.new(self, "media/boxybold.ttf", 20) causes following error:
ERROR:  failed to open 'media/boxybold.ttf'
ERROR: CreateFile failed

Default font is used instead.

I also noticed strange mouse cursor behavior in one project, but I had this problem before and this might be something I did not manage too fix very well, so never mind.

On the bright side, this update finally fixed one of my very old problems.
Reply
Parent - - By lol_o2 Date 2014-08-19 19:24
I have the same problem with font in 0.7.50, but it appears randomly, like 1 in 20 times when loading.
Parent - By jlnr (dev) Date 2014-08-19 21:45
You are right. I use some copy & pasted code to extract the font name out of TTF files that hasn't changed in years. In fact, it is so old that I am getting HTTP error 500 from github while trying to dig into the file's history before 2011. :D

The code has always opened the TTF file for exclusive(!) read access. This must have lead to non-deterministic bugs, because even an Explorer window in the background might sometimes open files to query some meta-data, which would cause CreateFile to fail.

Anyway, fixed in 0.8.1.
Parent - - By jlnr (dev) Date 2014-08-19 19:51
Hmmm, it is interesting that custom fonts would break - none of the code for that has changed. Can you please try loading the font with an absolute path name? Maybe SDL 2 changes the current directory?
Parent - - By jahmaican Date 2014-08-19 20:03
Yeah, thad didn't help. It has to be font-specific problem, as literally a line before I load an image from the exact same directory and it works ok.

Providing a non-existing path to the method causes different error btw. (ERROR: CreateFileMapping failed, not failed to open)
Reply
Parent - - By jlnr (dev) Date 2014-08-19 20:15
I have just received a second bug report about loading fonts, with the exact error message as yours, but in Gosu 0.7.50 - and passing an absolute path name worked. It has to use forward slashes, though ("C:/dir/file.ttf"). What a bizarre bug.
Parent - - By jahmaican Date 2014-08-19 20:25
I even tried Dir.pwd+"/media/boxybold.ttf" so the path has to be right, but still no fonts for me. Alright then :(
Reply
Parent - By jlnr (dev) Date 2014-08-19 20:30 Edited 2014-08-19 20:46
Hmm, can you please attach the font to a post here? I'd like to play around with this bug :)

Edit: Never mind, your github project is result #1 for the filename. :D
Parent - By jlnr (dev) Date 2014-08-19 20:19
Still testing, but  Gosu::Song works in C++. No surprise, it's a Ruby-only bug. :)
Parent - - By jahmaican Date 2014-08-21 15:47
I also noticed strange mouse cursor behavior in one project, but I had this problem before and this might be something I did not manage too fix very well, so never mind.

I can now confirm that 0.8.0 broke my turning around code in jCaster. Here's the story behind:
It's actually quite easy to make your character turn in 3D environment by moving your cursor left and right. But cursor tends to stop whenever it reaches an edge of the screen, whether or not it's visible. Let's say I'm turning left, the moment mouse_x reaches 0, I can no longer do it.
My clever as heck solution was to reset mouse_x to the middle of the screen at some point, so the cursor could just keep moving. BUT, as it turns out, now manually setting cursor position in the middle counts as if it was physically moved to given point, so when that happens, character turns back to the angle he was facing when the cursor was at this position in the first place.
Now I don't know if this could and/or should be fixed, because I guess it is not technically a bug. But it's somewhat interesting. And now I have to figure out a hack to fix a hack.
Reply
Parent - - By jlnr (dev) Date 2014-08-21 18:30
That's interesting. How did the code work before? I assume you calculate last_mouse_x - mouse_x in every update cycle and then reset the cursor to the centre – why would this not work in the new version?

That doesn't really sound like a big hack, I think that's what other games are doing as well :)
Parent - - By jahmaican Date 2014-08-22 09:26 Edited 2014-08-22 09:32
Well, I don't really do it every cycle (turned out it's a bit glichy this way), but other than that it's quite what I do.
https://github.com/Jahmaican/jcaster/blob/master/class/playerClass.rb - turn method

Anyway, on completely irrelevant topic - LD30 starts tommorow, if I'll manage to find enought time (which might be a bit hard), I will participate and I'm going to use new gosu. With all these brand new bugs, it might turn out quite funny.
Reply
Parent - By jlnr (dev) Date 2014-08-22 22:47
I'll lurk around the Ludum Dare blog this weekend, but I already have too many unfinished projects on my hand :) Good luck finding some free time!

The biggest question will be, what state is Ocra in currently? I wonder if it can build a Ruby/Gosu EXE - haven't tried in a while...
Parent - - By RunnerPack Date 2014-08-21 22:12 Edited 2014-08-22 01:28
Can't you just use the mouse position as a virtual joystick and change rotation speed according to the distance from the center of the screen?

EDIT: Also, I noticed that the mouse position is no longer updated when the cursor is outside of the window. I guess this is logical, and probably even simplifies certain tasks, but the former behavior was actually kind of handy in a couple of programs where I only cared about the angle of the mouse relative to the center of the window. I'm not complaining, and I don't think it's worth putting in an option or changing it back. However, if it is an easy change, a good compromise might be to go back to detecting the mouse outside the window, but clipping the coordinates to the client area.
Reply
Parent - - By jlnr (dev) Date 2014-08-22 05:28
Oh wow, I didn't notice that! I really liked the old behaviour. Even the fact that you could have a negative mouse_x and all that.

Thanks for pointing it out - I mostly use Tutorial.rb and an iOS game to make sure everything still works, and there are so many parts of Gosu that are under-tested... :)
Parent - - By RavensKrag Date 2014-08-22 11:03
Maybe it would be better to have an option to lock the cursor to the window instead?
Reply
Parent - By jlnr (dev) Date 2014-08-22 22:36
Another option would be to offer an interface to this SDL functionality: https://wiki.libsdl.org/SDL_SetRelativeMouseMode

But for everything else I'd still like to "fix" the mouse behaviour. :)

There is also this function, but it's part of the yet-unreleased SDL 2.0.4: https://wiki.libsdl.org/SDL_GetGlobalMouseState
Parent - By jahmaican Date 2014-08-22 09:33
I might, but that's not quite how FPS games work :)
Reply
Parent - By jlnr (dev) Date 2014-08-23 16:20
Re: cursor issues, let's wait for SDL 2.0.4 :) Shouldn't be too long, they're already beta-testing.

https://github.com/jlnr/gosu/issues/240
Up Topic Gosu / Gosu News / Gosu 0.8.0 released

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill