END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

I had it going nicely with XP (32-bit) with a patch before the old machine died.  Got new machine, very surprised, but then, not really, when I found that Microsoft didn't allow for MOST legacy MSDOS programs to be run easily when they made their latest "improvement" in producing Win7.  It does a whole lot more, but nothing of what I want...anyone else feel this way, or is it just ME?

Anyway, any ideas will be appreciated gratefully.  Thanx!

I thought exactly the same thing, and will have to look at HOW exactly.  Not simple, though...

Still, anyone have anything more like a patch for CMD?  Or did MS make that TRULY impossible?

I have moved it to the correct section and set sticky - hope it helps

I use fractint on Windows 7 64-bit in dosbox which I feel is a quite simple setup.

(image removed)

This is Fractint running on my laptop in a 1024x768 VESA graphics mode after generating the initial rendering of one of my own frm formulas.

Hope this helps.

Simon

Hi fracmonk

I've noticed many times, even in the default 320x200 mode the same thing happens if you switch to any text mode for anything while using fractint.

However, not sure where I read it, but there's some option you can enter when you run fractint which changes this behaviour.  I'll have a quick look right now... (delves into fractint help file).  Option was TEXTSAFE=<s> with the following options for <s>:

TEXTSAFE=yes|no|bios|save
When you switch from a graphics image to text mode (e.g. when you use [F1] while a fractal is on display), Fractint remembers the graphics image, and restores it when you return from the text mode. This should be no big deal - there are a number of well-defined ways Fractint could do this which *should* work on any video adapter. They don't - every fast approach we've tried runs into a bug on one video adapter or another. So, we've implemented a fast way which works on most adapters in most modes as the default, and added this parameter for use when the default approach doesn't work. If you experience the following problems, please fool around with this parameter to try to fix the problem:

Garbled image, or lines or dashes on image, when returning to image after going to menu, [tab] display, or help.
Blank screen when starting Fractint. The problems most often occur in higher resolution modes. We have not encountered them at all in modes under 320x200x256 - for those modes Fractint always uses a fast image save/restore approach.
Textsafe options:

yes:
This is the default. When switching to/from graphics, Fractint saves just that part of video memory which EGA/VGA adapters are supposed to modify during the mode changes.
no:
This forces use of monochrome 640x200x2 mode for text displays (when there is a high resolution graphics image to be saved.) This choice is fast but uses chunky and colorless characters. If it turns out to be the best choice for you, you might want to also specify "textcolors=mono" for a more consistent appearance in text screens.
bios:
This saves memory in the same way as textsafe=yes, but uses the adapter's BIOS routines to save/restore the graphics state. This approach is fast and ought to work on all adapters. Sadly, we've found that very few adapters implement this function perfectly.
save:
It should work on all adapters in all modes but it can be slow. It tells Fractint to save/restore the entire image. Expanded or extended memory is used for the save if you have enough available; otherwise a temporary disk file is used. The speed of textsafe=save will be acceptable on some machines but not others. If this method is too slow, try the other textsafe modes. The speed depends on:
Cpu and video adapter speed.
Whether enough expanded or extended memory is available.
Video mode of image being remembered. A few special modes are *very* slow compared to the rest. The slow ones are: 2 and 4 color modes with resolution higher than 640x480; custom modes for ATI EGA Wonder, Paradise EGA-480, STB, Compaq portable 386, AT&T 6300, and roll your own video modes implemented with customized YOURVID.C code.
If you want to tune Fractint to use different "textsafe" options for different video modes, see &"Customized Video Modes, FRACTINT.CFG" . (E.g. you might want to use the slower textsafe=save approach just for a few high-resolution modes which have problems with textsafe=yes.)

Tried the setting on the basic (F3) mode and it didn't work.

Also, it helps if fractint knows the exact video adaptor being emulated by dosbox.  I've looked at a couple of diagnostic programs (checkit, msd, amidiag) and the univbe program which I managed to download from somewhere a long time ago, and they report different things.

MSD (Microsoft Diagnostics) said the adaptor is an S3 Trio 64
Amidiag was too old (it asked me to describe how the ram chips were located on the mainboard)

UniVBE (universal vesa bios extensions) said the adaptor is a Tseng Labs SuperVGA (ET4000/W32 unknown revision) with 8mb ram

UPDATE: UniVBE was previously set up to be used with a Tseng Labs,  so I ran uvconfig and it then said the card was a S3 Trio 64.

I've looked in the fractint folder and there's a configuration command, makefcfg which should set available vesa video modes in the fractint.cfg file.  Make sure to select the right options, particularly which function key to start with, or it will overwrite the other modes you want to keep.  If you run it with /? option or no parameters, it should give you a list of command line options it supports.

In some of the new modes, the screen didn't seem to get garbled, while in others it did.  Therefore, I'm sure there's a solution, but what it is we will have to continue working on.

Interestingly, the new windows version also has many issues which aren't in the dos version.  I have noticed random mis-alignment of the text windows which progressively gets worse and ends up with only one column of text being displayed, and can crash it regularly by entering the v (view) menu and moving down with the down arrow to the end of available options.  Still, it is a 'development version' and not for general release.  I also notice the windows version doesn't support anything other than floating point calculations, and doesn't go into arbitrary precision after the limits of that are reached.  Most annoying.

Back to the subject of the dos version running in DosBox, I have found significant speed increases by pressing (I think) CTRL-F11 and then CTRL-F8 or is it F9, one of which increases the 'frameskip', the other which increases cycles (don't go too high or it is similar to a pause - it stops completely).  This makes everything run many times faster, and even deep zooms then generate much quicker.

I have seen another version of FractInt, which has been designed to run in windows, manpwin, which has recently been updated, and is very fast when running fractint formulas.  I am running it in Windows 7 64-bit without any problems, and I understand it is based on the original fractint dos and windows source code.

Simon

Hi fractmonk.

Depending on the fractal, you can keep zooming as long as there's something to zoom in and see.  I've written some formula where you keep zooming but see very limited new complexity, and others which look quite bland at the start but when you zoom in a whole new world emerges.  It is so weird how that happens.

I know what you mean about keeping it simple.  My second gallery post (after a banner for the top of the forum page):

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=10567

shows a nice formula with a simple outcome.  You have to zoom out a bit before the circle is completely on screen, and you can zoom in quite a bit into the artefacts with little trouble.  In fact, in the new version of FractInt for Windows I hit the limits of precision quite quickly (it doesn't appear to start using arbitrary precision when it should).

The windows version of Fractint is 16-bit Win3.x software and it will not run in Windows 7 64-bit. The only way to run it under Windows 7 64-bit is to install Windows XP-Mode, and this is only available if you are running Windows 7 Professional. I believe Windows XP mode is the only current method of running 16-bit code at full speed under 64-bit windows. You may also need to enable "Virtual Mode" in your computer's BIOS settings to allow this. DOS-box is an x86 emulator, so you will get significant slowdowns as all the 16-bit pointers will have to be converted to 32-bit before they can be properly executed.

What I would like to know, is why do people still use this software? It's not multi-threaded, and it uses 16-bit integers for deep-zoom arbitrary precision, so it takes 4x as many multiplication instructions as 32-bit software and 16x as many instructions as 64-bit software. On an 8-core machine like mine, that would mean that Fractint (if it runs at all) would render deep-zoom fractals at most about 1/128 as fast as a multi-threaded 64-bit fractal application like Fractal Extreme. If I have to run it in an emulator like DOS-box, the effective render speed would be even slower.

Since Fractint is open-source, why can't it just be possible to compile it to a native 64-bit windows executable with multiple render threads? The performance improvement would be astronomical.