Dustbin
I made a little falling sand game today in mojo.
https://github.com/helehex/dustbin
GitHub
GitHub - helehex/dustbin
Contribute to helehex/dustbin development by creating an account on GitHub.
27 Replies
Next up, model gym for learning lunar lander but all in mojo
Wheeeeee
Thoughts?
I had to do it
tell me if running
sudo apt install libsdl2-dev in your terminal works, if not i might have to make some changes to sdl bindings
if your still awake
i didnt see the message until now
i have a feeling you'r gonna have to install all the satellite libraries aswell which im not even using
working on improving sdl bindings rn to give better errors and such
How can I incorporate both magnets and digital intelligence into my little dustbinhttps://anaconda.org/conda-forge/sdl2 It might make sense to use the conda-forge version of sdl2.
that would probly be really helpful
I didn’t realize there were SDL bindings already
I was looking into doing this but the sdl bindings currently use mojo nightly and magic doesn't support nightly yet. Definitely going to try to get that working once next stable drops
We really just need nightly in magic.
yeah this would also work
getting some random segfaults in the nightly that just dropped, same with thermo
i think maybe something with the sdl event system
What’re tonight’s changes?
ok, it's definitely something with the event system causing segfaults.. but now mojo is refusing to compile because of commented out code..
nvm i forgot the sdl example file was using the packaged version 😮💨
i fixed the aforementioned segfault in sdl bindings btw, but also, tonight i added camera movement and zoom
rendering took a performance hit, but it can definitely be improved back to it's former glory
I found it broken in Ubuntu 24 , this is because the Window in sdl-binding will construct Surface , and it's forbidden in SDL2 / Ubuntu2 .
I fix it by remove it . because dustbin use Render and not allow Surface bind to Window
++ b/src/render.mojo
@@ -10,25 +10,25 @@ struct Renderer[lif: AnyLifetime[False].type]:
var sdl: Reference[SDL, lif]
var _renderer_ptr: Ptr[_Renderer]
var window: Window[lif]
- var surface: Surface[lif]
+ #var surface: Surface[lif]
fn init(inout self, owned window: Window[lif], index: Int = -1, flags: UInt32 = RendererFlags.SDL_RENDERER_ACCELERATED) raises:
self.sdl = window.sdl
self._renderer_ptr = self.sdl[]._sdl.create_renderer(window._window_ptr, index, flags)
self.window = window^
- self.surface = Surface(self.sdl[])
+ #self.surface = window.surface
fn init(inout self, owned surface: Surface[lif]) raises:
self.sdl = surface.sdl
self._renderer_ptr = self.sdl[]._sdl.create_software_renderer(surface._surface_ptr)
self.window = Window(self.sdl[])
- self.surface = surface^
+ #self.surface = window.surface
fn moveinit(inout self, owned other: Self):
self.sdl = other.sdl
self._renderer_ptr = other._renderer_ptr
self.window = other.window^
- self.surface = other.surface^
+ #self.surface = other.surface
Renderer could not be created! SDL_Error: Surface already associated with window.
in Ubuntu 22 it works fine , it's seems Ubuntu 24 forbidden it .
im aware that your not supposed to use surface and renderer together, but i didn't know it was that bad that just calling get surface would cause issues.. everything worked fin for me.
Also, as of yesterday, im not actually using renderer in dustbin other than creating it. Things got changed when adding camera movement to directly modifying the window surface pixels, but i'm going to work on improving render performance today, so it'll likely change back to using renderer.
For sdl-bindings, we could destroy the window surface once a window is passed into a renderer's initializer... but not sure if theres a better way
*edit: i'm actually still using renderer to draw the cursor rect, and to get the output size. hopefully i can come up with something better for the draw loop today
If you have a fix, definitely open a pr in sdl-bindings https://github.com/Ryul0rd/sdl-bindings
I updated dustbin, hopefully this problem is resolved?
The world is by default 6000x800 cells now, and it runs pretty good, my target is 100 fps
Also, zooming in gives better performance currently, but the whole world is still being simulated
i dont think i've seen anyone do stone like this, but i kinda like it... I'm sure someone's tried it, they just didn't like it enough to keep it afaik
I'll push it before i go to sleep, there was one other thing i wanted to try fixing in the sdl.mojopkg im using aswell
I maybe fixed the sdl-bindings thing... I thought
destroy_window_surface() would do what i want, but using it segfaults, so I'm just destroying it manually...
Tonight I abstracted particle logic into their own functions for each particle type, and also added pausing and frame stepping.Nice!!
Make that a trait and wrap it in a bow 😉
Managed to get this working.
@Darin Simmons also suggested changing the cursor color based on what's selected, so i added that
theres still another 2 bytes i could add to
Particle to make it 64 bits
if i move color to a separate allocation, that frees up even more for other things
i can also change skip to a byte for various flags
at some point i'm gonna try doing a hybrid of frame swapping, and skip marking
so that i can have a game of life particledo you know is it can run under wsl2? I try in wsl2, raise:
Unhandled exception caught during execution: SDL_Error: Could not create renderer, Surface already associated with windowyeah, that's what i'm using
are you sure you have the latest version? I was getting that error on my debian laptop but fixed it yesterday
my version: Ubuntu 24.04 LTS
Linux ub24.04 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
did some testing, and i dont think having color be a separate allocation to avoid the cpu copy would give as much rendering speed up as i would hope, which is wierd..
The
render.copy actually takes more time than the cpu copy loop, and since it seems a render.copy is required either way, not sure it's worth it for the added complexity and overhead it would cause for the particle loop
i tried with both RENDER_ACCELERATED and RENDER_SOFTWARE, hardware acceleration actually causes everything to be about twice as slow
not sure whats going on there, even if i comment out my cpu copy loop which is the thing locking/unlocking the texture
which i'm assuming locking/unlocking would cause issues with passing back and forth between cpu and gpu
but maybe render.copy does as well, since thats even slower than my cpu copy loop
all in all, i'm very confused about the performance of everything, and not sure how to improve rendering yet
so for now i'm just gonna say the rending is good'nuff
if anyone knows more about sdl rendering and want to give me some tips, that be much appreciated. i've only started learning sdl about a month ago
I removed all noticeable sideways bias by flipping the x scan direction every frame.
It was already barely noticeable, but even better now.
I also tried some different things for pseudorandom number generation, but decided to just stick with xorshift
One of the things i tried today was caching a large batch of random numbers at the start of each frame, then iterating an index every call to rand()
But that was the same speed as xorshift
Maybe to squeeze more out, i could keep a bigger random state, and make batched calls to random inside each particles update loop, so each particle would only have to call rand() once.
then there would be no index to increment, and should free up the cpu pipes
i also just added update regioning, which was very easy
so only particles in view get updated
i have a field with 268435456 particles running at 100 fps :]
I can feel my L2 cache as i move around to fast though
made it per-axis as well, since you probably dont want y regioning:mojonightly:
dustbin uses magic now, so you no longer have to manually install SDL.
I'm using my fork of the sdl-bindings package, but not sure how to make it a dependency in magic yet, so it's still inside the repo