Jonathan, Sorry to bother you with this, but there seems to be a bug in the 'render-to-disk' mode (or, in my case, to XMS), which more or less clobbers the calculated image. This kicks in only if used *directly after startup* of Fractint and only in a certain range of image line lengths: Everything is ok on my machine up to 2048; the first undisturbed picture I get after that is at 4800 x 3600 (haven't checked precisely, this is simply the first higher disk mode in my fractint.cfg that works again). Switching to one of the "bad" modes after having already finished/interrupted another image makes the bug disappear (even an internal start with <insert> doesn't change this). Almost forgot: Fractint 20.04 patch 4 on MS-DOS 6.22, (very) old Intel Pentium MMX 233 MHz. The par below isn't really necessary, but that's what I used checking through the offending disk-mode resolutions. Regards, Gerald --------------------------- PAR FOLLOWS --------------------------- Bug {;After start use 'Disk'-mode with line-length > 2048 ;Fractint Version 2004 Patchlevel 4 reset=2004 type=mandel passes=1 corners=-2.5/1.5/-1.5/1.5 params=0/0 float=y maxiter=256 bailout=100 inside=0 symmetry=none } ---------------------------- END OF PAR ---------------------------
Gerald,
Sorry to bother you with this, but there seems to be a bug in the 'render-to-disk' mode (or, in my case, to XMS), which more or less clobbers the calculated image.
I'll have a look. Thanks.
This was introduced sometime between version 20.0 and the current version. The immediate fix would be to remove the float=y from the parameter entry. No, this isn't the real fix. It forces the code to initialize whatever is getting missed when the code determines that floating point is really required to generate the image. I can think of two possible changes that might have caused this. Either the change to the disk video code to use the new memory routines or the change that generates the pixel grid on-the-fly (this second is the more likely cause). Maybe Tim can help narrow this down. Jonathan
Gerald,
I can think of two possible changes that might have caused this. Either the change to the disk video code to use the new memory routines or the change that generates the pixel grid on-the-fly (this second is the more likely cause). Maybe Tim can help narrow this down.
Found it. Fixed it. This problem was introduced in the last patch, so if you go back to 20.04 patch 3 the disk video modes will work. Thanks for the bug report. Jonathan
participants (2)
-
Gerald K. Dobiasovsky -
Jonathan Osuch