stbenge wrote:
> My inclination _is_ to to start using profane expletives, 

Profanity is my number one debugging tool.

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

> As it turns out, there were two places to change the window size, so it
> should be fixed now.

OK it's working now, very smooth.

Post a reply to this message

On 31/01/2011 08:24 PM, stbenge wrote:
> Thank you all for your input! I'd still like to hear any comments you
> might have, if you can take the time.
>
> One of my goals is to prepare a full-on cellular automata gallery that
> anyone (with a graphics card) can view.

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



I don't know about cellular automaton; it looks more like some sort of 
reaction-diffusion system.

http://texturegarden.com/java/rd/

Then again, there are other types of differential equations which 
apparently produce similar results. Which is why I find it quite 
surprising that you claim this is a *discrete* system, not a continuous 
one. It certainly doesn't look very discrete.

I also wonder whether the visible image on-screen actually represents 
all the information in the frame, or whether there are details too faint 
to see. Certainly the simulation behaves in a wonderfully unpredictable way.

Clicking the mouse is like detonating a high-yield nuclear bomb, and the 
fallout usually dies away quickly, but sometimes inexplicably lasts for 
a very, very long time.

It is worth noting that, certainly for RD systems, almost all 
combinations of parameter settings do absolutely nothing interesting at 
all. Only a tiny fraction of possible settings do anything remotely 
worth watching. Finding these interesting bits is highly non-trivial. 
And yet, you seem to have hit upon something quite interesting here.

It appears that the image boundaries are held at a constant state. You 
might try toroidal symmetry (i.e., joining the edges together). Also, it 
occurs to me that if you were to run a simulation and stack each 
successive frame one on top of the other, you could make some rather 
interesting 3D shapes.

(Alternatively, perhaps the algorithm generalises easily to 3D. I'm not 
sure how easy to visualise that would be though...)



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

Unsurprisingly, Java was orders of magnitude slower. I had it render at 
256x256, and draw 4x larger on screen. And still it was absurdly slow. 
(I didn't measure exactly how slow.)

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!

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

Post a reply to this message

On 01/02/2011 2:15 AM, stbenge wrote:
> On 1/31/2011 5:30 PM, Stephen wrote:
>> On 01/02/2011 12:00 AM, stbenge wrote:
>>> My inclination _is_ to to start using profane expletives, but the Zen
>>> method of realizing the path I must take fills me with peace.
>>
>> Ah! My son.
>
> You aren't my father! No! No! (getting carried away with Star Wars
> geekiabilia there)
>

It is so easy. :-)

>> You will realise, after years of study and training that the
>> circle can be completed and the mind’s control of the body is as nothing
>> to letting rip when the hammer of fate connects with the thumb of life.
>> So take yourself into the desert and kick the coyote until He gives you
>> the gift of fire.
>
> I've done that, but it really doesn't work. Expressing emotional turmoil
> to desert creatures (or other socially arid inhabitants) doesn't really
> accomplish much, although you /do/ get some exercise.
>

Just slap your computer, then.


-- 
Regards
     Stephen

Post a reply to this message

On 1/31/2011 6:54 PM, Darren New wrote:
> stbenge wrote:
>> My inclination _is_ to to start using profane expletives,
>
> Profanity is my number one debugging tool.

lol!

Post a reply to this message

On 2/1/2011 4:04 AM, Stephen wrote:
> On 01/02/2011 2:15 AM, stbenge wrote:
>> On 1/31/2011 5:30 PM, Stephen wrote:
>>> On 01/02/2011 12:00 AM, stbenge wrote:
>>>> My inclination _is_ to to start using profane expletives, but the Zen
>>>> method of realizing the path I must take fills me with peace.
>>>
>>> Ah! My son.
>>
>> You aren't my father! No! No! (getting carried away with Star Wars
>> geekiabilia there)
>
> It is so easy. :-)

