This is the current beta; beta 4 is no longer available.
FractInt for Windows (Beta 5)
<http://tinyurl.com/2wqa7r>
You can uninstall beta 4 or you can install beta 5 over top of beta 4.
If you install over top, beta 4 will be upgraded to beta 5.
This fixes all the issues reported earlier with the exception of the
history buffer. It appears to reset parameters to their default for
the fractal instead of the history buffer parameters, so there is
still something going on there...
--
"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/>
In article <45D79642.7000601(a)grapevine.net.au>,
Barry Smith <barrys(a)grapevine.net.au> writes:
> However when I tried to run Fractint for Windows I got an error message:
> The procedure entry point MiniDumpWriteDump could not be located in
> .... dbghelp.dll
Fixed.
--
"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/>
In this function, there are two arrays that are carved out of
extraseg: same and colour.
What are the maximum indices into these arrays?
The same[] array appears to be indexed from 0 to xdots.
However, when colour is carved out of extraseg after same, it is done
with this code:
same = (int far *)MK_FP(extraseg,0);
colour = &same[ydots];
This seems to carve out an array for same[] that is ydots long. This
is all fine and dandy as long as ydots > xdots, which it is for real
video modes, but not necessarily for disk video modes.
The same array is only indexed by what looks like an x coordinate, so
I think this is a typo and should be xdots and not ydots.
I will make this change on the branch; should it be fixed on the HEAD?
--
"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/>
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/>
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/>
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/>
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/>
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/>
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/>
