Wow, that looks quite cool. How did you do the screen coordinates to world coordinates calculation?

The transparency bug is now fixed in the svn and it should be part of the next update. The problem existed only with Images that are using the palette, and most image manipulation programs don't use these. In these images, the transparency chunk (tRNS) was misinterpreted. See http://code.google.com/p/gosu/source/detail?r=1800 and http://code.google.com/p/gosu/source/detail?r=1801 for details.

Try to run 'glxinfo' and grep for "direct rendering". If unsure, past the output here and I will have a look. What kind of graphics card do you use?

These sample images are only on your local drive or can we see them too?

I for one would really like to help out on the C++/OpenGL side of things, but I am lacking proper goals and directions to do so. The GLFW port for example was even much more fun than I imagined. :)

Also I am afraid that contributing is not that easy, what is the reason to have both a github and a google code page, if you only push the svn changes back to git anyways? Merging git-forks back into the svn seems like an awful waste of time :\

I have never noticed anything like that, can you show us some code/video/screenshots?

I will be participating, trying to convince my gf to do the same. :)

flush makes perfect sense for me too, I have been (ab)using beginGL(); endGL(); to do exactly the same for quite a time now :)

ippa:

> Gosu::enabled_undocumented_retrofication  ftw :) ..
> glad someone else then me needed it too ;)

I used it too, but implemented it myself at that time :)
What I don't get is: Why didn't jlnr already document it? ;)

Find a way on how to do it with pure opengl commands (any maybe even supply a working patch for it) and I will guarantee you julian will implement it. If there is no way with pure opengl, I don't think you have a chance of it getting implemented in gosu (Maybe you can do it with texplay?)

Worst theme ever. I am not going to spend much time and effort in this, hoping I can throw together a nice comedy entry...

I too had problems with weird crashes in the release build with MSVS. Most of the time I forgot to initialize a variable or did something stupid with points that the debug build just ignores. I guess you have the same problem with your code.

I like the visual style you have achieved with such "simple" methods, and the level files look quite structured.

A couple of things I did not like:

* Controls. Seriously. You need to rework those. Every state the player is in has a different control-set (Walking, climbing ladder, swimming) - Pressing Q to climber a ladder and E to jump from it is counter intuitive and really hard to handle
* Speed of the game. Also a major point. It feels like everything around the player happens way too fast, except for the actions of the player itself. Players projectile are quite slow, and you can only shoot every 1 seconds, while enemys hauling projectiles at you almost every tick
* Spawn positions of some enemys, esp. after teleporting to a location. There is no way for me at the moment to play any further, because I almost die instantly the moment I teleport.
* Memleak. Maybe this is not your fault, but its really slowing my computer down after ~10 minutes of playing

This is the first LD that allows teams? I thought you participated in a team-compo a few years ago.

Anyways, this sounds like fun and I think I could be free on that weekend. Anyone want to team up? I would even try to learn ruby! :)
(Yeah, alright, I prefer C++ tho, no idea how this is going to work, as I have basically no experience with collaborative software development..)

I haven't looked at this for a while, but it looks really good, at least the screenshots do.
The game itself does not really work on my computer. The small resolution of the game made my monitor cry, and the whole screen got screwed up because of the fullscreen.

Loading times seem to be better, but some loading indication wouldn't hurt. Also, I could not exit the shop, so I gave up.

The problem I see with FBOs at the moment, other than the higher requirements on the graphics card, is that you would have to patch the source to actually do something like this. I can't think of a way to actually get gosu to render to an FBO with just an extension.
If you can think of someway, please post it! :) I wanted to use them in my post-processing class too, but didn't get around to have a closer look at them.

And even if FBOs wont work right now, you can still copy the current framebuffer to an opengl texture and work with this texture as an viewpoint. (But I don't think this is a solution you would want to depend on, as some hardware might not be able to handle texture sizes as big as the gosu window can be)

AmIMeYets snippet seems good enough for a simple viewpoint if you don't actually want to manipulate the rendered images (brightness, blending, transparency, hue etc..)

I already posted this in #gosu a couple of days ago, but this is something I am working on lately.

Its an implementation of Normal Mapping for libgosu, using it to "fake" lighting and detail on normal images. (see video at the end of the post, you actually cant see the effect on the screenshot)

The current implementation needs three passes:
1. Render the normal map of an image (or multiple images) to an texture
2. Render the images that are to be "normal mapped" to an texture
3. Render everything with the vertex/pixel shader enabled

To do this I had to extend my PostProcessing-Framework (I think I actually have to rename it) to handle custom vertex shader aswell, and I still need to think of an easy and fast way to actually combine normal drawing within gosu and normal mapping.
(At the moment everything you will draw before pass 1 will not be visible anymore)

Unfortunately, the developer still has to manage the z-ordering itself for the normal-mapped image, the same as it is with my current implementation of fragment shaders. (It's not possible for extensions to interact with the DrawOpQueue.)

Video demonstration of normal mapping (YouTube)

This was my third time I participated in the Ludum Dare, and this is my best one yet!
I really enjoyed it, hanging out in #gosu and just coding - tho it was really though this time and I worked until 10minutes before the deadline.

Here it is: http://www.ludumdare.com/compo/ludum-dare-15/?action=rate&uid=539

Used C++ and my shader framework.

rock on! http://www.ludumdare.com/compo/ludum-dare-15/?action=preview&uid=539

The last few days I experimented a bit with fragment shaders and their use in a 2D game development library like Gosu, and with the help of jlnr I came up with this extension header for Gosu, that simplifies the use of fragment shader.
With the use of GLEW to check for shader support this should work on Windows, Mac OS X and Linux aswell.

What the class does is, that each time a fragment shader is executed Gosu is forced to draw everything (=> flush the DrawOpQueue) and then the framebuffer contents are copied to a texture. This texture is rendered with the shader applied, and thus the PostProcessing class can handle multiple shaders.
If no shader support is available the class does not create a texture and simply does not execute the shader.

It should be even possible to apply the shader to only certain parts of a game, i.e. running a shader not at the end of your draw function, but in between it. This maybe even necessary for parts of the game that should not have the shader applied to, like on-screen text and HUDs.

I included a few sample shaders (Which I found on the internet and modified to get them working, and I really don't recall where I got them, sorry) which demonstrate the usage of the shaders.
Here is a video on YouTube demonstrating a few simple shaders

I am looking forward to test further applications of fragment shader in 2D games (per-pixel lighting and bloom comes to my mind). Feel free to post suggestions and criticism about the extension, implementation of it or new shaders.

This is C++ only for now, until jlnr figures a way to wrap this to ruby *hinthint* ;)