In this tutorial, we’re going to cover the Main Title Page of the game.
Following on from Tutorial 6 where we created the sprite atlas with Andy Nobles artwork, We need to construct the title page, and this is fairly straight forward as we’ll basically load the sprites from the texture atlas and drop them on the screen, towards the end of the tutorial I’ll show you a simple trick to optimise the title screen for performance and squeeze a few more cycles out of AGK BASIC.
There are a number of ways you can construct the title page, the obvious one is to create a Single Static Sprite (512 x 384), and if you didn’t need to reuse any portion of that screen again within the game then that is an acceptable method. The joy of programming means there’s usually many ways to achieve the same result, some are better than others depending on the type of program you are creating.
However, we want to re-use some of the sub sprites (i.e. the Piano, the Title Bar and of course Miner Willy’s home on the 20th level).
As our previous tutorial already created the sprites as individual images, so we can simply load these and place them on the screen.
We’re also going to add a few new files to our project :-
- MainTitlePage.agc – Draw the Main Piano Title Page.
- MainTitlePageV2.agc – Draw the Main Piano Title Page (optimised version)
- ManicDance.agc – Perform the Willy Dance when the music stops playing.
- TextHelperFunctions.agc – Miscellaneous functions related to Text/Strings.
This will draw the main title page we see in the picture above, and in version one we will simply load the sprites from the texture map and add them to the screen.
But first, some globals and constants 🙂
The constants define the positions that the filler blocks (green hills and cliffs) use to complete Miner Willy’s home. (The original artwork and Spectrum game had blank spaces where Willy’s Exit is and the platforms resides).
The global variables are :-
- g_iScrollingMessage – Text ID of the Scrolling Message
- g_iManicSpriteSheetID – Image ID of the Texture Atlas
- g_iPlayAreaOffsetX – The X Offset to centre the scene on screen
- g_iPlayAreaOffsetY – The Y Offset to centre the scene on screen
- g_iSignalScrollingMessageComplete – Signal the end of the scrolling message. (We’ll use this to start Demo mode later in the tutorial series).
This function will perform the following :-
- Delete All Sprites, Images, Text and Objects held in AGK memory (start from fresh).
- Set the Clear Colour to Light Grey
- Set the Border Colour to Black (if you are playing on a device and the screen is adjusted for a virtual screen).
- Calculate the X and Y offset to centre the GAMEBOARD of (512 x 384 Pixels) within a 640 x 480 Virtual Screen – This allows a border similar to a ZX Spectrum to be displayed.
- Load the Main Sprite Texture we defined in Tutorial 6.
- Position the sprites on the screen to create the Piano Title Page.
- Add the message to the MessageBAR, in this case “Made with AGK2”
- Set up the scrolling text message.
- before finally adding the Star of the Show “Willy” to the screen.
If you have a sprite placement editor or tool, that would be a very useful program to have to speed up game development and/or workflow, for now, I’m doing this programmatically to keep things simple.
Does exactly that! It simply adjusts the X-Position of the Scrolling Text Sprite two pixels to the left until the text is no longer visible on the screen.
When the text has fully scrolled, it additionally sets a signal to say the message has completed a cycle, reset the message back to the far right and start again.
In the real game, once the message scrolling has completed and the user has not pressed play, the game will demo each level for 5 seconds. (For now we’ll just restart the scroll).
We’ve added this function to reset the global variables and to correctly deallocate (Tear down) the Main Title Page, this will become obvious once we start adding game states.
This file contains the functions to make Miner Willy dance on the screen when the music has finished playing. We use a simple technique using SpriteFrames to create this illusion.
Of course, more Globals and Constants!
- g_iManicDance – Sprite containing the Willy Dance Frames.
- g_iWillyDanceCounter – A timer counter to adjust the speed Willy Dances.
- g_iCurrentWillyDance – (Not used)
- g_iDanceMoves as integer = [1,3,6,7,2,1,7,3] – The Dance Frame Sequence Numbers
- g_iDanceMoveP – Position in the array above.
- WILLYDANCEWAITTIME 10 – Wait 10 Frames
- WILLYMAXDANCEFRAMES 7 – reset the Pointer to 0 when this limit is reached.
This function will load the Willy Dance Sprite if it is not already available. It does assume that the main Sprite Sheet has been loaded first though.
This function will load the Willy Dance sprite if it has not been loaded already, initialise the sprite frames and set the dance counters appropriately.
This function will make Miner Willy dance by adjusting the Animation Frame according to the array g_iDanceMoves defined earlier.
- First it will decrement the Tick Counter (currently set to 10 Ticks (10/60ths or 1/6th second) before Willy changes dance position.
- The Position in the array will be incremented, and then checked to ensure it remains in the arrays bounds (g_iDanceMoves).
- Before finally getting the desired Frame to display and setting the frame appropriately.
This function simply resets the global variables to their initial startup values.
This function ensures that the Willy Dance sprite is correctly deallocated (removed from memory)
This include file adds some text helper functions that will be used within the game, and it will grow during the course of the tutorial.
We will use this later to include a retro 8 bit font for the game.
This function will take a string as a parameter and correctly centre on screen within the Message Bar graphic the text to display. In the game we’ll call this to display the level name.
This function takes a string as a parameter and creates the scrolling message we will use on the TitlePage and set the position accordingly. We also use a Text Scissor defined as the width of the game play area and the height of the text message itself. Scissors are very useful features of AGK and I think of them as inner windows to sprites, and we’ll use this a lot with the collapsing floor during the level design.
If you attempt to display a sprite outside the scissor window, it will be cut, i.e. not displayed.
Finally in main.agc we need to include the new files we’ve created :-
We also set two defaults on this project
The default Min and MagFilter sets the way that sprites are expanded/scaled on screen. As we are going for a retro 8 bit look, we don’t want anti-aliasing switched on and therefore want the sprites to look blocky. Setting this to Zero will achieve that effect.
Using the sample code of the project, look at what happens when these two are commented out. Where you see the green filler blocks positioned on the screen you will see a thin black line appear showing where the images are stitched together and clearly that is undesirable.
All that is left to do is run the code, and you will be presented with the familiar Piano Title Page!
Yes the code works, and so far it’s looking good (and that’s mainly due to Andy Nobles Artwork!) however if we dig a little deeper, we see at a basic performance level what is happening when AGK is rendering the screen frame by frame.
in main.agc I’ve added a debugInfo() function, and this performs the following :-
- Number of Sprites Drawn Count
- Number of Sprite Draws Called
- Pixels Drawn
- If there are unassigned images (images loaded but not assigned to an operational sprite)
- The number of unassigned images
- Some basic info about those unassigned images
Simply add this to your DO/SYNC() Loop to display the output.
Here we can see a bit more that’s going on under the AGK Basic covers. There are eight sprites drawn each frame and approximately 400K pixels drawn each frame. AGK performance is pretty good for an interpreted language, but surely we can squeeze some more performance out of AGK?
Currently and simply, all sprites loaded are being drawn in turn one by one every frame, and I’ve tried to represent it in the picture below as AGK layers each sprite individually.
However, the majority of the sprites remain static (Miner Willy’s Home, The Air Bar, The Piano etc) and the only sprites to move are Miner Willy himself and the scrolling text message. (until we add the piano sequence).
So how can we improve performance?
The answer is to use a simple technique to create the static sprites onto a backbuffer, copy the image created to create one sprite, and then delete the individual sprites themselves. (In a nutshell go back to the start and create one main sprite).
I have created in the project folder
This contains the changes made to optimise performance of the Title Page. In main.agc simply change the #include “MainTitlePage.agc” to #include “MainTitlePageV2.agc” and re-run the program to see the difference it makes!
So what’s changed?
We still load the individual sprites from the Texture Atlas earlier, however this time we’ve added the following :-
Swap() switches the backbuffer to the screen and clears the backbuffer ready for rendering the next frame.
We then explicitly clear the screen before calling Render() which basically draws all sprites and text to the screen. Before finally creating a new sprite
- g_iMainTitlePage = CreateSprite( GetImage(0,0,GAMEAREAWIDTH,GAMEAREAHEIGHT) )
- setspriteSize( g_iMainTitlePage, GAMEAREAWIDTH, GAMEAREAHEIGHT )
The sprite is created with the game board size (512 x 384 Pixels), and to ensure that the sprites are scaled correctly we also explicitly set the sprite size by calling SetSpriteSize() (Thanks to Paul Johnson for making me aware of this, as my original game didn’t scale properly when going full screen!)
Once this new sprite has been created, which is basically a snapshot of the screen, we delete the individual sprites loaded to free up memory, and we do this by calling the following :-
So was this extra effort worth it?
Well if we run the program again with the debugInfo being displayed we see something like :-
This has resulted in reducing the sprites drawn from 8 to 2 (only 25% draws now required), it has interestingly increased the Sprite Draw Calls to 3 – I’m not sure why. But more importantly the number of pixels drawn has reduced from 413480 to 253992 almost (40% decrease).
On a PC/Mac or Linux Machine you probably wouldn’t notice the difference this makes, but if you are targeting a lower end Android or iOS device those extra cycles can make a huge difference to frame rate and performance, especially with complex projects where you are trying to maximise the number of sprites/animations on screen.
We will continue to use this simple technique throughout the project.
Your Feedback Needed!
Going forward the project will become more complex, and I’m looking for your feedback to help shape the level of detail you want to see in these tutorials. Less info/More Info, too dry, how can I improve the quality of information to you?
Coming up next :-
Animating the Piano to play the musical notes to “The Blue Danube” or any tune you wish to code up.
Don’t forget to check us out on FaceBook https://www.facebook.com/WonkyPix
The more Shares and Likes you can help us achieve, the closer you’ll be to receiving the full source code of the project to customise your own way!
Also checkout our main website http://www.wonkypix.com, even help support us buy downloading our games from the AppStore
Thanks for tuning in!