search

AdamsLair / duality

a 2D Game Development Framework
https://adamslair.github.io/duality
MIT License
1.41k stars 287 forks source link

Enable determination of maximimum texture/RenderTarget size supported by garphic board / driver #567

Open FaithlessQ opened 7 years ago

FaithlessQ commented 7 years ago

Summary

It should be possible to determine the maximum supported texture/RenderTarget size of the used graphic device.

Analysis [Feature Requests]

At the moment you can use whatever texture size you want, but when you render internally on this texture I don't get any drawings on it. The texture stays simply empty. There is also no exception here.

First, it will be helpful to throw an exception on an unsupported texture size. Second, the Duality-API should be extended to the maximum possible texture/RenderTarget size can determined.

Benefit is, that you no longer can do things which won't work and you can adjust your code to the limits of the device.

SirePi commented 7 years ago

I did a tentative implementation, but something went wrong while testing. OpenGL reported a max size of 16384 pixels on my machine; importing a square 8192px texture in the editor went well, but as soon as I dragged the 16384 (32 bit - 1GB uncompressed image) the whole system got stuck (including mouse cursor - completely non responsive), hard disk working at full power for over 15 minutes with no sign of movement.

Need to understand if it's an editor issue (hardly), my machine issue (not enough RAM? 4GB free when importing), or the value reported is the wrong one.

ilexp commented 7 years ago

This is kind of a bigger issue, both because it would make sense to provide a generalized "system capabilities / limits" API in Duality, which has yet to be designed, and also because it is not unheard of that OpenGL and graphics drivers lie about their capabilities or limits when queried via OpenGL API.

It will probably end up being a core API that is internally asking various backends for their opinion and may or may not transform some of the values before exposing them. Developers could then query that API in order to provide fallbacks or auto-adjust quality settings. In any case, there's definitely some design work to be done.

(Also, this specific issue of render target sizes could also be related to OpenGL viewport size limits, which are independent from texture size limits.)

FaithlessQ commented 7 years ago

(Also, this specific issue of render target sizes could also be related to OpenGL viewport size limits, which are independent from texture size limits.)

Indeed it may be an issue with the RenderTarget. In my case I had a texture and a RenderTarget with size 16384x128 pixel. The texture creation itself was successful and it could be drawn normally.

I edited the issue and added "RenderTarget".