Turning ifsoGUI into a killer GAME UI

Pick 'Em
Monday Night
Survivor

[matibee]

As I said earlier, ifsoGUI has 90%of the the functionality of an OS UI making it perfect for game editors but please bear with me as I make some suggestions on how to turn it into a really saleable GAME UI....  These are not major additions and they could be made quite quickly IMHO;

• 1. A tri-state bitmap button

If I have three glitzy images for 'normal','hover' & 'down', maybe even multiple frame anim images, they are going to look a lot more exciting than a GUI button.

• 2. Bitmap fonts

I'm not really keen on using bitmap images with text embedded in them because I have an eye for localisation.  I'd recommend allowing some controls to use a bitmap font caption (using Mike Wiering's bmfont module).

• 3. Animations

Game UI's rarely sit still!  Some animation could come from using the animated tri-state button, but generating lots of frames is hard work.  I have a better way.

• 4. Transitions

Game UI's don't just appear or disappear!  Animated transitions would be tied to a form for show and hide time.  When each transition had played through, the UI would fire an event (eg "HIDECOMPLETE") and then the coder would know to "show" the next form.

• 5. Sounds

If you could take control of sounds for the user many users would use it.  If they have a specialised sound system they could still resort to playing their wn sounds during the event processing.
[/list]

Don't rely on users adding this kind of functionality by deriving their own gadgets.  This would be perfect for beginner users and that's where a lot of your customers will come from.

For animations I've coded a simple animation controller.  Actions are hard coded internally and I currently have code for LINEAR LERP, ACCELERATE, SIN CURVE & BOUNCE.  The parameters are loaded from a basic text file (start up values & the action to perform).  This means I can optionally load an animcontroller for X, Y, Rotation, Scale and Alpha.  When the UI is updated it has to update all the animcontrollers and when it's drawn it looks to the controllers for the current values.  I didn't just code this anim system for my UI code though, I use it on sprites all the time.

It might be better if you simplify this system by supplying pre-made transitions and animations;  Fly-in/out, fade-in/out for forms, color/alpha glow for buttons.

You've got all the complex stuff in place so this is just glitz for game makers, rather than for tool developers.  I've not seen any of the other blitz GUI's provide this kind of functionality (though my testing with them has been limited to downloadin the demo's).

[TaskMaster]

Thanks for the feedback.  Most of this is already on the todo list.

1. A tri-state bitmap button
If I have three glitzy images for 'normal','hover' & 'down', maybe even multiple frame anim images, they are going to look a lot more exciting than a GUI button.

Image buttons are on the todo list.

2. Bitmap fonts

This is also on the todo list.  The only issue with this is choosing a system to support.

I thought about making some generic font calls that the user could override, so they could use any font system they wanted to.  There are only a few font drawing functions as it is.  TextWidth, TextHeight, DrawText, etc...  If i made an ifsoGUI type that the user could override, then you could use ANY font system you wanted to.  Then the gadgets could have a generic font object that the user could assign their font for each gadget to.

I will look at the font system you mentioned, but there are so many of them, it is hard just to choose to support one of them.  I have used ziggy's FontMachine and had considered using that one.  The problem with directly supporting one is that the author may quit developing it, then you are kinda left with trying to fix/improve it yourself, or having to take the time to switch the entire thing to a new one.

4. Transitions
Game UI's don't just appear or disappear!  Animated transitions would be tied to a form for show and hide time.  When each transition had played through, the UI would fire an event (eg "HIDECOMPLETE") and then the coder would know to "show" the next form.

True, but it is just so easy to do this yourself.  There are just soooo many transitions that could be done.  It is hard to just say, I'll make two.  You could grow a window from any direction, you could fade in or out to/from transparent, slide it in from a direction, etc.  All easily done by the user.

Maybe it would be better to just put together some samples of transitions.

5. Sounds
If you could take control of sounds for the user many users would use it.  If they have a specialised sound system they could still resort to playing their wn sounds during the event processing.

