heya all,
I was just tinkering with an old patch and I can't get single-buffering to work. It worked before...
I'm using Chris's bianry release for OSX from two weeks ago.
The window does not complain, seems to enter single-buffering mode. but when I try and draw something (by banging on a gemhead) I get nothing but black. Changing the gemwin color does not render either, all black...
Anyhow I hope it gets fixed as its something I often use.
Oh and since the gemchains are now PD messages when I break a chain (via spigot for example) do I need to hit stop rendering and start it again for Gem to register the change? (In 0.87 it looks like one had to rerender, on CVS it seems to work) Also is there a way to have a chain keep its texture data after bring broken? Even in CVS it seems breaking a chain will cause it to loose its texture.
Thanks ben
Quoting ben@ekran.org:
heya all,
I was just tinkering with an old patch and I can't get single-buffering to work. It worked before...
I'm using Chris's bianry release for OSX from two weeks ago.
The window does not complain, seems to enter single-buffering mode. but when I try and draw something (by banging on a gemhead) I get nothing but black. Changing the gemwin color does not render either, all black...
Anyhow I hope it gets fixed as its something I often use.
There is no single buffering of GL contexts in OSX. Never has been and never will be. There's nothing we can do about this - it was a very early Apple design decision.
Oh and since the gemchains are now PD messages when I break a chain (via spigot for example) do I need to hit stop rendering and start it again for Gem to register the change? (In 0.87 it looks like one had to rerender, on CVS it seems to work) Also is there a way to have a chain keep its texture data after bring broken? Even in CVS it seems breaking a chain will cause it to loose its texture.
0.87 didn't have pd messaging, but the CVS does. the texture data will be kept if the memory addresses haven't changed. does spigot do anything odd with the pointers? i suppose there could be a 'rebind' function and corresponding message to pix_texture, but that seems like a hack.
cgc
Thanks ben
On Thursday, September 11, 2003, at 04:49 PM, cgc@humboldtblvd.com wrote:
Quoting ben@ekran.org:
heya all,
I was just tinkering with an old patch and I can't get single-buffering to work. It worked before...
I'm using Chris's bianry release for OSX from two weeks ago.
The window does not complain, seems to enter single-buffering mode. but when I try and draw something (by banging on a gemhead) I get nothing but black. Changing the gemwin color does not render either, all black...
Anyhow I hope it gets fixed as its something I often use.
There is no single buffering of GL contexts in OSX. Never has been and never will be. There's nothing we can do about this - it was a very early Apple design decision.
...uh, strictly speaking you're right, but I do remember a 'single buffer' mode working in earlier versions of the GEM OSX port...I think it was one of ben's early example patches: but as I recall, ya had to select single buffer before creating the window, which resulted in the buffer getting filled by all drawing events, which was cool as long as ya had a way to change your drawing colors/shapes/etc...I haven't tried this in awhile, so I'll look into it tonight...
l8r, jamie
Hello All,
After playing with my Gem GOPs today (released soon I hope! I wanted to get a few more done though) I'm even more assured that single-buffering is an important feature. Important enough for it to end up in all my patches in some form or another. The reason why? single buffering makes very very beutiful organic shapes possible with very little polys. They render really fast, and are incredably smooth. Today I was playing with a static object in single buffering playing a video on it. The effect was visually very close to pix_biquad and pix_blur (smoother than pix_blur) without any extra computation. The frames smoothly get blended together as if the frames were actually being cross-fade. I was blown away, and realize I really have to try it with live video!
single buffering is, for me, one of the most important features, because it makes possible forms in time that would take a lot more processing power to do without it.
Anyhow I am the only one to use single buffering??
Ben
On Thursday, September 11, 2003, at 04:49 PM, cgc@humboldtblvd.com wrote:
Quoting ben@ekran.org:
heya all,
I was just tinkering with an old patch and I can't get single-buffering to work. It worked before...
I'm using Chris's bianry release for OSX from two weeks ago.
The window does not complain, seems to enter single-buffering mode. but when I try and draw something (by banging on a gemhead) I get nothing but black. Changing the gemwin color does not render either, all black...
Anyhow I hope it gets fixed as its something I often use.
There is no single buffering of GL contexts in OSX. Never has been and never will be. There's nothing we can do about this - it was a very early Apple design decision.
...uh, strictly speaking you're right, but I do remember a 'single buffer' mode working in earlier versions of the GEM OSX port...I think it was one of ben's early example patches: but as I recall, ya had to select single buffer before creating the window, which resulted in the buffer getting filled by all drawing events, which was cool as long as ya had a way to change your drawing colors/shapes/etc...I haven't tried this in awhile, so I'll look into it tonight...
l8r, jamie
Hi Ben,
I think the answer to your troubles - in both the short and long terms, might be using double buffering but disabling the clearing of the frame buffer at each page flip. This is supported in Gem CVS. This works well on the hardware I've tested on, but screen appearance may vary depending on the buffer flipping scheme being used - in fact I fear that on some hardware you'll end up with nasty frame strobing as a different set of objects will appear in each of the two frame buffers. The upshot is that you shouldn't get any tearing. Please let me know how you fare.
Here is the doco for this (ie some messages I posted to pd-dev some time ago... sorry!)
Daniel said:
- I'm going to implement some control over window clearing into gemwin.
This can be used to do multipass rendering and various other things. I'm proposing a couple of changes:
- "clearmode f" message to [gemwin] to set which buffers are cleared
automatically in each render cycle
- [clear] object to be inserted into the rendering chain to force a clear
at
that time.
A first pass at this is now in CVS.
The "clearmask N" message can be passed to a gemwin to set the clearing behaviour. "N" is simply cached and passed directly in the glClear call - generate it using the GLdefine mechanism and GL_COLOR_BUFFER_BIT, GL_DEPTH_BUFFER_BIT etc..
[GEMglClear] can be used in other gemlists to control buffer clearing.
Daniel
----- Original Message ----- From: ben@ekran.org To: tigital@mac.com Cc: cgc@humboldtblvd.com; ben@ekran.org; GEM-dev@iem.at Sent: Saturday, September 13, 2003 1:55 AM Subject: Re: [GEM-dev] single buffering
Hello All,
After playing with my Gem GOPs today (released soon I hope! I wanted to get a few more done though) I'm even more assured that single-buffering is an important feature. Important enough for it to end up in all my patches in some form or another. The reason why? single buffering makes very very beutiful organic shapes possible with very little polys. They render really fast, and are incredably smooth. Today I was playing with a static object in single buffering playing a video on it. The effect was visually very close to pix_biquad and pix_blur (smoother than pix_blur) without any extra computation. The frames smoothly get blended together as if the frames were actually being cross-fade. I was blown away, and realize I really have to try it with live video!
single buffering is, for me, one of the most important features, because it makes possible forms in time that would take a lot more processing power to do without it.
Anyhow I am the only one to use single buffering??
Ben
On Thursday, September 11, 2003, at 04:49 PM, cgc@humboldtblvd.com wrote:
Quoting ben@ekran.org:
heya all,
I was just tinkering with an old patch and I can't get single-buffering to work. It worked before...
I'm using Chris's bianry release for OSX from two weeks ago.
The window does not complain, seems to enter single-buffering mode. but when I try and draw something (by banging on a gemhead) I get nothing but black. Changing the gemwin color does not render either, all black...
Anyhow I hope it gets fixed as its something I often use.
There is no single buffering of GL contexts in OSX. Never has been and never will be. There's nothing we can do about this - it was a very early Apple design decision.
...uh, strictly speaking you're right, but I do remember a 'single buffer' mode working in earlier versions of the GEM OSX port...I think it was one of ben's early example patches: but as I recall, ya had to select single buffer before creating the window, which resulted in the buffer getting filled by all drawing events, which was cool as long as ya had a way to change your drawing colors/shapes/etc...I haven't tried this in awhile, so I'll look into it tonight...
l8r, jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
ben＠ekran.org -
cgc＠humboldtblvd.com -
Daniel Heckenberg -
tigital