Re: [Fractdev] Requst info on FRACTINT Variables for 8 bit to True colour conversion
Hi Tim, I do disagree because there is not a lot of benefit to just porting to WINDOWS. I already ahve a true colour version which works ok on 1/2 pass. This was also the motivation behind MANPWin. I think 32 bit and true colour are more urgent than getting functionality up to 20.2.4. It may be worth while (but dangerous) to keep winows stream separate from the LINUX stream but I am very reluctant to start a new branch if it is not required. Comments please. Thanks, PHD. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: Tim Wegner <twegner@swbell.net> Date: Friday, April 19, 2002 11:53 am Subject: Re: [Fractdev] Requst info on FRACTINT Variables for 8 bit to True colour conversion
I notice that the existing code assumes that color (+dstack and others) are all BYTE. For true colour to have any use, I need to pass a minimum of 16 bits around (32K maxiter) and this is a substantial change to FRACTINT code.
My opinion is that you should not try to simultaneously port Fractint to Win32 and also add truecolor support. I suggest you first port to Win32. If we had a Win32 version of Fractint with good performance and everything working, then we could REALLY start making changes and improvements, because we wouldn't need the DOS version any more. Then adding truecolor could be done more gracefully.
Of course you are free to disagree!
Tim
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
PHD wrote:
I do disagree because there is not a lot of benefit to just porting > to WINDOWS.
The benefit is to abandon the medium memory model. Fractint is incredibly optimized to work amazingly well within that obsolete platform, but further growth is impossible. Please understand I am not saying don't do truecolor, I'm just suggesting finish the port first. If the goal is not to port Fractint, then you might as well keep building on manpwin. By trying to do the port at the same time to attempt massive changes, you will be creating another branch. But once again you can do what you want :-) Tim
On Thursday 18 April 2002 08:44 pm, PHD wrote:
I do disagree because there is not a lot of benefit to just porting to WINDOWS. I already ahve a true colour version which works ok on 1/2 pass. This was also the motivation behind MANPWin. I think 32 bit and true colour are more urgent than getting functionality up to 20.2.4. It may be worth while (but dangerous) to keep winows stream separate from the LINUX stream but I am very reluctant to start a new branch if it is not required.
The benefit would be that you would know what was broken if it didn't work. Was it one of the true color changes or is the port messed up? There are an awful lot of lines of code to go through if you have no idea what or where the problem is. Been there, done that. Keep doing it, and I don't like it! Even if all you do is the port, when you send it to me, the chances are real good that it won't work under Linux. And, I won't have any idea where the problem is. See above. Jonathan
OK guys. I've been thinking a lot about our discussions and I agree that you're right. I was selfish in looking at my own derired outcomes but as a member of a team we should try to keep a single base source together. I agree that we should do incremental improvements so we all stay in synch. This is what I'll do: 1. Get WINFract working on 32 bit memory model for WIN32. 2. As far as possible within the limitations of windows, get the functionality up to 20.2.4. 3. Add 16 bit colour 4. Add a couple of other ideas I've got in mind. I will do minimal changes to the original XFRACT source and then only via #ifdef WIN32 and send the full sources to Jonathan for synchronisation after each of the previous 4 steps. Any experimental code I'll develop into ManpWIN. I'll start from scratch so as to keep the origianl code as pure as I can. Give me some time. Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: "Jonathan Osuch" <osuchj@avalon.net> To: <fractdev@mailman.xmission.com> Sent: Saturday, April 20, 2002 10:19 AM Subject: Re: [Fractdev] Requst info on FRACTINT Variables for 8 bit to True colour conversion On Thursday 18 April 2002 08:44 pm, PHD wrote:
I do disagree because there is not a lot of benefit to just porting to WINDOWS. I already ahve a true colour version which works ok on 1/2 pass. This was also the motivation behind MANPWin. I think 32 bit and true colour are more urgent than getting functionality up to 20.2.4. It may be worth while (but dangerous) to keep winows stream separate from the LINUX stream but I am very reluctant to start a new branch if it is not required.
The benefit would be that you would know what was broken if it didn't work. Was it one of the true color changes or is the port messed up? There are an awful lot of lines of code to go through if you have no idea what or where the problem is. Been there, done that. Keep doing it, and I don't like it! Even if all you do is the port, when you send it to me, the chances are real good that it won't work under Linux. And, I won't have any idea where the problem is. See above. Jonathan _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
On Saturday 20 April 2002 09:57 pm, PHD wrote:
OK guys. I've been thinking a lot about our discussions and I agree that you're right. I was selfish in looking at my own desired outcomes but as a member of a team we should try to keep a single base source together. I agree that we should do incremental improvements so we all stay in synch. This is what I'll do:
1. Get WINFract working on 32 bit memory model for WIN32. 2. As far as possible within the limitations of windows, get the functionality up to 20.2.4. 3. Add 16 bit colour 4. Add a couple of other ideas I've got in mind.
I will do minimal changes to the original XFRACT source and then only via #ifdef WIN32 and send the full sources to Jonathan for synchronisation after each of the previous 4 steps. Any experimental code I'll develop into ManpWIN.
I'll start from scratch so as to keep the original code as pure as I can. Give me some time.
Your enthusiasm for the task is very much appreciated since I don't have the knowledge or inclination to tackle porting to WIN32. As demonstrated by it not having been done yet. Keep in mind that we want to switch over to the float only source one of these days. This isn't very hard, but the patches don't go in cleanly, and some will have to be done by hand. It is my intention (or hope) to eventually switch over to the experimental source. This has the interface code broken out to facilitate porting to other environments. For example, all the X11 specific code is found in d_x11.c. This is another case where the patches don't go in cleanly, so keeping it current is not always on the top of my list. It may be worth a look. This approach reproduces the DOS Fractint user interface. Not very appealing to GUI fans. My current thinking is to dump the Allegro port and make the X11 and disk video versions work using the Allegro port as a road map for how to change routines. The disadvantage to this approach is finding a way to get the sound routines to work. But, one step at a time. When you get to the point of thinking about the assembly language routines, I believe that NASM has been ported over to WIN32. The assembly code has to be rewritten anyway to use the 32 bit environment. Jonathan
Hi Guys, I'm having a lot of trouble getting the 8 bit colour working but actually made a lot of progress with the 16 bit true colour. May I suggest a compromise. I build a 16 bit windows engine but truncate its implementation to pass only 8 bits so the original fractint code has minimal disturbance. The only down side to this is the true colour palette rotation algorithm is very slow on older machines. Comments please. Thanks, Paul de. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: "Jonathan Osuch" <osuchj@avalon.net> To: <fractdev@mailman.xmission.com> Sent: Sunday, April 21, 2002 10:35 PM Subject: Re: [Fractdev] Requst info on FRACTINT Variables for 8 bit to True colour conversion On Saturday 20 April 2002 09:57 pm, PHD wrote:
OK guys. I've been thinking a lot about our discussions and I agree that you're right. I was selfish in looking at my own desired outcomes but as a member of a team we should try to keep a single base source together. I agree that we should do incremental improvements so we all stay in synch. This is what I'll do:
1. Get WINFract working on 32 bit memory model for WIN32. 2. As far as possible within the limitations of windows, get the functionality up to 20.2.4. 3. Add 16 bit colour 4. Add a couple of other ideas I've got in mind.
I will do minimal changes to the original XFRACT source and then only via #ifdef WIN32 and send the full sources to Jonathan for synchronisation after each of the previous 4 steps. Any experimental code I'll develop into ManpWIN.
I'll start from scratch so as to keep the original code as pure as I can. Give me some time.
Your enthusiasm for the task is very much appreciated since I don't have the knowledge or inclination to tackle porting to WIN32. As demonstrated by it not having been done yet. Keep in mind that we want to switch over to the float only source one of these days. This isn't very hard, but the patches don't go in cleanly, and some will have to be done by hand. It is my intention (or hope) to eventually switch over to the experimental source. This has the interface code broken out to facilitate porting to other environments. For example, all the X11 specific code is found in d_x11.c. This is another case where the patches don't go in cleanly, so keeping it current is not always on the top of my list. It may be worth a look. This approach reproduces the DOS Fractint user interface. Not very appealing to GUI fans. My current thinking is to dump the Allegro port and make the X11 and disk video versions work using the Allegro port as a road map for how to change routines. The disadvantage to this approach is finding a way to get the sound routines to work. But, one step at a time. When you get to the point of thinking about the assembly language routines, I believe that NASM has been ported over to WIN32. The assembly code has to be rewritten anyway to use the 32 bit environment. Jonathan _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
On Tuesday 23 April 2002 07:10 am, PHD wrote:
I'm having a lot of trouble getting the 8 bit colour working but actually made a lot of progress with the 16 bit true colour. May I suggest a compromise. I build a 16 bit windows engine but truncate its implementation to pass only 8 bits so the original fractint code has minimal disturbance. The only down side to this is the true colour palette rotation algorithm is very slow on older machines.
Ideally, would you not want to be able to run in 8, 15, 16, 24, and 32 bit color depths? That way the user wouldn't have to change color depths just to run Fractint. The only reason I bring it up is that I have a program at home (I don't remember which one) that requires, as it puts it, thousands of colors. Since I was running 8-bit color for the speed, I changed to 24-bit color. It didn't like that because that wasn't thousands. I had to use 16-bit color to get it to run. Jonathan
Paul de Leeuw (I give up, I can never remeber initials!):
OK guys. I've been thinking a lot about our discussions and I agree that you're right. I was selfish in looking at my own derired outcomes but as a member of a team we should try to keep a single base source together. I agree that we should do incremental improvements so we all stay in synch.
I don't think you were being selfish or that we were "right" and you were "wrong". It's kind of like strategizing about the best path through some mountainous outback. :-) There is something to the idea of separating two complex, systematic changes to a large program. Jonathan said it best when he made the observation that doing the port first permits testing.
This is what I'll do:
1. Get WINFract working on 32 bit memory model for WIN32. 2. As far as possible within the limitations of windows, get the functionality up to 20.2.4. 3. Add 16 bit colour 4. Add a couple of other ideas I've got in mind.
I will do minimal changes to the original XFRACT source and then only via #ifdef WIN32 and send the full sources to Jonathan for synchronisation after each of the previous 4 steps. Any experimental code I'll develop into ManpWIN.
I'll start from scratch so as to keep the origianl code as pure as I can. Give me some time.
That looks like a good plan. I'll get the float-only Xfractint up today. We should decide if that is a better starting point that the regular Xfractint. I have made *no* changes to the DOS float only files, so all you don't have yet are the Xfractint-specific files.. Tim
Hi Tim, I have just about backed out the true colour code but I am going away for a week or so Wednesday so progress will be slow until I return. I have a question about the help files. I want to use the MS helpfiles rather than the help system used by fractint. Is this a problem? Is there an easy way to port the FARCTINT help source files to .rtf for importing to the MS help compiler? Regards, Paul. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: "Tim Wegner" <twegner@swbell.net> To: <fractdev@mailman.xmission.com> Sent: Monday, April 22, 2002 4:43 AM Subject: Re: [Fractdev] Requst info on FRACTINT Variables for 8 bit to Truecolour conversion
Paul de Leeuw (I give up, I can never remeber initials!):
OK guys. I've been thinking a lot about our discussions and I agree that you're right. I was selfish in looking at my own derired outcomes but as a member of a team we should try to keep a single base source together. I agree that we should do incremental improvements so we all stay in synch.
I don't think you were being selfish or that we were "right" and you were "wrong". It's kind of like strategizing about the best path through some mountainous outback. :-)
There is something to the idea of separating two complex, systematic changes to a large program. Jonathan said it best when he made the observation that doing the port first permits testing.
This is what I'll do:
1. Get WINFract working on 32 bit memory model for WIN32. 2. As far as possible within the limitations of windows, get the functionality up to 20.2.4. 3. Add 16 bit colour 4. Add a couple of other ideas I've got in mind.
I will do minimal changes to the original XFRACT source and then only via #ifdef WIN32 and send the full sources to Jonathan for synchronisation after each of the previous 4 steps. Any experimental code I'll develop into ManpWIN.
I'll start from scratch so as to keep the origianl code as pure as I can. Give me some time.
That looks like a good plan. I'll get the float-only Xfractint up today. We should decide if that is a better starting point that the regular Xfractint. I have made *no* changes to the DOS float only files, so all you don't have yet are the Xfractint-specific files..
Tim
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
Paul de Leeuw asked:
I have a question about the help files. I want to use the MS helpfiles rather than the help system used by fractint. Is this a problem?
No and yes. Fractint's own help system was a pioneering hypertext implementation, but there is no longer any need to continue it. Even though as a user I am not personally fond of the Windows help system (it never does what I want!), it makes sense to use it for a windows implementation. But we will want to do something else for other versions.
Is there an easy way to port the FRACTINT help source files to .rtf for importing to the MS help compiler?
Off hand I don't know, but since the help.c program in fractint understands the Fractint system, it can probably be modified to output another form of hypertext. Maybe we need an html help system. So I guess the anwer is we have to figure this out! :-) Tim
Tim, - Even though as a user I am not personally fond of the Windows help - system (it never does what I want!), it makes sense to use it for - a windows implementation. But we will want to do something else for - other versions. Why not just convert the help to HTML format, and use a web browser to display it? This should work on almost all platforms. Damien M. Jones \\ dmj@fractalus.com \\ Fractalus Galleries & Info: \\ http://www.fractalus.com/ Please do not post my e-mail address on a web site or in a newsgroup. Thank you.
Hi Tim, I'll leave the helpfile for a while. I do like the universal approach to html as it will work for all platforms. I'm actually struggling more with 8 bit colour than I thought I would. True colour is easy for me as my commercial program is based on true colour drivers. I will persist however as I am a great believer that WINDOWS is the way forward in the MS arena. Regards, Paul de. ---------------------------------------------------------- Paul de Leeuw Computers Central Coast Australia Email: pdeleeuw@deleeuw.com.au www: <http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- ----- Original Message ----- From: "Tim Wegner" <twegner@swbell.net> To: <fractdev@mailman.xmission.com> Sent: Tuesday, April 23, 2002 9:37 AM Subject: [Fractdev] Re: help systems (was Requst info on FRACTINT Variables for 8 bit toTruecolour conversion)
Paul de Leeuw asked:
I have a question about the help files. I want to use the MS helpfiles rather than the help system used by fractint. Is this a problem?
No and yes. Fractint's own help system was a pioneering hypertext implementation, but there is no longer any need to continue it. Even though as a user I am not personally fond of the Windows help system (it never does what I want!), it makes sense to use it for a windows implementation. But we will want to do something else for other versions.
Is there an easy way to port the FRACTINT help source files to .rtf for importing to the MS help compiler?
Off hand I don't know, but since the help.c program in fractint understands the Fractint system, it can probably be modified to output another form of hypertext.
Maybe we need an html help system.
So I guess the anwer is we have to figure this out! :-)
Tim
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
participants (5)
-
Damien M. Jones -
Jonathan Osuch -
Paul de Leeuw -
pdeleeuw -
Tim Wegner