Texture atlas generation about khamake HOT 9 CLOSED

Don't want to. Atlases will become mostly obsolete when I finally get to adding mutlitexture and texture array support in G2onG4 plus atlases are problematic with mipmaps which I want to support, too. Sorry.

from khamake.

Image object have rectangle info in runtime

That's most likely unnecessary bloat for every image, even if it isn't on an atlas.

Add build time atlas generator from npm with some define

You should be able to add that already via project callbacks in your khafile.

And people don't need to change drawImage/drawSubImage/etc calls to Atlas.drawImage(g, "imageId", x, y) or something.

using MyG2AltasExtension;
g2.drawAtlasImage(...);

Is actually much clearer to me.

Thoughts?

Sry, doesn't belong here IMO.

from khamake.

@sh-dave it only adds var x:Int; var y:Int offset in image object if there is atlas define, i think, and this little overhead should be optional. With personal Atlas class you still need to change every api, based on kha.Image and pass instead imageId:String and rectangle array/object. Even without mipmap support this feature will be useful for 2D with opengl < 3.1, where multitexturing has appeared?

from khamake.

Multitexturing is available in ES 2 which can mitigate the need for atlases greatly. ES 3 supports texture arrays which makes atlases completely obsolete - and that's 80% of current Android devices and basically 100% of everything else (minus some Linux systems).

from khamake.

Cool, I'll be waiting for this stuff. Is there a separate issue?

from khamake.

For something decent it would also need at least: w, h; additionally cropped variants for x, y, w, h and maybe even rotation.

With personal Atlas class you still need to change every api, based on kha.Image and pass instead imageId:String and rectangle array/object.

I don't get what you mean by that. Just call g2.drawYourStuff(region, x, y); instead of g2.drawImage(img, x, y)?;

from khamake.

Aren't texture arrays limited to same size textures?

from khamake.

True, I tend to forget that. I'll see what I can come up with when I combine texture arrays and multitexturing. I'll probably start with bindless textures and work my way down.
And no, there is no issue about that other than all the issues in/with my head.

from khamake.

Just call g2.drawYourStuff(region, x, y); instead of g2.drawImage(img, x, y)?;

Yep, but i get images sometimes with Assets.images.get("imageId"), so you also need StringMap of regions.

kha.Image already have h/w, so that's enough. True about rotation for complex atlases tho. Example of implementation:

#if kha_atlas
public static function drawImage(g:Graphics, image:Image, x:Float, y:Float):Void {
	g.drawSubImage(atlas, x, y, // real drawSubImage for short
		image.x, image.y, image.width, image.height
	);
}

public static function drawSubImage(
	g:Graphics, image:Image, x:Float, y:Float,
	sx:Float, sy:Float, sw:Float, sh:Float
):Void {
	g.drawSubImage( // real drawSubImage for short
		atlas, x, y,
		image.x + sx, image.y + sy,
		sw, sh
	);
}
#end

Ideally, with #kha_atlas, all Image objects refer to the data of a single image, but have their x / y / width / height. Anyway, I'll try to use khamake callbacks and add x / y to the imageDescription files, but using a separate rendering class.

from khamake.