February 2007 - Fractdev - mailman.xmission.com

beta 1
by Richard 13 Feb '07

13 Feb '07

OK, here is an initial stab at a beta. Known issues: - Sometimes the window size is confused when switching video modes. Workaround: switch to another mode, then switch back to the desired mode - After zooming around for a while with PAGEUP, the image freezes and the zoom box is not properly removed even when not zooming. Workaround: maybe changing a parameter slightly will help resync. - If the screen doesn't appear correctly, give it a second to flush any pending updates. You can also try minimizing/restoring the window to force a fulls creen repaint. - Close button most likely doesn't cause the app to exit all the way <http://www.xmission.com/~legalize/fractals/fractdev/FractIntSetup-21.00.bet…> -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

5 38

no more beta 3 bugs?
by Richard 07 Feb '07

07 Feb '07

Other than the ones that have been reported, are people seeing any more beta 3 bugs? I'd like to know if there's anything else I should fix before beta 4 this weekend. Lee was complaining about the excessive updates; I have put in a hack to limit updates to no more than 10 fps. I still don't understand why my partial rectangle updates don't work, which would also help the display performance. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

1 0

diskisactive
by Richard 07 Feb '07

07 Feb '07

It appears that the only place this is used is in startdisk() where it returns without doing anything if this is set. However, throughout the code there is this pattern: diskisactive = 1; savetodisk(savename); diskisactive = 0; Which seems to imply that the function savetodisk() is affected by this flag, but that isn't the case. In the branch, the only place startdisk() is called is from the driver code, so I am going to remove this variable and only call startdisk() when appropriate in the driver. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

1 1

Re: [Fractdev] beta 1 - Problems with Two tests
by Richard 07 Feb '07

07 Feb '07

In article <45BFDA28.2060700(a)thuntek.net>, "Lee H. Skinner" <skinner(a)thuntek.net> writes: > But I have run into some problems. Starting with the par file > 640test.par, I ran 2 tests at 640x480, passes=g1. > > These generated the 2 images testb1.gif and testm1.gif, which have > slightly but quite noticeable wrong center-mag co-ordinates. > > I also generated the same 2 pars in DOS Fractint (images DOSTSTB1.GIF > and DOSTSTM1.GIF) which are generated with the correct co-ordinates. > > Then I generated the file New.par in Fractint for Windows by using the > <b> command for all 4 images. Note the new center-mag co-ordinated for > the DOS images which include #INF and #IO. > > Finally I generated the file NEWDOS.par in DOS Fractint by using the <b> > command for all 4 images. Note the new center-mag co-ordinated for the > Windows images which include #QNAN and #IND. Also DOS isn't able to > access the calculation time for the Windows generated images. I think I have this fixed -- it was all due to the structure alignment of the fractal information stored in the GIF file. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

2 1

fractinf_len?
by Richard 07 Feb '07

07 Feb '07

Why do this? loadfile.c(625): fractinf_len = FRACTAL_INFO_SIZE + (FRACTAL_INFO_SIZE+254)/255; Its almost like the intention is to round up to the next multiple of 255, but that would be this: 255*((FRACTAL_INFO_SIZE + 254)/255) What's the purpose of this line? I'm not getting it. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

3 6

understanding GIF extension blocks
by Richard 06 Feb '07

06 Feb '07

