December 2006 - Fractdev - mailman.xmission.com

Athlon woes
by Tim Wegner 03 Sep '08

03 Sep '08

I built a computer last year using an Athlon with a Gigabyte motherboard. I had troubles with Fractint - with any SVGA mode the computer would hang after the completion of the image. I always assumed this was an Windows XP issue. Today I tried Fractint with freedos on the same computer, with the same results. So apparently it's an incompatability bgetween fractint and my compuiter. Truecolor, 320x200, diskvideo, and even tweaked modes work. SCGA modes fail, and only after the image completes. This behavior appears to have nothing to do with recent versions. Has anyone else had trouble with Athlon? Hmm, maybe I need to look at bios settings. Tim

7 21

Failed assertion when doing makedoc=
by Richard 31 Dec '06

31 Dec '06

When doing makedoc= to get a help file, I get a failed assertion: assert(t<80); after it reads in the one-byte length of an ID. The value comes back as 118. (The length of the id field in the structure is 81 bytes, so...) This is while formatting page 234, line 47, so its quite a ways into the document. The assertion is in the PD_GET_CONTENT case of print_doc_get_info. I added an assertion in the help compiler to assert that the length of IDs it writes out are < 80 and that assertion didn't fail. So that tells me that the help file is most likely correct, but the new fractint code is doing something wrong when reading it. I've bumped into a couple of these situations where offsets are computed from magic numbers relating to the size of 16-bit ints instead of using sizeof(int). It looks like hc.c is writing out 4-byte integers everywhere that it used to write out 2-byte integers because it uses sizeof() to compute lengths of data to be written. Any suggestions on where I should look to hunt this down? -- "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 5

video modes in fractint.cfg
by Richard 30 Dec '06

30 Dec '06

How important is keeping the fractint.cfg facility for listing video modes? It doesn't really make much sense in the driver model because these video modes aren't associated with any particular driver. At the moment, the driver adds the video modes it supports to the global table used by the code. When you select video modes, you're selecting the modes in the current driver. I will add some way to switch drivers at some point, but for now you just have the one and its modes. How upset would people be if fractint.cfg went by the wayside? What value are you getting out of it in a world where image dimensions are arbitrary and video modes are generally just a glorified way of specifying image dimensions? -- "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 11

alpha 0
by Richard 29 Dec '06

29 Dec '06

It will probably crash. Disk video only. The saved image isn't right. It has some keyboard funkiness (in particular, Ctrl/Shift modifiers seem to be horked). However, its far enough along to give you an idea where things are going if you're curious and don't have CVS access or anything. <http://www.xmission.com/~legalize/fractals/fractdev/FractIntSetup-21.00.alp…> Don't consider this any kind of real "release"; think of it more as a "quasi-stable build". The setup package should be fully functional, so if you're eager to do some testing, check the following: - All dialogs have the fractint banner on them - Installed shortcuts work - Add/Remove Programs entry has reasonable information and works properly - Appropriate files are installed - Maps/Pars/Frms/etc. can be loaded from the installed app. You can send bug reports to me directly or to the list. -- "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 2

Disk video limping along
by Richard 28 Dec '06

28 Dec '06

OK, I've plugged in the existing disk video code into my Win32 driver and its limping along. Its not fully debugged yet and it still crashes after playing with it for a little while, but its a good milestone. The following screens appear to be working properly: - intro screen - parameter screens (x, y, z, etc.) - select video mode screen - help screens(*) - tab screen(*) (*) has some display weirdness, but is functional. Its interesting how FractInt deals with video and screen resolutions. FractInt has what you might call the "AutoCad model" for device independence -- a little bit of code is written for each supported video device and glued into the application. The glue allows the application to use a single API abstraction to deal with a video card. The assembly routines in video.asm form the "API" that's used by the C code to interact with the video card. The assembler code in turn depends on BIOS routines for some of its tasks and writes directly into video memory for others. XFractint ditched all of this code and hacked up a single video mode whose pixel dimensions are specified by the -geometry flag. The branch uses a hybrid approach. Each driver is initialized in the application startup process. During initialization a driver can add video modes to the list of supported video modes. This lets each driver provide a set of typical resolutions like 320x200, 640x480, 800x600, etc. It also allows drivers like the full screen DirectX driver to enumerate the full-screen video modes it supports. Ironicly, a full-screen DirectX driver would be most like the feeling of the DOS application since "switching to graphics" most likely involves a change in the scan rate for the monitor giving that familiar "click click" as the monitor switches from text (desktop, really, in Win32) to graphics modes. The driver model I'm putting in has given me some interesting ideas, both forward looking and "retro". In the forward looking direction we have the XNA Game Studio Express framework from Microsoft that lets anyone write applications for the Xbox 360. At the moment, this toolkit only supports C#, so the code would have to be transliterated into C# from C. Essentially FractInt would become one giant class iwth static data members and static methods. In the retro direction, and this would be easier to achieve, I have a number of Tektronix 4105 and 4205 serial terminals. These are terminals with a color text screen and a color graphics screen. A driver could be written to perform all I/O through the terminal via the serial port. Here the irony is that the I/O model of the original FractInt code most closely matches the I/O model of a 1980s terminal :-). -- "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 2

Text screens, cursors and help
by Richard 27 Dec '06

27 Dec '06

