search

haxenme / nme

A cross-platform native backend for Haxe projects
MIT License
479 stars 123 forks source link

NME on Android silently generates POT textures from NPOT images #433

Open bendmorris opened 7 years ago

bendmorris commented 7 years ago

This isn't necessarily a bug but probably could at least be configurable. When this is done automatically, my texture coordinates, based on the dimensions of the original non-power-of-two BitmapData, are then incorrect, resulting in distortion when rendered:

screen

(Notice the background image, 480x800, doesn't fill the whole screen as it should because of the extra padding)

So far I have seen this only on Android, not on desktop.

Is there either a way to disable this, or a way to get the dimensions of the bound texture so that texture coordinates can compensate for the difference in size?

hughsando commented 7 years ago

Nme checks for the ARB_texture_non_power_of_two. It is possible that the device supports nonpot but this extension check is not working. If it is a newer device, a bad check seems more likely than lack of actual support. But if it is an older device, it might be that it's just not supported. In this case I will need to add a function to get the actual texture size. What API are you using? BitmapData + opnegl? The DisplayObject api/tiles should know about the texture scaling.

bendmorris commented 7 years ago

This was on a Samsung Galaxy J7, so not very old. I'm using HaxePunk, which batches draw calls (consisting of BitmapData + screen/texture coords) which are rendered by an OpenGLView. Exposing the texture size on BitmapData so that we can adjust texture coords if there's a size difference would be a great solution. (For now the workaround is just to pad all my images to POT so it's not blocking me, but other HaxePunk users may run into this.)

thomasuster commented 6 years ago

Hey @bendmorris is this still an issue? If so, any chance you can reproduce this issue in simple raw NME project?