Framework questions

Monkey Forums/Monkey Programming/Framework questions

NoOdle(Posted 2011) [#1]
I'm working on a framework to help make games quickly and easily. What kind of features would you like to see?

I currently have:

FontManager
BitmapFonts - static labels, dynamic labels

SpriteAtlasManager
SpriteAtlas - single frame grabbing, animation frame grabbbing

SceneManager
Scenes - scene changes, scene transition effects

Sprites
Primitives - Circle, Poly, Point, Rect, Arc, Line

ActionManager
Actions - Sequence, Repeat, RepeatForver, DelayTime, Animate, Move, Scale, Rotate, Blink which support decorator actions such as xxxIn, xxxOut, xxxInOut where xxx is Elastic, Ease, Bounce, Quadratic, Sine, Back etc

Actions can be run on any Node, so that means you can run actions on Scenes, Sprites, Primitives etc.

Virtual Buttons - Toggle, Click or Hold
Virtual DPad - 4 directional or 8 directional
Virtual Analogue Stick

Virtual Resolution thanks to DruggedBunny for his lovely code

I would appreciate any suggestions :)

[edit] forgot to say that once I have added a bit more to it, I plan on releasing it for free.


Topanoe(Posted 2011) [#2]
Hi noodle. Will this be like a "spritecandy" for Monkey? AWESOME!!

Looking forward to seeing it.


TheRedFox(Posted 2011) [#3]
A nice feature would be the ability to use parts in isolation as much as possible.

e.g. Actions alone, Atlas alone...


DruggedBunny(Posted 2011) [#4]

Virtual Resolution thanks to DruggedBunny for his lovely code


Cool, it's nice to hear when you've finally done something useful!

One thing others have mentioned is image batching (eg. Gabriel, here), but I have no idea how you go about it, so perhaps that might be something worth looking at? I imagine it involves platform-specific code, though -- could be wrong -- which might not be part of your plan!


AdamRedwoods(Posted 2011) [#5]
Image batching requires planning by the coder.
You can do this on your own by using texture atlases. Try to get your draw loops to call the same units in each atlas. Example: Class Background would use method Draw() to draw everything in the background layer using only one texture atlas called background.


dawlane(Posted 2011) [#6]
Not too sure what Gabriel meant as well but at a guess I would say that if you were doing a platformer you would arrange your atlas so that you have one big platform graphic thats let say 10 game tiles long (2 tiles for the ends 8 for the middle at 32x32 pixels each tile). Then if your game needs a platform thats 10 tiles (2 end tiles, 8 middle tiles) you just need to call the drawing routine once for the whole image 320x32 pixels. Then if you need any thing thats smaller say 5 tiles then you would call the routine twice. The first call to draw one part of the big graphic an end and 3 middle sections (128x32 pixel) and the second to draw the last part an end section at 32x32. Of course if you need something bigger then you will have to call the draw routine 3 or more times depending on the size of the mid section tiles.

Doing it that way you would be sacrificing atlas image space just to make fewer calls to the drawing routine.
But just think of how many calls you would have to make if the platform graphic was just 3 tiles long (96 pixelsx32) and you need a platform thats 10 tiles.


Samah(Posted 2011) [#7]
Dawlane the point of a texture atlas is to reduce the number of texture binds required. Drawing an image is relatively inexpensive, but uploading it to the gpu is costly. It's faster to upload a large batch of renders for one image.


dawlane(Posted 2011) [#8]
@Samah
Yep I already know that mate that's why the game I've been working on use an atlas. It's just trying to figure out what Gabriel ment by "Draw calls will get you every time though. For the second gen iOS devices, you want about 20 draw calls max. So depending on how much you have to draw, you probably need to be building texture atlases, sharing materials and textures and batching as much as possible into one draw call. One of my current games has 550-600 items to be draw each frame but we batch it down to under 20."


Samah(Posted 2011) [#9]
Right, but define "draw call". To me a draw call is the act of queuing a render (x,y,z,u,v coordinates). A "flush" is the act of piping the vertex info to the GPU. Binding a new texture or changing a render setting (blending, for example) will require a flush.

So you can call "Draw" 10000 times if you like, as long as it's only pushing to the GPU a handful of times per frame.


dawlane(Posted 2011) [#10]
@Samah
After re-reading Gabriel's post along with yours it sounds like that's what he's talking about.
Cheers


DruggedBunny(Posted 2011) [#11]
So how does batching translate to Monkey code? Is it just a case of repeated DrawImageRect calls using various rects within the same image as many times in a row as possible, or does it require low-level platform-specific code?

(NB. Not a clue here... never used image atlases ever!)


skid(Posted 2011) [#12]
Is it just a case of repeated DrawImageRect calls using various rects within the same image


yes


Samah(Posted 2011) [#13]
Also, using GrabImage just creates a reference to the same surface, using different texture coordinates. Pretty much zero overhead, and doesn't reload the source.


NoOdle(Posted 2011) [#14]
I've added some more:

Touch Manager - Detects touch down, up, up inside, move, and multi tap versions of all
Touch dispatcher - Dispatches touches to nodes which can optionally swallow touches
Gesture Manager - Detects gestures, either pre built ones or create your own
Sound Manager - Stores sounds in a library
Menus - Horizontal, Vertical, Grid x/y all are scrollable and can contain labels or sprites

Batching is already in, implemented when SpriteAtlas was implemented. There are some limitations regarding z depth with sprites from other Atlases but usually not an issue.

Improved action manager, can now reverse any action or sequence of actions to create more complicated actions.
Spawn actions - spawn multiple actions at the same time. All of this can be applied to any node. e.g. scene, layer, sprite, menu etc etc.

Also improved touch support for transformed nodes, now takes into account rotation, scaling, skew etc; transforming the rect bounds so that touch detection is more accurate.

Future additions will be highscore system, custom poly bounds for super accurate touching, collision detection and response, parallax layer, tiled layers, grid layers. Particle system. Too much to list really but lots of additions.

For those that know cocos2D, I'm pretty much replicating the functionality. I may even write a translator to spit out cocos2D xcode projects if I feel that it could work for most projects. Still not sure about this.

I will be releasing this sometime in the new year as I've been a bit distracted recently learning python and various libraries; tkinter, pyqt, wxPython, matplotlib, pySerial...


NoOdle(Posted 2011) [#15]

TheRedFox (Posted 1 week ago) #3
A nice feature would be the ability to use parts in isolation as much as possible.

e.g. Actions alone, Atlas alone...



Sorry the framework is fairly reliant on other parts. But you would be free to rip out that dependancy and use the actions as you wish.

The sprite atlas actually can be used separately. It currently supports loading of Zwoptex sprite sheets. Plan to add support for others.

Likewise the bitmap font loader supports loading of GlyphDesigner fonts. Also plan to add support for others.


Tibit(Posted 2011) [#16]
Noodle, your framework sounds really cool. Do you have a download link or a project site? Or do you have an ETA for release?


zoqfotpik(Posted 2012) [#17]
I'm curious as to how you would apply decorator actions to all of those different actions.

I was thinking of having callback functions available for things like movement that had various trig functions embedded in them to modify object motion...