Source Image Size
by Doc308 · in Torque 2D Beginner · 02/20/2013 (6:53 am) · 12 replies
I've been tinkering around getting Spriter files loaded into MIT, and hit my first engine snag. In Legacy T2D I could find the original image size by calling upon the function within ImageMapDataBlock -> getSrcBitmapSize(). Of course all DataBlock information has been scrapped now. In place of it is the Taml system with Assets. I've looked at the ImageAsset code, and the "closest" thing I see is getImageSize(), however, all this really does is pull in what is read from the Taml grab, so if the size is set, it will extract the size from those set parameters. What I need is the Source information, it does not appear to be available as a Script utility function anymore.
I'm trying to do this in script only as a first pass. I still see calls in gBitmap for source information, and it was based upon Texture sizes, etc.. Also, the new libPng library houses some size information (though nothing is available for me to extract the source size). Is there any other method to get the source size?
Or do I need to make a pull request to get the appropriate Console call re-asserted?
I'm trying to do this in script only as a first pass. I still see calls in gBitmap for source information, and it was based upon Texture sizes, etc.. Also, the new libPng library houses some size information (though nothing is available for me to extract the source size). Is there any other method to get the source size?
Or do I need to make a pull request to get the appropriate Console call re-asserted?
#2
1. acquireAsset is a costly function, so it's not recommended you do it often
2. Always call releaseAsset afterwards
02/20/2013 (9:20 am)
%asset = AssetDatabase.acquireAsset("ToyAssets:jungleSky");
%width = %asset.getImageWidth();
%height = %asset.getImageHeight();
AssetDatabase.releaseAsset(%asset.getAssetId());1. acquireAsset is a costly function, so it's not recommended you do it often
2. Always call releaseAsset afterwards
#3
And .getImageSize() returns "x y" - thought that's what Doc was looking for....
02/20/2013 (9:22 am)
Hey! When did acquire become costly - Melv said it's fast so don't worry 'bout it.And .getImageSize() returns "x y" - thought that's what Doc was looking for....
#4
02/20/2013 (9:59 am)
Sorry, I was wrong. Thinking back to some code from the 3SS editor and got confused. It's not costly like I said, but you still have to be cautious using it. If you forget to release it, the memory will be held onto and that's likely not your intention. 
#5
The "getImageSize()", "getImageWidth()" and "getImageHeight()" all get the original bitmap size which is stored in the texture object. This is the bitmap source and not the potentially resized texture size.
A good example might be the "ToyAssets:brick_01" asset. The image file is 48 wide by 17 high. If you were to do this somewhere:
... you should get an output of:
Width=48
Height=17
02/20/2013 (10:31 am)
All the methods for the ImageAsset type are here.Quote:however, all this really does is pull in what is read from the Taml grab, so if the size is set, it will extract the size from those set parameters.Not so and I have no idea why you think that might be the case.
The "getImageSize()", "getImageWidth()" and "getImageHeight()" all get the original bitmap size which is stored in the texture object. This is the bitmap source and not the potentially resized texture size.
A good example might be the "ToyAssets:brick_01" asset. The image file is 48 wide by 17 high. If you were to do this somewhere:
%asset = AssetDatabase.acquireAsset( "ToyAssets:brick_01" ); echo( "Width=" @ %asset.getImageWidth() ); echo( "Height=" @ %asset.getImageHeight() ); AssetDatabase.releaseAsset( %asset.getAssetId() );
... you should get an output of:
Width=48
Height=17
#6
I guess I didn't see the AssetDatabase portion tie in.
I'm getting much much closer to finishing this, and hopefully when it's done it will be useful. As Mich has pointed out, dynamically creating the information really isn't the "best" method, but it's what I have to do for now until they change the export to be something more useful.
Many thanks for the help!!
02/20/2013 (10:40 am)
I think I figured out the flaw in my logic, as Richard pointed out, and many thanks the Mich for assistance in the irc chat.. I needed to instance the AssetDatabase in order to gain access to the correct information.I guess I didn't see the AssetDatabase portion tie in.
I'm getting much much closer to finishing this, and hopefully when it's done it will be useful. As Mich has pointed out, dynamically creating the information really isn't the "best" method, but it's what I have to do for now until they change the export to be something more useful.
Many thanks for the help!!
#7
Not sure what you mean by "export" - the asset doesn't store the image size (nothing in the engine does), it directly accesses the image's properties via it's OpenGL texture information. In a "level file" you'd store a sprite size, but this has no relation whatsoever with the image size. Even the asset definition for a multi-celled image only stores cell size, not the actual image size (though you could use that to extrapolate the image size since these numbers are directly used to reference the unscaled image dimensions).
02/20/2013 (12:44 pm)
But you're not "dynamically creating the information" - you're grabbing an instance of the asset and directly accessing the original texture information through that asset instance. Unless you then proceed to display that asset instance you're really not consuming much time at all.Not sure what you mean by "export" - the asset doesn't store the image size (nothing in the engine does), it directly accesses the image's properties via it's OpenGL texture information. In a "level file" you'd store a sprite size, but this has no relation whatsoever with the image size. Even the asset definition for a multi-celled image only stores cell size, not the actual image size (though you could use that to extrapolate the image size since these numbers are directly used to reference the unscaled image dimensions).
#8
02/20/2013 (12:48 pm)
@Richard - He's referring to a Spriter implementation. Dynamically creating T2D objects and assets after reading in a Spriter file.
#9
The texture object is available via the texture handle and this is what the above dimension methods retrieve.
02/20/2013 (12:51 pm)
... and the texture object does store both the texture dimensions and the original bitmap dimensions even if it has subsequently unloaded the source bitmap after uploading to the card.The texture object is available via the texture handle and this is what the above dimension methods retrieve.
#10
And I wasn't intending to imply that the texture dimensions were never changed, only that the original wasn't altered and that these dimensions are not stored in the asset definition file (or any other file that we seem to write out). Of course, if the image itself is altered then the texture information should be updated by the asset system, yes?
02/20/2013 (12:58 pm)
Ah - does spriter attempt to store a texture size?And I wasn't intending to imply that the texture dimensions were never changed, only that the original wasn't altered and that these dimensions are not stored in the asset definition file (or any other file that we seem to write out). Of course, if the image itself is altered then the texture information should be updated by the asset system, yes?
#11
Designer -> Creates SCML file, and utilizes images
Designer -> Copies SCML file, and associated images to T2D module
Designer -> Launched the toy to see the SCML rendered (animations pending)
So, to save some headache to those designers, I'm utilizing a dynamic creation system based upon the existing information. So, I'm going through and making the Taml's for all associated images stored in the SCML file that is created from Spriter.
It's what worked for the legacy format, so I'm following the same approach, only had a hiccup on some changes related to MIT (Ex: Asset vs Datablock)
02/20/2013 (1:03 pm)
The whole reason behind needing to access the image dynamically is due to the SCML reading. Basically, I'm "assuming" a straight forward approach.Designer -> Creates SCML file, and utilizes images
Designer -> Copies SCML file, and associated images to T2D module
Designer -> Launched the toy to see the SCML rendered (animations pending)
So, to save some headache to those designers, I'm utilizing a dynamic creation system based upon the existing information. So, I'm going through and making the Taml's for all associated images stored in the SCML file that is created from Spriter.
It's what worked for the legacy format, so I'm following the same approach, only had a hiccup on some changes related to MIT (Ex: Asset vs Datablock)
#12
So you can go down the generating TAML directly route or do what an editor would do and generate the objects in TorqueScript and just save them using TAML after all, that's all an asset definition is, an object saved using TAML.
Good luck, ask away if you need some more detail on anything.
02/21/2013 (1:46 am)
Cool.So you can go down the generating TAML directly route or do what an editor would do and generate the objects in TorqueScript and just save them using TAML after all, that's all an asset definition is, an object saved using TAML.
Good luck, ask away if you need some more detail on anything.
Torque Owner Richard Ranft
Roostertail Games
Melv assure us (and it definitely appears from extensive use) that this is quite fast and shouldn't have much impact on performance.
Everything you see there must be called on an asset instance, just like the example above. This will get you results similar to the old way of simply accessing datablock fields, but it would be wise to get all of the information you need from the asset while you have it acquired.