161–170 of 193 posts
http://tinlizzie.org/~ohshima/shadama2/live2017/
http://tinlizzie.org/~ohshima/shadama2/
It's a bit similar, but uses GPU and spawns millions of particles. On the other hand, it's less of a sandbox and more of a demo. You can write your own code in the browser too, but it's a bit tricky to program, because it compiles to shader language and it has some weird limitations.
Earlier quoted context omitted.
Fork it!
I think the CPU load is just inherent to the type of program it is. It's running a fluid dynamics simulation, a thermal dynamics simulation, Newtonian gravity simulation, and discrete particle simulation all at once. If you made all that in 3D, you would have made an incredibly amazing game engine that no computer could possibly run.
Earlier quoted context omitted.
My point of view is that a game is something where you play within some parameters or structure.
Yes, rules are needed for a game. But is it enough? e.g. there are rules to writing a syntactically correct program; ways to drive a car; use a GUI. Does that make them games? If a user can make a game out of them, what do they add, to make it into a "game"? Is the thing added an objective of some kind (i.e. a win condition)?
I'd suggest that in order to make something into a game, the user is adding "playfulness", which is pretty subjective and may or may not include a simple goal.
In an open game or fun simulation, the player is going to be coming up with their own goals or roles of play. Or maybe they will just be going with a simple open ended goal of curious exploration.
1. If a sand pixel had an empty pixel below it, exchange them. 2. If more than two sand pixels are stacked but there's space to the side, kick one sand grain out to that side.
These rules were enough to make the sand form simple hill shapes. All of the cores bash on the same shared memory array; rather than use locks or synchronization I just had each core start in a different column of the screen and all move left to right by columns - in theory there should be enough separation that they'd never conflict.
However - and this is the part I thought interesting to post about - somehow after a few seconds or minutes the 7 cores would catch up with each other and start running in lockstep (effectively reducing the speed of the simulation to equivalent of 1 core).
Barring a bug that was simply crashing cores, what I think was happening was that not every control flow path took the same number of cycles, so a core processing a column with a complex sand pattern might slow down and allow another core to catch up to it. Once two cores were operating on exactly the same data, they'd be doing the same deterministic logic on the same inputs and writing out the same result, effectively just duplicating the work in lockstep.
Wow! This thread brings back some fond memories. Long ago, I came across a tiny Java applet linked on Fark to a Japanese forum post. Everyone loved it but I found it annoyingly small. It was barely 300px x 400px. I had been coding my senior thesis in Java and had recently learned how to use a Java decompiler. So I downloaded the applet, decompiled it, spent a few minutes figuring out exactly where the dimensions were…
Does anyone have the same problem?