Just when you think you have it under control, someone cuts off your 
hand and starts making outrageous parental claims :(

> Just slap your computer, then.

OK... . whoa, that's a lot of dust!

Post a reply to this message

On 2/1/2011 12:39 AM, scott wrote:
>> As it turns out, there were two places to change the window size, so it
>> should be fixed now.
>
> OK it's working now, very smooth.

Cool.

Post a reply to this message

On 2/1/2011 1:45 AM, Invisible wrote:
> On 31/01/2011 08:24 PM, stbenge wrote:
>> Thank you all for your input! I'd still like to hear any comments you
>> might have, if you can take the time.
>
> 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.

> I don't know about cellular automaton; it looks more like some sort of
> reaction-diffusion system.

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.

> http://texturegarden.com/java/rd/

Oh yeah, I was there yesterday :) There's also another link at the same 
site concerning fractal drainage patterns:

http://fd.alife.co.uk/model/plugin/index.html

When trying to model minimal surfaces, I inadvertently stumbled upon a 
way to model such drainage patterns. What you see in my demo is the 
result of the drainage ridges becoming stabilized. I think it might even 
lead to a way for eroding height_field data.

> Then again, there are other types of differential equations which
> apparently produce similar results. Which is why I find it quite
> surprising that you claim this is a *discrete* system, not a continuous
> one. It certainly doesn't look very discrete.

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 also wonder whether the visible image on-screen actually represents
> all the information in the frame, or whether there are details too faint
> to see. Certainly the simulation behaves in a wonderfully unpredictable
> way.

The video surfaces are not scaled down, but they /do/ use linear 
interpolation, so there is inter-pixel testing going on. I didn't use 
noise for the field, but when you click the mouse, it sprays 
randomly-valued pixels locally. That's the only randomization present.

> It is worth noting that, certainly for RD systems, almost all
> combinations of parameter settings do absolutely nothing interesting at
> all. Only a tiny fraction of possible settings do anything remotely
> worth watching. Finding these interesting bits is highly non-trivial.
> And yet, you seem to have hit upon something quite interesting here.

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 :)

> It appears that the image boundaries are held at a constant state. You
> might try toroidal symmetry (i.e., joining the edges together).

Yeah, the library I'm using for the GLSL doesn't allow me to tell OpenGL 
to wrap a texture. Which means I need to make a function, which means 
things will slow down somewhat, though not appreciably.

> Also, it
> occurs to me that if you were to run a simulation and stack each
> successive frame one on top of the other, you could make some rather
> interesting 3D shapes.

I should try that. I don't see why it couldn't be done (unless I run out 
of RAM).

> (Alternatively, perhaps the algorithm generalises easily to 3D. I'm not
> sure how easy to visualise that would be though...)

I'm sure a 3D version would work just fine, but would be hecka slow. 
I've thought about stacking 2D surfaces and testing between them. The 
current setup (768x768) amounts to 589,824 pixels. A 64x64x64 stacked 
planes setup would be 262,144 pixels total. But such a setup would 
require more pixel samples to be taken, and some sort of way to test the 
nearest surfaces. To visualize it, I could use alpha transparency and a 
simple bump-mapping technique. But there are other problems with doing 
all of that that I haven't resolved.

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

> Unsurprisingly, Java was orders of magnitude slower. I had it render at
> 256x256, and draw 4x larger on screen. And still it was absurdly slow.
> (I didn't measure exactly how slow.)

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

> 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. That's why GLSL 
appeals to me so much: I can quickly type out an idea and see it play 
out in real-time. 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.

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

Sam

Post a reply to this message

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

On 01/02/2011 6:18 PM, stbenge wrote:
>>> You aren't my father! No! No! (getting carried away with Star Wars
>>> geekiabilia there)
>>
>> It is so easy. :-)
>
> Just when you think you have it under control, someone cuts off your
> hand and starts making outrageous parental claims :(
>

There, there, there. :-)

>> Just slap your computer, then.
>
> OK... . whoa, that's a lot of dust!

Hot dust?

-- 
Regards
     Stephen

Post a reply to this message

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

> It's the edge technique described in Milkdrop's preset authoring page.

 From what I can tell, very little is actually *described* in the 
