Fractint vs XP, redux
I've read with some interest the discussions on the difficulty of getting the DOS version of Fractint running under Windows XP. While there are obviously solutions around using DOS, FreeDOS, bootable CDs, etc, I can't help thinking that the hassle involved in rebooting is too great for this to be viable. Long-term, some sort of rewrite to make Fractint more environment-neutral so it can have DOS, Windows, X11, etc, flavors built from a largely common code base, would seem to be ideal. But, as has also been pointed out numerous times, this would be a huge undertaking and no-one seems to have the time. I wonder if the more limited goal of getting Fractint and Windows to 'play nice' is more achievable? That is, keep the existing interface and make the minimal changes possible so Fractint will run under XP. It sounds like the major problem is graphics card support - are there any other major gotchas people know about? If that's the main problem, the simplest approach I can think of is: 1) Get Fractint compiling with a modern C compiler toolchain (eg Visual C++) to produce a Win32 executable. 2) Modify the display-driver code to use DirectX, so that Windows supplies the video-card handling. Otherwise leave as a full-screen, character-mode app. (This would of course be IFDEF'ed to leave the existing code intact). That still sounds like a lot of effort, but perhaps a bit more achievable than the 'major rewrite' approach. Does this sound interesting? Plausible? Can anyone think of anything simpler? Would it be simplest to start with the DOS code, or XFractint (or one of the other branches I've heard mentioned)? Regards, -- Edwin
Hi Edwin, If someone can get the code to compile with Microsnot visual c++, I can do the rest. I already have developed a greatly cut down version of FRACTINT called MANPWIN which has true colour support and true windows 32 bit operation. The problem with FRACTINT code is the massive number of globals which makes porting so difficult. Most of them are hard to follow. If only fractint was made of stand alone subroutines, it would be so much easier to port. I understand why it was set up that way due to the speed requirements on 8086 machines, but today, it is not an issue. Fractint is just too big. My 2 cents worth, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com]On Behalf Of Edwin Sent: Thursday, 22 July 2004 12:29 PM To: fractdev@mailman.xmission.com Subject: [Fractdev] Fractint vs XP, redux I've read with some interest the discussions on the difficulty of getting the DOS version of Fractint running under Windows XP. While there are obviously solutions around using DOS, FreeDOS, bootable CDs, etc, I can't help thinking that the hassle involved in rebooting is too great for this to be viable. Long-term, some sort of rewrite to make Fractint more environment-neutral so it can have DOS, Windows, X11, etc, flavors built from a largely common code base, would seem to be ideal. But, as has also been pointed out numerous times, this would be a huge undertaking and no-one seems to have the time. I wonder if the more limited goal of getting Fractint and Windows to 'play nice' is more achievable? That is, keep the existing interface and make the minimal changes possible so Fractint will run under XP. It sounds like the major problem is graphics card support - are there any other major gotchas people know about? If that's the main problem, the simplest approach I can think of is: 1) Get Fractint compiling with a modern C compiler toolchain (eg Visual C++) to produce a Win32 executable. 2) Modify the display-driver code to use DirectX, so that Windows supplies the video-card handling. Otherwise leave as a full-screen, character-mode app. (This would of course be IFDEF'ed to leave the existing code intact). That still sounds like a lot of effort, but perhaps a bit more achievable than the 'major rewrite' approach. Does this sound interesting? Plausible? Can anyone think of anything simpler? Would it be simplest to start with the DOS code, or XFractint (or one of the other branches I've heard mentioned)? Regards, -- Edwin _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <IFEOLDIDHJENENHBALGPIEEEDKAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
If someone can get the code to compile with Microsnot visual c++ [...]
My xfractint branch compiles with vc++. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Rich, Forgive my ignorance, but is your xfractint branch the same thing as fractint compiled with -DXFRACT, or something else? If the latter, what and where is it? As a larger question, what other Fractint branches, offshoots and bifurcations exist? It sounds like a cross between Rich & Paul's code might already be most of the way to a Fractint which works with Windows... -- Edwin ----- Original Message ----- From: "Rich" <legalize@xmission.com> To: "Fractint developer's list" <fractdev@mailman.xmission.com> Sent: Thursday, July 22, 2004 9:50 AM Subject: Re: [Fractdev] Fractint vs XP, redux
In article <IFEOLDIDHJENENHBALGPIEEEDKAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
If someone can get the code to compile with Microsnot visual c++ [...]
My xfractint branch compiles with vc++. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <001901c47073$060f4330$1c02a8c0@edyounghome>, "Edwin Young" <edwin@bathysphere.org> writes:
Forgive my ignorance, but is your xfractint branch the same thing as fractint compiled with -DXFRACT, or something else? If the latter, what and where is it?
My branch is different than just the plain -DXFRACT code. I added a device driver abstraction that I got mostly working but haven't had time to finish, unfortunately. I think I also contributed some .dsw/.dsp files that made the current xfractint code compile with VC++. It wasn't that hard, IIRC.
As a larger question, what other Fractint branches, offshoots and bifurcations exist?
I haven't been actively involved in the source for some time now (more than a year or two), but I believe they setup a fractint CVS source tree somewhere. My device driver abstraction is on the "allegro port", but I don't know where that is in CVS, or if it is in CVS at all. Someone else would be better able to tell you these things... -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
On Friday 23 July 2004 10:26 am, Rich wrote:
I haven't been actively involved in the source for some time now (more than a year or two), but I believe they setup a fractint CVS source tree somewhere. My device driver abstraction is on the "allegro port", but I don't know where that is in CVS, or if it is in CVS at all.
The CVS source is currently on my Syquest drive with a backup on my desktop. There is an old zip of the CVS source which Tim can get to, but afaik he hasn't looked at it yet. The "allegro port" hasn't made it into the CVS source yet because it has issues with files containing DOS end-of-line characters. It is also several patches behind and will not compile in my current development environment. Jonathan
In article <200407231559.51614.osuchj@avalon.net>, Jonathan Osuch <osuchj@avalon.net> writes:
The CVS source is currently on my Syquest drive with a backup on my desktop.
Oops. There's not really much point in having a CVS of the source if its not in a place where all developers can share and checkin. Why can't we get a CVS repository on fractint.org and have ssh keys that let us all do checkin/checkout? -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
Jonathan, you might remember that I have been having problems running Fractint on my "new" (now a year old) home build machine running Windows XP on an Athlon chip. The symptom was that with an SVGA mode, the system hangs up after the fractal is generated. Really hangs - a hard boot is needed. 1. Win XP was innocent - same behavior when booting to DOS. 2. Today I swapped out the ATI Radeon 7500 and put in an old PCI SVGA with an Ark chip, and everything was fine. So the Athlon is innocent. Clue: the ATI board goes in an AGP slot. I wonder if the same ATI board equipped for PCI would exhibit the same behavior? I haven't done this yet, but I could instrument the fractint code and narrow down where the code is hanging. As I said it's after the image generates. But whatever the problem is, it does NOT occur with native VGA modes, including the tweaked modes. I'll look at the output of one of the VESA test programs.
The results of svgainfo for the old ARk board (works OK) and the newer ASTI board (doesn't work) are here: http://tim.fractint.org/ARK.TXT http://tim.fractint.org/ATI7500.TXT Let me know if you spot anything. I see that on the ATI board "4F4Dh, Video Cursor Interface Request function, is Not supported" I also noticed that the number of Kilobytes of video memory shows as zero. Tim
On Saturday 31 July 2004 10:58 pm, Tim Wegner wrote:
The results of svgainfo for the old ARk board (works OK) and the newer ASTI board (doesn't work) are here:
http://tim.fractint.org/ARK.TXT http://tim.fractint.org/ATI7500.TXT
Let me know if you spot anything. I see that on the ATI board "4F4Dh, Video Cursor Interface Request function, is Not supported"
I also noticed that the number of Kilobytes of video memory shows as zero.
The functions of interest would be 4F06h and 4F07h. Does the 640x400 mode work with both adapters? If it does, then the results for a mode that doesn't work may provide more insight. Try starting up with the command line option virtual=n. This might help unless you have already tried using version 20.0 with the same results. Jonathan
Tim,
Try starting up with the command line option virtual=n. This might help unless you have already tried using version 20.0 with the same results.
Never mind. I went back to the older messages and found your answer. Do you get the beep indicating the calculation is complete? Jonathan
Jonathan asked:
Does the 640x400 mode work with both adapters?
Does display ok on the ATI, but hangs. The only reason the SVGOINFO results show 640x400 is that is the default. However, looks like 640x400 is as good as any for our purposes. To answer your question, no, images look complete on the screen, but hang before the beep. I think the program makecfg.exe is based on shows more information, I'll look for it. You know, I've always had trouble with ATI boards and Fractint. Tim
On Sunday 01 August 2004 2:28 pm, Tim Wegner wrote:
To answer your question, no, images look complete on the screen, but hang before the beep.
That does help to narrow it down, but once we've started plotting pixels, what routine would get called that would be affected by the video card???
You know, I've always had trouble with ATI boards and Fractint.
I would agree with that, although my current laptop machine has an ATI video chipset and I haven't had any trouble with it. Jonathan
Hi Rich, Do you have a direct link to the source and the MSVC++ .dsw/.dsp files? Of course the message handler loop needs to be built pretty much from scratch (maybe with a bit from WINFRACT). Please advise. Many thanks, Paul. ---------------------------------------------------------- Paul de Leeuw Computers NSW Central Coast, Australia Email: pdeleeuw@deleeuw.com.au www: < http://www.deleeuw.com.au> ABN 72 360 822 562 ---------------------------------------------------------- -----Original Message----- From: fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com [mailto:fractdev-bounces+pdeleeuw=deleeuw.com.au@mailman.xmission.com]On Behalf Of Rich Sent: Saturday, 24 July 2004 1:27 AM To: Fractint developer's list Subject: Re: [Fractdev] Fractint vs XP, redux In article <001901c47073$060f4330$1c02a8c0@edyounghome>, "Edwin Young" <edwin@bathysphere.org> writes:
Forgive my ignorance, but is your xfractint branch the same thing as fractint compiled with -DXFRACT, or something else? If the latter, what and where is it?
My branch is different than just the plain -DXFRACT code. I added a device driver abstraction that I got mostly working but haven't had time to finish, unfortunately. I think I also contributed some .dsw/.dsp files that made the current xfractint code compile with VC++. It wasn't that hard, IIRC.
As a larger question, what other Fractint branches, offshoots and bifurcations exist?
I haven't been actively involved in the source for some time now (more than a year or two), but I believe they setup a fractint CVS source tree somewhere. My device driver abstraction is on the "allegro port", but I don't know where that is in CVS, or if it is in CVS at all. Someone else would be better able to tell you these things... -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org> _______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
In article <IFEOLDIDHJENENHBALGPOEIADKAA.pdeleeuw@deleeuw.com.au>, "Paul" <pdeleeuw@deleeuw.com.au> writes:
Do you have a direct link to the source and the MSVC++ .dsw/.dsp files?
I'll look around.
Of course the message handler loop needs to be built pretty much from scratch (maybe with a bit from WINFRACT).
Its already builtin to the xfractint. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> Pilgrimage: Utah's annual demoparty <http://pilgrimage.scene.org>
participants (6)
-
Edwin -
Edwin Young
-
Jonathan Osuch -
Paul -
Rich -
Tim Wegner