Slime Update Archive - February 2003

Now you have no excuse

The truly observant will have noticed a new link in the menu bar: the email form. That’s right, folks, now you can avoid the hassle of mailto links and contact me directly through a form! There’s no real advantage to this. The main reason it’s there is so that I have something to link to when I encourage you to respond to my posts. So, uh, what do you think?

Posted at 11 PM on February 26, 2003

Something had to be done.

I couldn’t find a reason to update my page, so I decided the only thing I could do was redesign the whole thing. Now I can update it to tell you that I redesigned. See?

The general consensus seems to be that the old design was better. That’s OK, I like this one. If you prefer the old one, take a look at the new “Style Sheets” section in the menu bar; you can change it to the old style (”cleanwhite”) and it will remember your preference in the future if you have cookies enabled.

Oh, yeah, that’s the cool thing about this: despite the drastic change in appearance, the HTML has hardly changed at all, and does not change when you change the active style sheet. Bow to the power of CSS.

This design was inspired partly by the colors in Zeldman’s non-default orange style sheet and the layout of In-dented.

Let me know what you think.

Posted at 8 PM on February 25, 2003

”You will know endless torment!”

Spent all day yesterday writing a program in C for a class this morning, in which I learned some assembly language. Spent the next two hours studying for an exam which I just took. Will spend the next two hours doing another homework assignment for my next class, which will last two hours, followed by working on a homework assignment due in 24 hours for my last class of the week.

After which I will play Warcraft 3 for the entire weekend.

Posted at noon on February 20, 2003

JavaScript Discussion

Creation of the JavaScript Raytracer

Now that the JavaScript Raytracer has been released, I am free to discuss a few things that I learned while creating it:

  • If you create a checkbox form element with the DOM in Internet Explorer for Windows, and set its checked property to true, and then add it to the page with the appendChild method of some other element, it will not be checked.
  • If you create a radio button form element with the DOM in Internet Explorer for Windows, not only will it ignore the same checked property, it will not be checkable at all. This means that when the user clicks on it, it will remain unchecked, no matter what. Great for confusing your users!
  • If you create a select form element (a drop down menu) with the DOM in Internet Explorer 5.x for Windows, and attempt to add options to it with its options array, before it has been added to the page, the browser may crash. This isn’t a problem in Internet Explorer 6.
  • Multiple nested <fieldset> elements display very slowly in Internet Explorer for Windows when their contents are changed via the DOM or innerHTML.
  • <label> elements created with the DOM in Internet Explorer for Windows don’t behave correctly when clicked on.
  • Raytracing with JavaScript is frickin’ slow.

Mozilla appears to render images faster than Internet Explorer, and consumes slightly less memory. I used it for all of the 320x240 renders that are displayed on the help page.

I was happy to find that Opera 7 handled the raytracer almost flawlessly. It has some minor bugs with the interface, but nothing that gets in the way of using it. The only significant problem it had was that the “pixel size” couldn’t be changed, because it doesn’t support document.styleSheets. Not a biggie, when you compare it to Opera 6. *shudder*

The Future of the JavaScript Raytracer

It’s possible that I’ll create a version 2.1 sometime in the distant future. This would contain mainly interface enhancements. I created a great JavaScript object that controls the interface, and I’d like it to have the potential to be used elsewhere, so this is what I will work on. It needs a lot of little changes. Among the enhancements would be a new way of saving workspaces that doesn’t grow so quickly. (The final version of the flower’s workspace took almost 50 KB of disk space.)

However, before that, I’ll be working on writing a raytracer in C++: Slimeray. (Clever name, eh?) I plan for this to be similar to POV-Ray, and use a scripting language nearly (though not entirely) identical to POV-Ray’s SDL (Scene Description Language). It certainly won’t support all of POV-Ray’s features, but it should have some advantages over POV-Ray. For instance, I plan for it to have much better animation support, without having to re-parse the entire scene file for every frame. Other desired features include fast parsing times when macros, include files, and while loops are used, and little things like blurred reflection, motion blur, and improved textures.

That’s a while off, however. All I’ve written is some of the parsing functions. The basic raytracing algorithms can be mostly copied from the JavaScript Raytracer, but lots of enhancements will be necessary to speed it up (including an efficient bounding hierarchy).

JavaScript as it’s meant to be used

Zeldman today did a very smart thing with his JavaScript style switcher. He noticed that Mozilla based browsers have a bug that causes them to treat the following incorrectly:

<a href="somewhere.html" onclick="doSomething(); return false;">clickie</a>

When such a link is clicked on, browsers should run the doSomething function, and then, upon seeing return false, do nothing else. Zeldman noticed that Mozilla and Netscape ignored the return false, and incorrectly followed the link to somewhere.html. His solution? Make the hyperlink link to a page that explains the browser bug.

This is hundreds of times better than resorting to the href="JavaScript:doSomething();" alternative. Why? Because it works in any browser that supports HTML correctly, even if that browser doesn’t understand JavaScript. If the browser doesn’t run scripts, it will simply link the user to the page which explains to them that their browser can’t handle the link they clicked on. In addition, if someone tries to follow the link by right-clicking and selecting “Open Link in New Window,” they won’t get a JavaScript error. That is how JavaScript is meant to be used: it complements HTML, it shouldn’t replace it.

Posted at 1 PM on February 12, 2003

The JavaScript Raytracer Revealed!

I present to you: The JavaScript Raytracer version 2.0.

If you don’t have a clue what to do with it, look for the “Load Preset” dropdown menu, select one from the list, click “Load,” and then click “Render” at the bottom of the page.

An issue has been fixed that was casing the “Load Preset” dropdown menu to be invisible in Internet Explorer 5.x. Sorry about that. If you use IE 5, try using it again - this time, you should be able to load the presets.

Posted at 1 AM on February 9, 2003
Edited at noon on February 10