Building a Game (Engine) w/ Pixel Simulation in C
HTML-код
- Опубликовано: 12 дек 2024
- "Nobody said it was easy"
Coldplay, The Scientist
Signup for updates and/or support the project: colbyhub.com/
Play my falling sand game, Pocket Dust: colbyhub.com/p...
![Doubling the speed of my game's graphics [Voxel Devlog #18]](http://i.ytimg.com/vi/P2bGF6GPmfc/mqdefault.jpg)
![Doubling the speed of my game's graphics [Voxel Devlog #18]](/img/tr.png)
*appears*
*posts a video*
*disappears*
On the how cool is this = falling boxes = dopamine . you earned my follow and love !
Making a game engine is the ultimate passion project, I’ve entered in this space myself, but I’m having someone else build it for me.
Totally! Why the move to have someone else build it?
@@colbyhub I can’t code lol
@@scottcastle9119 just start off with something simple like lua in pico8 for example and move when you want to have more power.
I started at the beginning of this week and I have a very basic physics engine up that bounces balls arround and has them collide.
@@ThatMathEnjoyer pico 8 is such a killer tool for learning game development stuff
I really appreciate this idea man, i aways loved to see sand falling, and mixed with rigid body physics objects and stuff its just so cool, even tho theres 2 years we dont see progress, i hope one day you come back somehow.
I need more of this in my life
I would love seeing more of this
Dude, im on the same journey!!! Glad to see someone in the same crazy fun and demanding situation 😅
3:40 thats beautifull man.... I have my wallpaper
another flex project, nice!
Man I gotta know how you got the physics bodies interacting with the pixel simulation, because I’m stuck on that exact thing!
Hey! I have the source code up over here: git.sr.ht/~colbyhub/ampersand , my memory is a bit foggy, but it's something like "once per frame, after the physics processing and sand processing, see if any 2D bodies overlap any of the sand cells -- if so, then fling the sand randomly out of the way". The Noita GDC talk also is a good resource!
Hey man, you have a discord or something we could join? Just delving into multi-threaded C programming and this peaked my interest. I have experience building a similar 2d physics simulator in C++.
Hey! Thanks for asking! The project has been on a hiatus due to other competing projects and life changes, but I've considered starting a Discord for this and other projects if folks are interested -- nothing at the moment, though!
Too late, I got lit AF.
I would like to see this physics engine support periodic table
music used in the beginning please
Flippin’
Great work! I'm also working on a sand simulation game.
After reading your source code, seems you are iterating the cells one by one in every tick.
I wonder if you have considered "only update the cells (and its neighbors) that were updated in the previous tick".
Thank you! That's a really interesting idea! Yes, I am currently iterating over the whole grid, but exiting early if it's "air" or was updated this tick already. This makes reasoning about cell positions on the screen and in-memory very easy but still requires a large number of calls. Using your suggested method, do you think we could make less calls? What would be the best way to store that information?
@@colbyhub I just store the cell objects in a HashSet in each iteration:
In the very first tick, I put all the cells into the HashSet; in the second/later ticks, I iterate through every cell in the hash set, update them, and put them back into the hash set if they've changed.
To improve performance, I also needed to override the hashcode() function for my Cell (something like hashcode = x + y * maxHeight) to avoid hash collision in the hash set.
One caveat of this approach is that since there are no ordering in the Hash Set, we cannot guarantee "the lower cells will get processed before the upper cells". I guess I can use Sorted Set to keep the cells sorted by their Y coordinate, but it'll definitely hurt performance. So far Hash Set seems working for me.
I think this approach will have better performance if the entire grid is relatively "quiet" - if the grid is super busy all the time, then we better off iterate through every single cell in every tick.
I'm also exploring integrating rigid body physics into the sand simulation (I think the "main stream" way is to use a physics engine like Box2d and then synch the rigid body into the sand simulation). Your approach of implementing the physics in the sand simulation will definitely out perform them and will scale better.
Pixels, projectiles, effects? Reminds me of multiplayer 2d game Arcanists
Hy if the project is open source, can you post your github link? Thx!
Hey! You can view the source here: git.sr.ht/~colbyhub/ampersand I haven't updated it for a while, but hope to get back to it someday!
Cool! Are you still working on this?
Hey thanks! It was put on pause for a season (attempted to start a separate SaaS business), but I've recently picked it up again and have started on the harder parts (like implementing a marching square algorithm to generate physics bodies for sprites on-the-fly) so hoping to make a follow-up when there's more to show haha
Also, I recognized your name from when I was researching ECS, thanks for making that video -- it was helpful!
@@colbyhub Oh that's great, I'm glad you found it helpful. I wish you good fortune with your business! Looking forward to the updates :)
Like!
First!