Older blog entries for Alquimista (starting at number 4)

New year's day!

Here's the design for the intersection code. This is going to get more complex from here; keeping the code real clean is going to become a serious priority now.

  1. Intersection on 3d is very complex, but is going to have to be considered to future. Right now what's needed is a good 2d implementation, so I'll ignore the z coordinates for testing lines and will assign the average to the resulting intersection.
  2. Lines not on the same bounding box should not be tested.
  3. Lines that may or not intersect should be tested first for intersection with a cheap algorithm before expending on finding the intersection itself.
  4. Lines that are found to intersect have their distance to the cursor tested for a minimum.

Points one to three are easy to cache; such cache would then have to be updated after adding lines.

I'll take advantage of this chance to advertise a shameless plug to my project, Fandango. Testers are welcome, and anybody that can understand the current code is encouraged to improve into it, on particular on the python modules that are really easy to hack. I'll be available by mail to help, and the project page has already some basic documentation.

I've been reading about porting Fandango to libSDL.That will ensure portability and reduce the window code size. The problem is, the fonts library depends directly on XLoadQueryFont.

SDL_ttf is technically a good way to substitute it, but looks like the quality is not as good. I like better the crisp fonts that are produced by glXUseXFont.

Advantages. Replacing the window/keyboard/mouse management code for something much cleaner. Better event handling (?). Easier potential port to Win32 or MacOS X.

Disadvantages. Requires an extra library. Using the current font code requires pulling font data on an unelegant and less portable (read: still requires xlib) way. Probable hidden porting issues.

That's just planning, I'm not doing any real work before the holidays end.

Now that the END snap works for lines and line strips it's time to plan how to do INT snaps.

A naive approach to the problem would be to traverse all line-like entities, test for intersection and then test the results for distance to the click. With adecuate caching it may be feasible.

20 Dec 2002 (updated 20 Dec 2002 at 17:03 UTC) »

Well, I had a bit of fun testing the diary :)

I decided to make a call similar to cadget.clicks() called cadget.snaps() that returns a tuple [[xyz][xyz][xyz]] of the already snapped clicks. The clicks queue remains untouched.

Boring stuff today. I have commited the code to do vertex snaps in Fandango, but it still needs tweaks. It only finds a snap at a time. That complicates matters when drawing individual lines and having to snap both ends. I think that I'll do a parallel stack to iWindow::getClickQueue() that will return the snapped or clicked vertex instead of clicks only.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!