Hi, I'm kinda new at gosu and I read different post here on 2D cameras and clipping... but I'm not sure if it can help me to do what i want to achieve: Viewports.
That's how they work:

you have a class Viewport, and an instance is pretty much like a rect, but with Z ordering between other viewports, and some visibility switch, color blending etc...it can be moved and such, but it's invisible by itself.

and drawable stuff can be attributed to a viewport. or to be exact, a viewport can be attributed to a sprite (kinda like sprite.viewport =  my_viewport_instance )

If so, the coordinates of the picture  are relative to the viewport and not to the main window anymore. If the picture is "getting out" of the viewport, then the part that is out isn't visible.

Some people here will recognize the Viewport class from the RGSS library from RPG Maker XP or VX. That's a very convenient class to do different effects. ( like scrollable text etc... )

So is there anyway to implement that somehow with something using not a lot ressources?

not having this class is pretty much what stops me from moving to something less constraining than RPG Maker.

Thanks for your answers!

hi,

i can think of a couple of ways to go about this:
(1) In OpenGL it is possible to render to a texture rather than the screen. I'm not entirely sure, but i think FBO (frame buffer objects) are relevant to this. So, a 'viewport' would be a blank texture, of whatever size, that you render your stuff to. You could have as many of these as you wanted and place them wherever on the screen you like. Like I said, im not entirely sure this is the best approach to implementing 'view ports' but it's one i'd like to research nonetheless

(2) You could splice images into a blank Gosu::Image using TexPlay. I can think of a few ways to make viewports possible in TexPlay and i think it'd be reasonably performant. The basic idea would be to save the region about to be obscured, draw the object on that region, and then replace the obscured region...I think i should be able to make this reasonably performant and present a nice interface so it's similar to rendering to the screen.

I will implement (2) for the TexPlay 0.3.0 release but (1) is likely to be a lot faster and a better approach in the long run (IMHO). If someone here with proper OpenGL chops thinks that (1) is the best approach but doesn't want to implement it themselves, i'd like to try my hand at it as it seems pretty fun :))

I think the easiest way will be to subclass Gosu::Image and just add some values to x/y/z in all drawing methods. To get everything in order you could write a viewport class that has a method that takes a block:

class Viewport
  # boring stuff

  def draw
    @window.clip_to(...) do
      # tell all images belonging to this viewport to add x/y/z to their coordinates ...
      yield
    end
  end
end

...

my_viewport.draw do
  # draw all images that belong to the viewport
end


If you don't want such a block structure, you will have to add the clip_to to every drawing method to get the viewport effect.

I am still not convinced that a Viewport class really makes it a lot easier to write full games, but since it was asked for several times in the last month, if someone can come up with an implementation, it should be posted. :)

Yes, window#clip_to should do exactly what Trebor wants.

Color and Tone might be a little harder to implement though..

Something like this?
Usable by giving every image access to their viewport, and adding vp.x, .y, .ox, .oy, etc. to their normal drawing code..
Or is my logic flawed here? I haven't even tested it in Gosu yet..

Also, @Trebor.. When the hell did the people at HBGames start using Gosu? :S

Well I know gosu from some french dev forums, for a few years now. Played a bit with it, and quite enjoyed it for rapid prototyping ^^.
but HBgames is, since it's renamming from RMXP.org to HBGAMEs, open to any kind of Maker/ game lib projects. And there is a part of the forum dedicated to gosu now.

I'll have a look at the openGL "render to texture" thing .  :) and if find something useful try to make something with your snippets guys!

No, you don't have to look in to OpenGL anymore. You can simply use my snippet:
A demo in the form of a textbox here

Edit: Oh wait, instead of using @position, maybe I should have just increased/decreased Viewport#oy

I didn't know about the to_clip method, it looks like the best approach...

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

yeah its snippet is very good :) I added a few simple features to it :) as if it's hidden, all the associated sprites to it are not drawn.

no the trick i'm a bit worried about, is on Z ordering those viewport, between each others... it's kinda independent from the sprite Zordering... but that more a matter of organizing well your stuff to make sure it's at the right place than anything else.

As an artefact of how Gosu works, a gl{} block has to flush all the currently queued rendering to the screen. So if you wabt to have everything on which .draw was called rendered to the screen, and start with a new Z-order on top of that, you can just call your_window.window.gl {} :)