Dynamic imagemaps
by Tomas Dahle · in Torque Game Builder · 04/27/2005 (2:11 am) · 4 replies
T2D seems to do all its loading based on datablocks. First question I got is what happens when I do:
Does it
A) Load the texture into memory when the datablock is declared?
or
B) Load the texture into memory only when an instance that uses the datablock is created?
I am asking because I want to create dynamic imagemaps. That is, an image that I do some computations on (or generate) before loading it into T2D.
My dream-solution would be a C++ function that takes an easy to understand structure containing RGBA values (and size+width parameters) and returns a datablock-object that uses this image and keeps the image loaded in memory for as long as the datablock exists. If anyone has the know-how or some ideas on how I can create such a function or at least a few steps in the right direction, that would surely be very helpful.
Any alternative ideas on feeding T2D custom-generated images are also welcome, as I may certainly be off on the wrong course from the get-go for all I know ;)
Well, I'm off to see if I can't make this happen, and then when I return someone has probably said something smart that makes all my work for naught, but that's ok.
EDIT: As far as I can see, textures are loaded and kept in memory when they are declared. This will make at least an intermediary solution to this extremely simple as I can just create temporary images and delete them after using them in a datablock. (tell me if I'm wrong)
datablock fxImageMapDatablock2D(priestImageMap)
{
mode = full;
textureName = "~/client/images/priest";
};Does it
A) Load the texture into memory when the datablock is declared?
or
B) Load the texture into memory only when an instance that uses the datablock is created?
I am asking because I want to create dynamic imagemaps. That is, an image that I do some computations on (or generate) before loading it into T2D.
My dream-solution would be a C++ function that takes an easy to understand structure containing RGBA values (and size+width parameters) and returns a datablock-object that uses this image and keeps the image loaded in memory for as long as the datablock exists. If anyone has the know-how or some ideas on how I can create such a function or at least a few steps in the right direction, that would surely be very helpful.
Any alternative ideas on feeding T2D custom-generated images are also welcome, as I may certainly be off on the wrong course from the get-go for all I know ;)
Well, I'm off to see if I can't make this happen, and then when I return someone has probably said something smart that makes all my work for naught, but that's ok.
EDIT: As far as I can see, textures are loaded and kept in memory when they are declared. This will make at least an intermediary solution to this extremely simple as I can just create temporary images and delete them after using them in a datablock. (tell me if I'm wrong)
About the author
#2
T2D keeps an analogy between the bitmap and a texture. If two datablocks use the same bitmap, it will ultimately point to the same texture.
There are many things we can and will be doing to extend this architecture.
- Melv.
04/27/2005 (3:37 am)
Datablocks currently load the bitmap/texture into memory when they are declared. This is why you must have the canvas active before declaring any datablocks.T2D keeps an analogy between the bitmap and a texture. If two datablocks use the same bitmap, it will ultimately point to the same texture.
There are many things we can and will be doing to extend this architecture.
- Melv.
#3
04/27/2005 (4:02 am)
Melv: Right now I have some code that relies 100% on the fact that datablocks load the texture into memory (as I delete the source-file after the datablock has inspected it). Do you plan to change this behaviour? And if so, will you provide a flag to put in datablocks to specify to load the texture into memory so old code (like mine) will still work?
#4
When you say "load the texture into memory", presumably you are referring to keeping the bitmap in memory after the texture has been generated? Obviously the texture resides in GPU memory. There's no reason why it couldn't be an option in-case you want to manipulate the bitmap further and upload as a texture.
Imagemaps are going to be more abstracted from the target hardware for the future so things like bitmaps sizes, POT issues, filtering-issues are just dealt with in an appropriate and transparent manner. There's also no reason why more advanced users can't get hold of finer controls though so that they can further manipulate imagery. We can see imageMaps becoming more of an object in their own sense than the datablock-definition currently provides.
I can't really comment further on what features will/won't be in imagemaps at this point, it's just too early to provide any more details. We will try to ensure that we are not constantly changing the ways things work though. Some of the fixes/improvements have been deferred for that very reason.
Be assured though that for major changes to functionality, we'll definatley provide as much info on the changes before they happen as well as try to get some feedback. That's one of the reasons we're doing the EA and why we think it can be so good for everyone.
- Melv.
04/27/2005 (4:51 am)
Tomas,When you say "load the texture into memory", presumably you are referring to keeping the bitmap in memory after the texture has been generated? Obviously the texture resides in GPU memory. There's no reason why it couldn't be an option in-case you want to manipulate the bitmap further and upload as a texture.
Imagemaps are going to be more abstracted from the target hardware for the future so things like bitmaps sizes, POT issues, filtering-issues are just dealt with in an appropriate and transparent manner. There's also no reason why more advanced users can't get hold of finer controls though so that they can further manipulate imagery. We can see imageMaps becoming more of an object in their own sense than the datablock-definition currently provides.
I can't really comment further on what features will/won't be in imagemaps at this point, it's just too early to provide any more details. We will try to ensure that we are not constantly changing the ways things work though. Some of the fixes/improvements have been deferred for that very reason.
Be assured though that for major changes to functionality, we'll definatley provide as much info on the changes before they happen as well as try to get some feedback. That's one of the reasons we're doing the EA and why we think it can be so good for everyone.
- Melv.
Torque Owner Charlie Malbaurn
Image blocks wouldnt work dynamically as they are designed to keep static information about objects so that you do not need to declare the same information over and over again. You can however change class information dynamically.
There is another thread around here that deals with off screen rendering of images. You may want to check that one out
Here is a link:
www.garagegames.com/mg/forums/result.thread.php?qt=29367
The threads subject is more on the line of editing images but it may serve some insight to what you are looking for.
Either way, good luck with that. Just because Torque uses datablocks to handle images, doesn't mean that it has to only do it with image maps. Maybe you can come up with a better alternative