What's the longest anim strip BMax can handle?
BlitzMax Forums/BlitzMax Programming/What's the longest anim strip BMax can handle?
| ||
| Just asking because I may have to load one which is 30000 pixels wide, 90 frames. Has anyone tried loading an anim strip this big and did BMax handle it? Just wanted to know in case the artist wastes ages. I know that texture size doesn't matter as the anim strip will be split down by BlitzMax into individual frames. |
| ||
| might want to write a script that breaks it into more manageable chunks. say 16 frames each? you could use Blitzmax or Python to do that. anyway, why dont you post a sample app with the image and we can give it a try on our various setups. |
| ||
| Loading could be a little critical. Assuming that it is 96px in height, this mean more than 112 MB RAM ... |
| ||
| You're using 90 334x334 images? Won't they get resized up to 512x512? Better to scale them down to 256x256. If you insist on having 334x334 images, why don't you fit them into a, 3340x3006 image? |
| ||
| make your strips tall instead of wide. I doubt max has an issue with that... any problems will most likely come from the DX and Opengl drivers. there used to be limitations in many cards on the width of textures and buffers. to support the largest number of cards, limit the width to the smallest resolution size. but the height can be as big as you want. so instead of making strips 40 tiles wide, make them either 40 tiles tall or a grid like 10x4. |
| ||
| http://www.blitzbasic.com/codearcs/codearcs.php?code=1990#comments run this and press space button after the explosion is performed. I have managed with tweaking the parameter to get an anim Strip of around 120 frames (512*512) and BMax loads the strip without any problem. |
| ||
| dmaz: But LoadAnimImage only works with horiztonal strips :-( I can load in a 3000 pixel wide strip on my PC and Bmax splits it up properly where it fails to handle a 3000 pixel image if loaded as a normal image (>2048 texture size I suspect). So I was wondering if BMax can handle a really long texture... Dreamora: How did you arrive at that figure? If I do 30000 x 96 x 4(bytes per pixel) /1024 / 1024 = I get 11MB. Or were you scaling width/height up to next power of 2? Gfk: Yeah 512x512 would be 90MB. Thing is it may only be 100 pixels tall so will size up to 128. There was that thing about some cards having to use a perfectly square texture but I think it was wrong and that each dimension can have different sizes as long as they are power of 2. Maybe I'll just load it in from numbered files and try to get it less than 256 pixels wide, and maybe reduce the framecount by half... |
| ||
| klepto2: Aha so you managed to load in a 61440 x 512 png, wow. |
| ||
| Dreamora: How did you arrive at that figure? If I do 30000 x 96 x 4(bytes per pixel) /1024 / 1024 = I get 11MB I think he assumed 512x512, as GFK mentioned that. Assuming they scale up to 512x128, I think you're going to use 22.5MB with them, which is more or less a quarter of what Dreamora mentioned. |
| ||
| I'm gonna try to get them in 256x128 then only 45 frames = 5.6MB. |
| ||
| But LoadAnimImage only works with horiztonal strips Are you sure about that? It seems to work OK for me. |
| ||
| But LoadAnimImage only works with horiztonal strips What gave you that idea?Loadanimimage loads the 'sprite sheet' as one large pixmap and chops it up into smaller pixmaps ready to be turned into image frames when needed. You need only worry about the vidmem required to hold the final textures, not the initial 'sprite sheet' size. [edit] Blimey...Was I really faffing around for 12 minutes? :o/ [/edit] |
| ||
| loadanimimage doesnt need a strip, just use a 2024x2024 or whatever, I always use a square source...stops bmax trying to scale it. |
| ||
| mydumb ... yeah its 11mb not 110. And while you are able to load non square textures theoretically: 1. BM won't do it. OpenGL 1.2 forbids it. So BM will always black extend to the next square power of 2 2. even if it didn't, with lower end cards it makes a performance difference if it is square or not. thats something I learned on a project with B3D on Radeon 9200 cards where the difference makes a serious difference on particle textures for example. |
| ||
| And while you are able to load non square textures theoretically: 1. BM won't do it. OpenGL 1.2 forbids it. So BM will always black extend to the next square power of 2 I might be wrong here but Bmax seems to run Pow2size for width and height seperately for both DX and OGL. That suggests the textures will be translated to pow2 size but *not* necessarily square. |
| ||
| I agree with TonyG. This is how the image loaders work. [edit] Did you edit your initial post, GA? [/edit] |
| ||
| Yeah I heard the same as TonyG. Yan: no I didn't. But LoadAnimImage only works with horiztonal strips Oh I just assumed it used a long strip. So I can do vertical columns and squares yes? wow.What gave you that idea? But are we in agreement that if you load in a 30000 pixel wide anim strip, the graphics card will never touch the original strip because BMax will cut it into pieces and it's those pieces that the power of 2 rules apply to, not the original massive strip, yes? In fact is the massive 30000 strip discarded, or is it kept in memory in case the textures need to be created again? |
| ||
| The strip is split up into small pixmaps which are used by it. That are clones of the original strip but the original one is kicked unless you loaded the animimage from a previously loaded pixmap. |
| ||
| hmmm, it would be faster if bmax used the original texture and just used rect offsets...it would save a ton of texture changes. |
| ||
| But are we in agreement that if you load in a 30000 pixel wide anim strip, the graphics card will never touch the original strip because BMax will cut it into pieces and it's those pieces that the power of 2 rules apply to, not the original massive strip, yes? Yup. :o) In fact is the massive 30000 strip discarded, or is it kept in memory in case the textures need to be created again? The 'sprite sheet' is discarded and the individual ('chopped up') pixmaps are retained for building the textures. |
| ||
| smilertoo: That would be a very bad idea. For the reason mentioned above with max texture size etc. Although, there are situations we agree with you, for that reason there are drawImageArea functions in the code archives that allow you to load an image and draw subareas of it quite like DrawImageRect worked in the old blitz (BM drawimagerect is something completely different) |
| ||
| OK thanks for the clarification people. And yeah I agree, if it was retained it could have advantages but the I couldn't load in my 30000 pixel animstrip. |
| ||
| this might help for quicker anim drawings (and maybe tilesets). |
| ||
| dmaz: But LoadAnimImage only works with horiztonal strips :-( It works with any shape -- if you have a multi-row, multi-column it should automatically fall over to the next row once it hits the end of a line. Didn't BlitzPlus behave the same way? |
| ||
| Maybe BlitzPlus does too, I just totally assumed Bmax only handled a "strip" haha. Of course in the past I've coded bitmap fonts and animations from square images myself so I guess there's no reason why BMax shouldn't support it :-) |
   |