This is also something that is on the todo list.  Can you suggest what events would have sounds?  Mostly just clicking?

For animations I've coded a simple animation controller.  Actions are hard coded internally and I currently have code for LINEAR LERP, ACCELERATE, SIN CURVE & BOUNCE.  The parameters are loaded from a basic text file (start up values & the action to perform).

Other than an animated button, what else could be animated?

[matibee]

1. Image buttons - So you're not just thinking of the bitmap button that's a normal UI looking button with icons instead of text.  Just to be clear I'm talking about the images being the entire graphic.

2. Bitmap fonts.  Agreed it's difficult to to know what to do.  I believe the bmfont module I pointed out is licensed quite liberally and comes with source (I've even had to fix an issue with it recently).  So you could control it from that respect.  I don't think the Angel code tool will go away anytime soon (I've seen the author on GameDev for over 10 years now).

4.  Transitions.  Ok there are options, but that doesn't mean you shouldn't supply some out of the box.  If there was fade-in/out and fly-in/out I'd still expect to have control over the fade to/from color, the fly direction and speed.  The system needs to support this though with a "HIDECOMPLETE" notification event otherwise it's a pita for users to keep track of.

5. Sounds.  Everything would have a sound.  Mouse over, click, form show and hide (transitions! ).  Have a look at the BigFishGames' UI's. Now if there was a gadget.SeteventSound( filename$ ) your system would have to keep a handle on all the loaded files and instance them so as not load dozens of the same sound file.

Other than an animated button, what else could be animated?

Well I use those script systems on anything;  personally I'd like them for form show/hide transitions.  They're also useful for really lively buttons.  For example, a mouse over animation might cause the button to repeatedly grow/shrink in scale.

[TaskMaster]

1. Image buttons - So you're not just thinking of the bitmap button that's a normal UI looking button with icons instead of text.  Just to be clear I'm talking about the images being the entire graphic.

This is quite easily done.  All there needs to be is a ShowButton property.  If on, the image is on a standard button, if off the standard button is not drawn under the image.

2. Bitmap fonts.  Agreed it's difficult to to know what to do.  I believe the bmfont module I pointed out is licensed quite liberally and comes with source (I've even had to fix an issue with it recently).  So you could control it from that respect.  I don't think the Angel code tool will go away anytime soon (I've seen the author on GameDev for over 10 years now).

I will take a look at it.  But, I still believe just making the Text functions overridable would make the whole thing easy.  Then you could use any font module you wanted to.  And if you didn't override them, then it would use the standard BlitzMax functions.

4.  Transitions.  Ok there are options, but that doesn't mean you shouldn't supply some out of the box.  If there was fade-in/out and fly-in/out I'd still expect to have control over the fade to/from color, the fly direction and speed.  The system needs to support this though with a "HIDECOMPLETE" notification event otherwise it's a pita for users to keep track of.

Understood.  Could just be a TransitionWindow gadget.  It would just subclass the standard window and have some transition features built in.  This way, if you didn't want them, they wouldn't even be there.

5. Sounds.  Everything would have a sound.  Mouse over, click, form show and hide (transitions! ).  Have a look at the BigFishGames' UI's. Now if there was a gadget.SeteventSound( filename$ ) your system would have to keep a handle on all the loaded files and instance them so as not load dozens of the same sound file.

I see.  This is also easily accomplished.

Would it really need a SoundManager?  This is fairly easy to do.  If you load a sound, then you just set the Sound property of the gadget equal to that sound.  You are just using pointers.  The user would be able to just use whatever sound manager they are using them self.

'Pseudo code
ClickSound = LoadSound("MySound.wav")
btn1.SetClickSound(ClickSound)
btn2.SetClickSound(ClickSound)
btn3.SetClickSound(ClickSound)
etc...

