Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 7.8K All Categories
- 11 Help with translations
- 4.2K General questions
- 107 Roadmap
- 358 Game & application design
- 316 Plugins
- 70 User experience
- 75 Marketplace
- 290 Code snippets
- 34 Building a team?
- 269 Suggestions & requests
- 352 Announce your apps made with Gideros.
- 90 Step by step tutorials
- 668 Bugs and issues
- 195 Introduce yourself
- 239 Announcements
- 106 Forum talk
- 404 Relax cafe
In this Discussion
Box2D performance, or different approach?
totebo
Member
Hi,
I'm playing around with a prototype. Up to 100 constantly moving Box2D dynamic bodies avoid each other by raycasting in their general direction. I draw each body as a solid colour Shape. This works well, but is too slow on low end devices. After a few tests the main bottlenecks seem to be:
- Raycasting (when turning it off completely it speeds up somewhat)
- Shape drawing (when not drawing any shapes it speeds up somewhat)
So, questions;
1. In your experience, are png bitmaps faster than Shapes drawn at runtime? I draw each Shape only once.
2. Is there a faster alternative to Raycasting?
Maybe there is a better collision engine I can use that is more lightweight (and faster)? It would need to support rotated shapes.
Cheers,
Niclas
I'm playing around with a prototype. Up to 100 constantly moving Box2D dynamic bodies avoid each other by raycasting in their general direction. I draw each body as a solid colour Shape. This works well, but is too slow on low end devices. After a few tests the main bottlenecks seem to be:
- Raycasting (when turning it off completely it speeds up somewhat)
- Shape drawing (when not drawing any shapes it speeds up somewhat)
So, questions;
1. In your experience, are png bitmaps faster than Shapes drawn at runtime? I draw each Shape only once.
2. Is there a faster alternative to Raycasting?
Maybe there is a better collision engine I can use that is more lightweight (and faster)? It would need to support rotated shapes.
Cheers,
Niclas
My Gideros games: www.totebo.com
Comments
Also sidetip, box2d debug draw also really makes it slow too.
Don't know much abouy raycasting though, they are all calculations, so my assumption that it would be slow on software floating point phones and on old armv6 phones definitely.
New armv7 phones with hardware floating point should deal with it without a problem.
Since box2d calculations are done on c++ level, event LuaJIT won't help you there, unfortunately.
My advice would be try to optimize what you can (like drawing) and see if it is good enough and if not, then maybe try to find another way to predict collisions. Or maybe shorten the ray casting length, etc.
TexturePack sound like a great replacement for Shape. I'm also going to try to replace the raycasts now happening each frame with a sensor fixture on each body to see if that's less demanding CPU wise.
I'm not able to use debug draw because of the misalignment bug (which now has been fixed; waiting for a new Gideros build!), so good call, but that can't be the culprit regrettably.