View Full Version : Texture Coordinates

03-23-2011, 09:16 PM

Can you give me some hint about accessing/changing texture coordinates? I'm using OverlayRenderComponent which loads and uses whole file as a texture. I'd like to keep many textures (with different size) in 1 file and simply set their uv coordinates. I found out that you have been using files like that in LooneyLadders game but I can't figure out how are they used in code.

Thanks in advance

03-24-2011, 06:52 AM
OverlayRenderComponent internally uses a SurfaceAnim object - this can do basic "grid" sprite separation:

void SetupAnim(int framesX, int framesY);
void BlitAnim(float x, float y, int frameX = 0, int frameY = 0, unsigned int rgba = MAKE_RGBA(255,255,255,255), float rotation=0, CL_Vec2f vRotationPt = CL_Vec2f(0,0));
void BlitScaledAnim( float x, float y, int frameX, int frameY, CL_Vec2f vScale, eAlignment alignment = ALIGNMENT_CENTER, unsigned int rgba = MAKE_RGBA(255,255,255,255), float rotation=0, CL_Vec2f vRotationPt = CL_Vec2f(0,0), bool flipX = false, bool flipY = false);

If you need more advance uv positioning you should use calculate the rect you want to use and blit it manually like this (available in a Surface or SurfaceAnim) :

void Surface::BlitEx(rtRectf dst, rtRectf src, unsigned int rgba = MAKE_RGBA(255,255,255,255), float rotation = 0, CL_Vec2f vRotatePt = CL_Vec2f(0,0)); //more advanced version, can do scaling and sub-texture blits

For the "custom src/dst rect" method (good for say, a texture atlas with custom sizes) it's impossible to do that kind of advanced stuff from inside an OverlayRenderComponent so you'd have to make your own component.

If you just need the basic grid-animation features, you CAN do that through the standard OverlayRenderComponent like this:

//texture is a 16 tile grid of 4X4
uint32 frameCountX = 4;
uint32 frameCountY = 4;

//let the component know the dimensions
pOverlayRenderComp->GetFunction("SetupAnim")->sig_function(&VariantList(frameCountX, frameCountY));

//now tell it which frame to use

uint32 frameX = 2;
uint32 frameY = 2;

Or, be lazy and use some functions from EntityUtils.cpp that do it for you:

SetupAnimEntity(pEntity, 4, 4, 2, 2);

You can also tell it to smoothly animate or loop by using other EntityUtil helpers like AnimateEntity, AnimateStopEntity, AnimateStopEntityAndSetFrame, AnimateEntitySetMirrorMode. They are basic, but it's all I used for Dungeon Scroll and LooneyLadders.

04-08-2011, 10:24 PM

I've implemented Texture Atlas's with proton sdk as a OverlayAtlasRenderComponent. The code's barely alpha, as I haven't yet tested it thoroughly, but it does work fairly well. It's supported by two classes: TextureAtlas, which contains all the atlas information, and TextureAtlasManager, which reads atlas files and caches the TextureAtlas's.

It substitutes entirely the OverlayRenderComponent, working both with "regular" textures and specially formatted texture atlases (simple text file description with corresponding texture). Animations have been partially tested and seem to work.

Only minor changes were needed in EntityUtils (mostly due to totalFramesX/Y and frameX/Y being dropped in favor of totalFrames / frame), I have simply commented out the functions I needed and re-implemented them in a project-specific file.

If anyone's interested, I can release the code. It's not generic enough yet (it expects that foo@0 foo@1 foo@2 etc. indicate 3 frames of texture "foo" in the atlas) but it might be useful to someone.

Just let me know :-)

04-09-2011, 02:20 PM
Hey pilu40000, nice, sounds useful.

I'd be interested in adding your atlasing code to the proton svn.

The best would be if there is a way for it to co-exist with the existing EntityUtils functions as not to break my existing games - it doesn't sound like that would be hard to do though.

04-09-2011, 10:15 PM
Okay, I'll keep working on it and once I make sure that the default OverlayRenderComponent behavior isn't broken with respect to the functions I don't really use (having the textures change color and do weird animation stuff, mostly), I'll send it to you. I'd also have to make sure there are no memory leaks (yeah, alfa stuff :-)

Nonetheless, the integration seems pretty seemless, but the changes are mostly linked to the disappearance of frameX / frameY.
Should I try to emulate such behaviour for complete retrocompatibility?
It would probably make more sense to create a new SetupAnim method (I had deleted the OverlayRender one) that programmatically generate an atlas and uses it in place of frameX/frameY.. and from there, edit EntityUtils. It's a bit more disruptive, but possibly cleaner in the end.

What's your opinion on the two solutions?

Also, I have basically rendered SurfaceAnim useless, as its BlitScaledAnim function was integrated into OverlayAtlasRenderComponent::OnRender. Is this the wrong approach with respect to your design? It seemed the most natural one but I'm not too convinced about it.

In any case, good job on proton sdk... the lack of documentation is a bit annoying at times but it had been a long time since I had this much fun working on this kind of modifications ;)

04-11-2011, 12:58 PM

Sounds good. 100% retro compatibility is pretty important I think, one idea is through the helper functions you modified into OverlayAtlasRenderComponent.cpp directly and leave the originals that work with OverlayRenderComponent in EntityUtils.cpp alone - could call it SetupAnimAtlas.

I've been throwing those global utilities in the .cpp/h of the bottom of the actual components lately and it seems to work ok, and doesn't break existing projects. (Would be nice if we don't force anybody to include OverlayAtlasRenderComponent.. I'm lazy so don't like fixing old projects.. :) )

If you get it where you're comfortable with a release please attach it anytime, hopefully with some code showing how to do a simple example with it.