In looking at differences between the float-only version and the head, I'm seeing a number of changes relating to recognizing the '*' at the start of the fractal name. What is the nature of this change and what does it do? Should I prefer the float-only code which doesn't check for names starting with *, or should I prefer the code on the head? -- "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 asked:
In looking at differences between the float-only version and the head, I'm seeing a number of changes relating to recognizing the '*' at the start of the fractal name.
What is the nature of this change and what does it do?
The asterisk makes the fractal type invisible in the list of fractal types shown to the user. The original reason for this was that each different type of math requires an entry in the fractalspecific structure, so only one record should be without an asterisk. Otherwise the user would see multiple instances of the same fractal. Keep in mind that the index in the structure has to be maintained for backwards compatability. So if you look in my float only code, I had to leave blank entries in the structure for the integer versions that I removed. I would like to totally revisit this in the future, but now is not the time. If at all possible your version should save the same fractal information as the DOS version so a fractal is generated with your version should be loadable in any other version with the fractal info intact. The Xwindows and old WInfract do this pretty well. Once your version is working, we can revisit how fractal information is stored.
Should I prefer the float-only code which doesn't check for names starting with *, or should I prefer the code on the head?
I hope my above discussion answers this. Just make sure each fractal type is displayed exactly once in the user list. This should be obvious, but it's really great you are taking on this daunting task. Tim
In article <457ACD46.2749.D0338F@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
The asterisk makes the fractal type invisible in the list of fractal types shown to the user. The original reason for this was that each different type of math requires an entry in the fractalspecific structure, so only one record should be without an asterisk. Otherwise the user would see multiple instances of the same fractal.
So that is why the float-only code drops this? We don't need to distinguish between different "types" that are really the same type but use different math? -- "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 asked:
So that is why the float-only code drops this? We don't need to distinguish between different "types" that are really the same type but use different math?
You don't need asterisks unless there are two or more entries for the same fractal in fractalspecific. The other point I was making (that we should revisit later) is make sure each fractal is in the same position in the fractalspecific structure, otherwise if a DOS user loads a fractal from a GIF, it will regenerate a different fractal. I reserved a fRAc cgunk for PNG but never used it. It will be fun to define this - but later. I'll have some time after Christmas, I'd like to catch up with what you are doing. Tim
In article <457AE844.7414.139A65F@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
[...] The other point I was making (that we should revisit later) is make sure each fractal is in the same position in the fractalspecific structure, otherwise if a DOS user loads a fractal from a GIF, it will regenerate a different fractal.
It looks to me like the float-only code drops the integer fractal types completely from the fractalspecific array in fractalp.c. Is this a defect in the float-only code? -- "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 wrote:
It looks to me like the float-only code drops the integer fractal types completely from the fractalspecific array in fractalp.c.
Is this a defect in the float-only code?
Yikes, I hate to make incorrect statements! I'm in an awkward position with my home office tuned upsidedown by construction so I'm going by memory when I should be checking. I'm sure you are right. There's an array somewhere that maps the new to old indices, or some other way to correct the index that's saved. Sorry I misled you. In the DOS fractint the exact fractalspecific index was saved. In the floatonly version there is some mechanism to correct the index before it is saved. What should be saved is the index of that fractal in the classic DOS version. I've forgotten exactly what I did to achieve that, but I'm sure it is very easy to find now that I've alerted you. Tim
In article <457AF916.29242.17B57F0@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
I'm sure you are right. There's an array somewhere that maps the new to old indices, or some other way to correct the index that's saved.
Ah, yes. I found in loadfile.c an array that maps the old types to the new types during load; there is another similar array that is used when parsing the command-line IIRC. I found the reverse array in encoder.c that saves the correct type number from teh new index. -- "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 <457ACD46.2749.D0338F@twegner.swbell.net>, "Tim Wegner" <twegner@swbell.net> writes:
I would like to totally revisit this in the future, but now is not the time. [...]
Actually I'm thinking that merging in the float-only changes would make things simpler, so I was looking at the diffs. The branch is going to be a flat memory model and there's a point where it deviates from the currnet HEAD so much that the diffs for the float-only version get messier and messier with changes not related to the float-only stuff. So I was looking at merging the float-only stuff into the branch now before things diverge even more. -- "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,
Actually I'm thinking that merging in the float-only changes would make things simpler, so I was looking at the diffs. The branch is going to be a flat memory model and there's a point where it deviates from the currnet HEAD so much that the diffs for the float-only version get messier and messier with changes not related to the float-only stuff.
So I was looking at merging the float-only stuff into the branch now before things diverge even more.
There are still some places in the float-only code where integer math routines are still used. The places I know of are SetupLogTable in mpmath_c.c and the 3d transformation code in 3d.c and line3d.c. There may be others I didn't run across. Jonathan
In article <1165754436.3509.14.camel@linux.site>, Jonathan Osuch <osuchj@avalon.net> writes:
There are still some places in the float-only code where integer math routines are still used. The places I know of are SetupLogTable in mpmath_c.c and the 3d transformation code in 3d.c and line3d.c. There may be others I didn't run across.
Good to know. At the moment, I haven't committed any float-only changes to my refactor branch. I have something experimental, but I decided to heed Tim's advice and leave the float-only until later, even if the diffs are uglier. -- "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 -
Richard -
Tim Wegner