All of this would only load the sound once and just pass the pointer to each object.  Even if the original ClickSound variable was local and went of out scope, the references to it would continue to exist and keep it from being removed by the garbage collector.  Do you really believe the GUI should handle this?  And have a SoundManager built into it?

Other than an animated button, what else could be animated?

Well I use those script systems on anything;  personally I'd like them for form show/hide transitions.  They're also useful for really lively buttons.  For example, a mouse over animation might cause the button to repeatedly grow/shrink in scale.

Obviously the transitions would need user controlled properties like speed, and colors, and whatever they use.  And an AnimatedImageButton would have properties for that as well.  But what other gadgets would be animated?  All of them?  You want checkboxes that animate?  ComboBoxes?  etc?  That is quite a bit of work?  Would probably be best to subclass the original gadgets and make each of those animated gadgets their own gadget.  Definitely something to that could be done.  Once the first one was done, the rest would probably just flow easily.  Would require an imagestrip for each one.  Hmmm...

[matibee]

(I typed a reply yesterday but my mobile broadband really struggles to load this forum)

Sounds;  Yes your sample would work perfectly well.  I'm an old C/C++ programmer who's still not fully thinking in BlitzMax.  After giving it more thought I actually think the user could just assign sounds to the entire GUI and not to an individual gadget.  Sounds for Mouse Over and Click should be enough.  Any others and they can use the events to process their own.

GUI sounds are a major part in game ui's so I think it's right for ifsoGUI to provide some core functionality.

Animation;  The only things that require animation are the form transitions and that bitmap button I'm looking for.  It seems pretty pointless trying to animate everything else.  I'll do a little mock exe to show what I expect the bitmap button to do.

[TaskMaster]

(I typed a reply yesterday but my mobile broadband really struggles to load this forum)

Sounds;  Yes your sample would work perfectly well.  I'm an old C/C++ programmer who's still not fully thinking in BlitzMax.  After giving it more thought I actually think the user could just assign sounds to the entire GUI and not to an individual gadget.  Sounds for Mouse Over and Click should be enough.  Any others and they can use the events to process their own.

GUI sounds are a major part in game ui's so I think it's right for ifsoGUI to provide some core functionality.

Animation;  The only things that require animation are the form transitions and that bitmap button I'm looking for.  It seems pretty pointless trying to animate everything else.  I'll do a little mock exe to show what I expect the bitmap button to do.

OK, I think having global sounds for MouseOver, and Click, or maybe MouseEnter, MouseOut, and Click (maybe even MouseDown and MouseUp) would be good and easy to do.  Then it is just a matter of deciding which gadgets should process them.  Obviously you won't want panels or windows having the sounds, as the mouse entering a panel should not do a sound.  But most other gadgets should, like checkbox, combobox, etc.  Maybe each gadget should just have a parameter for which sounds it plays.  Would be easy to add, as it would just need to be put into the basegadget, since all the other gadgets subclass it.

[matibee]

Here's a simple example.

It uses fixed bitmaps for the button states and the animations are tweaks of the scale or position.  Add a bit of sound and you've got a polished looking Game UI.

[TaskMaster]

Here's a simple example.

It uses fixed bitmaps for the button states and the animations are tweaks of the scale or position.  Add a bit of sound and you've got a polished looking Game UI.

OK, I see.

Not just animation frames, but also moving and scaling the graphic with or without animation frames.

No problem, shouldn't be too difficult to work that out.

[matibee]

Perhaps it's simpler for you to provide the bitmap button gadget with callbacks for pre- and post draw.

It'd be easy to give newbies samples of how to achieve those effects in the pre-draw callback (plus it would allow many more effects too) and the post-draw callback could be used to add caption text using any font system they like as you suggested.

I like to get carried away with allowing too much sometimes and then I have to come up with scripting to support the multitude of options that become possible.  I'm sure you'll take a more measured approach.

[TaskMaster]

Perhaps it's simpler for you to provide the bitmap button gadget with callbacks for pre- and post draw.

