Topic awaiting preservation: "tutorial" : Drawing lines in JavaScript

Tada! I just open an Articles section on my site. The first one covers a method I use to draw some lines in JavaScript and wrote ~4 years ago. It's damn easy, but surprisingly I've never seen it used elsewhere.

Hope you'll enjoy it.


ps: it has nothing to do with DHTML, but I've released two new stuffs for an Atari demo party few days ago.

[edit] I haven't added the preload in the code samples. If you don't mind I'll had later, it's 3am here [/edit]


(Edited by poi on 03-31-2005 02:15)

I have to say that I like your tutorial. While I'm already pretty familiar with JS, I thought your tutorial was fully informative

Also, I like your site's design scheme a great deal.

Interesting. An idea: instead of limiting yourself to 2x2, 4x4, 8x8, etc sized images, why not make one single large image, draw a line longer than you need to, and then clip it to the portion you want to see? Then you can avoid the ugly artifacts.


 

Slime: Indeed that's an option I tried too. Alas though the image is partially visible, it's still resized to incredibly big dimensions which slows down the process and render the method unusable for realtime applications.

I also tried to remove completely the image swapping by putting all the images in a big one, but the impact on the speed due to massive resizing is even bigger than using a simple clipping.

To give you an idea, I've coupled the line routine exposed in the tutorial with an import XML script to render some wireframe 3D objects, and got 20fps with an object having 60 edges.

Well, PO1, you could avoid that crazed resizing by simply having lots of images, and selecting just the one that's slightly larger than what you want.

For instance, you could keep handy a 1x1, a 2x2, a 4x4, an 8x8, a 16x16, a 32x32, a 64x64, a 128x128, and (if necessary) a 256x256 image., just as you do Select the one that's big enough to hold the entire thing (contrained to 256, of course), clip it, and scale it. Best of both worlds.

It would add complexity but greatly improve the results. I mean, if you can trick people into believing that you actually draw the lines, in realtime, in JS, and then they see your extremely clever algorithm (which it is, I had never thought of the idea, kudos there ), then you will completely flabbergast them.

---
"Consider a simple room with only four walls, a ceiling and a floor. Can you see it in your mind?s eye? You better not be able to; I haven?t specified a light source yet." - Paul Nettle

(Edited by Iron Wallaby on 04-01-2005 17:30)

Nice job Poi!
I've had the same idea too, but I didn't put it into code since I also want to draw curves and things with my vector engine.
And the other negative effect is that you don't have total control of where each pixel is placed. That makes it hard to write a nice fillingalgorithm for polygons.

Aren't there image formats based on vector graphics? What if you would use that format instead of a gif to make the lines even better?

/TwoD

Iron Wallaby: Nice suggestion. AFAIR I tried that too in the early stages of this algo, that is few years ago now, and don't remember precisely the reason for which I gave up the clipping technique.

I guess that was because at the time I considered the artifacts introduced by the use of smaller images a little price to pay for the improved speed.

TwoD: The lack of absolute control of position of the pixels is not important if the lines are drawn precisely ( using a strecth & clip method ).

As for the polygon routines, it's a completely different subject that only involve horizontal lines.

I'm sure some of you are familiar with this Javascript vector graphics library already, but just thought I'd throw it out there for those who haven't seen it: http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm

That library is pretty cool, and fast! The polygon rendering speed is much thanks to the fast filling algorithm. I ran a couple of performance tests to compare that library with the vector engine I wrote. For small polygons, mine is just a few milliseconds slower, but the difference is more noticable on huge polygons, impressive!

/TwoD

Very cool work, poi. Thanks for the inspiration

: . . DHTML Slice Puzzle : . . .