On Wed, Jan 7, 2009 at 6:02 PM, Kao Cardoso Felix <[email protected]> wrote: > > Hi Lucio, > > Just for fun I made a very quick and dirty script to load a cocos > scene from xml. I just made it work for a very simple file. I've tried > to make it very generic so I've assumed that every tag name correspond > to a lowercase CocosNode subclass (e.g. layer, colorlayer, sprite) and > the properties correspond to a valid Python expression so I could use > eval to make a kwargs dict to pass to the class constructor. That way > the code ended up very brief :) > > I know I'm making a lot of assumptions about the correctness of the > input given and eval is specially dangerous, but hey! it's just a > quick hack to experiment ;) > > I've made it available here (along with a test file): > http://www.inf.ufrgs.br/~kcfelix/arquivos/cocos-xml.zip >
Nice! > On Wed, Jan 7, 2009 at 3:49 PM, Lucio Torre <[email protected]> wrote: >> 1- is cocos fast enough to handle all the images the guy is putting on >> screen? (is like having a couple hundrer sprites in the scene) > > If we make a solution for 2 the only thing to worry about here would > be memory usage, I guess. Otherwise, huge object counting on the same > screen space would most probably overload any engine available. Well, > at the very least some tests with this could give some valuable > profiling information to make cocos faster. > We should try using batched sprites and all that pyglet magic. >> 2- we need to add some viewport support so we dont render everything >> (if not, a couple hundred turn into a couple of tens of thousands) > > Yeah, I think this is a must. I've never implemented space > partitioning algorithms, but it seens to be the best way to optimize > things here. Maybe a simple space hash could do the job. > Some of this techniques should do it. Also, we should add the possibility of removing or adding certain layers depending on the zoom level. >> 3- how do we check for collisions and stuff? > > The most generic way I can think about, is to let the user associate > geometric primitives with CocosNodes. They shoud be optional and them > made available by a property so the user could use it to build the > apropriate geoms for whatever collision engine she's using. To build > the geometry data itself, we could provide an interactive editor along > with the map editor or load some external format like svg. I dont know about this. I like your idea because its very flexible, but it requires a lot of work for each implementation. We should provide something that is good enough to be of use without adding any infrastructure. Lucio. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "cocos2d discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cocos-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
