Ah! Thank you very much. Yes, window.Window.dispatch_events() certain _does_ set it up properly so I can now use the active framebuffer as a 'drawing board' for alpha blitting. So for example, say I have 20,000x20,000 pixel texture.. it will take ``only'' 1302 blit_into()s. This also assumes that the 'destination' texture doesn't have any alpha in it :)
This is much better than 4096 blit_into()s for a single 64x64 pixel. Also, your suggestion of setting up a hidden window for use as this 'temporary buffer' isn't quite a good idea because I've tested it thoroughly and there's no obvious way to avoid that window having 'popped up' at some time, for a fraction of a second. Well, actually now that I think about it, I haven't tried it with dispatch_events() which might help.. but even so it would be much nicer if pyglet.image.Texture.blit_into() would call the necessary GL for alpha preservation. :> On Sep 8, 7:46 pm, "Alex Holkner" <[EMAIL PROTECTED]> wrote: > On 9/9/08, 3TATUK <[EMAIL PROTECTED]> wrote: > > > > > I understand how things are 'supposed' to work, but I still don't > > understand why a texture blit doesn't work 'normally', out of that > > context it's 'supposed' to work in. > > > Whatever you said about 'screen.clear()' is _utterly_ irrelevant and I > > will prove it with two examples: > > stampson was correct in identifying one of the problems in your code; > that you were relying on undefined framebuffer behaviour. > > The next two code examples you give fail because the OpenGL defaults > are not the same as pyglet's defaults, and you haven't given pyglet > the chance to set itself up. > > > > > #1 > > from pyglet import * > > the_color_red = image.SolidColorImagePattern( ( 255, 0, 0, 255 ) ) > > red_square = the_color_red.create_image( 100, 100 ) > > screen = window.Window() > > while True: > > screen.clear() > > red_square.blit( 0, 0 ) > > screen.flip() > > In this example (#1) you haven't called screen.dispatch_events() in > your run loop. This is needed firstly to avoid the application > hanging; and secondly to ensure the on_resize event is dispatched to > the window. The default on_resize handler is what sets up the window > coordinate system you're expecting (by default, OpenGL uses normalized > device coordinates in range [-1,1] on all axes). > > > > > > > #2 > > from pyglet import * > > the_color_blue = image.SolidColorImagePattern( ( 0, 0, 255, 255 ) ) > > blue_square = the_color_blue.create_image( 100, 100 ) > > screen = window.Window() > > screen.clear() > > blue_square.blit( 0, 0 ) > > box = image.get_buffer_manager().get_color_buffer().get_texture() > > > @screen.event > > def on_draw(): > > > screen.clear() > > box.blit( 0, 0 ) > > app.run() > > The problem is similar in this example (#2): you're operating on the > framebuffer before the default on_resize handler is called for the > first time. An easy fix is to call either screen.dispatch_events() or > screen.on_resize(screen.width, screen.height) straight away (or to > restructure your code such that all drawing is in response to the > on_draw event). > > To preempt any suggestion that on_resize should be called > automatically as soon as a window is created: this would generate > undesirable behaviour for people wanting to replace the default > on_resize handler with their own. > > Cheers > Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
