FractInt for Windows (beta 4) -- open for testing
Welcome to the FractInt Makeover! For those of you on the fractint list that may not have heard, I've been overhauling the FractInt source base to move it out of the 16-bit DOS world. Things have been progressing nicely and I'm now at a point where I think widespread testing would be helpful. Download and install beta 4 of FractInt for Windows: <http://tinyurl.com/26dvd7> I've just resubscribed to the fractint list so you can send bug reports to me or to the list. If you have any doubt, just send any bugs to me. A memory dump file will be produced upon a crash, but that shouldn't be happening anymore :-). This is what I would call "Phase I" of the overhaul. It is a migration of the existing DOS source base to a 32-bit Windows application. The user interface looks and acts like DOS because it is just a port of the DOS ui. A minimal amount of "Windows-ification" has been done, but you'll notice a lack of normal Windows things like a menu bar, context menu, paying attention to the mouse, dialog boxes, etc. The next phase will be to backfill these changes into the X Window System version to make all these features available to xfractint. Once that is tested, the beta will be over and a new release made. Known Issues There is no sound output support. There is no mouse support. Panning and zooming is by keyboard only. Video modes with pixel dimensions other than 4/3 aspect ratio assume non-square pixels. The images all render fine, but they appear stretched or squashed. The choice of resolutions in fractint.cfg reflect this. With debugflag=10000, error messages are reported for disk video mode when: start fractint, pick any disk video mode (e.g. 320x200), let it render, wait for completion, then go to the <v> screen, change 320 to 32, submit it. Without the debugflag settings, FractInt for Windows will most likely crash. This problem is present in the DOS fractint and not a result of the port. There are a few gaps in functionality associated with fractal types that were computed via assembly language, but these were mostly integer versions of some of the more common fractal types. If you encounter this situation a message will be displayed informing you that you should switch to floating-point for a useful image. -- "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/>
Richard, The circular history buffer doesn't seem to be working: <\> or <h> or <ctrl-h> just redraws the current image and <g>,maxhistory=10 is not understood by the program. Lee
In article <45D76BBF.5010701@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
<\> or <h> or <ctrl-h> just redraws the current image and
I'm looking into this, there was a bug there that I fixed but its still not working.
<g>,maxhistory=10 is not understood by the program.
The code says that maxhistory is only recognized when fractint is starting and not from the <g> prompt. Can you set maxhistory from the <g> prompt in DOS fractint? -- "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/>
Richard,
The code says that maxhistory is only recognized when fractint is starting and not from the <g> prompt. Can you set maxhistory from the <g> prompt in DOS fractint? <<
No. I just just tried that in an effort to get the '"redraw previous image " function to work. I tried <\>, then <h>, then the maxhistory command (thinking that maxhistory was somehow set to zero instead of the default value used in DOS). I'm now guessing that the default value is probably not getting set to non-zero. Lee
In article <45D85D67.10009@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
No. I just just tried that in an effort to get the '"redraw previous image " function to work. I tried <\>, then <h>, then the maxhistory command (thinking that maxhistory was somehow set to zero instead of the default value used in DOS). I'm now guessing that the default value is probably not getting set to non-zero.
The default value is 10 like in DOS, but I don't know why it doesn't restore all the settings, or at least appears not to. Its probably another global variable that the driver isn't recognizing. Its under investigation. -- "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/>
Rich,
No. I just just tried that in an effort to get the '"redraw previous image " function to work. I tried <\>, then <h>, then the maxhistory command (thinking that maxhistory was somehow set to zero instead of the default value used in DOS). I'm now guessing that the default value is probably not getting set to non-zero.
The default value is 10 like in DOS, but I don't know why it doesn't restore all the settings, or at least appears not to. Its probably another global variable that the driver isn't recognizing. Its under investigation.
In the HEAD, I moved the history routines out of framain2.c into history.c. This was to allow using them in WinFract without having to re-implement them. Eventually, you'll want to do the same since most, if not all, of the code in framain2.c should go away. BTW, I managed to compile and run your source. Jonathan
In article <1171844972.3932.4.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
In the HEAD, I moved the history routines out of framain2.c into history.c. This was to allow using them in WinFract without having to re-implement them. Eventually, you'll want to do the same since most, if not all, of the code in framain2.c should go away.
It seems that it restores the HISTORY structure and then returns control to the main loop, but somehow we get out of synch and compute the wrong image. One thing that's changed here is the elimination of extraseg. We could have been depending on communication through extraseg before and now its an independent chunk of memory, so some state needs to be re-initialized. I noticed that the dx0, etc., arrays were allocated from extraseg before, but they are allocated independently now. This seems a likely candidate for the problem.
BTW, I managed to compile and run your source.
Great! I did adjust the source so that if it's compiled under VS.NET 2005 you don't get scads of warnings about the potentially unsafe C runtime functions like sprintf instead of sprintf_s (sprintf_s supplies an additional varargs argument that gives the length of the string for a %s format specifier). So Paul, if you try compiling the code with the C++ Express 2005, then it shouldn't give any more warnings. -- "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/>
Rich,
It seems that it restores the HISTORY structure and then returns control to the main loop, but somehow we get out of synch and compute the wrong image.
One thing that's changed here is the elimination of extraseg. We could have been depending on communication through extraseg before and now its an independent chunk of memory, so some state needs to be re-initialized. I noticed that the dx0, etc., arrays were allocated from extraseg before, but they are allocated independently now. This seems a likely candidate for the problem.
The history routines aren't using extraseg. They use the memory routines. If the memory routines got messed up, that would cause the problem. Jonathan
In article <1171852920.3932.8.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
The history routines aren't using extraseg. They use the memory routines. If the memory routines got messed up, that would cause the problem.
I might have messed something up in the memory routines then. I switched it to use malloc/free and it then works properly. The only useful part of the memory routines at this point is the disk buffering. -- "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/>
Rich,
The history routines aren't using extraseg. They use the memory routines. If the memory routines got messed up, that would cause the problem.
I might have messed something up in the memory routines then. I switched it to use malloc/free and it then works properly.
That would not be the ideal solution. Although, it does tell us where to look for the problem.
The only useful part of the memory routines at this point is the disk buffering.
What did you do with the evolver code (for example)? It uses the memory routines. The use of the memory routines is probably more wide spread than you think. Jonathan
In article <1171930695.3974.7.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
I might have messed something up in the memory routines then. I switched it to use malloc/free and it then works properly.
That would not be the ideal solution.
No, but the only useful part of the memory routines right now is the disk portion.
What did you do with the evolver code (for example)? It uses the memory routines. The use of the memory routines is probably more wide spread than you think.
I'm eliminating the MEMORY uses of MemoryAlloc. -- "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 <45D76BBF.5010701@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
<\> or <h> or <ctrl-h> just redraws the current image and
Fixed in beta 6 -- "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 <45D76D70.5030003@thuntek.net>, "Lee H. Skinner" <skinner@thuntek.net> writes:
Richard,
A great improvement in speed!! Thanks.
It tries to limit itself to 10 updates per second, IIRC. -- "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/>
participants (3)
-
Jonathan Osuch -
Lee H. Skinner -
Richard