Cute skunk wrote:
For performance reasons I'd leave some variables global to reduce calling overhead, but alot of them arn't critical like that.
I don''t think there is much calling overhead at all passing parameters with modern compilers. In any case, we can pass pointers to structures instead of using global variables. Doing a good job of associating the variables in appropriate structures is the hard part.
I think I'm going to have to setup a DOS development enviroment for the near future.
This would be a good idea. I am checking out Watcom now. It is at www.openwatcom.org. I vaguely remeber that we supported watcom once, but I can't find any old make files. Of course the easiest is if you can locate a copy of microsft C 7.0 and MASM. The reason why I'd love to get Watcom to work is that it's free and very full featured.
Politics.. fun fun. GPL sounds good, but figuring out who has to ok what code to relicense will probabily be more work than reimplmenting stuff from scratch. I'm not that sure really what else would need to be done to relicense the code if we couldn't get OKs from everyone ever involved with it.
Not as hard as you might think. I know who contributed what, and who has already given all rights to us. While I am very much in favor of radical refactoring of the code, we should avoid wholesale rewriting from scratch unless we have to. It is easy to forget what a huge investment of debugging and fine tuning is in legacy code. I much prefer an incremental approach where we make one kind of change and can recompile and test right away. We can put together a regression test suite that will give us confidence that we can change code. I like to partition changes into those that affect results and those that don't and do them separately. It is easy to test changes that should not change results at all!
e. Add the much delayed missing features. These are: True color support, PNG support, and a carefully designed fRAc chunk for storing fractal data.
I think these should be done before a complete fork, otherwise I fear that they won't make it back into a DOS version. Makeing parts of the current version into more of a self-contained black-box will also help greatly when the time comes to branch the code. (Unless we do a complete rewrite/translation)
The truecolor video drivers are already done in the DOS version. We CAN implement truecolor now if it doesn't consume too much resource, but of course GIF can't save truecolor, so we would most likely save as Targa as a temporary measure. The code is there.
Ok so to summerize, furutre directions:
(Ordered by priority)
Did you mean priority in imporatnace or in time?
1. Retain /all/ current features
yes
2. Be GPL
This can be done as we go. I can identify all the files that are already OK and those that need to be rewritten or the authors contacted. Maybe we need to make the files LGPL so the licenses can be mixed, then change to GPL when done.
3. Be multi-platform
Yes, but we can work on one platform first. There is, however, one huge advantage to multiplatform. More people can help. For example, Rich and Paul are interested in Windows. Jonathan and I can support either the DOS or X version.
4. real-mode DOS compatable (or should this be above 3.)
I think we start out making changes to Xfractint and Fractint in parallel. When we reach a dead end, we work in 32 bit version. However once there is a console version under Linux, how hard would it be to port that to a Windows console version? One item not on your list would be to back port assembler into the 32 bit versions where a bottleneck can be identified. Thjis would be a lower priority. Tim