Milkdrop documentation.

> When used carefully, you can produce reaction/diffusion and "skin dot"
> effects.

Yeah, you can do all kinds of really funky stuff with systems of 
differential equations, and the graphics hardware is pretty much 
designed for this type of number crunching.

> 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 can't imagine what the possible security risk could be...

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

Oh, yeah, I get how a graphics card works. What I can't figure out is 
how some of the effects that Milkdrop generates are mathematically 
possible. Figuring out the math is the hard part; actually making the 
hardware do it is usually quite simple.

Post a reply to this message

On 2/3/2011 2:08 AM, Invisible wrote:
>> It's the edge technique described in Milkdrop's preset authoring page.
>
>  From what I can tell, very little is actually *described* in the
> Milkdrop documentation.

It's enough to get a person going with preset authoring.

>>> 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...
>
> Oh, yeah, I get how a graphics card works.

Actually, I was describing what /Milkdrop/ does with a graphics card. 
All VJ'ing apps are pretty similar, I think.

> What I can't figure out is
> how some of the effects that Milkdrop generates are mathematically
> possible.

OK, you're going to have give me an example... give it over! Pick a 
preset from Milkdrop's standard distribution that epitomizes this 
nearly-impossible effect, and I'll tell you how I *think* it's done. 
Maybe other, more knowledgeable people will join in as well, and we can 
get to the bottom of this thing ;)

Sam

Post a reply to this message

stbenge wrote:
> 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? 

Distributing signed code via MS technologies requires you to get your 
signature from MS, at least in many cases. Bascially, you buy a normal web 
cert from a CA that MS trusts (any of several of the big ones), and then 
sign an empty ActiveX file with it, and send that to MS along with your 
public key, and MS signs the public key and sends it back. You can't just 
use a self-signed cert, at least for most of the stuff I've seen that deal 
with certs.

-- 
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/3/2011 11:37 AM, Darren New wrote:
> stbenge wrote:
>> 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?
>
> Distributing signed code via MS technologies requires you to get your
> signature from MS, at least in many cases. Bascially, you buy a normal
> web cert from a CA that MS trusts (any of several of the big ones), and
> then sign an empty ActiveX file with it, and send that to MS along with
> your public key, and MS signs the public key and sends it back. You
> can't just use a self-signed cert, at least for most of the stuff I've
> seen that deal with certs.

It would seem that Sun doesn't require the purchase a web certification, 
which is good for me since I don't plan on selling anything.

Hey, you seem knowledgeable about these things. I'm looking into using a 
file-hosting service to free up more space for my (future) site. Do you 
know of a good service that will allow me to store Java applets and use 
them directly in my pages? My ISP gives me a measly 5MB site space (you 
would think they'd be more generous, since I'm paying $20/mo for 24Kbps 
dialup), so to post more content I must rely on file-hosting services. 
I'm confident that I can use Photobucket for my images, but Java applets 
might be a little more difficult to get working.

I think that if I can get away with using my 5MBs for only HTML/CSS, I 
can stop worrying about running out of (my preciousss) space.

Sam

Post a reply to this message

stbenge wrote:
> It would seem that Sun doesn't require the purchase a web certification, 
> which is good for me since I don't plan on selling anything.

Yep. It also brings up that whole responsibility thing. Why do they make you 
sign it if they're not going to do even a nominal check on the signature, I 
wonder? :-)

> Hey, you seem knowledgeable about these things. I'm looking into using a 
> file-hosting service to free up more space for my (future) site. Do you 
> know of a good service that will allow me to store Java applets and use 
> them directly in my pages?

Last I looked (and that was a while ago), Java applets had to be served from 
the same host the HTML that embeds them come from.

