LoadAnimTexture Q
Blitz3D Forums/Blitz3D Programming/LoadAnimTexture Q
| ||
| If I load an animated Texture twice, with the same parameters, will blitz optimize the memory usage and use the first one for both instances, as it's doing it with non-animated textures? Yes, I could write a test app, but maybe some of you can tell me this :) |
| ||
| i would assume it loads it as it does a normal texture, so id assume yes |
| ||
| Ok, it seems it is optimizing pretty nicely, although you should keep in mind that the frames are uploaded to vidmem not earlier than when they actually are used. This includes camera fustrum culling. So if you do a caching render at startup, make sure to renderworld in all 6 directions. |
| ||
| hmmm, some good advice there id need a huge camera range too i suppose ^.^ |
| ||
| Thanks Cygnus, tested it while you answered :) Now what I really wonder is: Does this optimation also take place in the normal RAM, or only in the videoram? EDIT just checked this as well with the system monitor, YES! it loads it only once. Everything perfect :D |
| ||
| very useful to know, ive been worying about this myself cuz in supernova, my script engine could be made to reload an image several times... Tho tbh its probably best i just do a loop check to prevent it It also explains why im loading 20mb of graphics into a 16mb card and it still runs :) |
| ||
| indeed, it's amazing how much you can do with a little card. BTW, yes, use a huge camera range while caching. Halo used to post a caching function somwhere, but it didn't handle frustum culling or animated textures. The problem with uploading while playing is, the gameplay starts stuttering, and even the music stutters, including other sounds, and that sounds realy noisy, bad and out of rythm. So I'd suggest to store all animated textures in an array or as a type and use a function that will (byside other pre-caching) make use of each frame of every animated texture before you even start the game loop. |
| ||
| im glad someone else sees that about the music! >.< hehe another good idea about animated textures there... IM currently on a sis card (16mb shared. Ouch).. i have a feeling its the shared bit thats killing everything (obviously my game cant update while something else is doing memory stuff) ALl my texture systems are stored in arrays anyway so it makes all this very easy. cheers for some thought there :D |
| ||
| I have now made a precaching function that theoreticly renders each and everything. All animated textures, all stuff that would be hidden and gives me a short pause when I show it (eg. activation of new weapons) or the gunflash when it's shown the very first time. Unfortunately it is still stuttering. I have noiced that there is a direct relation with the harddrive activities: as long as the HD is still busy (whatever it does since the game already started, suggesting everything was loaded), the gameplay and sound etc. is noisy, stuttering. Now my theory: when the machine has only few system Ram, eg.128 megs, the OS needs to use harddrive cache to temporarily outsource other applications that where occupiing memory (eg. msie, that sits there all the time anyway, autoloaded). Well, if that is the problem, then I simply say :"minimum 128 MB, 256 reccomended" :) |
   |