[The branch I am working on] is 32-bit flat address space code all the way.
I think you are right that a lot of things were done to make all of Fractint's features fit into the medium memory model -- and that the flat address space can simplify a number of things.
Its not so much complex as it is simply huge. I may gripe about the use of global variables but its not entirely spaghetti :-).
I'm sure that as one learns more about the code one can see the reasons for why things were done the way they were. It seems to me that the tricky thing in a program this large is the non-call interaction between modules -- that is implemented in global variables and indirect function calls. You have to maintain the state of all the program's options and communicate them all over the place. Even without the restrictions of the medium memory model it seems to me that it would be a tricky task to design a clean architecture for a program that has to retain, update, display and communicate so much state to so many locations in the code. (Not a very good sentence, but I think you probably understand what I am trying to say.) Keep up the good work! - Hal Lane ######################### # hallane@earthlink.net <mailto:hallane@earthlink.net> # #########################
-----Original Message----- From: fractdev-bounces+hallane=earthlink.net@mailman.xmission.com [mailto:fractdev-bounces+hallane=earthlink.net@mailman.xmission.com]On Behalf Of Richard Sent: Tuesday, December 26, 2006 11:11 AM To: Fractint developer's list Subject: Re: [Fractdev] RE: [Richard] Text screens, cursors and help
"Hal Lane" <hallane@earthlink.net> writes:
I suspect the display weirdness comes from not having implemented some of the stubs or [not] having taken into account another global variable that affects the behavior.
BTW, the bug here was that set_attr wasn't honoring g_textrbase and g_textcbase. Now the links highlight in the right place again :-).
Also, the driver abstraction slowed the help screens down tremendously. It turns out that its making a function call per-character (which in the driver translates into a whole buncha stuff going on per-character). I did a quick hack to make things better, but the help page drawer needs to be revisited to draw strings not characters.
I have found at least one global variable defined and initialized in assembler code and used in the c code, so please watch out for that.
Yep. Most of that was handled by the xfractint code since it doesn't use any assembly.
Unfortunately your very useful cross reference won't show you this particular trick.
Yeah, the vendor of that tool says they support assembler, but they don't understand the old 16-bit DOS assembler syntax that fractint uses. I use "find in files" a lot in VS.NET to find references to weird items.
Fractint is pretty scary code. That may come from the Stone Soup method of development. But I am constantly amazed that such complex code has been made so reliable. It is a testament to the dedication of the people who developed it.
Its not so much complex as it is simply huge. I may gripe about the use of global variables but its not entirely spaghetti :-).
The branch is 32-bit flat address space code all the way. Far, near, huge, FCODE, etc., are all gone on the branch. I think some (most?) of the contortions the code goes through are due to the restrictions of the medium memory model. Can't put this code here, or the overlay is too big, can't put this text string here it has to go into the data segment, etc. All those issues go away on the branch and you just write code in the most natural way possible without worrying about overflowing any weird magic number size limits. No need for 'extraseg' to be aliased to 60 different data types because you can't malloc a big working buffer (or declare it staticly!).
I imagine that this will be a relief to Tim and Jonathan. :-) -- "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 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.28/604 - Release Date: 12/26/06
-- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.15.28/604 - Release Date: 12/26/06