Diddy vs Ignition vs...?
Monkey Forums/User Modules/Diddy vs Ignition vs...?
| ||
| I'm an old Blitz user who keeps popping in every once in a while to see the state of Monkey... Sorry if it's a lame question, but I'm wondering whether anybody has compared Diddy vs Ignition (and/or Fantom or others)? |
| ||
| It's not something I done or plan to do but it is something I would not mind having a look at. To be honest some one would need to be well and truly motivated to goto the trouble to do this I think most people just look at frameworks to see if they do the one or two things they want and if they do then cool, if not then they look for another. Is there features your interested in specifically ? |
| ||
| You can also compare them your self! Download a 30 days HTML5 trial of Ignition X here Download a 30 days HTML5 trial of Pyro here Both the zip files contain a free version of Monkey X and the framework modules (pre-installed). PLEASE make sure that you build the .monkey files (bananas, demos, etc.) with the Monkey X version that comes with this zip! or IT WILL NOT WORK! Probably best to open it from within Ted! |
| ||
| You can try them all and figure out what's right for you |
| ||
| Ignition has a R.U.B.E. importer wich is for me the main feature difference with diddy+box2D module. Ignition comes with a lot of examples and the docs combines with monkeys. (Does diddy do that?) I think it is nice for beggining/learning. Some examples are a bit hidden in the docs. But once you know their directory you almost don't need the docs for learning. I never used diddy though. |
| ||
| Ignition and Pyro are the only ones which are commercially supported. Diddy doesn't seem too bad, but it isn't well documented and updates come as revills/samah need to update it for their own uses typically! Fantom and the others AFAIK are no longer actively supported. Which is a shame, because I would've liked to see Flixel become a predominant framework for Monkey. |
| ||
| >Fantom and the others AFAIK are no longer actively supported. Which is a shame, because I would've liked to see Flixel become a predominant framework for Monkey. Fantom is still active, last I looked. Michael posts stuff for it at fantomgl.com. He's a little sporadic in his interest and I think something annoyed him and he picked up his ball and left this forum. I've never looked at Fantom beyond a few example lines posted here and fielding odd questions about Box2D so I don't have much to say about it, but it's not dead. Devolonter is still updating flixel-monkey if you look at the Github. The commits are primarily just bug-fix maintenance stuff AFAICT and it's been in a complete and working state for a long time so still a reasonable choice for anyone wanting to use a framework. I'm sure the Diddy guys would repeat their mantra that Diddy isn't meant to be a framework -- it's meant to be a bunch of utility libraries that are fairly modular. |
| ||
| @muddy_shoes: I'm sure the Diddy guys would repeat their mantra that Diddy isn't meant to be a framework -- it's meant to be a bunch of utility libraries that are fairly modular. Yep. :) Actually I was working on a spiritual successor to Diddy a while ago, which (although modular) is more heavily framework-based. Maybe I'll finish it one day... (incoming laughter from therevills) Edit: I've got the project open now actually, I'm just trying to remember where I was up to. XD |
| ||
| (incoming laughter from therevills) HAHAHAHHAHAHahhahahahahhaahHAHHAhahahhahaHAHAhhahahaAhahaha! ;) |
| ||
| Hey at least my Asteroids demo project works! ;) |
| ||
| Release the Kong to the wild! |
| ||
| @therevills: Release the Kong to the wild! I'll think about, but some of it is still incomplete and a little bit volatile. Here's a somewhat inexhaustive list of stuff: Complete/Usable: * Screen Framework * Asset Manager (read from .json file) * Containers (mostly copied from Diddy with some tweaks) * Threading (mostly copied from Diddy with some tweaks) * Math functions * SAX XML parser * Exception handling WIP: * Scenegraph (works, mostly) * Particle system (extension of scenegraph with a bunch of optimisations) * Tweening (currently copied from Diddy, but I was thinking of rolling my own implementation) Planned: * Tiled loader/renderer (will be separate modules, kind of) * Platform-independent utility functions as an independent submodule (covers base64, sorting algorithms, etc.) * Native utility functions as an independent submodule (anything that requires native code) * Very simple GUI (extension of scenegraph) * Storyboard (extension of scenegraph) Maybe planned in the distant future... * Overlap2D implementation (extension of scenegraph) * Storyboard editor? (lol) Things in Diddy I won't be including: * DOM XML parser (most people use skn3's module nowadays) * Super-advanced GUI (I'm sick of writing event queues and all that bollocks) * Assertion (unit testing is out of scope for a framework) The kong.common module is the only mandatory import, and it contains very little concrete code. It allows modules to talk to each other without requiring a full import of that module, and allows the developer to only import the code they actually want. A lot of the things that are tied to Mojo are abstracted away somewhat, partly so that I can make any changes for Mojo 2 that might break Mojo 1, and partly to make MX2 migration easier. For example, the "image" and "sound" assets are accessible via interfaces, but the concrete implementations use Mojo. The developer simply creates a MojoAssetManager which magically handles it in the background, and the individual modules don't care, nor will they need to explicitly import mojo. It's currently on GitHub as a private repository, and once I'm ready I'll open it up for scrutiny. |
| ||
| SPEAKING OF PRIVATE REPOS, much apologies samah for not getting back to you on testing the audio thingy. Maybe that could be part of this new framework you say you're working on ;) |
| ||
| @Nobuyuki: ...much apologies samah for not getting back to you on testing the audio thingy. Np, I forgot I asked you, actually! XD @Nobuyuki: Maybe that could be part of this new framework you say you're working on ;) For now, this new framework will not contain any 3rd party bindings. It's going to be pure Monkey, apart from whatever native code is required to make some utility functions work. |
| ||
| 'Kong' Love the name! |
| ||
| @Playniax: 'Kong' Love the name! Damnit, now I feel obliged to release it! ;) I'll look at taking some beta testers at some point, but I'm not making it public until it can answer the question "why wouldn't I just use Diddy/<insert framework here>?". |
| ||
| 'Kong' Love the name! Damnit, now I feel obliged to release it! ;) Trying to take the credit for the naming again :P History: Diddy was meant to be a small subset of extra commands "missing" from Monkey, named "Diddy" after Diddy Kong, since he was smaller than Donkey Kong. When Samah was talking about creating a successor of Diddy I suggested "Kong" since its meant to be better/cleaner/faster than Diddy so named after "Donkey Kong" :) |
| ||
| @therevills: Trying to take the credit for the naming again :P See if you were in Skype with the cool crowd, you'd see that I gave attribution. :)  Also, nowhere here did I state or confirm the name of the framework. XD |
   |