Myself, I use amazon.com's s3 service for sloshing web files around. You can 
set the content type as you need it there, make stuff public or private, 
etc, and it's super cheap. (I think I wind up payin <$2/month to store all 
the random crap up there I have.)  There's no execution, you can't easily 
put a home page on it (since http://..../ doesn't default to redirecting to 
http://..../index.html or anything like that), and as I said the applet 
probably has to come from the same place as the html.

That said, you could put an HTML page up on your expensive host that's 
simple meta-refresh redirect to an HTML page on amazon that references the 
applet.

> I think that if I can get away with using my 5MBs for only HTML/CSS, I 
> can stop worrying about running out of (my preciousss) space.

I don't really do anything web-sophisticated on my own dime any more, so I'm 
kind of out of date on the options.

-- 
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/3/2011 5:14 PM, Darren New wrote:
> stbenge wrote:
>> It would seem that Sun doesn't require the purchase a web
>> certification, which is good for me since I don't plan on selling
>> anything.
>
> Yep. It also brings up that whole responsibility thing. Why do they make
> you sign it if they're not going to do even a nominal check on the
> signature, I wonder? :-)
>
>> Hey, you seem knowledgeable about these things. I'm looking into using
>> a file-hosting service to free up more space for my (future) site. Do
>> you know of a good service that will allow me to store Java applets
>> and use them directly in my pages?
>
> Last I looked (and that was a while ago), Java applets had to be served
> from the same host the HTML that embeds them come from.
>
> Myself, I use amazon.com's s3 service for sloshing web files around. You
> can set the content type as you need it there, make stuff public or
> private, etc, and it's super cheap. (I think I wind up payin <$2/month
> to store all the random crap up there I have.) There's no execution, you
> can't easily put a home page on it (since http://..../ doesn't default
> to redirecting to http://..../index.html or anything like that), and as
> I said the applet probably has to come from the same place as the html.
>
> That said, you could put an HTML page up on your expensive host that's
> simple meta-refresh redirect to an HTML page on amazon that references
> the applet.
>
>> I think that if I can get away with using my 5MBs for only HTML/CSS, I
>> can stop worrying about running out of (my preciousss) space.
>
> I don't really do anything web-sophisticated on my own dime any more, so
> I'm kind of out of date on the options.
>
If you don't mind administrating your own site entirely, and having it 
on a virtual machine, some people are using this:

http://www.tektonic.net/

to host their own applications even, like OpenSim, and the like, since 
you can install more or less what ever you want into it.

Found it nosing around to see what sort of places out their might host a 
sim, to make building easier, without paying someone else anywhere from 
$40-$250 a month for it instead.

-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott wrote:
> If you don't mind administrating your own site entirely, and having it 
> on a virtual machine, some people are using this:

Yeah, Amazon has a lot more services than their S3 storage server, but 
there's a lot of competition that is cheaper than Amazon's rates on compute 
time. Amazon has a bunch of different storage and CDN and hosting and 
database solutions too, but if you're just looking for plain old cycles, you 
can get it cheaper than amazon these days. Their raw storage, however, is 
super cheap. Like, $0.15/gig/month or some such.

-- 
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 04/02/2011 06:21 AM, Darren New wrote:
> Patrick Elliott wrote:
>> If you don't mind administrating your own site entirely, and having it
>> on a virtual machine, some people are using this:
>
> Yeah, Amazon has a lot more services than their S3 storage server, but
> there's a lot of competition that is cheaper than Amazon's rates on
> compute time. Amazon has a bunch of different storage and CDN and
> hosting and database solutions too, but if you're just looking for plain
> old cycles, you can get it cheaper than amazon these days. Their raw
> storage, however, is super cheap. Like, $0.15/gig/month or some such.

I have yet to find a virtual server offering that I could even plausibly 
afford. The cheapest I've seen is, like, £15/month, which is way more 
than I want to pay. Any suggestions?

Post a reply to this message

Invisible wrote:
> I have yet to find a virtual server offering that I could even plausibl
y 
> afford. The cheapest I've seen is, like, £15/month, which is way m
ore 
> than I want to pay. Any suggestions?

Not offhand. You could bid spot prices on Amazon servers for whatever pri
ce 
you want to pay and see if you get any. :-) But there's a lot out there. 

It's possible there's a virtual server farm that cheap.

