Cute Skunk wrote:
I've done a bunch of diffs between the xfractint-20.2.04 source and the regular DOS 20.2.4 source. The following files are exactly the same: ... These files are slightly different.. but they differ in the same sort of ways as DOS 20.0 differs from DOS 20.2..
3d.c cmdfiles.c encoder.c fractint.c fractsrc.doc loadfdos.c printer.c read.me zoom.c biginit.c cmplx.h evolve.c fractint.h helpdefs.h miscovl.c prompts2.c realdos.c
How's that?
These differ even more...
calcfrac.c fracsubr.c fractals.c framain2.c jb.c line3d.c lorenz.c lsys.h miscres.c mpmath_c.c prompts1.c externs.h fractalp.c fractype.h frasetup.c jiim.c loadfile.c lsys.c miscfrac.c mpmath.h parser.c prototyp.h
(Alot of it seems to be floating point stuff, and JuliBrot stuff)
Unless you got hold of the float only source, that shouldn't be the case. OTOH, I haven't been very reliable at preparing patches. Hmm, since I don't upload the DOS source (only patches)...
These files appear ONLY in the DOS version:
FRACTINT.LNK calmanfp.asm fr8514a.asm fractint.def lsysaf.asm parsera.asm tplus_a.asm big.inc calmanp5.asm frachelp.mak fractint.mak lyapunov.asm sound.c uclock.c bignuma.asm fpu087.asm fracsuba.asm general.asm makefrac.bat sschoice.asm uclock.h bigport.inc fpu387.asm fractint.cfg hgcfra.asm newton.asm tplus.dat video.asm
That would be correct.
And these files appear only in the XFractint version:
Makefile* default.map* fracsuba.c fractint.frm* if_else.txt* phctutor.frm* testfpu.par* video.c altern.map* demo.par* fract18.par* fractint.ifs* leebg.frm phctutor.txt* tiling.l* xfract_a.inc calcmand.c diskvidu.c fract19.par* fractint.l* leebg.par phoenix.par* tplus_a.c xfractint.man* calmanfp.c file_id.diz fract200.frm fractint.par* lyapunov.par* test.frm unix.c calmanfx.asm fpdebug.txt fract200.par general.c music.par* test.par unix.h cellular.par* fpu087.c fractint.doc* icons.par* penrose.l* testbug.par* unixscr.c
(some of them are in the regular DOS EXE distrib though)
Anyway, I was going to merge these two branches back together if no one minds. (There will be one code base and you just specify something at compile time to get one version or the other out)
If you want to do that, we should start with a synched source. That will ensure you aren't fixing things that aren't broke. Or, at least have a reason for being broke.
(I'm kinda thinking of seperating the actual math stuff from the UI stuff entirely as I said (like creating 'fractintlib.dll'?), but thinking about how to do it make me wonder about DOS compatability. Mostly with small memory models, and I don't think DOS can really multi-thread (The Linux version I'm working on now forks a sub proccess to handle signals and stuff (currently not needed for anything under dos though)) I think if I decouple the math stuff from the UI stuff then it will be possible to not have some fractal types be 'interupted' by going back to the menu, and even to allow computation to continue in the background while you have switched back into text mode for some reason (like hitting <TAB> or <ESC>) This will probabilly be a major code restructureing though.)
(oh and the file path/name handling code needs to be portable as well, Fractint won't have to know what's physically 'out there', so if you want to fetch/store stuff in a funky memory card on your cell phone, you only have to change one thing. I'm just going to write it for dos and linux for now, but I'm thinking maybe also treating .ZIP files as read-only directories, so you can use your 600 .PAR files while they're still archived. Useful if you run off floppys or something (which I used to do))
By the way, is there anyone 'officially' in charge of the 'official' version of fractint, like how Linus or Alan are in charge of the Linux kernel. I don't know if I would need to OK big changes in the structure of fractint's source code with anyone.
I like to think that Tim is 'officially' in charge. Jonathan