Sorry I didn't reply sooner, I've been away all weekend doing Aikido.
@Sean Doherty:
Yes generally there is a different screen for each state, but that's just how I've decided to make the AOTMG demo, you could use the same Types and do it differentlly. For example, the in-game menu is a TScreen that is shown on top of the TGameScreen.
1) Good question. The answer is both. Lots of graphics are loading on the loading screen when the loading bar moves across. However, they are kept in global lists and when the game screen and other screens need them, they are assigned to the objects. When the screens are destroyed, the links are killed but the graphics are still in the global store. However, other things are loaded dynamically and destroyed dyanmically like the menus and screen backgrounds for example. You can actually choose to do fully loaded or dynamic, or a mixture like I have. This will depend on the size of your graphics data, and if you want to interrupt the user with loading screens or not of course.
2) Remember it's up to you how much of the AOTMG code you want to use in your game, or if you just want to use the framework components. There is a TGameScreen Type in the AOTMG demo code, plus there is a TPlayer, TAlien, TBullet etc and lists to contain stuff. These are all fields of TGameScreen however, there is nothing to stop you making them global if you prefer.
3) I have examples of collision detection built into the framework (in the AOTMG demo) (e.g. lists of sprites placed on a layer and objects tested against the layer) and some useful collision functions in my commoncode.bmx file. However, the code framework doesn't have any collision code built in as the BMax collision code works well and people will want to use it in different ways. Do you think I should add some specific functions?
Thanks for your interest. Any more questions? Just ask.
WarpZone: oops sorry for the misunderstanding. I am just an affiliate for selling Absolute Blue, I liked it and so it's on my site but I didn't make it. Sorry :-( And yes, there is nothing in that game you couldn't do with my framework. All the other stuff on the site is by me, BUT it's in Blitz Plus not BMax so it's not a decent measure of what the framework can do. I moved to BMax as it's much more powerful and will help me achieve my game developement goals. Watch out for a game called Sudoku Maya Gold coming out soon (it'll be on the forums), this was totally rewritten in my framework by Gellyware in order to get on some big portals and it is looking sweet! Also, as you've identified, sprites can be animated at any framerate and the whole system is geared so it doesn't matter what Hz the screen is using, the anim will be the same. As for the multi-part anims, this is actually in evidence by simple things like the high scores screen. The scores that slide on the screen use 3 parts: 1 a delay in order to stagger the lines, 2 the slide itself, 3 a flash of colour when in the final position. This same thing can be applied to sprites of course. Finally, my new match-3 game will have plenty of animations in it and I've added a basic particle engine to the framework too (not released yet) and it's due out in August sometime... Anyway thanks for your interest, I hope you buy it :-)
@Sean Doherty:
Yes generally there is a different screen for each state, but that's just how I've decided to make the AOTMG demo, you could use the same Types and do it differentlly. For example, the in-game menu is a TScreen that is shown on top of the TGameScreen.
1) Good question. The answer is both. Lots of graphics are loading on the loading screen when the loading bar moves across. However, they are kept in global lists and when the game screen and other screens need them, they are assigned to the objects. When the screens are destroyed, the links are killed but the graphics are still in the global store. However, other things are loaded dynamically and destroyed dyanmically like the menus and screen backgrounds for example. You can actually choose to do fully loaded or dynamic, or a mixture like I have. This will depend on the size of your graphics data, and if you want to interrupt the user with loading screens or not of course.
2) Remember it's up to you how much of the AOTMG code you want to use in your game, or if you just want to use the framework components. There is a TGameScreen Type in the AOTMG demo code, plus there is a TPlayer, TAlien, TBullet etc and lists to contain stuff. These are all fields of TGameScreen however, there is nothing to stop you making them global if you prefer.
3) I have examples of collision detection built into the framework (in the AOTMG demo) (e.g. lists of sprites placed on a layer and objects tested against the layer) and some useful collision functions in my commoncode.bmx file. However, the code framework doesn't have any collision code built in as the BMax collision code works well and people will want to use it in different ways. Do you think I should add some specific functions?
Thanks for your interest. Any more questions? Just ask.
WarpZone: oops sorry for the misunderstanding. I am just an affiliate for selling Absolute Blue, I liked it and so it's on my site but I didn't make it. Sorry :-( And yes, there is nothing in that game you couldn't do with my framework. All the other stuff on the site is by me, BUT it's in Blitz Plus not BMax so it's not a decent measure of what the framework can do. I moved to BMax as it's much more powerful and will help me achieve my game developement goals. Watch out for a game called Sudoku Maya Gold coming out soon (it'll be on the forums), this was totally rewritten in my framework by Gellyware in order to get on some big portals and it is looking sweet! Also, as you've identified, sprites can be animated at any framerate and the whole system is geared so it doesn't matter what Hz the screen is using, the anim will be the same. As for the multi-part anims, this is actually in evidence by simple things like the high scores screen. The scores that slide on the screen use 3 parts: 1 a delay in order to stagger the lines, 2 the slide itself, 3 a flash of colour when in the final position. This same thing can be applied to sprites of course. Finally, my new match-3 game will have plenty of animations in it and I've added a basic particle engine to the framework too (not released yet) and it's due out in August sometime... Anyway thanks for your interest, I hope you buy it :-)