-- 
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 1/31/2011 12:49 PM, stbenge wrote:
> On 1/31/2011 9:46 AM, nemesis wrote:
>>
>> 404: not found
>
> I just uploaded it to a new directory:
>
> http://www.caltel.com/~abenge/applet/index.html

"Error: Class not found:  RDMinim"

Regards,
John

Post a reply to this message

On 2/5/2011 1:59 PM, John VanSickle wrote:
> On 1/31/2011 12:49 PM, stbenge wrote:
>> On 1/31/2011 9:46 AM, nemesis wrote:
>>>
>>> 404: not found
>>
>> I just uploaded it to a new directory:
>>
>> http://www.caltel.com/~abenge/applet/index.html
>
> "Error: Class not found: RDMinim"
>
> Regards,
> John

Yeah, I've narrowed down the cause to one probability: the new version 
of JRE requires the signing of applets when used in conjunction with 
OpenGL. I'll be able to sign my applets pretty soon.

Thanks,

Sam

Post a reply to this message

Gah!

I was hoping that after downloading the JDK, the process of signing my 
applets (thus making them viewable in a web page, on most computers) 
would become possible. But no. Every turn I make takes me down a path 
fraught with peril. And for what? For an applet that would take up a big 
ol' chunk of my limited web space?

It's just not worth it!

So in order to save what's left of my sanity, I'll release anything I 
make as a standalone application. I realize that this will limit my 
audience, but if I make something truly worth seeing, then the download 
will be worth it. I could then use a file-hosting service to provide 
direct downloads. And, if I ever finish a game, save files will be 
easier to manage.

At least Processing lets me export applications to the Big Three OSs :/

