I made some additional changes, and I think it makes sense now. There is a new _get_max_texture_size() function inside the atlas module, which both TextureAtlas and TextureBin validate against. If you request an impossible size, you will get back a the biggest size possible instead of crashing. I also changed the default width/height to 2048, after much searching and after seeing this: http://feedback.wildfiregames.com/report/opengl/feature/GL_MAX_TEXTURE_SIZE It looks like 99% of people have cards that can provide 2048, so this seemed reasonable. OpenGL 3.0 requires this size as well, so it seems a good choice.
The resource module now defaults to 512x512 as the maximum size for inclusion in the default TextureBin. Perhaps 1024 would also make sense. I'll have to consider that some more. -Ben On Wednesday, February 8, 2017 at 11:29:54 AM UTC+9, Benjamin Moran wrote: > > Hi Charles, you're right about that. I've been doing some tests with > 4096x4096 altases, and I've also increased those values in my tests out of > necessity. Currently, it's excluding images that are 1/2 of the atlas size. > That seems like a reasonable rule to keep for now. Long term, I think it > would be great to enhance the pyglet.image.atlas.Allocator class that is > used by the TextureAtlases. This is a nice little bit of pure-python code, > that could be improved by someone who likes math :) > > I've actually just had a thought, and I think it may make sense to put the > MAX_TEXTURE_SIZE checks into the TextureAtlas class itself. It could > default to 4096x4096, with an internal check to confirm what it's capable > of. If you can't get the atlas size you requested, it will simply return > whatever smaller atlas it's capable of (while possibly making a call to the > warning module). Having the code in there would mean that you can create a > TextureAtlas without having to think about the size. This could also mean > that your code may not crash if run on an older GPU. I'm going to explore > this idea. > > > On Wednesday, February 8, 2017 at 11:05:36 AM UTC+9, Charles wrote: >> >> Another consideration I saw when I was looking at the requirements is the >> 128 width OR height limit in the texture loading with a 256 sized Bin. >> >> If I load two 128x256 images, they would both fit in a 256x256 image, but >> in the code since it's > 128, they would each be given their own texture ID >> instead of being able to put it into 1. >> >> Maybe there needs to be smarter packing checks? >> >> >> On Monday, January 30, 2017 at 1:26:16 AM UTC-6, Benjamin Moran wrote: >>> >>> Hi guys, >>> >>> Thinking about this issue on the tracker: >>> https://bitbucket.org/pyglet/pyglet/issues/107/texture-atlas-sizes-too-small-for-most-gfx >>> Currently, the default texture size for a TextureAtlas is 256x256xRGBA. >>> The pyglet.resource module only places images into a TextureAtlas if it's >>> smaller than 128x128. >>> >>> Even for older cards, these numbers are very small. We should probably >>> bump this up so that it better fits current resolutions. This could cause >>> issues on some older laptop hardware, but maybe it can fall back to a lower >>> resolution if it throws an error. Doing a query for the maximum texture >>> size probably wouldn't work, since modern cards can support some >>> rediculously large textures. Perhaps we can do the following: >>> >>> 1. Raise the default size to something like 1024x1024, or 2048x2048, >>> (or?), and if there is a texture creation exception, we can fall back to >>> 512x512. >>> 2. Bump the minimum pyglet.resource size for adding to an Atlas to >>> 256x256 (or?). >>> >>> Any thoughts? >>> >> -- 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.
