not really, most people these days have a 1.5ghz core 2 or celeron.. but i have a P4 box that hates CC like the plague, and a laptop that loves it. guess which i use
THAT WATER TOY IS AWESOME
will kotsoft give away the source for it or not? it looks like MOPixels, lol..

CC really doesn't have the functions necessary for calculating or drawing something like this. If we had something equivalent to gmod's surface.draw, it might work.

I wish I could see that without crashing Zalo. But yes, the thing is, that's just optimized internally. It'd be great if Data would do that.

Geti, numgun, a developer of the game, uses a computer that's the same as mine but with less RAM. In fact, pretty much everyone I know that plays CC uses a computer like that. No, I don't live in a slum or ghetto or third-world country. It's just that the only people that actually get around to joining the forums here tend to be modders and coders - most of whom have gaming-class PCs.

No way, TLB. I have a 1.5 Ghz 512 Mb or Ram and it runs fine, not incredibly good or anything, just fine.

Hey guys, just for your information, that is the way I am doing it. Only, this way is like 500x faster.

You are like: Checking every other particle is the only way.

I am like: Checking only particles that are already close to it is a better way.

yeah for that other java water demo i was just getting started multithreading (i made it over a year ago, before i got more advanced with multithreading), and while it works fine on dual cores and hyperthreaded machines, it goes really screwy for the single core machines. the motion would have been smooth if i had pulled off multithreading correctly at the time. but i think CC should be able to handle say maybe an additional 1000 particles on top at least.

@lord tim, yeah, i use a uniform grid for my demos because the particles are equally sized. i don't really use any quadtrees cause they are more complex and have a little more overhead. i update the grid cells only when particles move in or out, so each step only a few grid cells get updated, so the size of the grid doesn't really affect anything unless memory is the bottleneck, which it seldom will be in 2d. memory is usually pretty efficient in 2d.

Ah, but CC doesn't support 2 cores. It just uses one. So you'd be better off using a "4 Ghz Pentium 4" single core than a 3.0 Ghz Dual Core like me.

yeah, i was just mentioning a little glitch in the java applet when i multithreaded it. it was one of my first attempts and i separated the drawing of the particles and the physics to different threads. i've fixed those problems in my newer sandboxes, but anyways, we can totally make the fluid simulation for single core too. 1000 particles is a pretty pessimistic estimate i made for single core computers and simulating on top of CC.

how much lua do you know kotsoft? someone with experience emulating fluids to such an.. awesome degree is likely going to be more successful than the majority of us. looking at the water2 demo, getting that many particles into CC isnt actually an issue. it'll be doing collisions with that many particles

i only took a little glance at lua, but it's understandable, and i should be able to learn it. the pseudocode for that water2 demo after the neighbor searching is done is earlier in the thread. i've been really busy with other stuff these weeks but there's also this other simulation method that i want to try(the particle in cell methods/material point method) as soon as i get the time.

i have an AMD Athlon 64 processor, and only 512 MB of ram, and I don't have a problem. 2GB of VRMem will do that. I think you guys should all set up VR Mem of +1.5 GB and try again.

also the java wouldn't load for me (but I have had .exe's of physics tests like that, i know how it works.)

I still disagree with calling Numgun a developer of anything other than content.

Anyways.

I have about three laptops with less than 2 ghz processor speed, and 1gb ram.

Then I've got a 3.2 ghz dual core with 2 gb ram.

CC isn't written for two cores, but having two cores still helps plenty.

Hrm. Well, I guess that confirms my suspicion that my computer is some kind of freak.
Seriously though, it probably needs to be defragged and repartitioned, in its 6 years with me I've never done it. Chances are there are also a bunch of temporary files on it too. Ditching it soon anyway.
Anyway, I'm getting entirely off-topic now. If you need to test the particles on a really slow computer though, let me know.

Here is my updated code. It pushes particles now, but not in the best way. Mostly I was working on getting the quadtree optimized. Data is mean and didn't make MOSParticle.ID work, therefore there are no unique identifiers for particles, and it looks like particles are actually recreated every update, so you can't access by them, or set your own table info on the userdata.

okay, well, what all objects can be used? MOSParticle, will this work with MOPixel, AEmitter(?) or something i'm forgetting?