OK, I'm a little boggled here. Lee Skinner sent me the following bug report: "But I have run into some problems. Starting with the par file 640test.par, I ran 2 tests at 640x480, passes=g1. These generated the 2 images testb1.gif and testm1.gif, which have slightly but quite noticeable wrong center-mag co-ordinates. I also generated the same 2 pars in DOS Fractint (images DOSTSTB1.GIF and DOSTSTM1.GIF) which are generated with the correct co-ordinates. Then I generated the file New.par in Fractint for Windows by using the <b> command for all 4 images. Note the new center-mag co-ordinated for the DOS images which include #INF and #IO. Finally I generated the file NEWDOS.par in DOS Fractint by using the <b> command for all 4 images. Note the new center-mag co-ordinated for the Windows images which include #QNAN and #IND. Also DOS isn't able to access the calculation time for the Windows generated images." Now this has all the hallmarks of one program interpreting ints as 16-bits and another program interpreting ints as 32-bits. However, everything in the structure is defined in terms of datatypes that would seem to have the same size on 16-bit and 32-bit compilers: struct fractal_info /* for saving data in GIF file */ { char info_id[8]; /* Unique identifier for info block */ short iterationsold; /* Pre version 18.24 */ short fractal_type; /* 0=Mandelbrot 1=Julia 2= ... */ double xmin; double xmax; double ymin; double ymax; double creal; double cimag; short videomodeax; short videomodebx; short videomodecx; short videomodedx; short dotmode; short xdots; short ydots; short colors; short version; /* used to be 'future[0]' */ float parm3; float parm4; float potential[3]; short rseed; short rflag; short biomorph; short inside; short logmapold; float invert[3]; short decomp[2]; short symmetry; /* version 2 stuff */ short init3d[16]; short previewfactor; short xtrans; short ytrans; short red_crop_left; short red_crop_right; short blue_crop_left; short blue_crop_right; short red_bright; short blue_bright; short xadjust; short eyeseparation; short glassestype; /* version 3 stuff, release 13 */ short outside; /* version 4 stuff, release 14 */ double x3rd; /* 3rd corner */ double y3rd; char stdcalcmode; /* 1/2/g/b */ char useinitorbit; /* init Mandelbrot orbit flag */ short calc_status; /* resumable, finished, etc */ long tot_extend_len; /* total length of extension blocks in .gif file */ short distestold; short floatflag; short bailoutold; long calctime; BYTE trigndx[4]; /* which trig functions selected */ short finattract; double initorbit[2]; /* init Mandelbrot orbit values */ short periodicity; /* periodicity checking */ /* version 5 stuff, release 15 */ short pot16bit; /* save 16 bit continuous potential info */ float faspectratio; /* finalaspectratio, y/x */ short system; /* 0 for dos, 1 for windows */ short release; /* release number, with 2 decimals implied */ short flag3d; /* stored only for now, for future use */ short transparent[2]; short ambient; short haze; short randomize; /* version 6 stuff, release 15.x */ short rotate_lo; short rotate_hi; short distestwidth; /* version 7 stuff, release 16 */ double dparm3; double dparm4; /* version 8 stuff, release 17 */ short fillcolor; /* version 9 stuff, release 18 */ double mxmaxfp; double mxminfp; double mymaxfp; double myminfp; short zdots; float originfp; float depthfp; float heightfp; float widthfp; float distfp; float eyesfp; short orbittype; short juli3Dmode; short maxfn; short inversejulia; double dparm5; double dparm6; double dparm7; double dparm8; double dparm9; double dparm10; /* version 10 stuff, release 19 */ long bailout; short bailoutest; long iterations; short bf_math; short bflength; short yadjust; /* yikes! we left this out ages ago! */ short old_demm_colors; long logmap; long distest; double dinvert[3]; short logcalc; short stoppass; short quick_calc; double closeprox; short nobof; long orbit_interval; short orbit_delay; double math_tol[2]; short future[7]; /* for stuff we haven't thought of yet */ }; So this is really confusing me. I can see when the header is read in find_fractal_info, that its already wrong: + info_id 0x0012fa5c "Fractal" iterationsold 1800 fractal_type 73 OK to here, but then... xmin -1.2154154409869020e+098 xmax 1.3410738056630158e-018 ymin 1.3376211045644711e-123 ymax -2.2249705443687879e-256 creal 5.302851936981e-315#DEN cimag 0.00000000000000000 Those look wrong. videomodeax 0 videomodebx 0 videomodecx 27 videomodedx 640 dotmode 480 xdots 256 ydots 17 ... These are definitely wrong... I think the ax,bx,cx,dx should all be zero, dotmode should be 27 and xdots/ydots 640/480. Any ideas? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

2 4

re: [Fractdev] <Paul> Recoloring an RGB triplet-colored fractal at a later time.
by charlie chernohorsky 06 Feb '07

06 Feb '07

Rich wrote: > [fullscreen] But I gotta be honest and say there's still more plumbing > that needs to change before those things are going to materialize. no hurry here, we just want to be sure that you won't lock the backdoor for such things to be able to sneak in later when their time comes... > There are two things here. The image and the iteration counts. Both > PNG and GIF image formats have extension chunks (there's one > registered for fractint, but its not been specced out according to Tim). > > So you can encode the iteration counts as a PNG image and stick that in > an extension block designed to hold iteration counts. i'm somewhat aware of chunks (er, a general idea), but even if you hack it to contain a regular png image, still you need a way to make the binary data, something like libpng api.. then, you will need to pretend it's not a grayscale to get more than 16 bits.. > > with infinite iterations (more comes bellow) it's easy to get over 2^32.. > > OK, I see what you mean now about infinite iterations and I'd already > considered that as something that's desirable before. glad to hear it.. again, no hurry, just leave the backdoor.. > The question is -- is it worth having a multiple precision > 'int' to store the iteration counts then? (within an image) oh no, i don't think so, 2^32 is enough, since it's primary use will be recoloring.. (or maybe resuming calculation?) if it's not enough, you can opt for RGBA 16 bits per channel > [SVG / HPGL] When things stabilize (i.e. plumbing changes are done), > adding new save formats should be easy. ...I'm reluctant to divert my > plumbing activity into new features until the plumbing is done. ..and again, no hurry, just try to keep all those in mind please when making any architectural decisions concerning plugability.. good-nite /charlie/

3 4

x11 update
by Richard 06 Feb '07

06 Feb '07

OK, I've got everything linking now on X11 with the exception of one unresolved symbol which I'm tracking down... This is just stubs on some routines on the X11 side, but at least I've gotten the driver back in sync. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

4 21

bignum.c: misleading indentation in unsafe_full_mult_bn
by Richard 03 Feb '07

03 Feb '07

Look at the first paragraph of code after the declarations in this function: if ((sign1 = is_bn_neg(n1)) != 0) /* =, not == */ neg_a_bn(n1); samevar = (n1 == n2); if (!samevar) /* check to see if they're the same pointer */ if ((sign2 = is_bn_neg(n2)) != 0) /* =, not == */ neg_a_bn(n2); The indentation clearly indicates that all this code goes with the true clause of the first if statement, but the compiler sees: if ((sign1 = is_bn_neg(n1)) != 0) /* =, not == */ neg_a_bn(n1); samevar = (n1 == n2); if (!samevar) /* check to see if they're the same pointer */ if ((sign2 = is_bn_neg(n2)) != 0) /* =, not == */ neg_a_bn(n2); Which is the true intention? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

2 1

extraseg, printer: gone
by Richard 02 Feb '07

02 Feb '07

All traces of extraseg and the printer driver code are now gone on the branch... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

1 0