Current World Making Software

[Wordman]

From time to time I toy with the idea of starting fresh rather than perpetually patching FT. I'm reworking the code base now to get ready for FT3, but it's like trying to turn a Yugo into a monster truck while going down the highway at 80 mph. Too many decisions made 10 years ago and the need to be compatible with prior versions are conflicting with some of the desires for modern features (for example, how do you handle multi-gigabyte paged databases on a 32-bit machine with code that assumes contiguous memory spans).

If I may suggest a strategy: build an experimental "modern" version on a Mac and let Cocoa worry about most of the crap and let you focus on fractal mapping. I'd wager you could jettison about 2/3 of the code in the current product and end up with something with all the features, and slicker to boot. Once you have the experimental version build, you could retarget what you've learned into a "real" reworking of a "modern" FT3.

Of course, this could just be a transparent attempt to get a version of this software on the Mac. (It is a better dev experience, though.)

[su_liam]

Hehehe! Mac-heads are such evil manipulative folks. Absolutely, and while he's at it, he can port Wilbur. Eeeexcelent!

I've been looking at java as a front end with the heavy lifting being done in a portable native implementation. Just number crunching without system calls. JNI will make sure the floats are 32-bit IEEE754 and the doubles are 64-bit IEEE754. I don't know about FT, but the GUI for Wilbur wouldn't slow java down at all, and putting the user interface and a lot of the filehandling in java would make the system calls portable.

Come on, Joe, think about it, please.

[waldronate]

Hehehe! Mac-heads are such evil manipulative folks. Absolutely, and while he's at it, he can port Wilbur. Eeeexcelent!

I've been looking at java as a front end with the heavy lifting being done in a portable native implementation. Just number crunching without system calls. JNI will make sure the floats are 32-bit IEEE754 and the doubles are 64-bit IEEE754. I don't know about FT, but the GUI for Wilbur wouldn't slow java down at all, and putting the user interface and a lot of the filehandling in java would make the system calls portable.

Come on, Joe, think about it, please.

It's unlikely that there will be a port of either software package in the near future. A few hundred thousand lines of code don't turn on a dime. If I were to port them I would like aim for the .NET platform as that is a relatively saleable skillset.

[su_liam]

And I'm guessing that open sourcing Wilbur is out of the question, because a lot of the source is proprietary to FT?

I'll stop pestering you now...