Programming thread

[Least Concern]

So for just a 256 grid with breathing air

Breathing Simulator lives?!

If doing all this with arrays is proving too slow for you, have you considered linked lists? I remember having an issue with arrays being too slow back in the bad old days of Flash and learning about linked lists and being surprised that they worked so much faster, but YMMV with C#/Unity's internals.

The tl;dr is that you have a listHead variable which points to the first object in your list, and each object has a nextObject value which points to the next object in the list. Instead of for looping through an array, you while loop until nextObject is null. You can also have prevObject values if you need to go through the list backwards, or have the nextObject value point back to the first item in the list if you want to continuously loop through them. You can still add and remove items; in [A, B, C], you would remove B by simply setting A's nextObject to C. Then add D after A by setting A's nextObject to D and D's nextObject to C.

The downside is that it's not so simple to access the Nth item in the list arbitrarily, but if you're going to be looping more often than doing that, linked lists might help.

 

[Bongocat]

I don't think linked lists will help here since they scatter themselves in memory. There's not much way of dealing with that many simulation elements without the cpu shitting itself.

However, if you really can't simplify this with approximate volumes, have you considered fluid simulation on the GPU? It's not trivial to implement, but it will do what you want and it'll do it fast.

This is a very old article but I found it very helpful. It's not 3D but 2D is a good starting point to help understand all this.

GPU Gems - Chapter 38. Fast Fluid Dynamics Simulation on the GPU

developer.download.nvidia.com

 

[Indefinite_Ordered_Sets]

