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/>
Richard said:
Things are progressing along rather nicely.
It sounds like you are really moving forward.
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.
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. Unfortunately your very useful cross reference won't show you this particular trick. I think I must have used the 'Search the contents of multiple files' feature in MS Visual Studio to find the declaration in the assembler file. 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. - 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: Monday, December 25, 2006 12:37 AM To: fractdev@mailman.xmission.com Subject: [Fractdev] Text screens, cursors and help
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... --
-- 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
In article <MDBBJLBFBICIIEIHFBMEEEPLCOAA.hallane@earthlink.net>, "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/>
[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
In article <MDBBJLBFBICIIEIHFBMEKEPMCOAA.hallane@earthlink.net>, "Hal Lane" <hallane@earthlink.net> writes:
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.
I do scratch my head sometimes and wonder. But I just accept it for what it is now and move forward. I was looking at old source releases of fractint and looking at how things have been added to it over the years. Its more of a curiosity than a useful guide to what we have now.
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.
That's where that xref I posted is handy. You can see where a variable is used so you know which parts of the code are talking to each other through those variables. Still, it does require "study" of the source. There's a certain point where a pile of software is simply too large to understand by scanning a few files or screen fulls of statements. That's when it takes "studying" and not just browsing. Fractint does have a pile of globals -- externs.h is 906 lines long in my branch. However, they roughly fall into three categories: stuff for the current fractal being computed, stuff for the user interface and stuff for the video configuration. I'm moving down a path on the branch that leads to the engine being separated from the UI/video. *That* opens the door for lots of interesting possibilities, like fractint on the xbox 360 and using a controller to pan/zoom. -- "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/>
I'm moving down a path on the branch that leads to the engine being separated from the UI/video.
Great!
...That's where that xref I posted is handy.
I'd say closer to 'invaluable.' - 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 5:16 PM To: Fractint developer's list Subject: Re: [Fractdev] [Richard] Keep up the good work!
"Hal Lane" <hallane@earthlink.net> writes:
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.
I do scratch my head sometimes and wonder. But I just accept it for what it is now and move forward. I was looking at old source releases of fractint and looking at how things have been added to it over the years. Its more of a curiosity than a useful guide to what we have now.
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.
That's where that xref I posted is handy. You can see where a variable is used so you know which parts of the code are talking to each other through those variables. Still, it does require "study" of the source. There's a certain point where a pile of software is simply too large to understand by scanning a few files or screen fulls of statements. That's when it takes "studying" and not just browsing.
Fractint does have a pile of globals -- externs.h is 906 lines long in my branch. However, they roughly fall into three categories: stuff for the current fractal being computed, stuff for the user interface and stuff for the video configuration.
I'm moving down a path on the branch that leads to the engine being separated from the UI/video. *That* opens the door for lots of interesting possibilities, like fractint on the xbox 360 and using a controller to pan/zoom. --
-- 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
participants (2)
-
Hal Lane -
Richard