Hello all -
I'm getting ready for next week's Ludum Dare by doing a quick, one-day mini-game event. Basically a lunar lander type thing.
I develop on OSX Lion, using ruby 1.9.2 p180 (in rvm), and gosu 0.7.33. Everything works like a charm. I get 60 frames per second, as expected.
Then I copy the game over to Windows. I'm using XP SP3 and Win7 to test with. I have ruby 1.9.2 p290 (i386-mingw32) and gosu 0.7.35 (i386-mingw32).
On both Windows setups, my frame rate drops to around 16fps. And when I close the window, rubyw hangs around in the task list, until I manually kill it. I have tried using the console version, and when the game exits, the console stays there, but is unresponsive, and I have to manually kill it.
I realize that both of these questions are probably more about ruby than gosu, but I'm wondering if other developers using a similar setup have seen the same thing.
No, Gosu hanging around in the task list is a problem with OpenAL. OpenAL seems to be terrible, but at least it doesn't crash in-game like the last library did. I will try to fix it until the Ludum Dare is coming up.
Gosu running slower is news though. Are these native Windows installations or running in a VM?
Hi jlnr -
I have run my Windows code on both a VM (Parallels on the Mac) and actual hardware. It was consistent on both, which is what got me thinking it might be a Windows specific thing.
I'll get mingw installed on one of the Windows images and see if I can help troubleshoot. I can also post my ruby code, if that would be useful.
Thanks for all your hard work! I'm really liking the library.
Is your game running faster if you use an older version of the Gosu gem, e.g. 0.7.33 or 0.7.30?
I haven't yet tried p290, maybe something has changed there. I will check it out.
No, both 0.7.30 and 0.7.33 give me the same results. I was thinking that maybe it had something to do with blitting to a window versus full screen, so I reran the tests with fullscreen set to true. I got the same frame rates, and a 640,480 window in the middle of a big black background.
On the plus side, the console didn't hang afterwards when using 0.7.30 or 0.7.33.
It would be a little tougher for me to roll back to an older ruby version, but I can if you think it will give you some meaningful info.
Is your game resource intensive at all? Gosu tends to be slower on Windows, but I never heard of such a crass difference. Is the code to your game available online?
I pasted it to http://pastebin.com/53beHCdB
Now, keep in mind it's not *good* code. I was going at Ludum Dare speed. It ran fine on my Mac, so I didn't worry about it much. It wasn't until I copied it over to Windows (to configure ocra, not even really to test it) that I saw the speed difference.
Can you also upload the media files so I can test it on my machine? You can simply zip them & attach the ZIP to your posting here after answering too. My schedule is a bit rough but if there is anything wrong with Gosu, I'd like to issue a hotfix before the LD starts.
Doh! Media files would definitely help.
There's got to be a good audio library alternative. I wish there were! D:
What are the ones you've already tried? Maybe in my spare time I can do a little research and find one?
No, please not another one :) OpenAL seems to work fine if you are super, super careful about resource management. It works okay for Ray (another Ruby gamedev lib). I will try to get it fixed this week.
I noticed that my background music played fine on the mac, but was unsupported on windows. It was an m4a file. I guess I need to convert everything to ogg?
Also, and this was weird, on Windows, some of the color constants didn't work. Gosu::Color::GREEN was undefined. It worked fine on the Mac side. I got around it by just setting my own constants, but I thought that was maybe worth mentioning.
Hmm, the constant thing sounds very unusual too. Can you post a minimal script that doesn't work with GREEN?
And yep, you may need to convert the files. OGG is great except on iOS, where m4a is a much better choice (hardware accelerated decoding!). I updated this wiki page a bit to reflect the recent library changes on Windows and Linux, though my writing skills aren't great today: https://github.com/jlnr/gosu/wiki/Supported-Audio-Formats
Better late than never. The new OpanAL library did not cause a hang on exit. That lib is what I ended up using the Ludum Dare. Thanks!
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill