Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu News / Gosu 0.7.36(.2) released
- - By jlnr (dev) Date 2011-08-24 14:07
Another small bug fix release that should make everything stable and fun again:

• Win/Ruby: Fixed unhelpful Image loading errors
• Linux: Lots of configure & Rubygem fixes (thanks again here, Jamer)
• Win/Ruby: Fixed crashing or hanging Ruby process on exit after using audio

This makes the workaround DLL posted here earlier unnecessary.

On a side note, I included FreeImage.dll with the Windows gem for those who need exotic image formats, e.g. loading straight from PSD files during development. This works out of the box on all platforms now. Just keep in mind that you may need to ship FreeImage.dll along with your game if you use any non-system image formats in production.
Reply
Parent - By jlnr (dev) Date 2011-08-25 08:40
More notes: 0.7.36.1 adds important files that were missing from the Ruby gems. 0.7.36.2 fixes a compilation issue on Linux and updates the C++ Tutorial to the Wiki version.
Parent - - By RavensKrag Date 2011-08-27 03:47
PSD support huh? Interesting... What does this do in terms of layers? Does it simply flatten everything onto on Gosu::Image? Would Gosu::Image#save allow writing to PSD?
Reply
Parent - - By jlnr (dev) Date 2011-08-27 04:46
Yeah, it does just flatten everything. It may be different between Windows/Linux (which use FreeImage), and OS X (which uses Apple's built-in PSD reader). I never thought about writing them. Without layers, couldn't you just save as PNG and only have advantages? :)

Color management might make for subtle differences between both platforms too. Or maybe not if you disable it in PS to begin with. Sadly my last mini-project didn't involve photoshopping, so I couldn't play around with it in depth yet.

Loading layers from PSD, or frames from GIF animations would all be pretty awesome, but that's the job of other libraries I guess.
Parent - - By erisdiscord Date 2011-08-28 15:01
It's a shame I use Pixelmator (can't afford Photoshop) cause this PSD loading feature sounds awesome for prototyping graphics. :D

I guess I could try saving as PSD, but I think Pixelmator's PSD support is kinda lacking.
Reply
Parent - - By jlnr (dev) Date 2011-08-28 19:17
It would be relatively easy for Gosu to support loading from QuickLook. Do Pixelmator files have a full-quality preview?

I think the biggest issue was that you'd have to supply the width and height when loading, since QuickLook is supposed to scale stuff; you basically call something like QLPreviewForThisSize(w, h). Not sure if that still makes it a productivity booster then...
Parent - - By erisdiscord Date 2011-08-28 19:19
They are viewable in QuickLook, but the preview generator has a tendency to crash on my machine. As cool as that hack sounds, I'm not sure it's worth the trouble!
Reply
Parent - - By jlnr (dev) Date 2011-08-28 19:19
I'm really starving for a reason to implement this nonsense. Same sad category as if id == Gosu::RemotePlay then… or Window#accelerometer_x or... ;)
Parent - By erisdiscord Date 2011-08-28 19:21
Well, if you really want to~ :D
Reply
Parent - - By RavensKrag Date 2011-08-28 18:22
Would you happen to know of any "other libraries" for PSD or GIF parsing?
Reply
Parent - - By jlnr (dev) Date 2011-08-28 19:16
I think, but I am not sure, that RMagick actually returns GIF files as an array of images. Not sure about PSD.

RMagick packaging for production is a nightmare though :)
Parent - By RavensKrag Date 2011-08-28 19:34
True about that RMagick... that's the one reason I switched to using TexPlay.

Thanks anyway.
Reply
Parent - By RunnerPack Date 2011-09-01 21:12
For animated GIF, I found this:

http://gif2apng.sourceforge.net/

As the name implies, it's a self-contained GIF->Animated PNG converter. It's written in C and looks fairly portable. It would be a bit of work, but you could extract the GIF loading code from it. It might also be useful as a standalone program...
Reply
Parent - - By RavensKrag Date 2011-09-03 00:23
Just noticed something slightly odd about how Gosu::Window#draw_quad is implemented.  Why does it draw two triangles instead of a quad?
Reply
Parent - - By jlnr (dev) Date 2011-09-03 00:55
It draws a GL_QUAD, but there is no difference between that and two triangles. The implication is that color interpolation between the four sides of a quad will not be perfect (two corners "don't mix"), is that what you experience?
Parent - - By RavensKrag Date 2011-09-03 01:16
Yes it is.  I was talking with someone earlier today who said he knew OpenGL, and said it looked wrong, so I figured he knew what he was talking about.  I suppose not ^_^;

I suppose I should have googled this first.  There seems to be a pretty good explanation of how the triangulation of quads effects the resulting gradient.

To reference this image here
http://cs.wellesley.edu/~cs307/readings/ColorInterpolationQuads.png

I was expecting the bottom right result, but opengl generates the top left one.
Reply
Parent - - By jlnr (dev) Date 2011-09-03 06:28
I was thinking about documenting that too, also specifying the order in which Gosu triangulates this. Some of my sky backgrounds looked terrible when I ported stuff from OS X to iOS because it changed from top left (top middle?) to top/right.
Parent - - By Basic Date 2011-09-03 06:47
I don't think it will effect Gosu because its using OpenGL 1.1 (is that right? ie what comes standard with Windows.), but GL_QUADS has been deprecated, along with Immediate mode.
Parent - By jlnr (dev) Date 2011-09-03 08:13
GL_QUADS is really nothing but a shortcut for two triangles. The difference between my sky gradients on Mac and on iOS didn't stem from GL_QUADS vs. triangles, but because the order in which I pass both to OpenGL was different. The order in which a drawQuad thingie is split into two triangles in Gosu should be unified and documented.
Up Topic Gosu / Gosu News / Gosu 0.7.36(.2) released

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill