![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |