Re: Created a layered order with pyglet
It's been a while since I've posted this thread. For any other users that ended up here, I did end up getting this working with the pyglet and zsprite, but it's a process and will require some careful design decisions. Hopefully this helps people. 1) If you plan to use integer numbers as your Z, you need to modify the default -1, 1 near/far values in your matrix, this includes the default Window and overriding the on_resize functions. Otherwise you need to set the matrix manually yourself before you draw your scene or just use floats to represent your Z axis (and enable subpixel on sprites). If you don't do this, they will not appear at all. 2) If any geometry intersects each other (same position on x, y, and z; or shares the same texture) you can get unpredictable behavior (sprites appearing out of order, weird collisions). Pyglet does not draw textures in order of creation (so texture 10 can render before texture 5 and 1, for instance) nor does it matter if they have a shared regular Group parent. So you cannot rely on what will show up without using OrderedGroups. This will force them to render as separate draw calls. The other method which works, if you want them in the same layer without collisions, is to give each sprite or entity it's own tiny z offset (0.01, 0.011, etc). This will ensure they no longer intersect. The downside is you have to enable subpixel access and have to be careful with sprite positions so they aren't between integers which can lead to more unpredictable behavior. I'm also not sure if float precision could be an issue, depending on how big your floats are, but something to think about. 3) Transparency (or I should say translucency) is the bigger problem. Most of the normal cases (alpha is 1 or 0) be alleviated with the alpha test, the bigger issue is when alpha is between 0 or 1. So if you have an object that fades out/in or a texture that has pixels between 0 and 1 alpha, requires it's drawn last. By drawn last, in this context means, either in the highest OrderedGroup or create a separate batch for it (for instance, opaque batch, transparent batch). So the opaque batch needs to been drawn already before you draw transparency. If you don't, it will have nothing to blend into except the glClearColor (usually black) and your blending will come out incorrectly. So setting a sprite to the transparent batch or group when it's opacity changes between 0 and 1 is all you need to do. I ended up doing a separate batch as the better approach (which also seemed faster performance wise rather than adding another orderedgroup), because that will alleviate another issue with transparency. Sure your transparent objects and opaque objects are now drawn correctly, but what if you have two transparent objects in the same batch? Now those may appear out of order... great. This may or may not be something your application has to deal with. If it does, you need to sort your transparent objects from furthest to closest. I believe you can do this with a batch as draw_subset, but requires you to pass the vertex lists of them. You will have to maintain your own list of vertex lists added into the transparent batch, because Pyglet does not store these after it's been allocated. Draw_subset is also a lot slower, so this only really works if you aren't going to have a ton of "translucent" objects. On Friday, April 5, 2019 at 1:57:04 AM UTC-5, Marcin Skibiński wrote: > > Hi, that would be probably the best. > But to be honest i still have some unexpected resoults when i mix > batch_groups and z-depth. On the other hand if users will go with the basic > -1,1 range of depth they have to remeber to set subpixel=true for each > sprite at the creation stage. > Unfortunately it looks that it is quite tricky to use it right now > > Pt., 5.04.2019, 08:05 użytkownik Benjamin Moran > napisał: > >> Hi Marcin, >> >> This is mostly because of how z coordinates are handled in OpenGL being >> opposite from what you might expect. >> At the moment, I don't plan to merge this in (because of the blending >> hurdles mentioned earlier in this thread). >> >> Maybe we could leave the ZSprite class in the examples folder in the >> repository? That way it's available for those >> who want it, and understand the tradeoffs. >> >> >> On Sunday, March 31, 2019 at 7:36:03 AM UTC+9, Marcin wrote: >>> >>> *when i have used the standard version it was opposite >>> >>> W dniu sobota, 30 marca 2019 23:35:05 UTC+1 użytkownik Marcin napisał: Good Afternoon, When i use the "new" sprite.py the Z ordering works nice. One change that i have noticed is that batch groups are drawn from bigger number to lower (when i have used . Do you plan to keep this that whey in the future versions? [image: Przechwytywanie.PNG] W dniu środa, 6 lutego 2019 02:46:19 UTC+1 użytkownik Benjamin Moran napisał: > > Sorry
Re: Image Grid [row,column] access
It is row, column. In your picture it is row 0 and column 3. Rows start bottom to top and columns are left to right. The rows start at the bottom, which is why it's 0. In most image processing, it's done top to bottom, but for OpenGL the bottom left is the reference (like a graph) so I'm sure that's why they did bottom up. As far as why it's not, [x, y]. I couldn't tell you, that's just the format that was decided. You should still be able to access in [y, x] form. On Thursday, March 28, 2019 at 6:43:43 PM UTC-5, Marcin wrote: > > Hi, > > I documentation (1.3 and 'latest') we can find that : > > "Images with more than one row can be accessed either as a > single-dimensional sequence, or as a (row, column) tuple" > > But then in our code we have to use (column,row) order instead. It is a > little confusing. > > Btw. Is there a reason why we do not access the grid in [x,y] -> > [row,column] way? > > > [image: pyg docs.PNG] > - Marcin > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Camera microstutter on movement
I think I see the issue but I'm unsure how to go about fixing it. To test I
went ahead and changed the value to do 3 pixel increments to move the
camera faster, then I went to implement interpolation, and printed the
offset during the render to see what values it was using.
What happens is the update portion of the camera updates quicker than the
draw, so therefore it will skip pixels during the interpolation. So for
example you jump to 3, use pyglet to schedule an update to move it 1, 2, 3.
The render portion will only see 1, 3, and skip one causing a small gap
that you may notice. The gaps increase the faster you move the offset.
On Sunday, January 15, 2017 at 1:12:53 AM UTC-6, Charles wrote:
>
> I have been trying to figure out what's wrong with my camera
> implementation, but I can't figure it out. It appears to be a microstutter,
> where the movement seems smooth then all of a sudden a a micropause or
> sometimes it even looks like it's a jerkiness. It's hard to see but it's
> there and my eye notices it. Thought I was going crazy but had another look
> at the panning image and noticed it too.
>
> I've tried just a barebones implementation and the issue still occurs,
> maybe someone can shed some light on this? I've tried two different
> graphics cards and two different monitors with the same results.
>
> Here is an example that causes it. Image just requires a 32x32 tile.
>
> import pyglet
> from pyglet.gl import glOrtho, glMatrixMode, glLoadIdentity,
> GL_MODELVIEW, glTranslatef, GL_PROJECTION
> window = pyglet.window.Window(800,600)
>
> group = pyglet.graphics.Group()
>
> batch = pyglet.graphics.Batch()
>
> image = pyglet.image.load("tile_test.png")
>
> global offsetX, offsetY
> offsetX, offsetY = 0, 0
>
> sprites = []
> for i in xrange(75):
> for j in xrange(75):
> if i % 2 or j % 2:
> sprite = pyglet.sprite.Sprite(image, x=i*32, y=j*32,
> batch=batch, group=group)
> sprites.append(sprite)
>
> @window.event
> def on_draw():
> window.clear()
>
> glMatrixMode(GL_PROJECTION)
> glLoadIdentity()
> glOrtho(0, 800, 0, 600, -1, 1)
>
> global offsetX, offsetY
>
>
> glTranslatef(-offsetX, -offsetY, 0)
>
> glMatrixMode(GL_MODELVIEW)
> glLoadIdentity();
>
> batch.draw()
>
> def pan_camera(dt, axis, val):
> if axis == "x":
> global offsetX
> offsetX += val
> else:
> global offsetY
> offsetY += val
>
> @window.event
> def on_key_press(symbol,modifiers):
> if symbol == pyglet.window.key.LEFT:
> pyglet.clock.schedule_interval(pan_camera, 1/60.0, "x", -1)
>
> elif symbol == pyglet.window.key.RIGHT:
> pyglet.clock.schedule_interval(pan_camera, 1/60.0, "x", 1)
>
> elif symbol == pyglet.window.key.UP:
> pyglet.clock.schedule_interval(pan_camera, 1/60.0, "y", 1)
>
> elif symbol == pyglet.window.key.DOWN:
> pyglet.clock.schedule_interval(pan_camera, 1/60.0, "y", -1)
>
> else:
> pyglet.clock.unschedule(pan_camera)
>
>
> pyglet.app.run()
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Camera microstutter on movement
I have been trying to figure out what's wrong with my camera
implementation, but I can't figure it out. It appears to be a microstutter,
where the movement seems smooth then all of a sudden a a micropause or
sometimes it even looks like it's a jerkiness. It's hard to see but it's
there and my eye notices it. Thought I was going crazy but had another look
at the panning image and noticed it too.
I've tried just a barebones implementation and the issue still occurs,
maybe someone can shed some light on this? I've tried two different
graphics cards and two different monitors with the same results.
Here is an example that causes it. Image just requires a 32x32 tile.
import pyglet
from pyglet.gl import glOrtho, glMatrixMode, glLoadIdentity, GL_MODELVIEW,
glTranslatef, GL_PROJECTION
window = pyglet.window.Window(800,600)
group = pyglet.graphics.Group()
batch = pyglet.graphics.Batch()
image = pyglet.image.load("tile_test.png")
global offsetX, offsetY
offsetX, offsetY = 0, 0
sprites = []
for i in xrange(75):
for j in xrange(75):
if i % 2 or j % 2:
sprite = pyglet.sprite.Sprite(image, x=i*32, y=j*32,
batch=batch, group=group)
sprites.append(sprite)
@window.event
def on_draw():
window.clear()
glMatrixMode(GL_PROJECTION)
glLoadIdentity()
glOrtho(0, 800, 0, 600, -1, 1)
global offsetX, offsetY
glTranslatef(-offsetX, -offsetY, 0)
glMatrixMode(GL_MODELVIEW)
glLoadIdentity();
batch.draw()
def pan_camera(dt, axis, val):
if axis == "x":
global offsetX
offsetX += val
else:
global offsetY
offsetY += val
@window.event
def on_key_press(symbol,modifiers):
if symbol == pyglet.window.key.LEFT:
pyglet.clock.schedule_interval(pan_camera, 1/60.0, "x", -1)
elif symbol == pyglet.window.key.RIGHT:
pyglet.clock.schedule_interval(pan_camera, 1/60.0, "x", 1)
elif symbol == pyglet.window.key.UP:
pyglet.clock.schedule_interval(pan_camera, 1/60.0, "y", 1)
elif symbol == pyglet.window.key.DOWN:
pyglet.clock.schedule_interval(pan_camera, 1/60.0, "y", -1)
else:
pyglet.clock.unschedule(pan_camera)
pyglet.app.run()
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Re: zsprites, or sorting sprites with the z buffer
It's been a long time since I checked this thread, but it looks like there has been quite a lot of progress since I last looked. I have tested the test branch and so far I have found the ordering to work without issues. I guess my questions on the latest changes are: 1) Are there any limitations for this? I know last I looked and tested the z sprite issues, there were some alpha and transparency issues. 2) Have you done any benchmarks on ordered groups compared to this method? How does having a lot of different sprites (hundreds) on various order levels affect performance? Thanks for your work guys! -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Traditional full screen support with Alt+Tab?
It's been a while since I have been able to program again, however I just tried this and the alt tab combination is not actually registered by pyglet (Windows 7). On Saturday, December 3, 2016 at 4:46:37 PM UTC-6, magu...@gmail.com wrote: > > What you can do is capture the alt-tab keys and use > window.set_fullscreen(False) to return to the desktops native resolution, > then you could use window.minimize() to miminize it to the task bar or just > leave it around. I've tried a few other approaches using > window.on_activate() and window.on_deactivate() for when the window gains > and looses focus, though I found the results were a little janky when it > came to scaling properly, others may be able to get better results. As it > stands in my current example when you tab back the window won't be in > fullscreen mode, but a simple alt+enter solves that. Example: > > import pyglet > from pyglet.window import key > from pyglet.gl import * > > class example(pyglet.window.Window): > def __init__(self): > super(example, self).__init__(640, 480, resizable=False, > fullscreen=True, caption="Test") > self.clear() > > #fullscreen aspect ratio > self.aspect = [self.width/640.0,self.height/480.0] > > pyglet.clock.get_fps() > self.fps_display = pyglet.clock.ClockDisplay() > > pyglet.clock.schedule_interval(self.update, .01) > > > def update(self,dt): > #draw screen > self.draw() > > > def draw(self): > self.clear() > self.fps_display.draw() > > > def on_key_press(self,symbol,modifiers): > if symbol == key.ESCAPE: > self.close() > #fullscreen toggle > if symbol == key.ENTER: > if modifiers & key.MOD_ALT: > #if fullscreen off, turn on and scale the screen > if self.fullscreen == False: > window.set_fullscreen(True) > > glScalef(window.width/640.0,window.height/480.0,1.0)#2.25x, > 1.875y > self.aspect[0] = window.width/640.0 > self.aspect[1] = window.height/480.0 > print 'PONG',self.aspect > #if its on, turn it off and un-scale the screen > else: > window.set_fullscreen(False) > glScalef((window.width/640.0)/self.aspect[0],(window. > height/480.0)/self.aspect[1],1.0) > > #tab out of fullsceen > if symbol == key.TAB: > if modifiers & key.MOD_ALT: > if self.fullscreen == True: > window.set_fullscreen(False) > glScalef((window.width/640.0)/self.aspect[0],(window. > height/480.0)/self.aspect[1],1.0) > self.minimize() > > > if __name__ == '__main__': > window = example() > pyglet.app.run() > > > > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: zsprites, or sorting sprites with the z buffer
I would be very interested to see these changes and additions to test out. One thing with the texture atlas containing everything, many graphics cards have max texture size limits, would a change like this cause problems then? On Monday, October 3, 2016 at 3:17:08 PM UTC-5, Josh wrote: > > I have the code with some bug fixes from after I sent it to you. It's not > in a public repository right now but I can put it somewhere. It's still not > thoroughly tested, it just worked for my project. > > Call for call, I think there isn't much difference between DrawArrays and > DrawElements (or if there is, it's on the GPU side). The huge advantage of > DrawElements is that you can render your entire game with just the one > call, and do it in whatever order you want. In current pyglet, when you > call batch.draw(), pyglet makes a separate DrawArrays call for each > separate texture that needs to be rendered. > > What if we subclass VertexDomain with OrderedVertexDomain, create a > ZSpriteGroup class, and create a ZSprite class? That keeps backwards > compatibility. ZSprites would be initialized with a fixed ZSpriteGroup. > Unlike normal groups, ZSpriteGroups would maintain a TextureAtlas, a sorted > list of indices, and an OrderedVertexDomain, and would not allow children. > Batch methods would be modified so the batch always associates a ZGroup's > domain, and only that domain, with that group. This requires changes to > Batch.migrate, Batch._get_domain, Batch._add_group that explicitly check if > a group is a ZSpriteGroup. > > > On Monday, October 3, 2016 at 5:02:59 AM UTC-5, Benjamin Moran wrote: >> >> Thanks for the lengthy writeup, Josh. It seems like this is one of those >> issues that has no "perfect" solution. I was able to find the code you >> shared before, and it looks like a nice bit of work. Do you still have an >> active branch of this somewhere? >> I'm also curious what your experience with glDrawArrays vs glDrawElements >> is, performance wise. Most of the talk on the subject is pretty old, so I'm >> wondering just what the differnce really is. >> >> Not breaking code would be ideal. I think as long as there are fallbacks >> (even if slow fallbacks) would be a requirement, so as not to regress in >> functionality. Additionally, not to impose any behaviour that would >> negatively affect people who don't even use the sprite class at all. >> >> >> >> On Monday, October 3, 2016 at 4:30:07 AM UTC+9, Josh wrote: >>> >>> Hi all, >>> >>> Been a while since I dealt with this, but here is the core of the >>> solution I came up with. Currently VertexDomain uses glDrawArrays to render >>> sprites. This requires the correct texture for each sprite has to be bound >>> before it can be rendered. So if you have, say, 100 distinct images being >>> rendered as sprites, that's (usually) 100 glDrawArrays calls per frame. >>> Also, all sprites sharing a texture are always rendered simultaneously if >>> they belong to the same batch. >>> >>> To solve this problem, I created a new method draw_ordered for >>> VertexDomain that uses glDrawElements. This allows you to pass a list of >>> indices that specifies the order the elements will be rendered in. However, >>> because you have to choose one texture to have bound before calling >>> DrawElements, everything in the domain still has to have a common texture. >>> So to make this solution work,* all sprites in a batch must take their >>> textures as regions from a single master textur**e *(in pyglet, >>> TextureAtlas was convenient for this; it automatically sets the texture >>> coordinates for the sprite vertices correctly). >>> >>> I still think the huge gains in efficiency make it worth changing to >>> glDrawArrays. To make it work with the existing pyglet framework, I created >>> a new rendering hierarchy in parallel with the existing pyglet methods: >>> OrderedBatch, OrderedSprite, AtlasAnimation, AnimationRegion. But a better >>> solution would be to have a singleton TextureAtlas. Getting images through >>> the pyglet resource tools would automatically enter them in the singleton, >>> and most users would not have to worry about the change in rendering >>> method. But definitely some code would break. >>> >> -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Created a layered order with pyglet
I apologize for the delay, I didn't really check back here after there
wasn't much activity for a few weeks and figured I wouldn't be able to do
what I needed.
Thanks for taking the time to test this! I did not realize the sprite group
resets things as well. I did try it and it does seem a lot better than what
I had implemented. However, the same alpha issues do arise; some things on
the same z level will have proper alpha while other objects may not. I did
have to change to 0.1 instead of 0.5 for it to even show up at all. I
suspect this might be part of the opacity stuff you were talking about.
On Friday, September 30, 2016 at 9:30:19 AM UTC-5, Benjamin Moran wrote:
>
> Hi Charles,
>
> I have a zsprite branch (that probably has the same changes that you've
> already made) that can be found here:
> https://bitbucket.org/treehousegames/pyglet/branch/z_sprite
>
> The OpenGL blending/code you posted looks fine, but it might be getting
> overridden by the SpriteGroup (pyglet.sprite.SpriteGroup) . My branch is
> not yet complete, but I've also modified the SpriteGroup class so that it's
> at least working OK for me. it only works right for simple
> transparent/solid alpha (not opacity), but it does render all sprites in
> the correct z order. Give it a try and see if it works for you. The z
> scale is set to be from -255 to 255.
>
> I will probably fix the opacity stuff at some point...
>
>
>
> On Thursday, September 1, 2016 at 8:28:43 AM UTC+9, Charles wrote:
>>
>> I am using a standard blending of GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA.
>> Here is an example of what doesn't work:
>>
>> import pyglet, random
>> from pyglet.gl import *
>>
>> window = pyglet.window.Window(800,600, vsync=False)
>>
>> fps = pyglet.clock.ClockDisplay()
>>
>> groups = []
>> group = pyglet.graphics.Group()
>>
>> tileImages = [pyglet.image.load("tile_test.png")]
>>
>> batch = pyglet.graphics.Batch()
>>
>> fadedImage = pyglet.image.load("wide-shadow-faded.png").get_texture()
>> playerImage = pyglet.image.load("player.png").get_texture()
>> treeImage = pyglet.image.load("tree.png").get_texture()
>>
>>
>> glEnable(GL_DEPTH_TEST)
>> glEnable(GL_BLEND)
>> glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
>> glAlphaFunc ( GL_GREATER, 0.1 ) ;
>> glEnable ( GL_ALPHA_TEST ) ;
>>
>> tiles = []
>> for i in range(40):
>> for j in range(40):
>> tile = pyglet.sprite.Sprite(random.choice(tileImages),
>> batch=batch, x=i*24, y=j*24, usage='static', group=group, subpixel=True)
>> tiles.append(tile)
>>
>> print len(tiles)
>>
>>
>> player = pyglet.sprite.Sprite(playerImage, batch=batch, group=group,
>> x=10, y=10, z=0.3, subpixel=True)
>>
>> tree = pyglet.sprite.Sprite(treeImage, batch=batch, group=group, x=30,
>> y=30, z=0.5, subpixel=True)
>>
>> fadedSprite = pyglet.sprite.Sprite(fadedImage, batch=batch, group=group,
>> x=100, y=100, z=0.5, subpixel=True)
>>
>>
>> @window.event
>> def on_draw():
>> window.dispatch_events()
>> window.clear()
>> batch.draw()
>> fps.draw()
>>
>> pyglet.app.run()
>>
>>
>>
>> The 'fadedImage' is basically just any image that has pixels of alpha
>> between 0 and 1 like a fade. If you take out the player and sprite, it may
>> sometimes show up properly, but if you reload it may change to all black,
>> it's never consistent.
>>
>>
>> On Tuesday, August 30, 2016 at 11:53:29 PM UTC-5, magu...@gmail.com
>> wrote:
>>>
>>> In what way are you blending objects? The source of that issue could be
>>> a number of things, could you provide a working example? Generally you
>>> should only have to update each visible objects vertices and Z axis every
>>> update cycle.
>>>
>>> Also, you can increase the depth range of the Z axis by setting up a
>>> custom config:
>>>
>>> config = Config(sample_buffers=1, samples=4, depth_size=1000,
>>> double_buffer=True)
>>>
>>> class Example(pyglet.window.Window):
>>> def __init__(self):
>>> super(Example, self).__init__(640, 480, resizable=True,
>>> fullscreen=False, caption="Example", config=config)
>>>
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Re: Created a layered order with pyglet
I am using a standard blending of GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA.
Here is an example of what doesn't work:
import pyglet, random
from pyglet.gl import *
window = pyglet.window.Window(800,600, vsync=False)
fps = pyglet.clock.ClockDisplay()
groups = []
group = pyglet.graphics.Group()
tileImages = [pyglet.image.load("tile_test.png")]
batch = pyglet.graphics.Batch()
fadedImage = pyglet.image.load("wide-shadow-faded.png").get_texture()
playerImage = pyglet.image.load("player.png").get_texture()
treeImage = pyglet.image.load("tree.png").get_texture()
glEnable(GL_DEPTH_TEST)
glEnable(GL_BLEND)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
glAlphaFunc ( GL_GREATER, 0.1 ) ;
glEnable ( GL_ALPHA_TEST ) ;
tiles = []
for i in range(40):
for j in range(40):
tile = pyglet.sprite.Sprite(random.choice(tileImages), batch=batch,
x=i*24, y=j*24, usage='static', group=group, subpixel=True)
tiles.append(tile)
print len(tiles)
player = pyglet.sprite.Sprite(playerImage, batch=batch, group=group, x=10,
y=10, z=0.3, subpixel=True)
tree = pyglet.sprite.Sprite(treeImage, batch=batch, group=group, x=30,
y=30, z=0.5, subpixel=True)
fadedSprite = pyglet.sprite.Sprite(fadedImage, batch=batch, group=group,
x=100, y=100, z=0.5, subpixel=True)
@window.event
def on_draw():
window.dispatch_events()
window.clear()
batch.draw()
fps.draw()
pyglet.app.run()
The 'fadedImage' is basically just any image that has pixels of alpha
between 0 and 1 like a fade. If you take out the player and sprite, it may
sometimes show up properly, but if you reload it may change to all black,
it's never consistent.
On Tuesday, August 30, 2016 at 11:53:29 PM UTC-5, magu...@gmail.com wrote:
>
> In what way are you blending objects? The source of that issue could be a
> number of things, could you provide a working example? Generally you should
> only have to update each visible objects vertices and Z axis every update
> cycle.
>
> Also, you can increase the depth range of the Z axis by setting up a
> custom config:
>
> config = Config(sample_buffers=1, samples=4, depth_size=1000,
> double_buffer=True)
>
> class Example(pyglet.window.Window):
> def __init__(self):
> super(Example, self).__init__(640, 480, resizable=True, fullscreen
> =False, caption="Example", config=config)
>
>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Created a layered order with pyglet
I have been working on something for a while now and have been trying to figure out a layered order properly. I have searched these forums for recommendations and read numerous articles but none of the proposed solutions have worked out. Basically I want a layered order based on the Y value without having to constantly create a new batch, re-add sprites, and sort everytime something needs to move. This way the player may appear between things depending on it's position. Here is a picture of what I mean: http://html.net/tutorials/css/figure020.gif 1) Tried implementing depth testing for a z-order by modifying pyglet a little (adding a third float for z), but found problems with alpha blending. You have to make sure the ones being blended are rendering last or they sometimes appear black. Basically you end up sorting them anyways since new objects get added to the screen and you need those to be removed and added back. This also is kind of impossible in a tile based system as some of the tiles may have some alpha blending. 2) Tried using OrderedGroup. In this context it would mean I would need an OrderedGroup for each Y axis. Unfortunately this brings the FPS down to unusable levels and I am guessing is removing the point of a batch. 3) I've tried sorting the objects before adding to the batch, which works, but when you have to make the player move you have to delete it from the batch, sort sprites, then create a new batch and migrate all of the current sprites over in the right order. This creates a lot of overhead and performance problems whenever something on the screen moves or if many things move. I really would like to use the batch system so I can try out shaders and get the benefits of those, instead of fixed function opengl, but in every test case I've done it's slower. I feel like I am over complicating something that should be very simple; is there another method I am missing? -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Setting RGBA for sprite regions
The game is a top down view, so I'm not sure the horizontal surface still applies. (Honestly not even sure how I would do this in the first place.) The problem is, I need it to blend into the background water image. Here is what I am doing right now: http://i.imgur.com/rl9FY3o.jpg It's separated into the head and body and I get regions to separate them into the two sprites. I basically have to get all the sprites in the water, then do some operations to alter the regions and set the alpha/rgb. I did test with the overlay mentioned in a previous post, but I couldn't get an effect I was looking for. My way works, but it just seems like such a hack at the moment and doesn't support partial coverage yet. Maybe this is the proper way? I don't really feel too comfortable with 3D OpenGL yet so I am just using an orthographic projection so I'm sure that limits my options unfortunately. On Sunday, May 29, 2016 at 9:14:52 PM UTC-5, Benjamin Moran wrote: > > I think Greg has the right idea. If you're not keen on going 3D, then I'm > sure there are other ways to fake the effect in 2D. If you happened to have > a link to a picture showing the effect you're trying to create, it might > help with the suggestions. > -Ben > > > On Monday, May 30, 2016 at 4:01:40 AM UTC+9, Charles wrote: >> >> I was actually planning on doing this, but the ground and water tiles are >> 32x32 and the player sprites are smaller so it would appear totally >> submerged. I am trying to create some 'fake' 2D perspective on how high the >> water depth looks in relation to the player. The lower half of the >> character may be 12 pixels and I would want that part considered >> 'submerged' when it is over the water tile rather than the whole player. >> >> On Saturday, May 28, 2016 at 7:06:21 PM UTC-5, Elliot Hallmark wrote: >>> >>> I think they meant let the water have an alpha channel of like .5 or >>> something, and draw the character behind it. No extra sprites/textures >>> >> >> = >> >> Oh I see, so a duplicate sprite overlayed that I can just manipulate the >> height, RGBA, blending, and can just offset it. I guess that's another way, >> seems similar to what I'm doing but without all the expensive cropping of >> textures constantly. Not sure why that never occurred to me. >> >> I did also want to look into modifying pixel data as well, so your >> example helps out quite a lot. Thanks for your input! >> >> On Saturday, May 28, 2016 at 6:42:40 PM UTC-5, magu...@gmail.com wrote: >>> >>> I believe what he's suggesting is leaving your original sprite intact, >>> and having a second texture with a transparent alpha channel rendered on >>> top to act as a water overlay rather than going through the trouble of >>> splitting one sprite in two all the time. Basically a form of cel animation >>> overlay, which could involve blending or color keying, depending. >>> >>> If strictly talking about modifying pixel data over specific regions, >> one method i've played with would be using Numpy Array operations to >> dynamically modify pixel data. I've attached an example script. >> > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Setting RGBA for sprite regions
I was actually planning on doing this, but the ground and water tiles are 32x32 and the player sprites are smaller so it would appear totally submerged. I am trying to create some 'fake' 2D perspective on how high the water depth looks in relation to the player. The lower half of the character may be 12 pixels and I would want that part considered 'submerged' when it is over the water tile rather than the whole player. On Saturday, May 28, 2016 at 7:06:21 PM UTC-5, Elliot Hallmark wrote: > > I think they meant let the water have an alpha channel of like .5 or > something, and draw the character behind it. No extra sprites/textures > = Oh I see, so a duplicate sprite overlayed that I can just manipulate the height, RGBA, blending, and can just offset it. I guess that's another way, seems similar to what I'm doing but without all the expensive cropping of textures constantly. Not sure why that never occurred to me. I did also want to look into modifying pixel data as well, so your example helps out quite a lot. Thanks for your input! On Saturday, May 28, 2016 at 6:42:40 PM UTC-5, magu...@gmail.com wrote: > > I believe what he's suggesting is leaving your original sprite intact, and > having a second texture with a transparent alpha channel rendered on top to > act as a water overlay rather than going through the trouble of splitting > one sprite in two all the time. Basically a form of cel animation overlay, > which could involve blending or color keying, depending. > > If strictly talking about modifying pixel data over specific regions, one method i've played with would be using Numpy Array operations to dynamically modify pixel data. I've attached an example script. -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Setting RGBA for sprite regions
I'm not sure I've heard of that, is this a form of blending? Do you know of any examples where this is done? On Saturday, May 28, 2016 at 11:57:58 AM UTC-5, Serdar Yegulalp wrote: > > Sounds like a better way to do this would be to have your environmental > sprites simply be composited on top of the character sprites by way of an > alpha channel. > -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
Re: Pyglet culling destroys FPS
Perfect, the addition of
glEnable(GL_ALPHA_TEST)
glAlphaFunc(GL_GREATER, .1)
Seemed to be the solution! I appreciate the help, I can continue from here.
@Elliot, Sorry, it seems to default me to an old account when coming here
for some reason.
On Tuesday, May 3, 2016 at 5:38:55 PM UTC-5, magu...@gmail.com wrote:
>
> That may be more of an OpenGL question, and may have to do with rendering
> orders in memory. Unfortunately I can't offer much more than that having
> not played with depth testing to any great degree. From the tests i've
> done, provided I stay within the depth ranges of 1.0 - 0.0, it seems to
> render layers and alpha blending fine. Depending on your needs that may be
> enough, but otherwise unless someone else happens along with a more clear
> answer, you may want to start looking into lower level OpenGL calls.
>
> Here's the current test script (assuming the images already have
> transparency applied):
>
> import pyglet
> from pyglet.gl import *
>
> class group(pyglet.graphics.OrderedGroup):
> def set_state(self):
> if self.order == 0:
> glBindTexture(GL_TEXTURE_2D, texture.id)
> elif self.order == 1:
> glBindTexture(GL_TEXTURE_2D, texture2.id)
>
> window = pyglet.window.Window(640,480)
>
> glEnable(GL_DEPTH_TEST)
>
> gl.glEnable(GL_BLEND)
> gl.glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
>
> glEnable(GL_ALPHA_TEST)
> glAlphaFunc(GL_GREATER, .1)
>
> rendered_sprites = []
>
> batch = pyglet.graphics.Batch()
>
> batch_idle = pyglet.graphics.Batch()
>
> texture = pyglet.image.load('test3.png').get_texture()
>
> texture2 = pyglet.image.load('test4.png').get_texture()
>
> background = pyglet.image.load('background.png').get_texture()
>
> rendered_sprites.append(batch.add(4, GL_QUADS, group(0),
> ('v3f/static', (0.0,0.0,0.1, 32.0,0.0,
> 0.1, 32.0,32.0,0.1, 0.0,32.0,0.1)),
> ('t3f/static', texture.tex_coords)))
>
> rendered_sprites.append(batch.add(4, GL_QUADS, group(1),
> ('v3f/static', (16.0,0.0,0.1, 48.0,0.0,
> 0.1, 48.0,32.0,0.1, 16.0,32.0,0.1)),
> ('t3f/static', texture2.tex_coords)))
>
>
> @window.event
> def on_draw():
> window.clear()
> background.blit(0,0)
> glEnable(GL_TEXTURE_2D)
> batch.draw()
> glDisable(GL_TEXTURE_2D)
>
> @window.event
> def on_key_press(symbol,modifiers):
> if symbol == pyglet.window.key.SPACE:
> if round(rendered_sprites[1].vertices[2],2) == 0.1:
> for a in xrange(2,12,3):
> rendered_sprites[1].vertices[a] = 1.0
> else:
> for a in xrange(2,12,3):
> rendered_sprites[1].vertices[a] = 0.1
>
> pyglet.app.run()
>
>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Re: Pyglet culling destroys FPS
Sorry, I had left for vacation and just got back. I have experimented with
depth test before, but there were many problems with alpha and textures.
The problems were really random and varied. Sometimes, the textures would
show black where the alpha, sometimes they would load properly depending on
the order they were added to the batch.
How were you able to solve the weird behavior regarding depth testing and
alpha?
On Friday, April 29, 2016 at 5:16:13 PM UTC-5, magu...@gmail.com wrote:
>
> Adding/removing for ordering is unnecessary, you just need to enable depth
> testing and change the relevant textures z coordinates (between 1.0 to 0.0):
>
> import pyglet
> from pyglet.gl import *
>
> class group(pyglet.graphics.OrderedGroup):
> def set_state(self):
> if self.order == 0:
> glBindTexture(GL_TEXTURE_2D, texture.id)
> elif self.order == 1:
> glBindTexture(GL_TEXTURE_2D, texture2.id)
>
> window = pyglet.window.Window(640,480)
>
> glEnable(GL_DEPTH_TEST)
>
> rendered_sprites = []
>
> batch = pyglet.graphics.Batch()
>
> batch_idle = pyglet.graphics.Batch()
>
> texture = pyglet.image.load('test.png').get_texture()
>
> texture2 = pyglet.image.load('test2.png').get_texture()
>
> rendered_sprites.append(batch.add(4, GL_QUADS, group(0),
> ('v3f/static', (0.0,0.0,0.0, 32.0,0.0,
> 0.0, 32.0,32.0,0.0, 0.0,32.0,0.0)),
> ('t3f/static', texture.tex_coords)))
>
> rendered_sprites.append(batch.add(4, GL_QUADS, group(1),
> ('v3f/static', (16.0,0.0,0.0, 48.0,0.0,
> 0.0, 48.0,32.0,0.0, 16.0,32.0,0.0)),
> ('t3f/static', texture2.tex_coords)))
>
>
> @window.event
> def on_draw():
> window.clear()
> glEnable(GL_TEXTURE_2D)
> batch.draw()
> glDisable(GL_TEXTURE_2D)
>
> @window.event
> def on_key_press(symbol,modifiers):
> if symbol == pyglet.window.key.SPACE:
> if rendered_sprites[1].vertices[2] == 0.0:
> for a in xrange(2,12,3):
> rendered_sprites[1].vertices[a] = 1.0
> else:
> for a in xrange(2,12,3):
> rendered_sprites[1].vertices[a] = 0.0
>
> pyglet.app.run()
>
> Pyglet also has multi-texturing support, if your inclined to use multiple
> textures per surface.
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Re: Pyglet culling destroys FPS
Hey thanks for the replies! I will certainly try both alternatives to see
which has the best results. I wouldn't have thought to just add the data
manually, I figured there might of been a built in function but that should
work since sprites also list their vertices.
Now that I have my tilemap, is this the same way people handle ordering
their movable sprites?
In an isometric or RTS type game, each object needs to overlap the object
above it depending on the position. For instance, all moveable objects must
be able to change their order when their position changes; so, for example,
they can appear behind objects, like trees, then they appear in front of
them as they move down. Or when you have many trees overlapping eachother
to create a forest effect. How is this accomplished in Pyglet? I certainly
can't use hundreds of ordered groups. (Seems it has problems with even just
a handful of ordered groups, even.) Is it the same concept of deleting them
from batch, put them in a list, sorting that list on the Y criteria, then
adding back to a batch one by one? Thanks.
On Thursday, April 28, 2016 at 4:09:53 PM UTC-5, magu...@gmail.com wrote:
>
> You can keep a list of the sprites for adding and removing them from
> batches:
>
> import pyglet
> from pyglet.gl import *
>
> window = pyglet.window.Window(640,480)
>
> rendered_sprites = []
>
> batch = pyglet.graphics.Batch()
>
> texture = pyglet.image.load('test.png').get_texture()
>
> @window.event
> def on_draw():
> window.clear()
> batch.draw()
>
> @window.event
> def on_key_press(symbol,modifiers):
> if symbol == pyglet.window.key.RETURN:
> rendered_sprites.append(batch.add(4, GL_QUADS, None,
> ('v2f/static', (0.0,0.0, 32.0,
> 0.0, 32.0,32.0, 0.0,32.0)),
> ('t3f/static', texture.
> tex_coords)))
>
> if symbol == pyglet.window.key.SPACE:
> rendered_sprites.pop(0).delete()
>
> pyglet.app.run()
>
> You could also create two separate batches, one for active rendering and
> one for idle storage, then migrate selected sprites from one batch to
> another, though it may not be as efficient as other methods:
>
> import pyglet
> from pyglet.gl import *
>
> window = pyglet.window.Window(640,480)
>
> rendered_sprites = []
>
> batch = pyglet.graphics.Batch()
>
> batch_idle = pyglet.graphics.Batch()
>
> texture = pyglet.image.load('test.png').get_texture()
>
> rendered_sprites.append(batch.add(4, GL_QUADS, None,
> ('v2f/static', (0.0,0.0, 32.0,0.0, 32.0,
> 32.0, 0.0,32.0)),
> ('t3f/static', texture.tex_coords)))
>
> @window.event
> def on_draw():
> window.clear()
> batch.draw()
>
> @window.event
> def on_key_press(symbol,modifiers):
> if symbol == pyglet.window.key.RETURN:
> batch.migrate(rendered_sprites[0],pyglet.gl.GL_QUADS, None,
> batch_idle)
>
> if symbol == pyglet.window.key.SPACE:
> batch_idle.migrate(rendered_sprites[0],pyglet.gl.GL_QUADS,
> None,batch)
>
> pyglet.app.run()
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pyglet-users+unsubscr...@googlegroups.com.
To post to this group, send email to pyglet-users@googlegroups.com.
Visit this group at https://groups.google.com/group/pyglet-users.
For more options, visit https://groups.google.com/d/optout.
Re: Texture bleedthrough issues
Hate to keep replying to myself, but figured I'd post this update. I create my tiles by using a tileset atlas and using image grid to slice it into 32x32 squares then use those for my tiles. If I stop using the atlas (and pyglets TextureGrid), and just load the texture as a single 32x32 texture file, the issue completely disappears. So clearly the issue is somewhere in pyglet? Where do I go from here? -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users+unsubscr...@googlegroups.com. To post to this group, send email to pyglet-users@googlegroups.com. Visit this group at https://groups.google.com/group/pyglet-users. For more options, visit https://groups.google.com/d/optout.