So, in short, I'm giving up... unless inspiration strikes and the 
solution become clear `:(

Sam

Post a reply to this message

stbenge wrote:
> So, in short, I'm giving up... unless inspiration strikes and the 
> solution become clear `:(

Demo the screen. Post video to youtube. Right now I can only vaguely imagine 
what you're talking about.

-- 
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 06/02/2011 11:49 PM, Darren New wrote:

> Demo the screen. Post video to youtube. Right now I can only vaguely
> imagine what you're talking about.

In related news... How the hell do you take a video of something 
actually on your computer screen? (Short of pointing a video camera at 
your monitor, which just seems silly...)

Post a reply to this message

> In related news... How the hell do you take a video of something
> actually on your computer screen?

http://en.wikipedia.org/wiki/Comparison_of_screencasting_software

Post a reply to this message

Le 07/02/2011 10:11, Invisible a écrit :
> On 06/02/2011 11:49 PM, Darren New wrote:
> 
>> Demo the screen. Post video to youtube. Right now I can only vaguely
>> imagine what you're talking about.
> 
> In related news... How the hell do you take a video of something
> actually on your computer screen? (Short of pointing a video camera at
> your monitor, which just seems silly...)

If you are on Windows, I recommend camstudio, with their proprietary
codec, for the capture on disk. (and it's free of charge) (you can
capture fullscreen or partial area)

Next you will need to transcode it to a codec supported by your video
editor, but that's an offline operation.

(for conversion, Freemake Video Converter is my other recommendation)



-- 
Software is like dirt - it costs time and money to change it and move it
around.<br/><br/>


Just because you can't see it, it doesn't weigh anything,
and you can't drill a hole in it and stick a rivet into it doesn't mean
it's free.

Post a reply to this message

On 07/02/2011 10:05 AM, scott wrote:
>> In related news... How the hell do you take a video of something
>> actually on your computer screen?
>
> http://en.wikipedia.org/wiki/Comparison_of_screencasting_software

Bizarrely, this claims that FFmpeg and VirtualDub can do screen capture...

Post a reply to this message

Invisible wrote:
> In related news... How the hell do you take a video of something 

Well, FRAPS is pretty much the standard for video games.

-- 
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 07/02/2011 03:52 PM, Darren New wrote:
> Invisible wrote:
>> In related news... How the hell do you take a video of something
>
> Well, FRAPS is pretty much the standard for video games.

Isn't that also insanely expensive though?

Post a reply to this message

Invisible wrote:
> On 07/02/2011 03:52 PM, Darren New wrote:
>> Invisible wrote:
>>> In related news... How the hell do you take a video of something
>>
>> Well, FRAPS is pretty much the standard for video games.
> 
> Isn't that also insanely expensive though?

First 30 seconds is free, then it's like $39 or something here?

So, no, unless you're very poor. :-)

-- 
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/6/2011 3:49 PM, Darren New wrote:
> stbenge wrote:
>> So, in short, I'm giving up... unless inspiration strikes and the
>> solution become clear `:(
>
> Demo the screen. Post video to youtube. Right now I can only vaguely
> imagine what you're talking about.

The whole point was that I was trying my make an interactive applet, 
which would have been much more interesting than watching a video or 
staring at a static image. An image wouldn't look much more impressive 
than a voronoi diagram.

I haven't given up completely. I've got other things to do ATM, but will 
continue to research the topic...

Sam

Post a reply to this message

On 2/7/2011 8:53 AM, Darren New wrote:
> Invisible wrote:
>> On 07/02/2011 03:52 PM, Darren New wrote:
>>> Invisible wrote:
>>>> In related news... How the hell do you take a video of something
>>>
>>> Well, FRAPS is pretty much the standard for video games.
>>
>> Isn't that also insanely expensive though?
>
> First 30 seconds is free, then it's like $39 or something here?
>
> So, no, unless you're very poor. :-)

I think if I was going to start throwing my money around, I would get 
one of these:

http://craig.gp2x.de/review/GP2XReview.html

Sam

Post a reply to this message

stbenge wrote:
> The whole point was that I was trying my make an interactive applet, 

Oh, I understand that. But I now have a burning curiousity that a video 
might at least tell me whether it's interesting to stay curious. :-)

-- 
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 <myu### [at] hotmailcom> wrote:
> Gah!
>
> I was hoping that after downloading the JDK, the process of signing my
> applets (thus making them viewable in a web page, on most computers)
> would become possible. But no. Every turn I make takes me down a path
> fraught with peril. And for what? For an applet that would take up a big
> ol' chunk of my limited web space?
>
> It's just not worth it!
>
> So in order to save what's left of my sanity, I'll release anything I
> make as a standalone application. I realize that this will limit my
> audience, but if I make something truly worth seeing, then the download
> will be worth it. I could then use a file-hosting service to provide
> direct downloads. And, if I ever finish a game, save files will be
> easier to manage.
>
> At least Processing lets me export applications to the Big Three OSs :/

If it's java, why bother about apps for each OS.  It's supposed to be
cross-platform by design... ;)

Post a reply to this message

> I think if I was going to start throwing my money around, I would get
> one of these:
>
> http://craig.gp2x.de/review/GP2XReview.html

A handheld Amiga? Oh come on, that's irresistible!

Post a reply to this message

On 2/7/2011 4:41 PM, nemesis wrote:
> stbenge<myu### [at] hotmailcom>  wrote:
>> So in order to save what's left of my sanity, I'll release anything I
>> make as a standalone application.
>> ...
>> At least Processing lets me export applications to the Big Three OSs :/
>
> If it's java, why bother about apps for each OS.  It's supposed to be
> cross-platform by design... ;)

I know, I know. It doesn't make sense, yet Processing exports separately 
to each. As it turns out, exporting to MacOSX requires..... drum roll 
please..... a Mac. So now I'm down to two of the Big Three. :P

Sam

Post a reply to this message

On 2/8/2011 1:21 AM, Invisible wrote:
>> I think if I was going to start throwing my money around, I would get
>> one of these:
>>
>> http://craig.gp2x.de/review/GP2XReview.html
>
> A handheld Amiga? Oh come on, that's irresistible!

Everything about the GP2X is cool :D

Post a reply to this message

Remember this? ;-)

>> What I can't figure out is
>> how some of the effects that Milkdrop generates are mathematically
>> possible.
>
> OK, you're going to have give me an example... give it over! Pick a
> preset from Milkdrop's standard distribution that epitomizes this
> nearly-impossible effect, and I'll tell you how I *think* it's done.
> Maybe other, more knowledgeable people will join in as well, and we can
> get to the bottom of this thing ;)

Milkdrop has several presets where the screen seems to be covered in 
"ink" that somehow "bleeds" in an apparently three-dimensional mannar.

For example, the first attachment. Quite apart from the emboss effect 
(which is presumably simple post-processing), different patches of ink 
flow down the screen independently, at different rates and in different 
directions. And patches somehow *occlude* each other. It's nothing 
unusual for newly rendered stuff to occlude existing imagery, but this 
preset is doing something altogether more clever.

And then there's the second attachment. It defies my comprehension that 
it is somehow possible to do this in realtime. Seemingly thousands of 
tiny fingers of colour, all moving and rotating in full 3D. Clearly it's 
impossible to hold such a complex structure in memory, so this must be 
some kind of 2D trickery with pixel shaders or some such. But I have 
absolutely no idea how it's possible. And it looks utterly fantastic, by 
the way. It's arguably THE BEST preset in the entire system.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Attachments:
Download 'eg1.jpg' (120 KB) Download 'eg2.jpg' (134 KB)

Preview of image 'eg1.jpg'

Preview of image 'eg2.jpg'

On 3/3/2011 2:35 PM, Orchid XP v8 wrote:
> Remember this? ;-)
>
>>> What I can't figure out is
>>> how some of the effects that Milkdrop generates are mathematically
>>> possible.
>>
>> OK, you're going to have give me an example... give it over! Pick a
>> preset from Milkdrop's standard distribution that epitomizes this
>> nearly-impossible effect, and I'll tell you how I *think* it's done.
>> Maybe other, more knowledgeable people will join in as well, and we can
>> get to the bottom of this thing ;)
>
> Milkdrop has several presets where the screen seems to be covered in
> "ink" that somehow "bleeds" in an apparently three-dimensional mannar.
>
> For example, the first attachment. Quite apart from the emboss effect
> (which is presumably simple post-processing), different patches of ink
> flow down the screen independently, at different rates and in different
> directions. And patches somehow *occlude* each other. It's nothing
> unusual for newly rendered stuff to occlude existing imagery, but this
> preset is doing something altogether more clever.

For this one I'm guessing that a texture channel is evaluated and then 
pushed around on a per-pixel basis. The ink propagates at different 
rates due to the varying values of the input texture. In essence, the UV 
coordinates of the texture are transformed based on one of the texture's 
color channels, thus causing uneven spreading.

> And then there's the second attachment. It defies my comprehension that
> it is somehow possible to do this in realtime. Seemingly thousands of
> tiny fingers of colour, all moving and rotating in full 3D. Clearly it's
> impossible to hold such a complex structure in memory, so this must be
> some kind of 2D trickery with pixel shaders or some such. But I have
> absolutely no idea how it's possible. And it looks utterly fantastic, by
> the way. It's arguably THE BEST preset in the entire system.

Same as the last, but with an added global offset based on the texture 
values. Values from one color channel would be used to offset the whole 
texture unevenly, resulting in a parallax scrolling effect.

These assumptions are based on my own dealings with similar systems. I 
achieved a pseudo 3D effect using the principles I described. It looks 
like a flowing height_field, and it's actually very similar to one. I 
couldn't get my ridges to occlude other ridges, though.

When you watch the second example, do the ridges seem to "eat away" the 
texture behind them?

Having not seen these presets in action, I can't say for certain whether 
my assumptions are correct :/

Sam

Post a reply to this message

On 3/3/2011 2:35 PM, Orchid XP v8 wrote:
> Remember this? ;-)

Ack! Thunderbird nearly pushed your reply out of its cache, and the 
web-version of OT doesn't show this thread at all. I should check up on 
the newsgroups I post in...

Post a reply to this message