My take on the classic benchmark. It produces thousands of individually colored and sized sprites moving at different velocities and rates of rotation. Nothing but gdscript.
I love it!
Is there a limit? Cause there is still plenty room in the corners. ;)
I made the boundaries smaller than I had to, so I could still see some grass. :)
@Andreas said: Is there a limit?
Yes, when your computer explodes.
Updated to 4.1.1.
Sadly, it's slower than before, especially on android. I can run 5000 bunnies at 60fps on my old laptop, only 2000 on my old phone. 🐌
Shame. What were the stats before?
Willin What were the stats before?
5500 and 3500 on the same hardware. It wasn't as heavily optimized gdscript before either. Every bunny was a scene with its own _process method.
On the brighter side, the typed arrays made a noticeable improvement over variant arrays in the same code. Newer hardware probably runs vulkan better than mine. And, maybe someone will make a c# version.
haha interesting, will give it a shot later on my ancient laptop and old Desktop.
Using Godot 4.2.dev5 on my desktop computer, I can get up to 15000 before the FPS starts to drop.
I was missing the font file ,so I commented the font loading line out, and packed it togther to make it easier to download for others.
On 4.1 stable, the FPS begin to drop at 5.5k in gl_compatible mode.
In forward_plus/Vulkan it's slightly better, begin to drop to 53 fps at 7k-7.5k.
Laptop Specs:
CPU & Integrated GPU: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx 2.10 GHz
RAM: Kingston DDR4 2400 8G
DISK: Samsuang NVME SSD
The weird thing is that it only utilizes about 40% on each physical core evenly or 20% on each logical core evenly, and GPU is only at 50% or so capacity.
Might be worth messing around a bit with 4.x's newly introduced multi-threading stuff, to see if that helps utilizing more CPU power in gds.
Cobbs Might be worth messing around a bit with 4.x's newly introduced multi-threading stuff
I don't see threading helping much. 99% of the activity is in these lines.
var bun:Sprite2D = bunnies[i]
var speed:Vector2 = speeds[i]
bun.position += speed * delta
bun.rotation += ang_vels[i] * delta
if not bounds.has_point(bun.position):
The scene tree isn't thread-safe, so the only thing I could do in a thread is the bounds check.
Burnt Tinkered with it a bit, add a simple and stupid pool to test if it's memory/disk overhead.
Full list of changes:
- Added curr_index global variable to keep track of current committed bunnies number.
- Added @export variable BUNNY_POOL_SIZE to set default POOL_SIZE
- Added @export variable BUNNY_INCREMENT to set bunnies increment/decrement per mouse click
- Added @export flag variable to set whether to use POOL or not
- Added function make_bunnies to make bunnies/speed/angle variables preloaded upon _ready
- Added Textbox to display POOL current_size / max_size
- Added Simplified routines to set bunny variable in 'pool mode', to reduce bunny creation/removal overhead, at the costs of memory.
Please test to see if it improves or the performance gets deteriorted. -.-
Cobbs Please test to see if it improves or the performance gets deteriorted. -.-
These are good ideas, but they aren't making any difference to the number of bunnies before framerate drops, at least on my systems. It looks to me that the changes would only affect the moment you add or remove bunnies, which isn't often. This version leaks a lot of object instances and resources when the program shuts down, as well. I'll need to look at it more closely to figure out where.
I did find a way to speed it up about 20%. If I run it in compatibility mode and limit the number of colors, godot will use opengl sprite batching, which definitely helps. I'm not sure if vulkan has anything like that, but forward doesn't seem to batch at all for me.
I can get 6000 bunnies on my laptop and 2000 on my phone this way. Unfortunately, it will probably slow things down on better hardware.
© 2022 - 2024 — McMap. All rights reserved.