Things are progressing along rather nicely. I've got the text screens rendering with cursor editing of parameter fields and some of the help system. Its kind of an interesting way to proceed -- I am stepping through the code and implementing bits of driver functionality as I encounter it. With the help system, I suspect the display weirdness comes from not having implemented some of the stubs or having taken into account another global variable that affects the behavior. I'll steal the disk video from diskvid.c and patch it together with the text screens I've got right now and it should be rendering a basic image in a few days... -- "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 5

Beyond Compare 2
by Richard 24 Dec '06

24 Dec '06

FYI, a really good diff/merge tool for use with CVS is "Beyond Compare 2" <http://www.scootersoftware.com/>. You can even diff/merge whole directory trees. This is what I've been using to compare the float-only and HEAD modules in CVS. They have a 30-day free trial and it costs $30 to purchase. If you are not yet using an external diff/merge engine and don't wish to spend any money, then I'd suggest WinMerge <http://winmerge.org/>. I used WM before I used BC2 and its OK, but BC2 is much more useful and worth the $ IMO. -- "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

Fractal history in WinFract
by Jonathan Osuch 19 Dec '06

19 Dec '06

Tim, I've got the fractal history working in WinFract (and it still works in Fractint and Xfractint). The key strokes are slightly different 'h' and 'H' instead of 'h' and '^h'. This may be fixed in the future when we figure out how to make it work. Jonathan

1 0

Qs re the Autokey feature of Fractint;
by Hal Lane 19 Dec '06

19 Dec '06

I'm taking a quick look at the Autokey capability of Fractint to see how useful it might be in regression testing during development of any new versions or features of Fractint. I was originally thinking of making these image comparisons between different versions of new code to check to see if changes had broken anything previously working. However, Richard and Paul also suggested that one could compare the DOS versions of the fractal images with the versions generated by new code. Autokey can also confirm that help screens are still being displayed, .par and .map files are being written out, as well as whether commands are processed as expected. One could have more than one set of regression tests -- perhaps: - one for verifying that the pixels of particular fractals are the same as a reference set of fractals; - one set for confirming that small versions of all fractals can be created; - one set for verifying that informative text screens all display; - one set for verifying .par and .map file creation; - etc. I currently only have the code of 20.0 to look at. I suspect that there are not too many differences between 20.0 and 20.4.4, but, would someone please tell me how I can get a copy of the 20.4.4 code? <---<< This will also give me a copy of the code that matches the comprehensive HTML cross reference document that Richard created and posted of 20.4.4 at: http://www.xmission.com/~legalize/fractals/fractint-xref/ This document is a great way for someone who is not familiar with Fractint's code (like me) to start to learn how a feature works. Indirection of functions (function pointers) -- like outln() is hard to follow when you first run across it! In fact, the Xref is so valuable to me that I captured a copy to speed up access to the info. Also, can someone please tell me how to use the debug flag 50 feature to actually compare two fractals that Fractint has created as stated in Debugfla.doc. I also saw the warning in the docs... Warning: an autokey file built for this version of Fractint will probably require some retouching before it works with future releases of Fractint. We have no intention of making sure that the same sequence of keystrokes will have exactly the same effect from one version of Fractint to the next. That would require pretty much freezing Fractint development, and we just love to keep enhancing it! Reading the code that does debug 50 I see that one of the two images must be reloaded with the 'r' command. I also found where a pixel of value zero is written to the screen if the two fractals have the same pixel value, and where a pixel of value one is written if they differ (a nice feature), but I have not been able to tell where the second file being compared comes from. Any help about how to compare two files using Fractint would be appreciated... >From reading the code in FRAMAIN2.C it would appear that you might need to be in batch mode for debugflag == 50 to be used. Is this true? <---<< Also, I have the vague recollection that whenever I tried to run demo.bat in the past that it behaved in ways that I didn't expect (or didn't understand.) Is the demo capability currently behaving as intended in 20.4.4? <---<< - Hal Lane ######################### # hallane(a)earthlink.net # ######################### -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.22/590 - Release Date: 12/16/06

3 2

USEBN
by Richard 17 Dec '06

17 Dec '06

I see this code in fractalp.c: /* type math orbitcalc fnct per_pixel fnct per_image fnct |-----|----|--------------|--------------|--------------| */ struct alternatemathstuff alternatemath[] = { #define USEBN #ifdef USEBN {JULIAFP, 1,JuliabnFractal,juliabn_per_pixel, MandelbnSetup}, {MANDELFP,1,JuliabnFractal,mandelbn_per_pixel, MandelbnSetup}, #else {JULIAFP, 2,JuliabfFractal,juliabf_per_pixel, MandelbfSetup}, {MANDELFP,2,JuliabfFractal,mandelbf_per_pixel, MandelbfSetup}, #endif /* NOTE: The default precision for bf_math=BIGNUM is not high enough for JuliaZpowerbnFractal. If you want to test BIGNUM (1) instead of the usual BIGFLT (2), then set bfdigits on the command to increase the precision. */ {FPJULIAZPOWER,2,JuliaZpowerbfFractal,juliabf_per_pixel, MandelbfSetup }, {FPMANDELZPOWER,2,JuliaZpowerbfFractal,mandelbf_per_pixel, MandelbfSetup}, {-1, 0,NULL, NULL, NULL } }; The cross-reference reports that JuliabfFractal is unused as a result. I looked through the rest of the code and couldn't find any other reference to JuliabfFractal and USEBN isn't used anywhere else either. CVS says Tim added this code on revision 1.3. Tim, is the intention to ultimately remove the bf code in favor of the bn code? -- "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 4