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?

Abomination(Posted 2009) [#1]
Lets say I do:
img=createimage(31,31,rand(1,4))
how many frames does img have?


Gabriel(Posted 2009) [#2]
frames=rand(1,4)
img=createimage(31,31,frames)



Abomination(Posted 2009) [#3]
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)


big10p(Posted 2009) [#4]
Gabriel's answer still holds. Just read the amount of frames into a variable before actually creating the image.


Abomination(Posted 2009) [#5]
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.


big10p(Posted 2009) [#6]
I dont see what use such a command would have since you need to specify the number of frames when calling LoadAnimImage.


Abomination(Posted 2009) [#7]
Well, If you create an image you also have to specify the width and height.
I don't see a practical difference.


Gabriel(Posted 2009) [#8]
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.


Abomination(Posted 2009) [#9]
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?!


Gabriel(Posted 2009) [#10]
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.


steve_ancell(Posted 2009) [#11]
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




GfK(Posted 2009) [#12]
You could have written your own custom image type (including frame counter) in less time than its taken to write this thread.


steve_ancell(Posted 2009) [#13]
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.


Abomination(Posted 2009) [#14]
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.


markcw(Posted 2009) [#15]
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 frames
From: http://www.blitzbasic.com/codearcs/codearcs.php?code=1751


steve_ancell(Posted 2009) [#16]
@ 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.


Abomination(Posted 2009) [#17]
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!


markcw(Posted 2009) [#18]
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.


steve_ancell(Posted 2009) [#19]
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))



WolRon(Posted 2009) [#20]
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.


Ginger Tea(Posted 2009) [#21]
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


Beaker(Posted 2009) [#22]
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.