Invisible wrote:
> Wait - it's written in *Java* and yet it can access the *graphics card*??
> How is that even possible?

It's not. It's using a library interface between Java and OpenGL probably 
written in C or C++. Hence the security restrictions people were talking about.

The CA is written in Java, but the graphics code is still in C-ish and 
shader language and such.

> does them in realtime, even though that's clearly impossible.

Back to that again? ;-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 2/2/2011 1:44 AM, Invisible wrote:
>> 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.

It's the edge technique described in Milkdrop's preset authoring page. 
When used carefully, you can produce reaction/diffusion and "skin dot" 
effects.

>> 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.

 From Wikipedia's stub on Continuous automaton:

"A continuous automaton can be described as a cellular automaton 
extended so the valid states a cell can take are not just discrete (for 
example, the states consist of integers between 0 and 3), but 
continuous, for example, the real number range [0,1]."

You can enforce discrete rules into continuous CA, hence my argument 
that there can be some crossover between the two. This is *probably* 
something you would have to do to make a continuous version of Conway's GOL.

Last night I began producing a "hard" version of continuous CA in which 
ships are born or killed based on area evaluation. It's looking to be a 
promising method. Already, it has managed to produce three main types of 
"ships," all relatively huge. In fact, it's nothing /but/ ships :S

>> 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. ;-)

I don't find it frustrating at all <G>

>>> 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?

Robust code, of course.

Evidently there are some security issues involved with allowing an 
applet to access graphics hardware, which is likely the reason the new 
version of JRE is so intolerant.

> 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.

It's really not that difficult to learn (mastering it OTOH...). It draws 
graphics (shapes, dots) to a texture residing on a screen-wide, flat 
quad mesh (the detail of which can be changed through settings) and then 
recycles the drawn graphics for the next frame. The quad mesh can be 
warped to "push" the graphics around. Many 3D effects are created by 
slightly altering the mesh. Then there are two pixel shaders allowing 
you filter all the graphics. The first pixel shader can let you to 
produce CA, reaction/diffusion, etc., since it "recycles." The other 
shader is the final composite function that lets you apply a pixel 
filter without affecting the next frame.

Some of the 3D effects which look too detailed, and seem to exist on a 
per-pixel level, are probably effects created by a 2D shader.


Oh yeah, the common link between the reaction/diffusion link you posted 
and the drainage pattern link I posted is this: http://www.cell-auto.com/

There are many interesting things to be found there :)

Sam

Post a reply to this message

On 2/2/2011 9:57 AM, Darren New wrote:
> Invisible wrote:
>> Wait - it's written in *Java* and yet it can access the *graphics card*??
>> How is that even possible?
>
> It's not. It's using a library interface between Java and OpenGL
> probably written in C or C++. Hence the security restrictions people
> were talking about.

You mean it's not "pure" Java? :S

Post a reply to this message

stbenge wrote:
> You mean it's not "pure" Java? :S

I was always amused to see things on software like "100% Pure Java!"(*)


(*) Requires Java 1.5.2.4 or later.


In other words, it's 100% pure java because their particular native 
interface got incorporated into the JVM just recently. :-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

stbenge wrote:
> Evidently there are some security issues involved with allowing an 
> applet to access graphics hardware, which is likely the reason the new 
> version of JRE is so intolerant.

Did you get it working on the new version? I kind of lost track.

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 2/2/2011 11:44 AM, Darren New wrote:
> stbenge wrote:
>> Evidently there are some security issues involved with allowing an
>> applet to access graphics hardware, which is likely the reason the new
>> version of JRE is so intolerant.
>
> Did you get it working on the new version? I kind of lost track.

No, but when I get the JDK downloaded/installed, I will (assuming that 
signing my applets is the cure).

Sam

Post a reply to this message

stbenge wrote:
> (assuming that signing my applets is the cure).

Heh heh heh.  Remember all the crap that Microsoft got for ActiveX security? :-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 2/2/2011 1:10 PM, Darren New wrote:
> stbenge wrote:
>> (assuming that signing my applets is the cure).
>
> Heh heh heh. Remember all the crap that Microsoft got for ActiveX
> security? :-)

I missed that... But I imagine if a company is faced with a potential 
lawsuit, they'd rather make things more difficult for developers rather 
than suffer the pain inflicted by hurled legal documents :/

Sam

Post a reply to this message

stbenge wrote:
> On 2/2/2011 1:10 PM, Darren New wrote:
>> stbenge wrote:
>>> (assuming that signing my applets is the cure).
>>
>> Heh heh heh. Remember all the crap that Microsoft got for ActiveX
>> security? :-)
> 
> I missed that... But I imagine if a company is faced with a potential 
> lawsuit, they'd rather make things more difficult for developers rather 
> than suffer the pain inflicted by hurled legal documents :/

Back when Java applets first came out, and ActiveX, everyone mocked ActiveX 
because it allowed unsafe code to run as long as the developer had signed 
the ActiveX package so you could track it back to him.

Now, 15 years later, Java gives in and does the same thing, because people 
really do want to run unsafe code sometimes.  (Altho what's unsafe about 
OpenGL I can't guess. :-)

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message

On 2/2/2011 5:43 PM, Darren New wrote:
> stbenge wrote:
>> On 2/2/2011 1:10 PM, Darren New wrote:
>>> stbenge wrote:
>>>> (assuming that signing my applets is the cure).
>>>
>>> Heh heh heh. Remember all the crap that Microsoft got for ActiveX
>>> security? :-)
>>
>> I missed that... But I imagine if a company is faced with a potential
>> lawsuit, they'd rather make things more difficult for developers
>> rather than suffer the pain inflicted by hurled legal documents :/
>
> Back when Java applets first came out, and ActiveX, everyone mocked
> ActiveX because it allowed unsafe code to run as long as the developer
> had signed the ActiveX package so you could track it back to him.

Ah, so /that's/ the point. I *knew* there had to be some reason behind 
it. But... aren't there file-hosting servers a person can use in 
conjunction with free website companies that would make anonymously 
distributing applets possible? I guess it can all be tracked down 
eventually, but it's not stopping some people, evidently.

> Now, 15 years later, Java gives in and does the same thing, because
> people really do want to run unsafe code sometimes. (Altho what's unsafe
> about OpenGL I can't guess. :-)

I don't know either. I'm sure there's a weakness somewhere (there always 
is [this is somehow more true for Microsoft apps]), or they wouldn't 
have made it an issue. Right? :(

Sam

Post a reply to this message