Congo - game frameworkMonkey Programming Forums/User Modules/Congo - game framework
| Hi fellow Monkey fans -|
I've been developing a small Monkey framework called Congo. Source code (MIT license) and further information is available via the Module page, or at http://code.google.com/p/congo-monkey/ . I use it for most of my recent 1-Game-A-Month and Mochi projects, see http://www.onegameamonth.com/GoodReactions .
I'm trying to keep it *lean*, i.e. a fairly thin layer on top of Monkey, so you don't lose sight of the underlying Monkey/mojo awesomeness :) Anyone coming from Cocos2d or Flash will recognise my way of doing things (parent/child, displayitems, actions etc).
A range of example projects are included, including a full game. It is documented and commented throughout (via monkeydoc). My focus is primarily on Flash, html5, iOS, and Android, though I do test the desktop GLFW targets when I can. I have not tested c#/xna.
If you fancy adding a feature (or fixing something!), let me know, you will be fully acknowledged. Its a work-in-progress. I'm on twitter @goodreactions.
| Seems cool, just a heads up - I had trouble building for desktop because of networkutils.|
I looked at it and saw it's deprecated anyway and the rest of the framework doesn't seem to use it?
So looked safe to delete and removing the import and it builds fine.
The only other case I could see is using the new OpenURL in one of the examples directly.
| Cheers. That sounds familiar, maybe I didn't check a file in...|
The platform specific stuff tends to be the trickiest -- and require most testing, of course.
| Nice work Baz, thank you for sharing this! |
| Hey Baz - |
In softtarget example I notice you have multiple backgrounds of essentially the same thing (bg.png, bgipad.png, bgiphone5w.png), but for example on a Galaxy S4 the 16:9 (bgiphone5w.png) background isn't used and you get black borders, I was wondering if theres a reason you went with checking resolution vs the aspect ratio?
I found this article http://v-play.net/doc/vplay-different-screen-sizes/ you might like which talks about making a single background that handles different aspect ratios
Yes, I see what you mean, its a bit iOS-centric, your S4 wont check for a double-res wide image (+ I didnt put one in the folder). I could check aspect ratios there. I'm releasing android stuff very soon, so its a timely question... :)
Good article. The 'letterbox' section is basically what autofit is doing here, and by disabling the clipping border (CONGO_AUTOFIT_NOBORDERS) you let a larger background image fill the screen. Using those larger 'catch-all' background sizes listed in the article is a good (easy) way to do it, and doesn't require any extra resolution checks. I think its a good compromise - you still work in fixed (autofit) coordinates but fill the background.
Possibly I'd need to recalc the clipping area -- rather than just disable it -- to be 100% safe, in case the bg doesnt fill the screen.
I guess the only other downside is loading oversized npot textures (e.g. >512, >1024) on devices that aren't actually using them -- this was often discussed in the past but perhaps its just not relevant these days, even on low-end devices.
| Hi baz,|
I'm creating my own framework as well (it's a good programming exercise) and I'm getting inspired by Congo quite a lot.
You might be interested in this article.
I'm going to implement this method so that the hires assets are going to be used in all targets, not just iOS.
Thanks again for the hard work :)
| Aha, Matt Rix knows his stuff -- I used his tips for cocos2d scaling ages ago, but not really followed his Futile work. It is a good exercise, especially when you add retina and autofit into the mix :/ I hope I got everything working correctly, but I'd consider my code to be 'alpha' for a while yet.|
His method looks like a good generalisation of the idea. I think its essentially the same thing (a more generalised version of what cocos2d did) : ie have a threshold display size at which each resource set is used. Unless I misunderstand, he appears to use a maxLength threshold, then scale down; whereas I went for the cautious choice, use a lower res threshold and scale up (?). Maybe it ends up being the same, my brain cant quite work it out!
I do regret using the hardcoded HD/SD/XHD setup; its on my todo list to change to a more general api where you can just add any res levels and namesâ€¦
(btw, the iOS issue mentioned above is kind of a different thing - in one of the examples I hard-coded extra backgrounds for specific sizes, overriding my sd/hd/xhd resources, as a way to avoid black bars caused by autofit. It should still pick up the xhd resourses for any display as long as its larger than the threshold size set).
Edit - if anyone finds good articles about how res scaling is generally done on *desktop* targets, let me know!
| Hey Baz, I'm using the same pause screen code from the softtarget example, however I'm not showing borders with virtual display - I was wondering whats the best way to draw over the entire screen in congo framework? (escaping the virtual display somehow?) |
| Hmm, that is indeed a bit awkward! I've enabled some coordinate transforms in the autofit code. Basically, you're asking for the device limits but from within the virtual coordinate space:|
DrawRect( ToVirtualPosX(0), ToVirtualPosY(0),
ToVirtualPosX(DeviceWidth() ) - ToVirtualPosX(0),
ToVirtualPosY(DeviceHeight() ) - ToVirtualPosY(0) )
ie it should result in negative coordinates, outside the usual virtual display area.
I guess if you decide to position anything around the edges of the display (outside the virtual display area), you'd need to do lots of this - unless its just a centered background.
Alternatively, you could override CongoApp OnRender and draw things before UpdateVirtualDisplay() is called, but that trick will only work there, not within Draw code for layers etc.
| Hurr, I should have see that function, that worked a charm, thanks!|
For me the virtualpos y functions were commented but I saw you updated them in source.