GETANIMSIZE and GETANIMFRAMES

[AndyH]

Could we have a GETANIMSIZE command to return the size of a frame in an ANIM Sprite, much like GETSPRITESIZE returns the size of a sprite.  Run this command on an anim, and it returns the total size of the graphic, not the size of a frame within - which is correct.  Would be useful to have a separate command to get the size of an anim frame.

In addition, could we have a GETANIMFRAMES command to return the number of frames in the animation?

[bigsofty]

I dont like the way the sprite commands have been branching since the introduction of "LOADANIM". Personally I don't use it as I have easily produced its functionality using the existing commands(GRABSRITE) and therefore in my opinion it was an unnecessary addition. If it is to stay then it should have just produce a bunch of sprites , then it would at least be compatible with the current Sprite manipulation commands, as it stands now, were duplicating, functionality wise, a lot of basic commands, which is wasteful, confusing to the beginner and moreover it is simply "Illogical Captain!" as Spock would say.

That's my 10p

[AndyH]

Making them load into separate sprites is in totally the opposite direction for why they were requested in the first place.  I guess you can just ignore these commands if you don't want to use them.  

Single sprite frames were a weakness of GLB ... IMHO.  Coming from other languages designed to help you make games, they all provide the ability to handle animations.  Forcing the developer to manage large lists of single sprites for animations will always be messy and lead to problems when you try to do anything of any scale no matter how careful you are, or how many wrappers you write to try to manage all the sprite Id's.  And why should the developer have to write wrappers?  This is non-standard, bespoke to your own code and does not help to share code across the community.  So I'm glad we have LOAD/DRAW ANIM and I think it needs expanding.

To be honest, I do not like having separate commands either.  If GLB could handle optional parameters the existing commands could be used with just an additional 'frame' parameter (or 'width' and 'height' in the case of LOADSPRITE).  If you exclude these, GLB acts as it does now.  If you supply them, GLB knows to apply it to a specific frame.   But I can live with separate commands if it means we get this functionality.  Actually I think Gernot has made a good choice in the naming of the new commands.  SPRITE's and ANIM's are easy to understand, as long as the documentation is there, then there is not a problem.

Again, I know you can write your own functions to try to abstract anything, but things can easily get messy - example: previously you had sprites 58 to 92 as a sequence of animations for the player facing a direction, this repeating for other directions in sprite 93 upwards...then you have sprites for other animations and level map tiles.  You have large number of Id's for sprites which each Id means something specific but it's all awash and mixed in to this massive global pool of Ids.  So then you want to add another 20 frames of animation to your players animation - eek!

Well you could put wrappers around every GLB sprite related command and use a function like 'GetImageID:' (to find the next available sprite Id) to decide what the sprite Id's are.  You then need to keep track of these in your game logic.  There's many work a-rounds you could code, my preference would be to make a type that held the required information and create an array of this type - then each index in the array can represent my objects but here we are again re-inventing the GLB code to do something it currently does not do, and not in a very nice way.  LOADANIM and DRAWANIM do this and are simple. If GLB was an OOP type language we could maybe just extend the current GLB commands to add the extra functionality, but it's not and that's one thing that I guess keeps GLB simple and easy to use but at the expense of duplicate commands.

GLB needs strong animation support, more so than single sprites, plain and simple.  It's a fundamental part of the majority of games.  So LOAD/DRAW ANIM are a must to give more power and make it simpler IMHO.  These are things that need to work out of the box and provided by GLB, not for the developer to re-invent the GLB functions as they are fundamental to making things easier and simpler for the game developer.  Keeping the command set down is not necessarily something for GLB to aspire to.  Providing easy and logical ways to solve a problem, in a cross platform compatible way and maintaining readability is something I feel GLB should aspire to do and if that means more functionality you won't hear me complain.

I'm sure there could be other possible answers to providing the best of both worlds for us developers.  For example, separate sprites could make sense if a 'sprite bank' was a bit like an array you could define.  Consider DIMSPRITE myPlayer[]; DIMSPRITE mySceneryTiles[]; DIMSPRITE myEnemySprites[] --- three separate sprite banks (of my choosing as the developer) to hold Id's starting at 0 counting up in each sprite back array.  No mixing up players, with scenery, with enemy, with ... and so on.  Sorry for rambling on, love the LOADANIM solution, don't drop it or dilute it please!  We need ANIM's to do what single SPRITES can do though, then it will be complete.

I love GLB so far, but it's got plenty of room to grow into a more mature programming language so I would not want to hold that back.  That's my 10 pence worth

[Kitty Hello]

OK, GETANIMSIZE might be interesting. But do not ask me of ROTOZOOMANIM. That'll explode my head for PocketPC/GP2X .

[PeeJay]

I have to side with Andy on the animated frames argument - especially as I have also come from a language that has support for this type of coding.

To put things into some sort of perspective, I am now investigating the possibility of converting one of my WIPs over to GLBasic, but there are 1328 separate graphical frames of animation involved (plus an extra 2050 for additional graphics sets). There is no way on earth I would even consider such a move without having animated frames, as keeping tabs on this number of graphics would be worse than a nightmare!

[Schranz0r]

