Gosu 0.7.36(.2) released

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.

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?

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.

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.

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...

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!

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... ;)

By erisdiscord Date 2011-08-28 19:21

Well, if you really want to~ :D

By RavensKrag Date 2011-08-28 18:22

Would you happen to know of any "other libraries" for PSD or GIF parsing?

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 :)

By RavensKrag Date 2011-08-28 19:34

True about that RMagick... that's the one reason I switched to using TexPlay.

Thanks anyway.

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...

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?

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?

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.

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.

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.

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.