Will T2D be able to deallocate unreferenced textures?
by Bryan Edds · in Torque Game Builder · 09/12/2005 (1:10 am) · 37 replies
In this thread that was talking about having T2D deallocate unreferenced textures in video memory -
www.garagegames.com/mg/forums/result.thread.php?qt=32457
Melv said -
The problem is pretty clear - a game of any non-trivial size is not going to be able to allocate all of its resources into video and system memory all at once. But this is T2D currently does. It seems to me that resources should be able to be deallocated when not being referenced by any scene objects when the programmer calls a flush method. It should also be possible for the resources to be allocated only when a scene object references that resource for its use - not when the datablock is declared.
From your statement, it seems as though you have intended to address this problem by doing something similar to what I have just suggested. Is this true? If so, where is it on your priority list? This seems rather majorly important. I won't be able to release my game until this functionality is in, so it's very important to me. While exactly "when this will be addressed" is not something I need to know, I do need to know whether or not it will be addressed and where it is on your priority list.
Thanks for listening!
T2D ROCKS!!!!
www.garagegames.com/mg/forums/result.thread.php?qt=32457
Melv said -
Quote:We intend to provide much more control over the handling of texture resources and work is already progressing on that. Please don't misunderstand me as I'm describing what you've currently got, not what the final product will be. If I start describing what will be and not what is, then the inevitable question will be when; something that I can't give an answer to at the moment.
With that said, there are to be many changes to be made to the way that T2D handles textures, not least is the ability to automatically deal with textures, especially texture sizes and POT issues, appropriate to the underlying hardware as well as providing an interface for finer, more advanced control. The handling of textures is an extremely high priority.
The problem is pretty clear - a game of any non-trivial size is not going to be able to allocate all of its resources into video and system memory all at once. But this is T2D currently does. It seems to me that resources should be able to be deallocated when not being referenced by any scene objects when the programmer calls a flush method. It should also be possible for the resources to be allocated only when a scene object references that resource for its use - not when the datablock is declared.
From your statement, it seems as though you have intended to address this problem by doing something similar to what I have just suggested. Is this true? If so, where is it on your priority list? This seems rather majorly important. I won't be able to release my game until this functionality is in, so it's very important to me. While exactly "when this will be addressed" is not something I need to know, I do need to know whether or not it will be addressed and where it is on your priority list.
Thanks for listening!
T2D ROCKS!!!!
#2
Ugh. That's awful. Would you like a game that hit the harddrive every time you spawned a new sprite just because there wasn't a sprite with that imagemap already loaded?
No, T2D lets you do memory management. It doesn't load all of its resources all at once; if it's doing that, then that's because the user told it to. In a level-based game, it is up to the user as to what to load. When the level goes away, it is up to the user to destroy the resources associated with that level.
Memory management is the user's responsibility. Though it would be nice if T2D provided some features for making resource management easier (like a resource "block", for lack of a better term, that you load other resources into and deleting the block deletes these resources. So the resources for a level can all be loaded into the same block and deleted all at once).
09/12/2005 (11:43 am)
Quote:It seems to me that resources should be able to be deallocated when not being referenced by any scene objects when the programmer calls a flush method.
Ugh. That's awful. Would you like a game that hit the harddrive every time you spawned a new sprite just because there wasn't a sprite with that imagemap already loaded?
No, T2D lets you do memory management. It doesn't load all of its resources all at once; if it's doing that, then that's because the user told it to. In a level-based game, it is up to the user as to what to load. When the level goes away, it is up to the user to destroy the resources associated with that level.
Memory management is the user's responsibility. Though it would be nice if T2D provided some features for making resource management easier (like a resource "block", for lack of a better term, that you load other resources into and deleting the block deletes these resources. So the resources for a level can all be loaded into the same block and deleted all at once).
#3
I do believe that safeDelete does not delete resources from video memory - it simply deletes the scene object that references the resource allocated by the datablock in the video memory. I'd be happy to know if I were wrong though.
Yes, that would be problematic. Let me try a different idea on you, and explain a little more.
ALL datablocks are supposed to be loaded at the start of the program. When a datablocks is loaded, all of the resources it references are loaded - that's the way Melv set T2D up. I believe Melv said that datablocks are not meant to be created and destroyed in order to allocate resources dynamically. Rather that datablock are meant to be loaded ONCE and unloaded ONCE (at the beginning and the ending of the program respectively). If this is the case, then there really is no way to dynamically manage resources in T2D (other than doing something the author specifically said you're not supposed to do). If this is the case, then that means that ALL resources used in a game must currently be allocated at once at the start, and deallocated once at the end.
What I'd like to see is the ability to "enable" and "disable" datablocks when you need them. As Melv said, the datablocks should still persist throughout the lifetime of the program, but they should be able to be enabled / disabled by the programmer at the beginning and the end of each level in order to allocate / deallocate the resources they manage.
For example, let's say I allocate an fxStaticImageDatablock2D at the beginning of the program. Currently, this will allocate the image specified in the datablock to video memory. At the end of the program, when all the game's datablocks are automatically destroyed, the image in video memory will be deallocated. What I would like is for the image to be allocated into video memory only optionally when the datablock is loaded (with it being loaded by default for backwards compatibility). The image, if chosen not to be allocated by default when the datablock is loaded, it should be able to be loaded only when the programmer "enables" the datablock or, in order to avoid an emergency situation of missing graphics, could be automatically enabled when its resource is referenced and shoot out a warning message to let the programmer know he forgot to enable a datablock he is using. Sure, the FPS will take a hit with the sudden, unthreaded disk access, but that's better than an end-product having a bug causing missing images in the game. When the level is over, the datablocks used in the level could be quickly disabled, thus freeing all the resources. This would allow each level to keep a SimSet of all the datablocks it uses and have a loop enable all of them at the start of the level, and disable them at the end - all without having to create and destroy datablocks dynamically.
09/12/2005 (9:48 pm)
Quote:You don't need them to manage your textures for you in order to be successful here. You can already allocate and deallocate image maps, sprites, and other stuff on the fly. Take a look at the .safeDelete method, for example
I do believe that safeDelete does not delete resources from video memory - it simply deletes the scene object that references the resource allocated by the datablock in the video memory. I'd be happy to know if I were wrong though.
Quote:Ugh. That's awful. Would you like a game that hit the harddrive every time you spawned a new sprite just because there wasn't a sprite with that imagemap already loaded?
Yes, that would be problematic. Let me try a different idea on you, and explain a little more.
ALL datablocks are supposed to be loaded at the start of the program. When a datablocks is loaded, all of the resources it references are loaded - that's the way Melv set T2D up. I believe Melv said that datablocks are not meant to be created and destroyed in order to allocate resources dynamically. Rather that datablock are meant to be loaded ONCE and unloaded ONCE (at the beginning and the ending of the program respectively). If this is the case, then there really is no way to dynamically manage resources in T2D (other than doing something the author specifically said you're not supposed to do). If this is the case, then that means that ALL resources used in a game must currently be allocated at once at the start, and deallocated once at the end.
What I'd like to see is the ability to "enable" and "disable" datablocks when you need them. As Melv said, the datablocks should still persist throughout the lifetime of the program, but they should be able to be enabled / disabled by the programmer at the beginning and the end of each level in order to allocate / deallocate the resources they manage.
For example, let's say I allocate an fxStaticImageDatablock2D at the beginning of the program. Currently, this will allocate the image specified in the datablock to video memory. At the end of the program, when all the game's datablocks are automatically destroyed, the image in video memory will be deallocated. What I would like is for the image to be allocated into video memory only optionally when the datablock is loaded (with it being loaded by default for backwards compatibility). The image, if chosen not to be allocated by default when the datablock is loaded, it should be able to be loaded only when the programmer "enables" the datablock or, in order to avoid an emergency situation of missing graphics, could be automatically enabled when its resource is referenced and shoot out a warning message to let the programmer know he forgot to enable a datablock he is using. Sure, the FPS will take a hit with the sudden, unthreaded disk access, but that's better than an end-product having a bug causing missing images in the game. When the level is over, the datablocks used in the level could be quickly disabled, thus freeing all the resources. This would allow each level to keep a SimSet of all the datablocks it uses and have a loop enable all of them at the start of the level, and disable them at the end - all without having to create and destroy datablocks dynamically.
#4
09/12/2005 (10:08 pm)
Just an interesting point... TGE (which is basically the same core as T2D) is set up through missions. When the server (which is the same as the client in a single player game) closes down a map to load a new one it deletes all datablocks with a command "deleteDatablocks" (never could've imagined that lol)... *shrug* didn't really want to get into the conversation since most valid points have been offered, just an intersting idea... for T2D games using T2D for guis the deletedatablocks won't work since it deletes all datablocks.
#5
In TGE, a datablock is just a group of server-side data that is kept around for storing non-dyamic entities during the lifetime of a mission/level/game. These datablocks are sent to the client upon mission download, and then referred from then on by a standard ID number. In fact, AFAIK, datablocks are just standard console container objects, and have a delete() method exposed.
Textures and animations are datablocks in T2D. This of course leads to complications if you want to have multiple missions/levels, and don't want to load all of the content at once. deleteDatablocks() will zap all loaded datablocks. But, as Matt points out, that will also zap datablocks that might be used for common items, such as player artwork or T2D-based GUI elements. There's no point in forcing the player to reload all of that per level load.
There is a thread in the TGE SDK forums about this, and Keith Johnston used the following snippet of code to selective delete datablocks. Datablocks are stored in their own special sim group, which is what this code takes advantage of. He just sets a flag in each datablock that is flushable (the "dontneed" variable) and then scans the simset and removes unneeded datablocks on mission switchover:
Removing an imagemap datablock will decrement a texture's reference, which should unload if it is only referred to once.
Of course, this is just from memory alone, but I had planned on treating my own game in the same method as outlined above.
EDIT: Oh yeah, it goes without saying that you should only zap datablocks once all possible references are removed, such as active scenegraphs and objects therein. Too bad safeDelete() only works on T2D objects. :)
09/12/2005 (10:40 pm)
What Matt says about TGE deleting datablocks is correct. I think what Melv was originally referring to (by saying you can't delete datablocks) is that once a datablock is sent to the client, you have to be careful about removing it if there are still references to that datablock.In TGE, a datablock is just a group of server-side data that is kept around for storing non-dyamic entities during the lifetime of a mission/level/game. These datablocks are sent to the client upon mission download, and then referred from then on by a standard ID number. In fact, AFAIK, datablocks are just standard console container objects, and have a delete() method exposed.
Textures and animations are datablocks in T2D. This of course leads to complications if you want to have multiple missions/levels, and don't want to load all of the content at once. deleteDatablocks() will zap all loaded datablocks. But, as Matt points out, that will also zap datablocks that might be used for common items, such as player artwork or T2D-based GUI elements. There's no point in forcing the player to reload all of that per level load.
There is a thread in the TGE SDK forums about this, and Keith Johnston used the following snippet of code to selective delete datablocks. Datablocks are stored in their own special sim group, which is what this code takes advantage of. He just sets a flag in each datablock that is flushable (the "dontneed" variable) and then scans the simset and removes unneeded datablocks on mission switchover:
// Delete datablocks for rooms we don't need
%dataGroup = "DataBlockGroup";
for (%i = 0; %i < %dataGroup.getCount(); %i++) {
%obj = %dataGroup.getObject(%i);
if (%obj.dontNeed) {
echo ("Deleting: " @ %obj.getName());
%obj.delete();
}
}Removing an imagemap datablock will decrement a texture's reference, which should unload if it is only referred to once.
Of course, this is just from memory alone, but I had planned on treating my own game in the same method as outlined above.
EDIT: Oh yeah, it goes without saying that you should only zap datablocks once all possible references are removed, such as active scenegraphs and objects therein. Too bad safeDelete() only works on T2D objects. :)
#7
09/13/2005 (5:18 am)
Also I remember seeing a recent post from Melv saying that future versions of T2D won't keep the texture in memory after its' been written to the gfx accelerator. Or something to that effect. Seems kinda related to what you are asking about Bryan
#8
09/13/2005 (10:11 am)
Robert, I found a clearTextureHolds function in T2D, but no purgeResources function. I tried calling clearTextureHolds, but I couldn't figure out what a does. Would you mind explaining a little more? Are you sure this function is compatible with T2D's texture allocation implementation?
#9
I, too, cannot find references to purgeResources. Is this perhaps a TGE 1.4 function? (I am not familiar with the newer TGE code base.)
I'm not entirely sure what Alex is referring to... My guess is that in the current T2D image map code, since it needs access to the bitmap data for doing things like color-keying frames, keeps the texture hanging around in system memory without deleting it once its done. In this case, you could never clear textures, even by using clearTextureHolds, as the reference count would always be one. (Unless you of course delete the datablock, which I suppose then unallocates the local copy of the texture.)
Some testing is needed to figure out how this all integrates with the T2D datablock/texture system.
09/13/2005 (11:03 am)
Bryan, according to the code, that function will scan the texture list, find textures with zero references and then free them. You would probably want to do this after removing all references to the textures (ie: delete the corresponding imagemap datablocks), as this will guarantee that the textures get flushed, instead of relying upon T2D to gradually flush unused textures. (Which I am not even sure that it does, or if so what algorithm it uses or when the flushes occur.)I, too, cannot find references to purgeResources. Is this perhaps a TGE 1.4 function? (I am not familiar with the newer TGE code base.)
I'm not entirely sure what Alex is referring to... My guess is that in the current T2D image map code, since it needs access to the bitmap data for doing things like color-keying frames, keeps the texture hanging around in system memory without deleting it once its done. In this case, you could never clear textures, even by using clearTextureHolds, as the reference count would always be one. (Unless you of course delete the datablock, which I suppose then unallocates the local copy of the texture.)
Some testing is needed to figure out how this all integrates with the T2D datablock/texture system.
#10
theres the command from TGE for purgeResources, don't think GG will mind me posting this since its just an accessor function to what already exists... you can compile that into a file that references core/resManager
09/13/2005 (11:28 am)
//--------------------------------------------------------------------------
ConsoleFunction( purgeResources, void, 1, 1, "Purge resources from the resource manager.")
{
ResourceManager->purge();
}theres the command from TGE for purgeResources, don't think GG will mind me posting this since its just an accessor function to what already exists... you can compile that into a file that references core/resManager
#11
I've learned to ignore what Melv "wants" in favor the needs of a game developer (particularly me). And datablocks (and their resources) are C++ objects. They can be deleted and the data that they reference expunged. This is not a problem.
Also, I don't agree that this is how Melv set T2D up. The fact that datablocks are used for less... "data-centric" items (animation frames, etc) is irrelevant; just delete the datablocks for images and so forth. The fact that the datablock mechanism was overloaded for use in non-resource mechanisms doesn't stop you from keeping a list of the image datablocks and deleting them as needed.
And purging all datablocks is a horrible resource management mechanism in any event.
09/13/2005 (11:58 am)
Quote:ALL datablocks are supposed to be loaded at the start of the program. When a datablocks is loaded, all of the resources it references are loaded - that's the way Melv set T2D up.
I've learned to ignore what Melv "wants" in favor the needs of a game developer (particularly me). And datablocks (and their resources) are C++ objects. They can be deleted and the data that they reference expunged. This is not a problem.
Also, I don't agree that this is how Melv set T2D up. The fact that datablocks are used for less... "data-centric" items (animation frames, etc) is irrelevant; just delete the datablocks for images and so forth. The fact that the datablock mechanism was overloaded for use in non-resource mechanisms doesn't stop you from keeping a list of the image datablocks and deleting them as needed.
And purging all datablocks is a horrible resource management mechanism in any event.
#12
Anyway, this function dumps a list of all texture manager resources, and lists their ref counts and holding state. I searched for references (in T2D) for this function, but it seems to be dead code that might've been used in the TGE code base at one point.
It's a little rough around the edges, but it at least lets you see what's being loaded and referenced. (For example, the reported textureSpace size is just the width*height, which makes me wonder if this is old code. Most textures these days aren't just 8-bit color depth. :)
I'm sure there is equivalent functions in the resource manager, too.
I agree with Smaug, you want to avoid purging the entire texture cache if you have a lot of non-transitory artwork/animations.
Another neat thing in gTexManager.cc...
getResidentFraction() - Returns a percentage of total loaded textures that are resident on the card. (Probably isn't %100 accurate, as it relies upon glAreTexturesResident. Also, it's a dummy call under the D3D wrapper.)
But, well, that's a different topic, heh.
09/13/2005 (12:49 pm)
Poking around in glTextureManager, I found something that is handy... DumpStats(). You will need to expose this to the console, however, by adding a console wrapper. (Oh, and don't forget to make sure the preprocessor define GATHER_METRICS is set.)Anyway, this function dumps a list of all texture manager resources, and lists their ref counts and holding state. I searched for references (in T2D) for this function, but it seems to be dead code that might've been used in the TGE code base at one point.
It's a little rough around the edges, but it at least lets you see what's being loaded and referenced. (For example, the reported textureSpace size is just the width*height, which makes me wonder if this is old code. Most textures these days aren't just 8-bit color depth. :)
I'm sure there is equivalent functions in the resource manager, too.
I agree with Smaug, you want to avoid purging the entire texture cache if you have a lot of non-transitory artwork/animations.
Another neat thing in gTexManager.cc...
getResidentFraction() - Returns a percentage of total loaded textures that are resident on the card. (Probably isn't %100 accurate, as it relies upon glAreTexturesResident. Also, it's a dummy call under the D3D wrapper.)
But, well, that's a different topic, heh.
#13
@Smaug: Not sure if you meant it that way or not, but that was a pretty snide and rude slight towards Melv...there are other ways of making your point besides off-side insults of the developers.
09/13/2005 (1:27 pm)
FYI, datablocks are an integral part of the networking of Torque, and you don't get one (networking) without the other. @Smaug: Not sure if you meant it that way or not, but that was a pretty snide and rude slight towards Melv...there are other ways of making your point besides off-side insults of the developers.
#14
Not at all, if you knew how TGE missions were set up then you'd understand why it does that, like I said its not exactly the same as T2D.
09/13/2005 (1:44 pm)
I'd agree that was a very rude comment Smaug, exremeley unprofessionalQuote:And purging all datablocks is a horrible resource management mechanism in any event.
Not at all, if you knew how TGE missions were set up then you'd understand why it does that, like I said its not exactly the same as T2D.
#15
The thing is, Melv *almost came out and said that all of this resource allocation stuff will be resolved behind the scenes. I figured the simplest way to do this is with using some sort of automated resource management system or at least one that gives the developer finer control over what to allocate and deallocate when without having to create / delete datablocks manually. Therefore, I figured I'd just not worry about it for the time being. But as I go along, I am getting a little more worried, and would just like to make sure what his intent actually is so I don't have to spend lots of time taking care of this stuff in code myself.
Where are you Melv? :)
09/13/2005 (1:47 pm)
Interesting information David! I'll poke around a bit.The thing is, Melv *almost came out and said that all of this resource allocation stuff will be resolved behind the scenes. I figured the simplest way to do this is with using some sort of automated resource management system or at least one that gives the developer finer control over what to allocate and deallocate when without having to create / delete datablocks manually. Therefore, I figured I'd just not worry about it for the time being. But as I go along, I am getting a little more worried, and would just like to make sure what his intent actually is so I don't have to spend lots of time taking care of this stuff in code myself.
Where are you Melv? :)
#16
(Like Matt, I am supposing such a short code snippet from the TGE SDK is fine. If not, feel free to edit my post!)
I can't speak for Melv, but I am guessing he is going to fix the problem with unneccessarily held textures and then maybe write some simple wrapper code for management of textures. But even with the imagemap datablock bug, you should be able to flush textures by removing their datablock references. You need zero code changes in T2D right now to do that*.
A lot of Bryan's requested functionality is already in Torque. It keeps track of texture usage, along with raw bitmap resource usage.
As for datablocks being deleted -- Yes, as Matt points out, this is how TGE works with its mission structure. Melv opted to use the same structure for T2D, so that in the future when networking becomes a part of T2D he won't have to re-write a lot of the major classes and can use existing datablock replication code. This is why datablocks have been pre-empted for resource allocation in T2D. In normal TGE, texture loading occurs when a 3D object is loaded and so it works a bit differently.
* Assumed. I haven't actually tested this, of course. The only issue I can see, however, is that the image datablock does not properly unlock the texture when it's freed, but this should be handled by the TextureHandle destructor regardless of what fxImageMapDatablock/fxChunkedImageDatablock does.
09/13/2005 (1:58 pm)
Re: on TextureManager::DumpStats -- It's actually used in normal TGE (in game.cc). To whit://--------------------------------------------------------------------------
ConsoleFunction( flushTextureCache, void, 1, 1, "Flush the texture cache.")
{
TextureManager::flush();
}
#ifdef GATHER_METRICS
ConsoleFunction(dumpTextureStats, void, 1, 1, "Dump texture manager statistics. Debug only!")
{
TextureManager::dumpStats();
}
#endif
#ifdef TORQUE_DEBUG
ConsoleFunction(dumpResourceStats, void, 1, 1, "Dump information about resources. Debug only!")
{
ResourceManager->dumpLoadedResources();
}
#endif(Like Matt, I am supposing such a short code snippet from the TGE SDK is fine. If not, feel free to edit my post!)
I can't speak for Melv, but I am guessing he is going to fix the problem with unneccessarily held textures and then maybe write some simple wrapper code for management of textures. But even with the imagemap datablock bug, you should be able to flush textures by removing their datablock references. You need zero code changes in T2D right now to do that*.
A lot of Bryan's requested functionality is already in Torque. It keeps track of texture usage, along with raw bitmap resource usage.
As for datablocks being deleted -- Yes, as Matt points out, this is how TGE works with its mission structure. Melv opted to use the same structure for T2D, so that in the future when networking becomes a part of T2D he won't have to re-write a lot of the major classes and can use existing datablock replication code. This is why datablocks have been pre-empted for resource allocation in T2D. In normal TGE, texture loading occurs when a 3D object is loaded and so it works a bit differently.
* Assumed. I haven't actually tested this, of course. The only issue I can see, however, is that the image datablock does not properly unlock the texture when it's freed, but this should be handled by the TextureHandle destructor regardless of what fxImageMapDatablock/fxChunkedImageDatablock does.
#17
09/13/2005 (2:18 pm)
I was looking at the TextureHandle class yesterday, and I saw the unlock call in its destructor.
#18
Just because TGE's mission system did it that way doesn't make it a good idea (for T2D or TGE). There are any number of reasons why one would want to keep some datablocks around, let alone any number of games that do this as a matter of course. It may work for a typical multiplayer FPS arena-based game, but even a singleplayer FPS should keep the main character's stuff around from mission to mission.
Sacrificing good resource management for networking (if that is indeed the reason behind it. I'm not willing to buy it yet, but network programming isn't my forte) seems to me to be too high a cost to pay for such things. Particularly if there is some way around it.
This just sound like a bug. The datablock is what (effectively) owns the TextureHandle. It makes sense that the removal of the block should cause its deletion. Unless TextureHandles can be owned by multiple datablocks (or other objects), in which case they should be reference counted and datablock deletion should decriment the reference.
Aside:
Hmm, I fail to see the logic in that.
I'm a game developer. My job is to make a game. Possibly with the aid of tools, like T2D, PhotoShop, and so forth.
If the designed intent of a particular tool is counterproductive towards that end, I either abandon the tool for something else or alter the tool so that it becomes productive towards that intent. If the designed intent of a portion of the tool makes the implementation of the game more difficult, then the tool once again is either abandoned or altered to conform. In either case, the question is whether or not the tool is doing the job that the game developer needs it to do.
So it's perfectly reasonable to ignore Melv's will (as interpreted through the T2D codebase) altoghether when dealing with game development. When his will and that of the game designer coincide, there is much rejoicing, for this is the goal of every engine designer. When they don't, then the game designer has more work to do to make the engine conform to his will. In either case, the will of the engine designer, his designed intent, is irrelevant.
The statement in question is insulting if you believe that T2D currently (or ever will) provides what every 2D game developer needs exactly as they need it and thus fits with everyone's will. Or, perhaps if you believe that if a game developer's will doesn't conform to the T2D way, then that game developer's will is wrong and ought to conform.
To my mind, neither of these attitudes is conducive towards either creating a better T2D or making games.
09/13/2005 (4:58 pm)
Quote:Not at all, if you knew how TGE missions were set up then you'd understand why it does that, like I said its not exactly the same as T2D.
Just because TGE's mission system did it that way doesn't make it a good idea (for T2D or TGE). There are any number of reasons why one would want to keep some datablocks around, let alone any number of games that do this as a matter of course. It may work for a typical multiplayer FPS arena-based game, but even a singleplayer FPS should keep the main character's stuff around from mission to mission.
Sacrificing good resource management for networking (if that is indeed the reason behind it. I'm not willing to buy it yet, but network programming isn't my forte) seems to me to be too high a cost to pay for such things. Particularly if there is some way around it.
Quote:The only issue I can see, however, is that the image datablock does not properly unlock the texture when it's freed, but this should be handled by the TextureHandle destructor regardless of what fxImageMapDatablock/fxChunkedImageDatablock does.
This just sound like a bug. The datablock is what (effectively) owns the TextureHandle. It makes sense that the removal of the block should cause its deletion. Unless TextureHandles can be owned by multiple datablocks (or other objects), in which case they should be reference counted and datablock deletion should decriment the reference.
Quote:I'd agree that was a very rude comment Smaug, exremeley unprofessional
Aside:
Hmm, I fail to see the logic in that.
I'm a game developer. My job is to make a game. Possibly with the aid of tools, like T2D, PhotoShop, and so forth.
If the designed intent of a particular tool is counterproductive towards that end, I either abandon the tool for something else or alter the tool so that it becomes productive towards that intent. If the designed intent of a portion of the tool makes the implementation of the game more difficult, then the tool once again is either abandoned or altered to conform. In either case, the question is whether or not the tool is doing the job that the game developer needs it to do.
So it's perfectly reasonable to ignore Melv's will (as interpreted through the T2D codebase) altoghether when dealing with game development. When his will and that of the game designer coincide, there is much rejoicing, for this is the goal of every engine designer. When they don't, then the game designer has more work to do to make the engine conform to his will. In either case, the will of the engine designer, his designed intent, is irrelevant.
The statement in question is insulting if you believe that T2D currently (or ever will) provides what every 2D game developer needs exactly as they need it and thus fits with everyone's will. Or, perhaps if you believe that if a game developer's will doesn't conform to the T2D way, then that game developer's will is wrong and ought to conform.
To my mind, neither of these attitudes is conducive towards either creating a better T2D or making games.
#19
All this about "bad design decisions" and "ignoring melv's will", "Sacrificing good resource management", "conforming" to the T2D way...is just B.S. These kinds of conversations should be taking into a phone call or a face 2 face with the lead developer (ie. Melv) Then maybe you can have an intelligent conversation about technical points. Otherwise it just deteriorates into the kind of comments seen here.
09/13/2005 (5:24 pm)
Hey I trust Melv, Josh, et al to make T2D as kick-ass as it possibly can be. What they have done to this point is really great. Also I knew when I bought T2D license [edit: I KNEW] that it was part of the Torque family and used the core for TGE [edit: T2D uses TGE core technology]. No surprises there.All this about "bad design decisions" and "ignoring melv's will", "Sacrificing good resource management", "conforming" to the T2D way...is just B.S. These kinds of conversations should be taking into a phone call or a face 2 face with the lead developer (ie. Melv) Then maybe you can have an intelligent conversation about technical points. Otherwise it just deteriorates into the kind of comments seen here.
#20
I honestly don't even think you mean to be that way, but that's how it comes across.
09/13/2005 (5:32 pm)
@Smaug: Not trying to pick on you man, it's just a presentation thing (which we've actually gone over before). No one expects anyone to be all sugar and syrup, and I'm not trying to protect any staff/developer/Melv's egos or anything, but while the pure content of your posts are always quite informative and make good sense, your presentation a lot of times completely blows away the actual content of your posts...there are connotations to what you say that tend to put people off, sometimes very strongly.I honestly don't even think you mean to be that way, but that's how it comes across.
Torque Owner Jason Cahill
Default Studio Name
Even though you've got the simplicity of a scripting language, it does not mean you should expect that you can be completely lazy and still get perfect memory utilization. Successful games will have their memory management thought about in logical chunks and their game developers will be using engine constructs like SimGroups to nuke stuff when it's not needed. I for one do not want an over-zealous memory manager. I like to know that when I have something allocated, it's really allocated so that I don't get hitches as stuff pages back from disk.
Diff'rent strokes for diff'rent folks, I guess.