Is there a way to get amount of frames in Image?
Blitz3D Forums/Blitz3D Beginners Area/Is there a way to get amount of frames in Image?
| ||
Lets say I do: img=createimage(31,31,rand(1,4)) how many frames does img have? |
| ||
frames=rand(1,4) img=createimage(31,31,frames) |
| ||
hehe..Attempt number two! Lets say I do: img=CreateImage(31,31,Asc(Left$(Input$("please enter a number between 1 And 4..."),1))-48) How many frames does img have? :0) |
| ||
Gabriel's answer still holds. Just read the amount of frames into a variable before actually creating the image. |
| ||
I appreciate your efforts to try and give me an answer guys. But... Gabriel did not answer my question. My question was: "Is there a way to get the amount of frames in an Image?" The answer could be: no. (witch I presume) Or perhaps: yes. (unlikely, but perhaps someone found an "easter-egg" or something. Or some kind of workaround? I find it annoyingly strange that we have the commands: imagewidth and imageheight, but not imageframes. If you want to parse the handle of an image to a function, you don't have to supply the width or height neither. |
| ||
I dont see what use such a command would have since you need to specify the number of frames when calling LoadAnimImage. |
| ||
Well, If you create an image you also have to specify the width and height. I don't see a practical difference. |
| ||
Well, If you create an image you also have to specify the width and height. I don't see a practical difference. There's a huge difference. Images can be loaded, in which case you don't have to specify the width or height, and you need some way to retrieve it. Animated images can only be loaded by specifying the number of frames, so there should never be a situation where you don't know how many frames there are in an animated image. |
| ||
That doesn't make my point less valid. It sustains the impracticality of the whole. Reasoning like that one could also say that "loadimage" should have the width and height specified, because we need certain dimensions to fit in our 2d-map or other framework. Or, i.o.w. If I can keep track of the number of frames, why cant Blitz?! |
| ||
That doesn't make my point less valid. Sorry, but the fact that there is a practical difference does make your point less valid if your point was that there is no practical difference. It sustains the impracticality of the whole. Are you using Babelfish? That makes no sense in this context. Reasoning like that one could also say that "loadimage" should have the width and height specified, because we need certain dimensions to fit in our 2d-map or other framework. No, that would be completely different reasoning. The width and height don't have to be specified, because they are specified in the image. There is only one possible width and height. Number of frames does have to be specified because it is *not* specified in the image. An image of 1024x1024 could include 4 512x512 frames, 16 256x256 frames or endless other combinations. Or, i.o.w. If I can keep track of the number of frames, why cant Blitz?! It would be more pertinent to ask if you can keep track of the number of frames, why don't you? Blitz *is* keeping track of the number of frames. If it wasn't your animations would show up all wrong. It just isn't bloating the API with a hundred commands to get things you should already have. There are many, many extra needless functions like this which could be added simply to retrieve data you must already have. Seriously, do you need help or are you just looking for an argument over something trivial? If it's the former, I'm happy to take time to help. With the latter, you can play alone. |
| ||
Here's how I normally do it, if I have understood what you are after.Global image_strip = LoadAnim("tiles.bmp", 32, 32, 0) anim_size = GetAnimSize(image_strip) Print anim_size WaitKey() End Function LoadAnim(file$, tile_w, tile_h, first_frame) temp_image = LoadImage(file$) across = ImageWidth(temp_image) / tile_w down = ImageHeight(temp_image) / tile_h anim_size = across * down anim_strip = LoadAnimImage(file$, tile_w, tile_h, first_frame, anim_size) Return anim_strip End Function Function GetAnimSize(image) frames = 0 Repeat If Not ImageBuffer(image, frames) Then Exit frames = frames + 1 Forever Return frames End Function |
| ||
You could have written your own custom image type (including frame counter) in less time than its taken to write this thread. |
| ||
GfK... I did think of using a Type, but I thought I would try to be cocky instead. LOL Your way does sound better though. |
| ||
Steve.. your loadanim-function works fine. And I was trying to use Imagebuffer the way you do in GetAnimSize, but I get a "Image frame out of range" if I try it like that. If it DOES work, it would be my salvation. ;) Pardon me for my bad Engrish, my babelfish drowned last night. ;) Let me assure you that my question is meant sincerely. It's just that I have the tendency to annoy people, by criticizing their well meant comments and advice. Sorry about that, for now and for in the future.(it's a bad habit) Not that I didn't mean what I said, because I do... It depends with what assumptions someone takes on a certain problem, that someone else can measure the meaning of his words. And so... Up to the problem at hand. I'm working with a few of my friends on a few projects, and the guy that does most of the file-handling and Imagework, return his functions with pointers to banks, in witch he stores all kind of things, including imagehandles. And now we have come to the conclusion that it is necessary to use Anim-images as well... ;/ Well... and there you have it. Of course we could rewrite stuff so we would take handles to anim-images into account, but that would be a LARGE amount of work. Is it silly to do it like this? Yes, but it's a hobby, not a profession. So to have something like Steve's GetAnimSize, would be a great help. |
| ||
I never thought it was any use but here.image=CreateImage(width,height,frames) BufferList=PeekI(image+4) ;pImageBufferList BufferListEnd=PeekI(image+8) ;pImageBufferListEnd numframes=(BufferListEnd-BufferList)/4 ;Number of image framesFrom: http://www.blitzbasic.com/codearcs/codearcs.php?code=1751 |
| ||
@ Abomination. Thank you for the kind reply, I use them two functions on regular occasions. GfK is a more experienced programmer than me though, and his work is very impressive. |
| ||
markcw... That works like a charm! You have my utmost gratitude. Realy! This will save us weeks of work. One 'little' thing though.. your "peekpoke example" only works for me correctly, if I add width and height(when loading "test.bmp") and lower 'UnlockBuffer buffer' to in-between 'endif' and 'While Not KeyDown(1) ;Esc key' Thought I'd mention it... cheers! |
| ||
Nice to know it's useful to someone. Never noticed the loadimage section doesn't work, oops. The lock/unlock buffer thing is an internal thing, if you don't lock you won't get a valid pointer to the stuff after it. Unlocking straight after worked when I wrote it, but yeah, to ensure the stuff is valid when accessing it unlock after. |
| ||
This is another one of my functions, I sometimes use.Function GetTileCount(filename$, tw, th) temp_image = LoadImage(filename$) across = (ImageWidth(temp_image) / tw) down = (ImageHeight(temp_image) / th) count = (across * down) FreeImage temp_image Return count End Function Usage of the function would be something like.... Global anim_strip = LoadAnimImage(file$, tile_w, tile_h, first, GetTileCount(file$, tile_w, tile_h)) |
| ||
An image of 1024x1024 could include 4 512x512 frames, 16 256x256 frames or endless other combinations. I think you answered your own question right there. An image CAN conceiveably contain dozens of different frame counts limited only by your use of them. So, an exact frame count is not really possible unless YOU specify frame dimensions. |
| ||
normally blitz needs you to tell you how many frames, hence why the first posts were more WTF? and yes an image can have more combinations of frames this method only works if you have a constant size of frames throughout the image and when loading the image define the frame size and it will tell you (or itself) how many possible frames can be made but is it in a way still more of a WTF? you have the image you have the number of frames on it, you have animstrip but hey you can program things to seem like there going the wrong way about it or reinventing the wheel, but if it works it works |
| ||
Just wrote this quickly: Seems to work fine for this image: Should work for lots of sprite images. It could be improved by: 1) ignoring any blank frames towards the end. 2) locking buffers and using readpixelfast. |