OK, GETANIMSIZE might be interesting. But do not ask me of ROTOZOOMANIM. That'll explode my head for PocketPC/GP2X .

With POLYVECTOR?

[bigsofty]

Im still against these new commands, there already in, with a little programming backup to the current commands.

For example here is a TileSet (LOADANIM) cutter in only a few lines which I banged together...

Code (glbasic) Select Expand

FUNCTION LoadSpriteMap: Filename$, SprBase, SprAmount, PadCnt, StartX, StartY, SprW, SprH, GrabDirec // Possibly background Pink flag for PNG's?

LOCAL i, Cols = 0, Rows = 0, Down = 0, Across = 0, ImgW, ImgH, GrabX1, GrabY1, GrabX2, GrabY2

LOADSPRITE Filename$, SprBase
BLACKSCREEN // < May need a FILLRECT Pink for PNGs?
//ALPHAMODE -.999
DRAWSPRITE SprBase, 0, 0
GETSPRITESIZE SprBase, ImgW, ImgH

WHILE i < SprBase

GrabX1 = StartX+(Across*(SprW+PadCnt))
GrabY1 = StartY+(Down*(SprH+PadCnt))
GrabX2 = StartX+(Across*(SprW+PadCnt))+SprW - 1
GrabY2 = StartY+(Down*(SprH+PadCnt))+SprH - 1


IF (GrabX2+PadCnt > ImgW - 1) OR (GrabY2+PadCnt > ImgH - 1)
IF GrabX2+PadCnt > ImgW - 1
Across = 0
StartX = 0
INC Down, 1
ENDIF
IF GrabY2+PadCnt > ImgH - 1
Down = 0
StartY = 0
INC Across, 1
ENDIF
ELSE
GRABSPRITE SprBase + i, GrabX1, GrabY1, SprW, SprH
INC i, 1
IF GrabDirec = 0
INC Across, 1
ELSE
INC Down, 1
ENDIF
ENDIF

WEND


ENDFUNCTIONThis can load different sized sprites/tiles on the same sheet, cut sequentially horizontally or vertically from anywhere on the sheet(both with wrap), add a padding space for removing grid lines etc...

My point is that this works with the current command set and produces SPRITES, therefore all the current command for rotating and stretching the sprites work fine... so you can see for me how to repeat functionality that is already available, with a little programming, is a bit unnecessary.

Dunno if that very clear, Im not heavily against this subject to the point I want to flame it out, so I just clam up if people in general want to go down the LOADANIM, ROTOANIMZOOM, MAKETEAANIM root... hehe

[AndyH]

That's cool.  But isn't LOADANIM "file.png", sprId, w, h much simpler?  For now I have created a wrapper to give me the functionality I need until a full set of ANIM commands are available.

Code (glbasic) Select Expand

FUNCTION oLoadAnim: _file$, _w, _h, _maxframes, _midHandle
LOCAL t AS OSprType
LOCAL num
    LOADANIM _file$, 0, _w, _h

LOCAL i
FOR i=0 TO _maxframes-1
DRAWRECT 0,0, _w,_h, RGB(255,0,128) // transparent colour
DRAWANIM 0, i, 0,0
LOCAL nextSprite
nextSprite = _GetNextSpriteID()
IF t.id = 0 THEN t.id = nextSprite
GRABSPRITE nextSprite, 0,0, _w,_h
NEXT
    t.maxframes = _maxframes
    IF _midHandle
    t.hx = t.w/2
    t.hy = t.h/2
    ELSE
    t.hx = 0
    t.hy = 0
    ENDIF
    DIMPUSH oSprites[], t
    LOADSPRITE "", 0 // clear out temporary sprite from memory
    BLACKSCREEN
    RETURN _GetNextOSprID()
ENDFUNCTIONBasically I'm striping out the animation frames into separate sprites so I can scale and rotate them as a temporary measure.  I have put a wrapper around everything that involves drawing sprites so I never touch sprite Id's or need to know what the boundaries are so hopefully that will reduce the headaches when things change in my game.

On the plus side I've got in some extra functionality such as some BMax commands (SETROTATION, SETSCALE, SETCOLOR and SETHANDLE) but I'd still use these (but with less code) once the ANIM commands are all present.

BTW, I'm using LOADANIM (in sprite Id 0 which I reserve for temporary manipulations like this) as this will let me have sprite animation frames the size of the screen rather than limiting the max size of my tilemap graphic to the size of the screen.  That issue can still be solved in a number of ways, but already LOADANIM could be your friend even if you don't want to use the full ANIM command set.

So please, yes, let us get the full set of ANIM commands we need to make our life easier and simpler rather than add layers that aren't necessary

[bigsofty]

Ah, I see you point I was going to use CREATSCREEN but I'm unsure if the > screensize bug had been fixed with it yet?

Well, the current commands arn't much use to me, I've various sprites animation, starting at different positions on the page and each can have different frame width and heights within the one page. So with increasing simplicity comes reduced flexibility but that's not really my point. Its really down to a matter of wether GLB needs extra commands that can easily be satisfied by the current command set, in my opinion this is the case.

But maybe thats just it, a matter of opinion, what may be no use to me may be of great use to another, cie la vie!