Re: [Fractint] xfractint questions and quirks
On Wed, 13 Nov 2002 21:14:49 -0600 Jonathan Osuch <osuchj@avalon.net> wrote
1. ---------- passes=b does not work, it freezes up xfractint.
Yes, it's broke. ?It is on my list of bugs to fix.
Good luck!
?> 2. ---------- Why is the initial colormap different from the
Put map=default.map in an sstools.ini file. ?Now, where to put the sstools.ini file, I don't have a clue.
I'll try to figure out where to put it.
?> 3. ---------- Is there no way to use multiple directories in
xfractint?
Use sstools.ini to define your subdirectories.
As soon as I've found out where to put it ;-)
4. ---------- In DOS I could move to another dir or to another ?> > drive, xfractint doesn't seem to know there are subdirs in the ?> > default dir.
Hmm, somebody should fix that. ?8-))
Would be great. ?> > 5. ---------- Is it possible to create an xfractint.rc file
Yes, use sstools.ini.
Yes, as soon as ... ;-) ?> > 6. ---------- When I use <Page-Up> to call up a zoombox it is not ?> > always visible. I tried <Ctrl-Ins> and <Ctrl-Del> to change the ?> > colors, no effect whatsoever. I tried <Ctrl-I> and <Ctrl-D> too, ?> > still no change of color. When using the mouse, the zoombox is ?> > visible. It makes no difference if I use the left or the right ?> > button. Manipulating the zoombox while using the mouse seems ?> > impossible. As soon as I release the button, the zoom-in is drawn.
Mouse support is not what it should be, yet. ?One of these days someone will get to working on it.
Thank you. And what about the invisible zoombox? And the color changing? ?> > 7. ---------- Sound doesn't work always. Sometimes it beeps
Sound is not implemented in Xfractint.
Doesn't really matter. ?> > 8. ---------- In the Helpscreens: Backspace to get to the Last
Topic dooesn't work. The Helpscreens get scrambled
Other than the top line being scrambled (it's on the list), the help screens work fine for me. ?Even the backspace works.
I've tried another xterm and yes, the Backspace works and the screen does not get scrambled. It seems that the various xterms behave differently. In this xterm the 'image-is-completed' beep uses the internal speaker. In the one I previously used the sound came via the soundcard. Natalie -- Stolen tagline: Linux is like a wigwam, no windows, no gates, apache inside. [ Linux Counter: user 230952 machine: 111180 ]
Jonathan wrote
Put map=default.map in an sstools.ini file. Now, where to put the sstools.ini file, I don't have a clue.
I wrote
I'll try to figure out where to put it.
I still don't know where to put the sstools.ini file but I found a solution. I tried with sstools.ini in the xfractint dir, no good. Then with SSTOOLS.INI, no. Both versions in my homedir, didn't work. Changed them to hidden files ( .SSTOOLS.INI & .sstools.ini), no effect. Looked through the code, didn't get any wiser. Renamed sstools.ini (the one in the xfractint dir) to xftest, typed xfractint @xftest an error message flashed past, I spotted the words couldn't understand ... I edited xftest, removed the first line, the one that says: [xfractint] And it WORKS! Natalie -- Stolen tagline: Linux is like a wigwam, no windows, no gates, apache inside. [ Linux Counter: user 230952 machine: 111180 ]
Natalie, I use a sub-directory named xfractint under my home directory. This is where all my user-generated files (such as par files and gif files) go. Before starting xfractint, I always `cd' to that direcory. Put your sstools.ini file in this xfractint directory. Xfractint looks for [fractint] (the DOS name) in sstools.ini. Scott On Thursday 14 November 2002 14:04, Natalie wrote:
Jonathan wrote
Put map=default.map in an sstools.ini file. Now, where to put the sstools.ini file, I don't have a clue.
I wrote
I'll try to figure out where to put it.
I still don't know where to put the sstools.ini file but I found a solution.
I tried with sstools.ini in the xfractint dir, no good. Then with SSTOOLS.INI, no. Both versions in my homedir, didn't work. Changed them to hidden files ( .SSTOOLS.INI & .sstools.ini), no effect.
Looked through the code, didn't get any wiser.
Renamed sstools.ini (the one in the xfractint dir) to xftest, typed xfractint @xftest an error message flashed past, I spotted the words couldn't understand ...
I edited xftest, removed the first line, the one that says: [xfractint]
And it WORKS!
Natalie
-- sdboyd56@swbell.net http://sdboyd.dyndns.org --------------------------------------- No Microsoft or other proprietary products were used in the creation of this email.
I've been animating my fractals with fractint using *.bat & *.par files created by "proggies" like batcher, fae, etc.... Even though I'm trying to use distributed processing, ie., a "main.bat" type file that "calls" other "sub.bat" files, I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower. Is there any way in writing the batch files that I can stop the "slowing down" and speed things up at bit? Would memory be a factor? Is there some kind of memory leak? I've allowed 8196K for XMS, 8196K for DPMI, I also checked HMA, and checked "protected" in the "convetional memory" settings for the "DOS Box" that's running the bat files. Should I allocate even more memory? Is there anything erong with the settings? What other settings should I be looking at? Does command.com use EMS? Should I be allocating memory to EMS? Ideas Anyone??? Is there something in the way I'm writing the *.bat files? I'm using "call" statments to call other smaller *.bat files. For example: ECHO OFF CALL 5SP001.BAT CALL 5SP002.BAT CALL 5SP003.BAT CALL 5SP004.BAT CALL 5SP005.BAT CALL 5SP006.BAT ........ etc. Then those *.bat files in turn call fractint and *.par files: FRACTINT @e:\fract\par\5sp001.par/Step0 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step1 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step2 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step3 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step4 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step5 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step6 BATCH=Y IF ERRORLEVEL 2 GOTO END .........etc....
What OS are you using (DOS WINDOWS)? Doug Stewart Tony Parker wrote:
I've been animating my fractals with fractint using *.bat & *.par files created by "proggies" like batcher, fae, etc....
Even though I'm trying to use distributed processing, ie., a "main.bat" type file that "calls" other "sub.bat" files, I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower.
Is there any way in writing the batch files that I can stop the "slowing down" and speed things up at bit?
Would memory be a factor? Is there some kind of memory leak? I've allowed 8196K for XMS, 8196K for DPMI, I also checked HMA, and checked "protected" in the "convetional memory" settings for the "DOS Box" that's running the bat files.
Should I allocate even more memory? Is there anything erong with the settings?
What other settings should I be looking at? Does command.com use EMS? Should I be allocating memory to EMS?
Ideas Anyone???
Is there something in the way I'm writing the *.bat files? I'm using "call" statments to call other smaller *.bat files. For example:
ECHO OFF CALL 5SP001.BAT CALL 5SP002.BAT CALL 5SP003.BAT CALL 5SP004.BAT CALL 5SP005.BAT CALL 5SP006.BAT ........ etc.
Then those *.bat files in turn call fractint and *.par files:
FRACTINT @e:\fract\par\5sp001.par/Step0 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step1 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step2 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step3 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step4 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step5 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step6 BATCH=Y IF ERRORLEVEL 2 GOTO END .........etc....
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Doug: Thanks for your reply. Please read the Message Subject Header of my e-mail message which should read: "Problems Using Fractint With Bat Files In Win98 Dos Box" Does that answer your question? Now, can you answer my question? TIA, Tony ----- Original Message ----- From: "Doug Stewart" <dastew@sympatico.ca> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 6:09 AM Subject: Re: [Fractint] Problems Using Fractint With Bat Files In Win98 Dos Box.
What OS are you using (DOS WINDOWS)? Doug Stewart
Tony Parker wrote:
I've been animating my fractals with fractint using *.bat & *.par files created by "proggies" like batcher, fae, etc....
Even though I'm trying to use distributed processing, ie., a "main.bat" type file that "calls" other "sub.bat" files, I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower.
Is there any way in writing the batch files that I can stop the "slowing down" and speed things up at bit?
Would memory be a factor? Is there some kind of memory leak? I've allowed 8196K for XMS, 8196K for DPMI, I also checked HMA, and checked "protected" in the "convetional memory" settings for the "DOS Box" that's running the bat files.
Should I allocate even more memory? Is there anything erong with the settings?
What other settings should I be looking at? Does command.com use EMS? Should I be allocating memory to EMS?
Ideas Anyone???
Is there something in the way I'm writing the *.bat files? I'm using "call" statments to call other smaller *.bat files. For example:
ECHO OFF CALL 5SP001.BAT CALL 5SP002.BAT CALL 5SP003.BAT CALL 5SP004.BAT CALL 5SP005.BAT CALL 5SP006.BAT ........ etc.
Then those *.bat files in turn call fractint and *.par files:
FRACTINT @e:\fract\par\5sp001.par/Step0 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step1 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step2 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step3 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step4 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step5 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step6 BATCH=Y IF ERRORLEVEL 2 GOTO END .........etc....
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
I'm trying to evaluate which is the fastest method for generating thousands of files for my fractal animations. I've been playing with partobat, FA100, FAE, Batcher etc.. which generate long BAT files with call statments and also calling Fractint *.par files. I'm also comparing that method with Fractint's internal Autokey scripting feature. I'd like to hear opinions which method might work best for generating thousands of images without "slowing down".. Just for the record I'm running the Fractint and the batch files from within a Win98 Dos Box. Here's a typical line from one of my bat files: FRACTINT @e:\fract\par\5sp001.par/Step0 BATCH=Y I've noticed on the long runs there's been a gradual "slowing down" of the Fractint processing speed. Is that due to "memory leaks" caused by the constant loading and unloading of Fractint from within a Win98 DOS box? Are there any Fractint or Win98 Dos Box settings or tweaks that might solve that problem? Does either Fractint or command.com need EMS to run the batch files? If that problem can't be solved, I'm looking at using the Fractint Autokey scripting as an alternative. Say I were to run a similar Fractint Autokey file to generate thousands of images, using a long Fractint Autokey file, would Fractint's processing speed remain constant, or would there also be this phenomenon of Fractint "slowing down"? The idea is to use the Autokey script to instruct Fractint to load a *.par file, parse the pars and then generate and save images. It seems to work OK for the few files that I ran. Will it work OK if I try to run an Autokey script to generate say 4,000 images? Heres my sample autokey file: ;; CALCWAIT "2" CALCWAIT F6 CALCWAIT ;; 5sp001.par "5sp001.par" ENTER ;; steps.key ;; ;; step0 "step0" ENTER CALCWAIT "s" CALCWAIT ;; step1 "@" "step1" ENTER CALCWAIT "s" CALCWAIT ;; step2 "@" "step2" ENTER CALCWAIT "s" CALCWAIT
Here's a Fractint Autokey Question I'm Using Fractint With Bat Files & Fractint Auto.key In A Win98 Dos Box. Is it possible to "call" distributed secondary Fractint autokey script files from within a "master" Fractint Autokey script files in a similar manner to calling distributed secondary bat files from a "master" bat file? For example in a "main.bat" file you would call other secondary files thusly: call sub1.bat call sub2.bat call sub3.bat What would be the correct "code" in the Fractint Autokey "language" to instruct Fractint to "call" secondary Autokey script files? Thanks in Advance, Tony
I'm investigating the "G" command string function. Would someone be kind enough to tell me how it works? Can you input more than one command string params at a time, or does it work one param at a time? Some command string params seem to work fine but others don't I can't get the following command string params to work. What am I (not) doing? autokey=play|record autokeyname=foobar.key If I can get this to work, then I want to try to use the "G" command string function in an autokey file to call other "nested" autokey files. Do you think it will work? TIA, Tony ----- Original Message ----- From: "Tony Parker" <tgparker@worldnet.att.net> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 2:13 PM Subject: [Fractint] Fractint Autokey Script Question
Here's a Fractint Autokey Question
I'm Using Fractint With Bat Files & Fractint Auto.key In A Win98 Dos Box.
Is it possible to "call" distributed secondary Fractint autokey script files from within a "master" Fractint Autokey script files in a similar manner to calling distributed secondary bat files from a "master" bat file?
For example in a "main.bat" file you would call other secondary files thusly:
call sub1.bat call sub2.bat call sub3.bat
What would be the correct "code" in the Fractint Autokey "language" to instruct Fractint to "call" secondary Autokey script files?
Thanks in Advance,
Tony
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Tony Parker wrote:
For example in a "main.bat" file you would call other secondary files thusly:
call sub1.bat call sub2.bat call sub3.bat
[I usually don't bother with the "call", but hey...]
What would be the correct "code" in the Fractint Autokey "language" to instruct Fractint to "call" secondary Autokey script files?
As I understand it, an Autokey script is just a fairly direct translation of keystrokes of the sort made during an autokey recording (with the autokey parser effectively taking over from the keyboard). As such, there are virtually no flow control or suchlike constructs, only keystroke commands. (There's a GOTO label construct, but without conditionals, it's only of limited use). In particular, there's no "include" directive. (And if you try and specify a new script during playback via "G", it doesn't seem to work.) It would be a Good Thing (at least, in my opinion), if the Autokey feature were to be extended to become more of a proper scripting language however. Then I wouldn't need to write Perl scripts to write Autokey scripts :) Morgan L. Owens "Hey, it worked for emacs"
Here's one for the archiologists.... Around 1988 a fellow called Nigel H. J. Long, from Southampton, in the UK, was posting messages to the Fractint mailing list about his writng a Fractint support Proggie that would scan *.par files, and then generate autokey files. apparently the fellow was using this proggie to help him generate image files for making fractal animations with Fractint. Does anybody remember this proggie? What was it's name? Where is it located? Where Can One D/L it? All the best, Tony
Morgan: Thanks for your reply. Who would you know on the "F-Team" is the expert for the Autokey scripting language? I would definitely like to confirm what you say about the "G" command being unable to "call" another autokey script. I had the same experience as you did, but I just thought that I wasn't using the "G" command properly when things in Fractint didn't happen the way I wanted them to. I'd really like to hear from anybody else who might have some more detailed experience to share with the Fractint autokey scripting language. All the best, Tony ----- Original Message ----- From: "Morgan L. Owens" <packrat@nznet.gen.nz> To: <fractint@mailman.xmission.com> Sent: Saturday, November 16, 2002 2:01 AM Subject: Re: [Fractint] Fractint Autokey Script Question
Tony Parker wrote:
For example in a "main.bat" file you would call other secondary files thusly:
call sub1.bat call sub2.bat call sub3.bat
[I usually don't bother with the "call", but hey...]
What would be the correct "code" in the Fractint Autokey "language" to instruct Fractint to "call" secondary Autokey script files?
As I understand it, an Autokey script is just a fairly direct translation of keystrokes of the sort made during an autokey recording (with the autokey parser effectively taking over from the keyboard). As such, there are virtually no flow control or suchlike constructs, only keystroke commands. (There's a GOTO label construct, but without conditionals, it's only of limited use). In particular, there's no "include" directive. (And if you try and specify a new script during playback via "G", it doesn't seem to work.)
It would be a Good Thing (at least, in my opinion), if the Autokey feature were to be extended to become more of a proper scripting language however. Then I wouldn't need to write Perl scripts to write Autokey scripts :)
Morgan L. Owens "Hey, it worked for emacs"
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Morgan wrote:
As I understand it, an Autokey script is just a fairly direct translation of keystrokes of the sort made during an autokey recording (with the autokey parser effectively taking over from the keyboard). As such, there are virtually no flow control or suchlike constructs, only keystroke commands.
This is exactly right. The autokey feature was written in a few days time when the book Fractal Creations was being put together, in order to do demos. Since all Fractint keystroke I/O goes through one function, it occurred to me that if I could intercept those keystrokes, I could duplicate the interactive control of the program, feeding the keystrokes back through the same function. The GOTO was added later. One intense session of programming added a very useful feature in a short time.
It would be a Good Thing (at least, in my opinion), if the Autokey feature were to be extended to become more of a proper scripting language however. Then I wouldn't need to write Perl scripts to write Autokey scripts :)
The beauty, and the weakness, of the autokey setup is that it is literally tied to keystrokes. This means that you can get autokey to make fractint do (almost) anything that a person can make fractint do. But it also means that the scripts are nearly un-intelligible, and are also liable to be broken anytime the the programmers change the user interface. A "proper" scripting language would be more abstract, and would be procedural. This would be more independent of the interface. However, this would be a completely different animal from the existing scripting language, which basically reads the script file and feeds keystrokes into fractint's keystrock function as though a person had typed them. So I don't think this will happen unless someone wants to add a completely new feature (many years ago I did give it some thought.) An autokey include mechanism is probably doable, though I am not sure I see the point. Maybe Tony can convince me :-) Or maybe he has already made a case, I'll go back and read the messages. Tim
Tim: Thanks for your input. I was hoping to know which autokey features were still "working" and which weren't. I have been trying to write autokey scripts in the same way that I've been writing *.bat files to instruct Fractint to generate thousands of fractal images which can then be compiled into an animated fractal image. The advantage to using autokey is that when running an "internal" autokey script you need only one instance of fractint running continuously, rather than constantly loading and unloading fractint from an "external" *.bat file. There doesn't seem to be that much actual documentation even in the Fractint manual about how to actually use the autokey script feature. I'd really like to have a definitive "primer" of the proper "language" and syntax" that can be used in an autokey script file. I have also attached a copy of one of my autokey script files as an example. I was hoping that one could "call" autokey script files by using the "G" command and thus have "nested" processing of multiple script files. I have tried to access other features via the "G" command and I'd really like to have a definiteve "primer" of what can be done via the "G" command. I have been unable to load autokey files via the "G" command either manually or from a autokey script file. I was wondering which features can actually be controled via the "G" command? If you are thinking of upgrading Fractint's autokey script language, you have my vote. I definitely think an internal script language for Fractint with just a little bit more muscle than it now has would be a most useful feature. All the best, Tony ----- Original Message ----- From: "Tim Wegner" <twegner@swbell.net> To: <fractint@mailman.xmission.com> Sent: Monday, November 25, 2002 11:21 PM Subject: Re: [Fractint] Fractint Autokey Script Question
Morgan wrote:
As I understand it, an Autokey script is just a fairly direct translation of keystrokes of the sort made during an autokey recording (with the autokey parser effectively taking over from the keyboard). As such, there are virtually no flow control or suchlike constructs, only keystroke commands.
This is exactly right. The autokey feature was written in a few days time when the book Fractal Creations was being put together, in order to do demos. Since all Fractint keystroke I/O goes through one function, it occurred to me that if I could intercept those keystrokes, I could duplicate the interactive control of the program, feeding the keystrokes back through the same function. The GOTO was added later. One intense session of programming added a very useful feature in a short time.
It would be a Good Thing (at least, in my opinion), if the Autokey feature were to be extended to become more of a proper scripting language however. Then I wouldn't need to write Perl scripts to write Autokey scripts :)
The beauty, and the weakness, of the autokey setup is that it is literally tied to keystrokes. This means that you can get autokey to make fractint do (almost) anything that a person can make fractint do. But it also means that the scripts are nearly un-intelligible, and are also liable to be broken anytime the the programmers change the user interface.
A "proper" scripting language would be more abstract, and would be procedural. This would be more independent of the interface. However, this would be a completely different animal from the existing scripting language, which basically reads the script file and feeds keystrokes into fractint's keystrock function as though a person had typed them. So I don't think this will happen unless someone wants to add a completely new feature (many years ago I did give it some thought.)
An autokey include mechanism is probably doable, though I am not sure I see the point. Maybe Tony can convince me :-) Or maybe he has already made a case, I'll go back and read the messages.
Tim
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Tony wrote:
There doesn't seem to be that much actual documentation even in the > Fractint manual about how to actually use the autokey script feature. I'd really like to have a definitive "primer" of the proper "language" and syntax" that can be used in an autokey script file. I have also attached a copy of one of my autokey script files as an example.
It's basically literal keystrokes as you would type them in , with some special words for special keys. Have you found the section on autokey in the docs? You have to search a bit, it's under startup parameters. If you can't find it, I could upload it in a message.
I was hoping that one could "call" autokey script files by using the "G" command and thus have "nested" processing of multiple script files. I have tried to access other features via the "G" command and I'd really like to have a definiteve "primer" of what can be done via the "G" command.
Basically, the "G" command lets you type in (almost) anything interactively that you can type in on the fractint command line. I say almost because I'm sure there are some limitations. For example: passes=2 changes the passes mode from whatever it was (guessing is the default) to 2. The results is the same as if you started fractint with: fractint passes=2
I have been unable to load autokey files via the "G" command either manually or from a autokey script file.
The autokey feature only works when it is started at runup. This is probably hard to change. If making an "include" command within an autokey file would suit your needs, it might not be too hard. The problem, though, is since the autokey commands are literal keystrokes, their effect depends on fractint's state. So you can't just include any old key file inside another without paying attention to whether the keystrokes make sense with fractint in the state it's in when the file is included. Sorry that thought is so convoluted :-)
I was wondering which features can actually be controled via the "G" command?
I'll look in the code and give you a list.
If you are thinking of upgrading Fractint's autokey script language, you have my vote. I definitely think an internal script language for Fractint with just a little bit more muscle than it now has would be a most useful feature.
I have "thought" about it in the past :-). These days, though, the big topic is porting fractint more than adding new features. It would make a lot more sense to implement a macro language after the program is ported. Tim
Tony Parker wrote:
I'm trying to evaluate which is the fastest method for generating thousands of files for my fractal animations.
I've been playing with partobat, FA100, FAE, Batcher etc.. which generate long BAT files with call statments and also calling Fractint *.par files.
I'm also comparing that method with Fractint's internal Autokey scripting feature. I'd like to hear opinions which method might work best for generating thousands of images without "slowing down"..
Offhand (very offhand), does Win98 still offer a setting called "Idle Sensitivity" in the DOS-Box settings? If so, how far towards "Low" is it set?
Thank you for your reply. I have greatly enjoyed reading your past and recent comments on the Fractint mailing list. I'm running Fractint and the *.bat files in a Win98 Dos Box. The Win98 Dos Box "Properties" > "Misc" > "Idle Sensitivity" slider is set to about 25% from "Low" (left). Are there any other settings that I should have a look at? BTW, in one of your archived Fractint mailing list messages you mentioned a special proggie that scanned *.par files and wrote the data to autokey files. Is it still around? What is it called? Where can I D/L it? Thanks again for your comments. Tony ----- Original Message ----- From: "Morgan L. Owens" <packrat@nznet.gen.nz> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 11:53 PM Subject: Re: [Fractint] Using Fractint With Bat Files Vs Fractint Auto.key In A Win98 Dos Box.
Tony Parker wrote:
I'm trying to evaluate which is the fastest method for generating thousands of files for my fractal animations.
I've been playing with partobat, FA100, FAE, Batcher etc.. which generate long BAT files with call statments and also calling Fractint *.par files.
I'm also comparing that method with Fractint's internal Autokey scripting feature. I'd like to hear opinions which method might work best for generating thousands of images without "slowing down"..
Offhand (very offhand), does Win98 still offer a setting called "Idle Sensitivity" in the DOS-Box settings? If so, how far towards "Low" is it set?
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
You might want to look at http://mvps.org/winmac/help.html John W. ----- Original Message ----- From: "Tony Parker" <tgparker@worldnet.att.net> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 9:42 PM Subject: Re: [Fractint] Using Fractint With Bat Files Vs Fractint Auto.key In A Win98 Dos Box.
Thank you for your reply.
I have greatly enjoyed reading your past and recent comments on the Fractint mailing list.
I'm running Fractint and the *.bat files in a Win98 Dos Box.
The Win98 Dos Box "Properties" > "Misc" > "Idle Sensitivity" slider is set to about 25% from "Low" (left).
Are there any other settings that I should have a look at?
BTW, in one of your archived Fractint mailing list messages you mentioned a special proggie that scanned *.par files and wrote the data to autokey files.
Is it still around? What is it called? Where can I D/L it?
Thanks again for your comments.
Tony ----- Original Message ----- From: "Morgan L. Owens" <packrat@nznet.gen.nz> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 11:53 PM Subject: Re: [Fractint] Using Fractint With Bat Files Vs Fractint Auto.key In A Win98 Dos Box.
Tony Parker wrote:
I'm trying to evaluate which is the fastest method for generating thousands of files for my fractal animations.
I've been playing with partobat, FA100, FAE, Batcher etc.. which generate long BAT files with call statments and also calling Fractint *.par files.
I'm also comparing that method with Fractint's internal Autokey scripting feature. I'd like to hear opinions which method might work best for generating thousands of images without "slowing down"..
Offhand (very offhand), does Win98 still offer a setting called "Idle Sensitivity" in the DOS-Box settings? If so, how far towards "Low" is it set?
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
I'd like to thank Tony Parker and all the others dishing out advice recently. I'm in the middle of creating a dual-boot DOS / Linux system, and found some of that stuff useful! I have a DOS 6.2.2 system running, and *used to have* RedHat Linux 5.2 installed, using LILO to boot to either/or. Unfortunately, I stumbled over a "50%-off" Osborne "Complete Reference" which contained a CD of the publishers version of RH 7.0. When I tried to install this, I blew the whole of the Linux half of the computer. Now I'm fighting to get it re-installed.in the face of a major problem...I know nothing of Linux! I have Fractint running in the DOS half, and have Scott Boyd's Xfractint package ready to install when I finally get past that installation problem. While researching the DOS stuff, I ran across the best DOS navigator ever; new shareware from Russia http://www.ritlabs.com/dn/ This is the best I've seen since Central Point Software's "PCTools" went into oblivion. Someone was looking for exactly this...Tony? John W.
Doug: Sorry about my slightly arch reply to your earlier e-mail, you caught me in a groughy moment. Just for the record, here's the specs on my Win98 Dos Box. If you or anyone else sees anything that should be changed please let me know. Ms-Dos Box > Properties > General > Archive - Checked Ms-Dos Box > Properties > Program > Run - Maximized Ms-Dos Box > Properties > Program > Close on exit - Checked Ms-Dos Box > Properties > Memory > Conventional memory > Total - Auto Ms-Dos Box > Properties > Memory > Conventional memory > Initial environmrnt - Auto Ms-Dos Box > Properties > Memory > Conventional memory > Protected - Checked Ms-Dos Box > Properties > Memory > Expanded (EMS) memory > Total - None Ms-Dos Box > Properties > Memory > Extended (XMS) memory > Total - 8192 Ms-Dos Box > Properties > Memory > Extended (XMS) memory > Uses HMA - Checked Ms-Dos Box > Properties > Memory > MS-DOS protected-mode (DPMI) memory > Total - 8192 Ms-Dos Box > Properties > Screen > Usage > Full screen - Selected Ms-Dos Box > Properties > Screen > Usage > Initial size - Default Ms-Dos Box > Properties > Screen > Window > Display toolbar - Checked Ms-Dos Box > Properties > Screen > Window > Restore settings on startup - Checked Ms-Dos Box > Properties > Screen > Window > Performance > Fast ROM emulation - Checked Ms-Dos Box > Properties > Screen > Window > Performance > Dynamic memory allocation - Unchecked Ms-Dos Box > Properties > Misc > Foreground > Allow screen saver - Unchecked Ms-Dos Box > Properties > Misc > Mouse > QuickEdit - Checked Ms-Dos Box > Properties > Misc > Mouse > Exclusive mode - Unchecked Ms-Dos Box > Properties > Misc > Background > Always suspend - Checked Ms-Dos Box > Properties > Misc > Termination > Warn if still active - Checked Ms-Dos Box > Properties > Misc > Idle sensitivity - Slider is 25% from Low (left) Ms-Dos Box > Properties > Misc > Other > Fast pasting - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Tab - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Ctl+Esc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+PrtSc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Space - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Esc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > PrtSc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Enter - Checked There are all my settings! All the best, Tony ----- Original Message ----- From: "Doug Stewart" <dastew@sympatico.ca> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 6:09 AM Subject: Re: [Fractint] Problems Using Fractint With Bat Files In Win98 Dos Box.
What OS are you using (DOS WINDOWS)? Doug Stewart
Tony Parker wrote:
I've been animating my fractals with fractint using *.bat & *.par files created by "proggies" like batcher, fae, etc....
Even though I'm trying to use distributed processing, ie., a "main.bat" type file that "calls" other "sub.bat" files, I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower.
Is there any way in writing the batch files that I can stop the "slowing down" and speed things up at bit?
Would memory be a factor? Is there some kind of memory leak? I've allowed 8196K for XMS, 8196K for DPMI, I also checked HMA, and checked "protected" in the "convetional memory" settings for the "DOS Box" that's running the bat files.
Should I allocate even more memory? Is there anything erong with the settings?
What other settings should I be looking at? Does command.com use EMS? Should I be allocating memory to EMS?
Ideas Anyone???
Is there something in the way I'm writing the *.bat files? I'm using "call" statments to call other smaller *.bat files. For example:
ECHO OFF CALL 5SP001.BAT CALL 5SP002.BAT CALL 5SP003.BAT CALL 5SP004.BAT CALL 5SP005.BAT CALL 5SP006.BAT ........ etc.
Then those *.bat files in turn call fractint and *.par files:
FRACTINT @e:\fract\par\5sp001.par/Step0 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step1 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step2 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step3 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step4 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step5 BATCH=Y IF ERRORLEVEL 2 GOTO END FRACTINT @e:\fract\par\5sp001.par/Step6 BATCH=Y IF ERRORLEVEL 2 GOTO END .........etc....
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Tony Parker wrote:
....I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower.
Besides the "Idle Sensitivity", which specifies how long Windows will allow the program to remain idle (waiting for keyboard input) before reducing the central processing unit (CPU) resources allotted to the program and enabling other programs to use them. Low idle sensitivity lets the program run longer before Windows reduces the CPU resources allotted to it. High idle sensitivity reduces the CPU resources allotted to the program sooner. If a program that is running in the background is not getting enough CPU resources, move the slider toward LOW. You might also look into the "Dynamic Memory Allocation" setting. Make sure this check box is selected when a program uses text and graphic modes and you want to maximize the amount of memory available to other programs when the program is running. When you switch to the mode requiring less memory, Windows makes more memory available to other programs. When you switch back to the mode requiring more memory, Windows attempts to provide the memory. To ensure that there is always enough memory for Windows to correctly display the program in any mode, clear the check box. You may wish to look into some of the FREEWARE products that do memory management, such as "RAM Idle". Use it to free up a selected amount of physical memory when the minimum level is reached. You can also use it to free up a selected amount of physical memory at a regular interval, and free up the physical memory manually as needed. Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html
Paul: Thanks for your most helpful and informative comments. BTW, What happens if I turn The Win98 Dos Box "Properties" > "Misc" > "Idle Sensitivity" slider all the way to 0% from "Low" (left)? Just for the record, here's the specs on my Win98 Dos Box. If you or anyone else sees anything that should be changed please let me know. Ms-Dos Box > Properties > General > Archive - Checked Ms-Dos Box > Properties > Program > Run - Maximized Ms-Dos Box > Properties > Program > Close on exit - Checked Ms-Dos Box > Properties > Memory > Conventional memory > Total - Auto Ms-Dos Box > Properties > Memory > Conventional memory > Initial environmrnt - Auto Ms-Dos Box > Properties > Memory > Conventional memory > Protected - Checked Ms-Dos Box > Properties > Memory > Expanded (EMS) memory > Total - None Ms-Dos Box > Properties > Memory > Extended (XMS) memory > Total - 8192 Ms-Dos Box > Properties > Memory > Extended (XMS) memory > Uses HMA - Checked Ms-Dos Box > Properties > Memory > MS-DOS protected-mode (DPMI) memory > Total - 8192 Ms-Dos Box > Properties > Screen > Usage > Full screen - Selected Ms-Dos Box > Properties > Screen > Usage > Initial size - Default Ms-Dos Box > Properties > Screen > Window > Display toolbar - Checked Ms-Dos Box > Properties > Screen > Window > Restore settings on startup - Checked Ms-Dos Box > Properties > Screen > Window > Performance > Fast ROM emulation - Checked Ms-Dos Box > Properties > Screen > Window > Performance > Dynamic memory allocation - Unchecked Ms-Dos Box > Properties > Misc > Foreground > Allow screen saver - Unchecked Ms-Dos Box > Properties > Misc > Mouse > QuickEdit - Checked Ms-Dos Box > Properties > Misc > Mouse > Exclusive mode - Unchecked Ms-Dos Box > Properties > Misc > Background > Always suspend - Checked Ms-Dos Box > Properties > Misc > Termination > Warn if still active - Checked Ms-Dos Box > Properties > Misc > Idle sensitivity - Slider is 25% from Low (left) Ms-Dos Box > Properties > Misc > Other > Fast pasting - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Tab - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Ctl+Esc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+PrtSc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Space - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Esc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > PrtSc - Checked Ms-Dos Box > Properties > Misc > Windows shortcut keys > Alt+Enter - Checked There are all my settings! All the best, Tony ----- Original Message ----- From: "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 9:09 PM Subject: Re: [Fractint] Problems Using Fractint With Bat Files In Win98 Dos Box.
Tony Parker wrote:
....I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower.
Besides the "Idle Sensitivity", which specifies how long Windows will allow the program to remain idle (waiting for keyboard input) before reducing the central processing unit (CPU) resources allotted to the program and enabling other programs to use them. Low idle sensitivity lets the program run longer before Windows reduces the CPU resources allotted to it. High idle sensitivity reduces the CPU resources allotted to the program sooner. If a program that is running in the background is not getting enough CPU resources, move the slider toward LOW.
You might also look into the "Dynamic Memory Allocation" setting. Make sure this check box is selected when a program uses text and graphic modes and you want to maximize the amount of memory available to other programs when the program is running. When you switch to the mode requiring less memory, Windows makes more memory available to other programs. When you switch back to the mode requiring more memory, Windows attempts to provide the memory. To ensure that there is always enough memory for Windows to correctly display the program in any mode, clear the check box.
You may wish to look into some of the FREEWARE products that do memory management, such as "RAM Idle". Use it to free up a selected amount of physical memory when the minimum level is reached. You can also use it to free up a selected amount of physical memory at a regular interval, and free up the physical memory manually as needed.
Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Paul: Thanks all your for your help and comments. All of this talk of MS-DOS finally reawakened some of my dormant ageing brain-cells and I started to remember those long forgotten DOS utilities that I used in the early days of DOS and Windows 3.xx. Remember all the "tweaking" and messing around we went through to squeeze that last ounce of RAM out of DOS? Do any of you remember all that re-arranging and tweaking the way DOS loaded itself and all the TSRs we needed to run our systems? The DOS utility tool called Memmaker.exe is essential for tweaking your initial Win98/DOS 7.01 environment. It's actually a DOS 6.22 tool, but it works fine in DOS 7.01. It's found in a Microsoft archive called "olddos.exe", which contains Memmaker.exe, its support files, plus a few other "oldie but goodie" DOS relics that make life with DOS a little easier. It's clumsy & kludgey, like everything that MS makes, but it does work and give you an excellent "Non-GUI" DOS working environment for Fractint. Now that my "DOS era" brain cells have been re-awakened, do any of you remember QEMM? The reason is because that QEMM supports a DPMI environment which some Fractint Gurus have told me makes Fractint really sizzle! One of the things that has really improved my Fractint and Fractint *.bat file performance 10 fold is my loading "SMARTDRV.EXE"! Since I've installed "smartie" onto my DOS 7.01 system, there isn't any "slow down" of fractint whn doing large animation batch files. SMARTDRV was one of those venerable DOS & Win 3.xx "utilities" that somehow disappeared from my system when I upgraded to Win95/98/ME! SMARTDRV needs to be carefully tweaked which is why alot of people gave up on it when "upgrading" to Win95b/Win98 double buffers and vcache. Fractint is now Zipping along rendering away files as fast as Ultra fractal! Using a Fractint, PAR, and BAT combo I rendered 4,000 image files without that horrible "slowdown" that seems to plague large Fractint BAT renders. I'm now using a multi-boot menu config.sys & autoexec.bat, that allows me the choice to either boot to Win98, or boot to a nice "NOEMS" XMS only environment for Fractint, and several other test environments, including a RAMDRIVE environment suggested by Jim Muth. This config.sys just makes things a little "neater" than my earlier "kludges" of different boot floppies, even though I had even been experimenting with a multiboot menu boot floppy which also seemed to work just fine. I had posted an earlier version of my multiboot menu config.sys, and autoexec.bat onto this e-group in an earlier post, but if anyone wants it, I'll post it again. A lot of this is really ancient stuff, which most of you Fractint Gurus have probably already figured all of this stuff out at least a decade ago, but I'd like know how any of you fellow amnesiacs & "Fractalieri" have fared with your own efforts at DOS tweaking. Here's the ftp type download address for olddos.exe. ftp://ftp.microsoft.com/Softlib/mslfiles/olddos.exe All the best, Tony ----- Original Message ----- From: "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> To: <fractint@mailman.xmission.com> Sent: Friday, November 15, 2002 9:09 PM Subject: Re: [Fractint] Problems Using Fractint With Bat Files In Win98 Dos Box.
Tony Parker wrote:
....I've noticed that when I gnerating large batches of several thpousand images with fractint, the batch processing starts off pretty smooth and quick but, as the job progresses the batch processing gets slower and slower.
Besides the "Idle Sensitivity", which specifies how long Windows will allow the program to remain idle (waiting for keyboard input) before reducing the central processing unit (CPU) resources allotted to the program and enabling other programs to use them. Low idle sensitivity lets the program run longer before Windows reduces the CPU resources allotted to it. High idle sensitivity reduces the CPU resources allotted to the program sooner. If a program that is running in the background is not getting enough CPU resources, move the slider toward LOW.
You might also look into the "Dynamic Memory Allocation" setting. Make sure this check box is selected when a program uses text and graphic modes and you want to maximize the amount of memory available to other programs when the program is running. When you switch to the mode requiring less memory, Windows makes more memory available to other programs. When you switch back to the mode requiring more memory, Windows attempts to provide the memory. To ensure that there is always enough memory for Windows to correctly display the program in any mode, clear the check box.
You may wish to look into some of the FREEWARE products that do memory management, such as "RAM Idle". Use it to free up a selected amount of physical memory when the minimum level is reached. You can also use it to free up a selected amount of physical memory at a regular interval, and free up the physical memory manually as needed.
Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Tony Parker wrote:
Paul: Thanks all your for your help and comments.
You are more than welcome!! :-)
Here's the ftp type download address for olddos.exe. ftp://ftp.microsoft.com/Softlib/mslfiles/olddos.exe
Most of the old Windows and DOS items may be found on the various levels of Windows install and upgrade CDs. They are usually located in the TOOLS directory on the CD (such as SMARTDRV.EXE, EMM386.EXE, MEM.EXE, etc.). All sorts of things that might be useful in the correct environment. Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html
Paul and everybody: I have just finished running a 4,000 1024 x 768 pixel image *bat * .par file image rendering run in less than 5 hours on a P2/450 running in DOS 7.01 from *.bat & *.par files generated by Thore Bernstein's little Windows proggie Fractint Animations which can be found on: http://home.online.no/~thbernt/fractint.htm I really recommend it. Anyone who has used the DOS proggie FReeGo 0.11 by Ivan Muccinelli will see a similarity in the *bat and *.par files that are generated! You can get Ivan's excellent proglet at: http://web.tiscali.it/freego_rifero/ Both proggies can generate the BAT & PAR files that instruct Fractint to generate my animations. However here's the part that really impressed me. I ran the *bat and *par files from a specially configured configuration of DOS 7.01 with XMS enabled using a SMARTDRV cache of 8 megs! It was the SMARTDRV HDD cache that made all the difference! There are some little tricks and tweaks on how to configure SMARTDRV to the optimal settings for your "mix" of CPU & HDD, but once properly configured SMARTDRV really does it's job supremely. Here's the line in my AUTOEXEC.BAT file that I used in my system to load SMARTRV.EXE: LH /L:0;2,41328 /S C:\WINDOWS\SMARTDRV.EXE 8192 16 A C+ K /E:8192 /B:32768 /N You will need to run MEMMAKER.EXE to actually do the configuring and load SMARTDRV.EXE properly into your DOS system. There was none of the dreadful "slowing down" or mangled damaged files that I had previusly experienced when trying to run these *.bat & *par files from within a Win98 "Dos Box". The *.bat and *.par file combo just kept cranking out the files in "Disk Video Mode " using the XMS and didn't slow done until it reached the end of the *.bat file. Could it be that without the proper HDD buffering and caching, Fractint really slows down to a crawl? Even though I wasn't using generating the image files in Fractint's Direct video mode, I also loaded a DOS video accelerator and the regular screen rendering speed has also been improved. Jack O Trades also reminded me that Dos 6.xx has a 1024 file limit per sub-directory. I think DOS 7.01 is a little better in that area, but the smart move is to either save the image files to the drive root directory or tweak the *.bat files to change to different sub-directories every 1024 files or so. Brute force and more CPU muscle and clock speed are nice, but until I started using SMARTDRV.EXE, I was getting the "slow-poke" results on my P4/1Gig and K7/2Gig machines. Maybe the HDD I/O has been the problem all along. Hmmmmmm. Even with only 32, 64, or 128 Megs of RAM, there's more than enough RAM on even an older Win3.xx/Win95/Win98 machine to load a monster HDD cache and a properly tweaked and configured Vesa Video Accelerator like UNIVBE and still give Fractint more than enough free RAM and clock speed to do it's math. Once you have a large enough HDD cache (SMARTDRV) that's properly configured all the HDD I/O operations just ZIP by! I have the carcasses of older P-100 and P-200 "boat-anchor" machines with 128 meg & 256 Meg of RAM. Maybe with SMARTDRV and the proper VESA software video accelerator loaded into DOS they might have enough muscle and clock speed to provide the resources that Fractint needs. Frankly, the only reason I need Windoze is to burn CD-ROMs and network to my other machines that have the image and sound apps to make my animations and send files to my DesignJet. There are plenty od "RETRO" DOS based apps that do all that now, so maybe if I can find all those DOS apps, I'll build me a totally "RETRO" DOS box with no "Windoze"! My little DOSBOX machine has been named "RENDER" on the network and it just sits there quietly rendering away, while it's bloated "Windoze" laden "net-buddies" "MAINPC" and "PRNTSRVR" grunt, thrash, churn, and grind away, even when they're idle! Go- figure! I know that I'm a member of the "Get Fractint into Windoze" lobby, but since I've discovered this radical improvement in the image rendering speed, I'm no longer all that disappointed with Fractint being such an "old-timer" and a "slow-poke". I'd really like to hear how any other Fractologists have managed to radically improve Fractint's performance in either this or any other way! BTW Does Fractint in batch mode need any special DOS resources like STACKS, FCBS, FILES, or BUFFERS? What settings would you recommend? Enjoy! ----- Original Message ----- From: "Paul N. Lee" <Paul.N.Lee@Worldnet.att.net> To: <fractint@mailman.xmission.com> Sent: Wednesday, November 20, 2002 10:47 PM Subject: Re: [Fractint] Problems Using Fractint With Bat Files In Win98 Dos Box.
Tony Parker wrote:
Paul: Thanks all your for your help and comments.
You are more than welcome!! :-)
Here's the ftp type download address for olddos.exe. ftp://ftp.microsoft.com/Softlib/mslfiles/olddos.exe
Most of the old Windows and DOS items may be found on the various levels of Windows install and upgrade CDs. They are usually located in the TOOLS directory on the CD (such as SMARTDRV.EXE, EMM386.EXE, MEM.EXE, etc.). All sorts of things that might be useful in the correct environment.
Sincerely, P.N.L. ------------------------------------------------- http://home.att.net/~Paul.N.Lee/PNL_Fractals.html
_______________________________________________ Fractint mailing list Fractint@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractint
Natalie,
6. ---------- When I use <Page-Up> to call up a zoombox it is not always visible. I tried <Ctrl-Ins> and <Ctrl-Del> to change the colors, no effect whatsoever. I tried <Ctrl-I> and <Ctrl-D> too, still no change of color. When using the mouse, the zoombox is visible. It makes no difference if I use the left or the right button. Manipulating the zoombox while using the mouse seems impossible. As soon as I release the button, the zoom-in is drawn.
Mouse support is not what it should be, yet. ?One of these days someone will get to working on it.
And what about the invisible zoombox? And the color changing?
I have a fix for the invisible zoombox. It will be in my next patch. It still won't be possible to change the zoombox color, but it is being drawn with xor, so that feature shouldn't be needed. Jonathan
Hi Jonathan,
And what about the invisible zoombox? And the color changing?
I have a fix for the invisible zoombox. It will be in my next patch. It still won't be possible to change the zoombox color, but it is being drawn with xor, so that feature shouldn't be needed.
Thanks, color changing won't be necessary then. Natalie -- Stolen tagline: Linux is like a wigwam, no windows, no gates, apache inside. [ Linux Counter: user 230952 machine: 111180 ]
participants (9)
-
Doug Stewart -
John Wilson -
Jonathan Osuch -
Morgan L. Owens -
Natalie -
Paul N. Lee -
Scott D. Boyd -
Tim Wegner -
Tony Parker