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
-~----------~----~----~----~------~----~------~--~---

Reply via email to