It'd be easy to give newbies samples of how to achieve those effects in the pre-draw callback (plus it would allow many more effects too) and the post-draw callback could be used to add caption text using any font system they like as you suggested.

I like to get carried away with allowing too much sometimes and then I have to come up with scripting to support the multitude of options that become possible.  I'm sure you'll take a more measured approach.

That is an interesting idea, but really, it then isn't any different than extending the gadget, and making your own Draw method like this:

Method Draw(parX:Int, parY:Int, parW:Int, parH:Int)
'Do your pre-stuff
Super.Draw(parX,parY,parW,parH)
'Do your post-stuff
End method

Which is probably just the best way to handle it all around.  Does that seem like it might be a good idea?

[matibee]

Ok, agreed.  As long as my new type only has to derive a new Draw method and ifsoGUI handles everything else

[TaskMaster]

Ok, agreed.  As long as my new type only has to derive a new Draw method and ifsoGUI handles everything else

Yes, that would be enough, that is how extending types works.

There may be other things you would want to change as well.  But it would be up to you.  When I write up a tutorial on making a gadget, you will see what I am referring to.  It is actually quite easy, once you know the technical details behind what each of the methods do.

[matibee]

I managed to code the bitmap and animated bitmap buttons as types derived from ifsoGUI_Button.  I'm not a BMax pro so some of what I've done may be wrong, so is this correct?

I'd like to have done away with the Create function and used ifsoGUI_Button's instead, how do I know I've initialised everything?

This uses the images attached previously.

Code:

SuperStrict

Import ifsogui.GUI
Import ifsogui.button

' Simple tri-state bitmap button..
Type myBitmapButton Extends ifsoGUI_Button
Field images:TImage[3]

Function Create:myBitMapButton ( iX:Int, iY:Int, iW:Int, iH:Int, strName:String, strLabel:String )
Local but:myBitmapButton = New myBitmapButton
but.SetXY( iX, iY )
but.SetWH( iW, iH )
but.name = strName
Return but
End Function

Method SetImages ( normal:TImage, over:TImage, down:TImage )
images[0] = normal
images[1] = over
images[2] = down
End Method

Method Draw(parX:Int, parY:Int, parW:Int, parH:Int)
Local iX:Int, iY:Int
GetAbsoluteXY( iX, iY )
DrawImage( images[ CurrentImage() ], iX, iY )
End Method

Method CurrentImage:Int ()
Return MouseStatus( MouseX(), MouseY() )
End Method
End Type

' Animated button that moves left/right on mouse over
Type mySquiggleButton Extends myBitmapButton

Method Draw(parX:Int, parY:Int, parW:Int, parH:Int)
Local iX:Int, iY:Int
GetAbsoluteXY( iX, iY )
iX :+ GetW() / 2
iY :+ GetH() / 2

Local xOffset:Int

If ( CurrentImage() = 1 ) xOffset = Sin( MilliSecs() ) * 4

DrawImage( images[ CurrentImage() ], iX + xoffset, iY )

End Method

Function Create:mySquiggleButton ( iX:Int, iY:Int, iW:Int, iH:Int, strName:String, strLabel:String )
Local but:mySquiggleButton = New mySquiggleButton
but.SetXY( iX, iY )
but.SetWH( iW, iH )
but.name = strName
Return but
End Function
End Type

' Animated button that scales up/down on mouse over
Type myBouncyButton Extends myBitmapButton

Method Draw(parX:Int, parY:Int, parW:Int, parH:Int)
Local iX:Int, iY:Int
GetAbsoluteXY( iX, iY )
iX :+ GetW() / 2
iY :+ GetH() / 2

If ( CurrentImage() = 1 )
Local scaleX:Float, scaleY:Float
GetScale( scaleX, scaleY )
SetScale ( 1 + Sin( MilliSecs() ) / 50, 1 + Sin( MilliSecs() ) / 50 )
DrawImage( images[ CurrentImage() ], iX, iY )
SetScale( scaleX, scaleY )
Else
DrawImage( images[ CurrentImage() ], iX, iY )
End If
End Method

