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/>