@Null if you are into those geometry and simulation autism, look up 0FPS blog (actually, here https://0fps.net/).

 

[awoo]

 

[Crunchy Oats]

Speaking of tile maps, I'm making a bunch of noise over here:

 

[Null]

burst code can't handle arrays, wtffffffffffffffffffffffffffffffffffffffffffffffffff

doing parallel processing is the hardest shit i've ever done ever

 

[Bongocat]

The next big language is going to be the one that finally gets concurrency right.

 

[Info Player Start]

Every language I start using, I run into something that pisses me off. I can't stop jumping around, I think this might be no joke hell.

 

[Crunchy Oats]

Every language I start using, I run into something that pisses me off. I can't stop jumping around, I think this might be no joke hell.

They're generally all the same with different syntax and uses, just find one and start somewhere, you'll end up changing what you code with a few times. If you have a job in it, you almost have to learn more than one anyway.

C++ or C# are good starts to learn most of the basic concepts, and you can still use them for advanced work as well.

 

[WeWuzFinns]

When I program I love using square brackets because their Finnish name reminds me of swastikas. They make me feel nostalgic.

 

[Strange Looking Dog]

Breathing Simulator lives?!

If doing all this with arrays is proving too slow for you, have you considered linked lists? I remember having an issue with arrays being too slow back in the bad old days of Flash and learning about linked lists and being surprised that they worked so much faster, but YMMV with C#/Unity's internals.

The tl;dr is that you have a listHead variable which points to the first object in your list, and each object has a nextObject value which points to the next object in the list. Instead of for looping through an array, you while loop until nextObject is null. You can also have prevObject values if you need to go through the list backwards, or have the nextObject value point back to the first item in the list if you want to continuously loop through them. You can still add and remove items; in [A, B, C], you would remove B by simply setting A's nextObject to C. Then add D after A by setting A's nextObject to D and D's nextObject to C.

The downside is that it's not so simple to access the Nth item in the list arbitrarily, but if you're going to be looping more often than doing that, linked lists might help.

Ok but now extend that to 2d, and add the requirement that each node needs to be able to access it's neighbors. I can guarantee you that slls are not a good solution for this.

burst code can't handle arrays, wtffffffffffffffffffffffffffffffffffffffffffffffffff

doing parallel processing is the hardest shit i've ever done ever

Yeah unity's solution to safe concurrency is kind of retarded and busted. I tried using it a year back and quickly gave up because it basically locks you out of using the majority of language features. Realizing that I'd have to associate even simple things like arrays and dictionaries with their entities using a ConcurrentDictionary or the like was the last straw.

What I'd do is first break your overall grid into smaller "chunks", stored as regular arrays, then use a regular C# Task per chunk to process it. The final step is to "double buffer" the simulation by keeping two copies of the grid, one copy will represent the previous state of the grid, and the other copy will represent the next state of the grid, so each task will basically read from the previous copy, and write to the next copy. Every time you finish simulating a step, you just swap the copies, thereby reusing memory, and allowing lockless parallel safety.

Every language I start using, I run into something that pisses me off. I can't stop jumping around, I think this might be no joke hell.

You have only one choice, you must make your own language

 

[Least Concern]

Ok but now extend that to 2d, and add the requirement that each node needs to be able to access it's neighbors. I can guarantee you that slls are not a good solution for this.

nodeAbove, nodeBelow, nodeNorth, nodeEast, etc. Things aren't as obviously linear anymore but it's still possible, I would think. (But dabbling aside IANA game developer.)

 

[Bongocat]

Yeah unity's solution to safe concurrency is kind of retarded and busted. I tried using it a year back and quickly gave up because it basically locks you out of using the majority of language features. Realizing that I'd have to associate even simple things like arrays and dictionaries with their entities using a ConcurrentDictionary or the like was the last straw.

I think this is Unity Technologies basically covering their ass.

A lot of kids and retards use Unity (not knocking it or saying Unity is bad, it's just more accessible than Unreal). Those programmers that don't know what they're doing are obviously going to make lots of things crash, and writing safe multithreaded code is a dark and arcane art that even pros have a hard time with. It's in Unity's best interest to make the concurrency code as idiot proof as possible even if that limits it's utility. If they don't a lot of teams ship unstable games and that hurts unity's reputation.

 

[Null]

I had some breakthroughs with my code and now I have to write a rendering implementation so that I can see the results of my work.

Now's a good time to start differentiating between client/server functionality so I installed the ancient NetCode 0.6 package. Supposedly a lot of the ECS shit is getting updated in 2022 so we'll see, but 2021 has been stone cold on ECS's front. I trust them when they say they're working on it, however. From the sound of it, very big companies want Unity to make shit blazing fast for mobile phones and right now Unity is mostly writing the DOTS for their needs.

 

[Cryonic Haunted Bullets]

The next big language is going to be the one that finally gets concurrency right.

there are quite a few of those

When I program I love using square brackets because their Finnish name reminds me of swastikas. They make me feel nostalgic.

you weren't joking:

 

[Null]

What I'd do is first break your overall grid into smaller "chunks"

I didn't start with this this way because the tiles don't really understand adjacency in this way but I'm going to move towards this so that I can safely limit data being sent to the client based on where they're at and what they can see. I'm also going to generate meshes on a per-chunk basis. So all areas of space with visible gas in a 16x16 area are going to share the same mesh and perhaps something similar with the floors, I've not decided yet.

I did have to move all my data from NativeStreams to NativeArrays despite the latter being slower. NativeStreams simply do not allow parallel read/write like I needed and it was slowing down my development. I think I have a working solution in place but I'm waiting on rendering to kick in.

 

[Crunchy Oats]

I didn't start with this this way because the tiles don't really understand adjacency in this way but I'm going to move towards this so that I can safely limit data being sent to the client based on where they're at and what they can see. I'm also going to generate meshes on a per-chunk basis. So all areas of space with visible gas in a 16x16 area are going to share the same mesh and perhaps something similar with the floors, I've not decided yet.

I did have to move all my data from NativeStreams to NativeArrays despite the latter being slower. NativeStreams simply do not allow parallel read/write like I needed and it was slowing down my development. I think I have a working solution in place but I'm waiting on rendering to kick in.

Are you making some type of chemical simulator? It almost sounds like you're making an advanced 3D version of SS13's air system (which is awesome if you are.)

 

[Null]

Are you making some type of chemical simulator? It almost sounds like you're making an advanced 3D version of SS13's air system (which is awesome if you are.)

Talking about your long-term goals is accomplishment masturbation. Only progress matters

 

[Shoggoth]

burst code can't handle arrays, wtffffffffffffffffffffffffffffffffffffffffffffffffff

doing parallel processing is the hardest shit i've ever done ever

One word for ya, immutability
But for games it's not really a sane option, so partitioning like @ConcernedAnon suggested is a good idea
That's before you get into shit like cache coherency

The next big language is going to be the one that finally gets concurrency right.

Erlang, Golang, Clojure, Scala ZIO
But it's not a good fit for HPC

 

[Least Concern]

Talking about your long-term goals is accomplishment masturbation. Only progress matters

Respectfully disagree, but I still love you. Having a well-defined idea of what you're building can help you stay focused and not get bogged down by experimental or unessential features. And as a freelancer, I insist on having a well-defined spec of what a client wants me to build before I start any work both to avoid feature creep from the client (or, more typically, so when feature creep inevitably happens, I can explain why I'm spending more time than I estimated) or even the case where I spend dozens of hours building something for a client and they say "this isn't what I had in mind at all" and refuse to pay for it, as happened a couple times early on in my freelance career.

In your case, though, it sounds like you're just fooling around and seeing what you can do, the programming equivalent of doodling loops in a sketchpad, so I can understand that you wouldn't have any well-defined long-term goals for it yet.