Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Extending Gosu / Stencil buffer?
- - By RavensKrag Date 2012-06-13 21:22
Noticed from poking around the forums that Gosu doesn't support the stencil buffer.  Is this something that could easily be added to Gosu? I'm going to try to patch support in, but I want to make sure it's not completely impossible.

Or would it just be better to go for the GLFW stuff first?
Parent - - By jlnr (dev) Date 2012-06-14 03:42
Without glfw, you'd have to add allocation of a stencil buffer to all three OpenGL initializations, but that is the least of all problems actually. :) Have you found a nice interface for using the stencil from within Gosu?
Parent - - By RavensKrag Date 2012-06-17 22:13
Well, this is how I have it set up.  Of course it currently doesn't work, but I think the interface is pretty clean.  It has nice symmetry with the syntax for other block commands like #gl or #transform.


mask = lambda { #draw the "mask" for the stencil buffer}

@window.stencil mask, z=0 do
   # Drawing code here
end
Parent - - By jlnr (dev) Date 2012-06-18 00:26
Maybe we could even overload #clip_to to accept a lambda or macro rendered with #record {}? Agreed, the interface is actually doable!

Oh man, I really have no excuse not to find time for Gosu hacking. I really hope I can take a week off freelancing again.
Parent - By RavensKrag Date 2012-06-18 20:48
Oh yeah, I totally forgot about the macro function.

I'd rather not overload clip_to because clipping is a rather different thing, especially once you start using transforms.
Parent - - By RavensKrag Date 2012-06-23 01:50
...I'm totally supposed to be using SWIG instead of hacking directly into RubyGosu_wrap.cxx, aren't I.

I was starting to wonder why it was such a mess in there.
Parent - - By jlnr (dev) Date 2012-06-23 04:04
Right. :D

On the C++ side, you don't *have* to use the beginStencil/endStencil scheme that clipping uses. I want to slowly migrate everything to methods that take std::function<> callback objects to make it more Ruby-like. But, whatever suits you best. :)
Parent - - By RavensKrag Date 2012-06-23 04:45 Edited 2012-06-23 05:07
I'll have to take a look at the std::function<> callback interface a bit later.  Taking a bit of a break from C++ for a bit (at most just a day or two) after looking through that SWIG mess.  Of course I brought that upon myself, but still :P

Looks like a C++ thing (still don't know much of the language) so it is part of SWIG, C++, or a Gosu-specific thing?

Side note: The long term plan is to migrate towards GLFW, right? As GLFW is made in C, does this mean that Gosu will be moving more towards a focus on C? Or is the plan for Gosu to always be C++?
Parent - By jlnr (dev) Date 2012-06-23 08:22
Gosu will always be in C++, and the APIs in the background have always been C. Not much of a change there with GLFW. :)

Yeah, std::function<> is relatively new - I forgot if it was introduced in C++11 or C++03. In any case, it was well-established as boost::function<> before.

It's basically a variable that can hold everything you can call with a given signature, not just C function pointers. Think proc variables in Ruby. So if you want to accept a callback that can be called without any arguments, you'd use std::function<void()> f and then just call f() to run the callback.
Up Topic Gosu / Extending Gosu / Stencil buffer?

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill