>> Neither URL works for me on my work PC. I get a security warning asking
>> if I want to run the applet, and then a blank page. The new URL works
>> just fine on my home PC. I have no idea why there would be a difference.
>> (But I recall that this kind of thing is highly typical of Java. Isn't
>> that their slogan? Write once, test everywhere?)
>
> Part of the problem is that I'm using OpenGL libraries, and the security
> restrictions imposed by the new version of JRE is keeping the thing from
> loading completely. In a few days (after the download is complete) I can
> start signing my applets, which should help.

Security restrictions block OpenGL? Man, whatever next...

> It /is/ partly a reaction-diffusion system. I've never made a "pure" RD
> system, though the edge-finding portion of mine is considered a type of RD.

Hmm, OK.

> No, it's definitely *not* discreet. After reading up on the definitions,
> I'd have to say that it's most likely continuous. I guess I have lumped
> all sorts of systems into the generalized term, "CA." There's a lot of
> crossover. I'm pretty sure there is a continuous version of the Game of
> Life (maybe still waiting to be found).

I see... I think.

>> It is worth noting that, certainly for RD systems, almost all
>> combinations of parameter settings do absolutely nothing interesting at
>> all.
>
> Well, it was a theory that actually worked! Usually when I hit upon
> something, the next phase is the small adjustment of values, to express
> what's truly going on. It's hard to tell exactly /what/ needs to be
> changed beforehand, since each subsequent generation becomes more and
> more difficult to predict. But that's what makes these systems so much
> fun :)

Fun and frustrating at the same time, usually. ;-)

>> It still amuses me that way, waaaay back in 1997 or so, I was playing
>> with Java, trying to copy the output of the ground-breaking Geiss
>> visualisation for WinAmp. Of course, Geiss used hand-optimised machine
>> code for all the main loops, and still ran cripplingly slowly. (E.g.,
>> about 12 frames/second at 800x600, only rising to sane speeds at
>> 320x240.)
>
> Whoa, that's pretty fast! I've gotten no better with SDL and C++...

Well, a tiny inner loop custom-coded in assembly... Go check out Project 
Euler. Apparently people really do still write assembly by hand. Go figure!

> Yeah. Java, as a rule, just isn't that fast.

No kidding. It certainly wasn't back in 1997.

>> And yet, your little Java applet sucks about 5% CPU out of my obsolete
>> AMD Athlon 2X 4200+ with its 2.2 GHz clock rate. How times have changed!
>
> Most of the work is being done on your graphics card.

Wait - it's written in *Java* and yet it can access the *graphics card*??

How is that even possible?

Oh, well, no wonder its fast then. The graphics card is purposely 
engineered to eat calculations like this for breakfast.

> I didn't even realize the potential until I saw some
> of Milkdrop's presets... At one point I was like, "Wait a minute! That's
> the Game of Life, running at 60FPS! Fullscreen!!!" I didn't get much
> sleep that night.

Yeah, Milkdrop basically 0wnz. Created by the same guy as the old Geiss 
plugin too... That is one talented guy!

I wish to God I could figure out how half of Milkdrop works. There are 
some amazing 3D effects which cannot be done in realtime, and yet it 
does them in realtime, even though that's clearly impossible.

>> I'm curious to know how you manage to get it to render at a constant
>> frame rate, rather than "as fast as you can".
>
> It /is/ running all-out, but it's possible that either Processing or the
> graphics hardware is capping the frame rate.

Right. I assumed it way rate-limited because it wasn't using all 
available CPU power.

Post a reply to this message