<Richard> Q's re Fractint for Windows
Richard,
Is the latest [beta] still: FractIntSetup-21.00.beta5.msi ? Yes Thanks for the confirmation.
I just installed this and I am very impressed with its behavior. Thanks for all your work! I really agree with your approach of keeping the DOS user interface and restructuring the fractal code for Windows as the first step towards a full migration of DOS Fractint to Windows. I was surprised (looking in Task Manager) at how little of my CPU was being used (and how it varied between fractals) when calculating some of the parm file fractals included in your distribution. [Its certainly pleasant not to have the DOS keyboard read routines not continuously sniffing at my fingers in your Windows beta!] What currently determines how much of the CPU is given to the calculation of a fractal? <---<<
I won't release another version until I've fixed a bug in the formula rendering that keeps giving a light red screen for certain formulas.
When I took a quick look at the formula parser some time ago, I was pretty intimidated. The parser looked like an ad hoc design approach, rather than an automatically generated parser, like lex and yacc. I guess if the formula parser code is still the original code, that something like the changed #includes and/or data typing and it passing must be the source of the problem. The fact that the bug in the formula rendering keeps giving a consistent symptom (a light red screen) should hopefully help in the eventual diagnosis of the problem. You may want to delete or update Jonathan's ReadMe.txt file in your next beta since it describes the DOS version. I note that you changed the keys that encode different screen resolutions from the original encodings. So far that has only impacted my SSTOOLS.INI file. It could also affect .BAT files that include a screen resolution change. I guess I'm working my way around to asking whether it could be useful to have the keys that encode screen resolutions be the same as the default DOS encodings... Do you have a web page where you collect the issues/bugs that people report or that you are working on -- beyond the items listed in the BUGS.txt file included in your distribution? I don't want to report any items that have already been reported, or reported and fixed like: <---<<
<\> or <h> or <ctrl-h> just redraws the current image Fixed in beta 6
- Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Richard Sent: Saturday, February 16, 2008 8:40 PM To: Fractint developer's list Subject: Re: [Fractdev] What is the latest version of Richard's 'Fractint forWindows'?
In article <MDBBJLBFBICIIEIHFBMEAECNDFAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
Is the latest still: FractIntSetup-21.00.beta5.msi ?
Yes
I won't release another version until I've fixed a bug in the formula rendering that keeps giving a light red screen for certain formulas. --
In article <MDBBJLBFBICIIEIHFBMEOECPDFAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
What currently determines how much of the CPU is given to the calculation of a fractal? <---<<
It runs as fast as it can. Screen updates are limited to 10 fps; Windows will give a process a little "bonus" in scheduling if its window is currently the selected foreground window. Otherwise, you're getting just the normal Windows timeslicing. Nothing fancy.
When I took a quick look at the formula parser some time ago, I was pretty intimidated. The parser looked like an ad hoc design approach, rather than an automatically generated parser, like lex and yacc.
Yes, its pretty inscrutable. My long term approach is actually to replace the parser entirely, but I wouldn't mind fixing the bug that causes some formulas to render incorrectly in the near term.
I guess if the formula parser code is still the original code, that something like the changed #includes and/or data typing and it passing must be the source of the problem.
Its probably some hidden assumption that an int is 16 bits somewhere. I've had to correct a number of those where they did pointer arithmetic and added 2 instead of sizeof(int), and so-on.
I note that you changed the keys that encode different screen resolutions from the original encodings.
The whole business of specifying video resolution by hotkeys is dumb, IMO. It will be replaced with something that lets you specify the resolution directly with a fallback to mapping "default" key assignments to their default resolutions. Its particularly dumb, since the user can change everything so that the key assignments don't mean the same resolutions anymore.
Do you have a web page where you collect the issues/bugs that people report or that you are working on -- beyond the items listed in the BUGS.txt file included in your distribution?
I have a list of bugs that have been reported, some of which are not in that text file since they were reported after the release of that beta version. Feel free to report any bugs to this list.
I don't want to report any items that have already been reported, or reported and fixed like: <---<<
<\> or <h> or <ctrl-h> just redraws the current image Fixed in beta 6
I can always give it a quick test and tell you whether or not I've fixed it already. I've fixed the major ones except for this formula rendering problem. -- "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/>
When I took a quick look at the formula parser some time ago, I was pretty intimidated. The parser looked like an ad hoc design approach, rather than an automatically generated parser, like lex and yacc.
Yes, its pretty inscrutable. My long term approach is actually to replace the parser entirely, but I wouldn't mind fixing the bug that causes some formulas to render incorrectly in the near term.
The language that needs to be parsed is a essentially a 'tiny c'. I will look around and see if anyone has already defined a 'tiny c' in lex and yacc that might be usable. I located a lex specification for ANSI C grammar circa 1985: http://www.lysator.liu.se/c/ANSI-C-grammar-l.html and its corresponding yacc: http://www.lysator.liu.se/c/ANSI-C-grammar-y.html A person posting on this page: http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/550002093631 ( or: http://tinyurl.com/ysyxxt ) said: "Bison has an option to generate a C++ based parser, or a re-entrant C parser. Either of these will feel a lot more modern than the default parser, which with its reliance on global variables, I agree feels very old-fashioned." I found a web page: http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html that says: "Below is a straight port and compilation of FLEX and BISON to the WIN32." The page has downloadable programs for the lex and yacc compatible flex and bison. I have not used lex or yacc or any of their variants. - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces@mailman.xmission.com [mailto:fractdev-bounces@mailman.xmission.com]On Behalf Of Richard Sent: Sunday, February 17, 2008 8:39 PM To: Fractint developer's list Subject: Re: [Fractdev] <Richard> Q's re Fractint for Windows
In article <MDBBJLBFBICIIEIHFBMEOECPDFAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
What currently determines how much of the CPU is given to the calculation of a fractal? <---<<
It runs as fast as it can. Screen updates are limited to 10 fps; Windows will give a process a little "bonus" in scheduling if its window is currently the selected foreground window. Otherwise, you're getting just the normal Windows timeslicing. Nothing fancy.
When I took a quick look at the formula parser some time ago, I was pretty intimidated. The parser looked like an ad hoc design approach, rather than an automatically generated parser, like lex and yacc.
Yes, its pretty inscrutable. My long term approach is actually to replace the parser entirely, but I wouldn't mind fixing the bug that causes some formulas to render incorrectly in the near term.
I guess if the formula parser code is still the original code, that something like the changed #includes and/or data typing and it passing must be the source of the problem.
Its probably some hidden assumption that an int is 16 bits somewhere. I've had to correct a number of those where they did pointer arithmetic and added 2 instead of sizeof(int), and so-on.
I note that you changed the keys that encode different screen resolutions from the original encodings.
The whole business of specifying video resolution by hotkeys is dumb, IMO. It will be replaced with something that lets you specify the resolution directly with a fallback to mapping "default" key assignments to their default resolutions. Its particularly dumb, since the user can change everything so that the key assignments don't mean the same resolutions anymore.
Do you have a web page where you collect the issues/bugs that people report or that you are working on -- beyond the items listed in the BUGS.txt file included in your distribution?
I have a list of bugs that have been reported, some of which are not in that text file since they were reported after the release of that beta version. Feel free to report any bugs to this list.
I don't want to report any items that have already been reported, or reported and fixed like: <---<<
<\> or <h> or <ctrl-h> just redraws the current image Fixed in beta 6
I can always give it a quick test and tell you whether or not I've fixed it already. I've fixed the major ones except for this formula rendering problem. -- "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/>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <MDBBJLBFBICIIEIHFBMECEDCDFAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
When I took a quick look at the formula parser some time ago, I was pretty intimidated. The parser looked like an ad hoc design approach, rather than an automatically generated parser, like lex and yacc.
Yes, its pretty inscrutable. My long term approach is actually to replace the parser entirely, but I wouldn't mind fixing the bug that causes some formulas to render incorrectly in the near term.
The language that needs to be parsed is a essentially a 'tiny c'.
Not really. C syntax is nothing at all like fractint's formula syntax.
'tiny c' in lex and yacc that might be usable.
I'm not using lex/yacc. -- "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 (2)
-
Hal Lane -
Richard