On Saturday, 18 June 2016 at 00:56:57 UTC, Joerg Joergonson wrote:
On Friday, 17 June 2016 at 14:48:22 UTC, Adam D. Ruppe wrote:
[...]
Yes, same here! Great! It runs around 122MB in x86 and 107MB
x64. Much better!
[...]
Yeah, strange but good catch! It now works in x64! I modified
it to to!wstring(title).dup simply to have the same title and
classname.
[...]
I have the opposite on memory but not a big deal.
[...]
I will investigate this soon and report back anything. It
probably is something straightforward.
[...]
I found this on non-power of 2 textures:
https://www.opengl.org/wiki/NPOT_Texture
https://www.opengl.org/registry/specs/ARB/texture_non_power_of_two.txt
It seems like it's probably a quick and easy add on and you
already have the padding code, it could easily be optional(set
a flag or pass a bool or whatever).
it could definitely same some serious memory for large textures.
e.g., a 3000x3000x4 texture takes about 36MB or 2^25.1 bytes.
Since this has to be rounded up to 2^26 = 67MB, we almost have
doubled the amount of wasted space.
Hence, allowing for non-power of two would probably reduce the
memory footprint of my code to near 50MB(around 40MB being the
minimum using uncompressed textures).
I might try to get a working version of that at some point.
Going to deal with the cpu thing now though.
Thanks again.
Never mind about this. I wasn't keeping in mind that these
textures are ultimately going to end up in the video card memory.
I simply removed your nextpowerof2 code(so the width and height
wasn't being enlarged) and saw no memory change). Obviously
because they are temporary buffers, I guess?
If this is the case, then maybe there is one odd temporary still
hanging around in png?