Function Create:myBouncyButton ( iX:Int, iY:Int, iW:Int, iH:Int, strName:String, strLabel:String )
Local but:myBouncyButton = New myBouncyButton
but.SetXY( iX, iY )
but.SetWH( iW, iH )
but.name = strName
Return but
End Function
End Type


SetGraphicsDriver GLMax2DDriver()
Graphics(640, 480)
GUI.SetResolution(640, 480)
GUI.LoadTheme("Skin2")
GUI.SetDefaultFont(LoadImageFont("Skin2/fonts/arial.ttf", 12))
GUI.SetDrawMouse(True)

AutoMidHandle( True )
Local myButton0:myBouncyButton = myBouncyButton.Create( 120, 120, 300, 100, "btn0", "" )
myButton0.SetImages( LoadImage( "b0.tga" ), LoadImage( "b1.tga" ), LoadImage( "b2.tga" ) )
GUI.AddGadget( myButton0 )

Local myButton1:mySquiggleButton = mySquiggleButton.Create( 120, 220, 300, 100, "btn1", "" )
myButton1.SetImages( LoadImage( "b0.tga" ), LoadImage( "b1.tga" ), LoadImage( "b2.tga" ) )
GUI.AddGadget( myButton1 )

SetClsColor 255,255,255

While Not AppTerminate()
Cls

CheckEvents()
GUI.Refresh()

Flip 0
Wend


Function CheckEvents()
Local e:ifsoGUI_Event
Repeat
e = GUI.GetEvent()
If Not e Exit

If e.gadget.Name = "btn0" And e.id = ifsoGUI_EVENT_CLICK

End If
Forever
End Function

The forum needs a codebox

[TaskMaster]

I'll see if there is a mod for a codebox on SMF.  

As for how you did it, that probably won't work exactly as is.  Pretty close though, that is the right idea and a good start.  I will look at what you got, work it out and post it when I get a chance.  Maybe later tonight or tomorrow morning.

As for the create, you can't use the ifsoGUI_Button.Create Function because it returns a ifsoGUI_Button type and not your type.  Of course, you don't even have to have a Create if you don't want to, but it is probably best to keep everything working the same way.

[TaskMaster]

(Part 1 of 3).
This is going to be in three posts, because I think there is too much text for one post.  I keep getting errors when trying to post it...

Started looking at your code.

First, you can't really use the images handle in the middle.  It throws off other functions that monitor whether or not you are drawing out of bound, so drawing has to be from the top left corner (0,0).  So, your images have to have SetImageHandle(image,0,0).  I know this is kind of a pain in the butt, but trust me, it makes a lot of other stuff easier in the GUI, like making sure images don't leave the bounds of their parent.  

Second, the parents X and Y are passed into the Draw Routine so you don't have to use GetAbsoluteXY().

Third, when drawing, you want to use ifsoGUI_VP.DrawImageArea() and ifsoGUI_VP.DrawImageAreaRect().  These are overriding functions of the DrawImage and DrawImageRect functions, that make sure you do not draw out of bounds.  So, when drawing at the edge of a panel or window, the graphic does not draw across the border and out of the parent gadget.

By the way, nice use of MouseStatus() to pull the status of the gadget for whether the mouse is over it or not, very tricky, but isn't necessary (I know you had no way of knowing).  But, MouseStatus is only suppose to be called to the ActiveGadget, so it won't return the correct value all of the time.  I put the correct code in though.

One last tip, you really should cut the extra space out of your images.  The hit area is based on the size of the image, so if you cut the extra border stuff out, the detection area of when the mouse is over the image will be much closer.  It would be possible to override this as well, and make the hit detection on your images much more accurate.  Would take a bit of work to figure out how to do it exactly, since you wouldn't want to use the built in collision detection of BlitzMax (or maybe you would)...