TImage??
BlitzMax Forums/BlitzMax Beginners Area/TImage??
| ||
Hi all...I'm new to BlitzMax, and have a rather fundemental question. What is TImage? I have seen it in tutorials as a keyword many times, but haven't found an explanation for it yet. |
| ||
Its an Image object. LoadImage() returns a TImage object. I.e.:Local myImage:TImage = LoadImage("myImage.png") Print myImage.width Print myImage.height Last edited 2011 |
| ||
Hi G! Yes, I understand the 'use' of TImage, but do not understand why it is used. Couldn't... Local myImage = LoadImage("myImage.png") ...do just as well, or is there a special significance to it? |
| ||
you can look at it to the right of the Ide, in the home tab, under: projects-> modules source->brl.mod->max2d.mod->image.bmx it is used to load pixmaps to be converted to textures for use by the drawImage command. |
| ||
You need to use it in Strict mode otherwise you'll get an error Strict advises the BlitzMax compiler to report as errors all auto defined variables. In non strict mode it's optional This will give an error Strict Graphics 800 , 600 , 1 Global pic = LoadImage("Image1.png") While Not KeyHit(KEY_ESCAPE) cls DrawImage pic,100,100 flip wend This won't Strict Graphics 800 , 600 , 1 Global pic:TImage = LoadImage("Image1.png") While Not KeyHit(KEY_ESCAPE) cls DrawImage pic,100,100 flip wend Last edited 2011 |
| ||
If you don't define the variable as a timage then garbage collection won't clean it up, leading to memory leaks. at least that's how blitzmax used to be - its not something I've done in a very long time. |
| ||
Also allows you to do stuff like;Global myimage:TImage = loadimage("bla") MyDrawImage(myimage,100,100) Function MyDrawImage(image:TImage,x,y) DrawImage image,x,y Drawtext image.width,10,10 Drawtext image.height,10,20 End Fucntion You'll find a use for it, as a rule I always load my image as TImage objects. |
| ||
When you use an integer handle like this...Local myImage = LoadImage("myImage.png")...A TImage object is still created but a reference to the object is stored in a hash table and the key is returned as the handle. Every time the handle is referenced, a hash lookup has to be carried out to obtain the relevant object. More importantly, a reference to that object will exist as long as the table entry remains, so it needs to be removed before the object can be collected. This is where release comes in. This system was meant to make things easier for beginners as you don't need to remember object types but, IMHO, it backfired. Most beginners failed to realise that the returned handles needed to be freed when no longer needed and, at one time, the forum was awash with people reporting memory leak bugs that were just unreleased handles. Get used to using objects directly as integer handles are not only slightly slower to create and use, they're also more prone to memory leaks. Also, to add insult to injury, integer handles can only be used in non strict mode which is inherently slower than either of the strict modes to begin with. Last edited 2011 |
| ||
If you're getting into programming through bmax I would highly recommend using strict or better still super strict. The reason for this is you will learn to declare things properly (critical in most other languages...) and it will prevent you from making silly mistakes that take forever to discover (like typos in your variable names...). The end result is you will develop a more portable knowledge base, and have fewer mind bending headaches in the process, so if/when you decide to try your hand at another language you'll have a much better head start. |
| ||
By giving the variable a type of TImage, only images can be stored in it. This helps create cleaner code which is easier to understand. If a function parameter is of type TImage, you know it expects an image. Otherwise, it's harder to tell what the function is expecting. In strict mode, you must provide a type for every variable. For example, you can't store a TImage in a variable one time and then store a TList the next time. This results in code which is much smarter and it is also faster as the compiler won't be suprised by a variable suddenly changing type. If you ever need a variable which really can store any kind of object at any time, there are ways but 90% of the time if you are doing this it is bad design, so try to avoid this! Last edited 2011 |
| ||
Thanks goes to all... :) |