...

I'd like to release it the way it is just so I can move on. But, since it doesn't quite work, I know that won't happen.

...

Jonathan

Consider at least making your version public so more people can try it. That's not the same as releasing.

Tim

it would be nice..! i feel responsible (..guilty..) for all that mess but i need the version as altered by you to check what i've done wrong.. ad VESAvirtscan: it has a code reuse not quite clean to keep it small maybe an unfolding should be considered.. gratefully yours charlie ______________________________________________________________________ Reklama: Soutez o 10.000,- Kc a jedno z deseti baleni noveho Aquafresh Whitening systemu - pro zarive bile zuby, intenzivne svezi dech a cela Tva usta. http://ad2.seznam.cz/redir.cgi?instance=43403%26url=http://www.icewhitening....

On Monday 24 February 2003 10:14 pm, Tim Wegner wrote:

...

If you have the time or energy you could put in jumps around sections of code in VESAvirtscan and see if it ever works on the Nvidia boards.

Please give me more details on what to try.

Try jumping over the following sections (1, 2, 3) of code. This is where I have had the most trouble with my other video card. One of the problems is that just because you can read the value of the scanline length doesn't mean that you can actually set the scanline length. VESAvirtscan proc near xor ax,ax once_again: mov cx,sxdots ; this should be passed twice mov dx,sydots cmp cx,vesa_xres ; asked wider than screen x? jae setvirtscan cmp dx,vesa_yres ; asked higher than screen y? jae setvirtscan jmp wedone ; otherwise do nothing setvirtscan: cmp ax,004fh ; is this second pass? je secondpass (1) jump over next mov ax,4f06h ; VESA fn 6 scanline length mov bx,1 ; subfn 1 get line width int 10h cmp ax,004fh ; did that work? jne bad_vesa ; bad vesa.. try it anyway (2) jump over next mov ax,4f06h ; VESA fn 6 scanline length mov bx,3 ; subfn 3 get max line width int 10h cmp ax,004fh ; did that work? jne bad_vesa ; bad vesa.. try it anyway (3) jump over next mov ax,4f06h mov cx,bx ; get the max width in bytes mov bx,2 ; subfn 2 set width in bytes and cx,0fff8h ; 8 bytes width align int 10h cmp ax,004fh ; did that work? jne bad_vesa ; bad vesa.. try it anyway (4) here cmp sxdots,cx ; max width in pixels in cx jae alreadyset ; can't set more bad_vesa: Jonathan

On Monday 03 March 2003 05:31 am, Charlie Chernohorsky wrote:

that jumps you've suggested to Tim at VESAvirtscan, the destination "(4) here" should be at "bad_vesa", otherwise it would do.. nothing at all, beacuse if

(4) here + cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more + bad_vesa:

then sxdots always equals to cx when skipping the parts above, this cmp is related to the last VESA call, so it should be skipped also like:

+ cmp sxdots,cx ; max width in pixels in cx + jae alreadyset ; can't set more (4) here + bad_vesa:

Since it is just for testing purposes, it makes no difference. We just need to see if one of these bios calls is causing the problems.

while looking at the experimental patch 5 diff file:

at loadfdos.c, at restoring images, the function which resizes dotmode==28 entries (well, to be honest, i've forgotten its name) - it should also be disabled when virtual=no, like:

+ /* try to change any VESA entries to fit the loaded image size */ + if (virtual && video_vram && initmode == -1) {

I'll fix it. Thanks.

then, i've found a mistake at prompts2.c / getviewparams(): instead of:

+ if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) if (truebytes < 2) + */ + ++truebytes;

it should be:

+ if truebytes==4 (32 bit) it does &= ..FFFE (&= -2) + */ + if (truebytes < 2) + ++truebytes;

(i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates..

I can increase the number of lines that diff catches on either side of changes. This will increase the diff file size, but the problem should go away.

finally, using view-window for smaller-than-screen request is ok, but why do you turn off view-window for greater-than-screen? do you think it would have no use then?

( ! if (sxdots < vesa_xres && sydots < vesa_yres) { ! viewwindow = 1; ! viewxdots = sxdots; ! viewydots = sydots; ! sxdots = vesa_xres; ! sydots = vesa_yres; ! } else { ! viewwindow = 0; /* make sure it is off */ ! viewxdots = 0; ! viewydots = 0; ! } )

There are problems which occur when the two are used at the same time. For example, using orbits doesn't work quite right (in terms of where they appear). There may be other problems, as well. It is true that if all you are doing is drawing an image, it works fine. At this point, I'd rather it was turned off so that we don't get complaints about it not working right.

VESAvirtscan once more: that "mov ax,2" is strange! (so is "mov ax,1" fifteen lines above..)

the scroll test should scroll the screen to the [cd; dx] not to the ax.. ax just indicates top-left corner here..

+ noretrace: + ;; xor ax,ax + mov ax,2 ; try to move a tad + mov wait_retrace,0 ; don't wait for v. retrace + mov video_startx,ax ; video didn't scroll yet + mov video_starty,ax + call VESAscroll ; try the instant scrolling + cmp ax,004fh ; did this scroll? + je wedone

it is also non-serious, but i see no use of it..?

Yes, indeed! That is strange. But, it is there because of how VESAscroll is coded. If you pass (Xc/2-1,Yc/2-1) (screen center offset divided by 2 then subtract 1) in cx and dx, then subtracting the screen center offset from them returns a negative number. The code then sets cx and dx to (0,0). Then we compare them to video_startx and video_starty, which we set in VESAvirtscan to (0,0). But, since we have zeroes all around, we bail out without calling the bios move screen routine. Not too big a deal, except we are using the return from the bios call to determine success. Since we haven't made the bios call, ax still contains 0, and we fail the test. Therefore, I added a small nudge (which doesn't happen anyway because it is too small) to force the bios call to occur. Let me know if you need more detail. Jonathan

On Tuesday 04 March 2003 04:11 am, Charlie Chernohorsky wrote:

...

...

then, i've found a mistake at prompts2.c / getviewparams(): instead of... (i guess it was caused by inserting that truebytes explanation) nothing serious, it just miss-estimates..

I can increase the number of lines that diff catches on either side of changes. This will increase the diff file size, but the problem should go away.

really? well, i've thought that if the end-of-comment mark is placed wrong, so it is not caused by diff.. i can think about some cases where increasing line-catch could help, but i don't think that it's this one..

I'm sorry. You are correct, I mangled the code when I added the comments.

i didn't think about passing thru this with s*dots equal to vesa_*res but, anyway, it should not ever get there then (as Tim said)..!

so, now i can see that small move is reasonable, but something must be wrong if we get there with so small s*dots..

No, there is nothing wrong because normally we don't care about the result that VESAscroll returns in the ax register. Jonathan

On Thursday 06 March 2003 06:15 am, Charlie Chernohorsky wrote:

not the result.. i meant, why or how do we get to the point where the scrolling is tested when there is no request for a large screen??

(then it would never have got negative coords..! and no "move a tad" would be needed..)

what is strange is why it does NOT skip everything up to the "wedone"? it should! (well, maybe i'm the one supposed to answer this..)

Ah, another good question. Because I didn't want the virtual screen prompts showing up on the viewwindows screen when it was not possible to use a virtual screen, I have the prompt code checking for video_scroll=1. But, the result is that the only way to initially get into the virtual screen checking code occurs when s?dots=vesa_?res. I changed the beginning of VESAvirtscan so that this could happen. A problem also arises because when you switch to a text mode, the bios changes vesa_?res to a value smaller than s?dots. At least some do. Jonathan

On Monday 03 March 2003 08:00 pm, Tim Wegner wrote:

I tried skipping all the blocks, as well as changing bad_vesa to wedone as you suggested in a private email. Nothing helped.

I assume that in each case I should put a jmp where one of your numbered "jump obver next" were placed, and place the jmp target before the next numbered spot (just after the jne bad_vesa).

Any other requests?

Hmm, the first jump makes no sense, except if you jump from it to wedone, there should be no problems (as confirmed below). If you jump from the second jump to wedone (change 'jne badvesa' to 'jne wedone'), then the first bios call will be tested. I think part of the problem is that even if we fail all the tests, we try to set it anyway. We should bail out if the first test fails. Try these changes at the third and fourth jumps, also.

Keep in mind that even though I am using virtual=yes, I am not actually trying to use a virtual mode. I'm basically starting fractint thusly:

fractint virtual=yes video=sf4

and then pressing ESC. If I understand the virtscan routine (unlikely! :-), I may never be entering the code you wanted me to skip. Aren't sxdots and sydots equal to vesa xres and yres in my case? Apparently not, because if I skip all the way to wedone, everything is OK.

They could be equal (and are when you first start up). But, in a text mode, vesa_xres and vesa_yres could be set to much smaller values. This would cause the code to execute. That is why I've been trying to prevent the call to VESAvirtscan when we switch to text mode. As you can see, I haven't been successful. Jonathan

On Monday 03 March 2003 09:04 pm, Tim Wegner wrote:

...

(change 'jne badvesa' to 'jne wedone')

I changed three of these, no luck.

More ideas ?? :-)

If we skip the whole routine via jmp wedone, everything is OK, as I said before. So SOMETHING in the routine is messing us up ...

That would indicate that the first 'int 10' is causing the problem, right? Have you run vesainfo or svgainfo on these machines? I put svgainfo.zip in the fractint directory a while back. That could tell us if your video cards support scrolling. Maybe. Jonathan

On Tuesday 04 March 2003 05:19 pm, Tim Wegner wrote:

I found Vesainfo.exe in \gcc\allegro\tests

See:

http://twegner.dyndns.org/timvid.txt

Hmm, I'll have to study that. Take a look at the new executable and diff in the experimental directory. I've cleaned up the problems that Charlie pointed out and made a minor adjustment at the end of VESAvirtscan. When we bailed out with a bad bios call, we were adjusting sxdots and sydots even if we hadn't modified them. Perhaps this will clear up our problems. Fingers crossed. 8-)) Jonathan

On Tuesday 04 March 2003 09:37 pm, Tim Wegner wrote:

No luck. I have recompiled everything, so if you have more things you want me to try, let me know.

I'll try the fix I had before that fixes your problem but causes my machine to mess up when you switch fractals using the <t> screen. Maybe it will work now. Jonathan

I just tried patch 4a with a Compaq Evo, Win XP and a VESA 2.0 S3 board. Worked fine. I never tried Fractint under Win XP before, but it worked fine at 1024x768x256

On Wednesday 05 March 2003 04:53 pm, Tim Wegner wrote:

I neglected to mention that I did observe an addressing problem when using a virtual mode. A little incorrect several-pixel-wide vertical sliver of a fractal appeared on the right-hand side of the phsical screen. The result wasn't too bad, but something is not right. I'll try again and give you more exact details.

I have seen that on my mother's machine, also. It's running XP. Didn't have the time to look into it. Jonathan

That doesn't quite tell everything I need. Try running svgainifo.

The stuff returned for mode 256 is: SVGAINFO Version 1.1 by Ron Thomas Copyright 1994 Video mode in decimal:256 Vesa Signature: VESA Vesa Version: 3.0 BIOS Identification: NVidia Capabilities: 01000000 Number of killobytes of Video memory:4096 Supported VESA modes:- 256 257 258 259 260 261 262 263 264 265 266 267 268 270 271 273 274 276 277 279 280 282 304 305 306 307 308 309 310 317 318 325 326 Press Enter for more info Information for mode:256 Mode_Attributes: 039F Window A attributes: 07 Window B attributes: 00 Window granularity in kb: 64 Window size in kb: 64 Window A start segment: A000 Window B start segment: 0000 WinFunc Pointer: C000:5B6F Bytes per scan line: 640 Horizontal resolution: 640 Vertical resolution: 400 Character cell width: 8 Character cell height: 16 Number of memory planes: 1 Bits per pixel: 8 Maximum number of colours: 256 Number of banks: 1 Memory model type: 4:- Packed pixel graphics Bank size in kb: 0 Number of image pages: 15 Press Enter for more info 4F06h, Set/Get Logical Scan Line Length function, is Not supported 4F07h, Set/Get Logical Display Start function, Is supported 4F08h, Set/Get DAC Palette Control function, Is supported 4F09h, Set/Get Palette Data function, is Not supported 4F0Ah, Return VBE Protected Mode Interface function, Is supported 4F0Bh, Set/Get Pixel Clock function, Is supported 4F4Dh, Video Cursor Interface Request function, is Not supported 4F12h, Display Management Power Signaling function, Is supported

Tim, Try the experimental code now. It has some quirks, but should work. Jonathan

On Thursday 13 March 2003 09:42 pm, Tim Wegner wrote:

My Nvidia board on the HP is a tough nut to crack. Sorry for the monotonous report, but same behavior as before after ESC. Works OK without virtual-yes (as before).

I expected as much. I'll track down where the <t> screen resets sxdots and sydots. Then I can use the setfortext and setforgraphics to set a flag that will jump around the VESAvirtscan code when a text mode is used. I had implemented this earlier and it fixed your problem, but caused others. Jonathan

The latest version of patch 4a is in the experimental directory. It should allow your problem video cards to work.

Yes it does, all is well now.

It does, however, have the problem with a virtual screen getting messed up when choosing another fractal type through the <t> screen.

Yes, I can duplicate this. It shows when using guessing, but not passes=1. Maybe that's a clue. Guessing reads the screen, but passes=1 does not. I'd look and see if the pixel reading routines need something for virtual mode support.

This appears to not be a problem with sxdots and sydots as I had first suspected. OTOH, I'm clueless (again).

Not too cluesless, because you fixed the problems with my video card. Maybe this comment is for Charlie. This is purely a personal preference, but in virtual mode often the screen scrolls when I don't think it should when I am moving a zoom box. If the zoom box can move, that's what it should do. The fractal should only pan if the zoom box hits the edge of the screen. Tim

On Saturday 15 March 2003 07:54 pm, Tim Wegner wrote:

Yes, I can duplicate this. It shows when using guessing, but not passes=1. Maybe that's a clue. Guessing reads the screen, but passes=1 does not. I'd look and see if the pixel reading routines need something for virtual mode support.

I see problems with passes=1. Setting symmetry=none helps, but doesn't fix it. Thought it could be problems with setting up the grid, but setting debug=3800 (forcing the use of the function instead of the static grid) didn't change anything. Jonathan

Yes, works for me (at least one one computer, the HP Pavilion with Nvidia), good job! Tim

Jonathan asked:

Can you think of any reason to leave in the virtual=yes command line option?

No, I can't think of any reason to leave it in. You might consider leaving virtual=yes in as an undocumented debugflag switch until we have more experience, but if that's any trouble, I have no problem with eliminating the switch entirely. Simplifies the docs. BTW, you've been sending messages both to the list and to me personally. I don't know if that is intentional or a side effect of ther new list software. It's sufficient to send a message to ther list, since my email program sorts the mail to the same place either way. If there's a list setting I need to change, I'll look into it. Tim

Jonathan wrote:

Your "reply to" contains both email addresses. As does Charlie's. Mine doesn't.

Good catch. I found a setting that causes reply-to to be overwritten, so now everybody's reply-to should be the list. The mailman software has always "strongly recommended" that the reply- to be set to the sender. I can understand why, but since our lists are relatively low volume, it has always seemed to me that for us it is better to have reply-to's go to the list in order to keep threads going. I know that this is a issue that has been discussed thoroughly in various places. If I'm wrong, I will cheerfully change the settings. If we follow the recommendation, replies would tend to go to the person directly unless you self-consciously edit the email address. On another issue, the archives expose our emails to spam harvesters. I could change the settings so only list members can see archives. Should I? I believe there is also an option to hide our emails. Should I turn that on? Another issue. I have always hated having to scroll through a list of bounces of attempted posts from non-members. The earlier software caused me to have to disposition each bounce individually. About 99.9% of these were spam, but occasionally there's a legitimate problem. The problem was we get 50 spam messages every few days. I have changed the settings to just silently discard attempted posts from non-members. This may be an unfriendly setting, but it reduces my list management responsibilities quite a bit. If anyone thinks this is wrong, say so, and say why. Normally list management is off topic, but I would welcome a little discussion to help me improve the list. The new software has many new options that I can set. Tim

Re: [Fractdev] Panning Tim wrote:

Maybe this comment is for Charlie. This is purely a personal preference, but in virtual mode often the screen scrolls when I don't think it should when I am moving a zoom box. If the zoom box can move, that's what it should do. The fractal should only pan if the zoom box hits the edge of the screen.

Tim

it's also a possibility, but what should it do when the zoombox is stretched or skewed, zoomed out or even rotated..? then at least two edges would be offscreen while two other not.. so, hitting the edge of the screen doesn't imply scrolling.. well, it could figure out zoombox's bounding box and then, if it were too large in a direction, it would switch to center-scrolling in that direction.. more, there could be a switch like: scroll zoombox: [always] / [at the edge only] if this is an acceptable behaviour, i'll do that, or at least i'll try.. charlie ______________________________________________________________________ Reklama: Jeden svet 2003 - 5. rocnik Mezinarodniho festivalu dokumentarnich filmu o lidskych pravech. http://www.oneworld.cz

In the past few days, I've run into a bug over a dozen times while exploring with the multifractal formula. I've also recently upgraded to patch level 5 of Fractint version 2002. It appears most often at 1600x1200 resolution, occasionally other resolutions. At 1600x1200, the following par illustrates the bug. It only does 2 or 3 lines at passes=1, and barely gets started at passes=t before it stops generating the picture. A showdot continues to move, but nothing else is generated. This is similar to a save and restore gif bug discovered several years ago, but no save and restore is necessary this time. It may have something to do with a buffer size since it occurs much more frequently with higher resolutions. Bug_Test { ; ; t= 0:01:28.42 on a P4 2Gh at ; 1600x1200 Image Copyright 2003 ; by Lee H. Skinner ver=2002 ; Version 2002 Patchlevel 5 reset=2002 type=formula formulafile=0from_ml.frm formulaname=multifractal ismand=n function=exp/exp/exp passes=t center-mag=-6.52603785028786300/-0.01400828975779934/\ 404.3077/1/77.5000000000016342/-4.47783476964502825e-\ 012 params=-0.1740997192297128/-0.2996141087069308/384.00\ 004/256.1106/2048.00016/768.00009/768.01536/256.01025\ /28974.5/12 float=y maxiter=2048 inside=maxiter outside=tdis logmap=yes symmetry=none periodicity=0 rseed=-2436 cyclerange=2/255 colors=000000zz1zzC<2>zzz<3>jqdfo_blU<3>Mb8<3>LQ8KM8K\ J8<2>I88H44G00<3>TA5WD6ZF7aI8eLAhMBiODjQF<3>qeBriAtm9\ vq8xu7zz5zz4zz3<4>zj4zg4zc4<3>zS5zP5zL6zI6zE6wE6tD6<6\

vAIv9Kv9M<3>x7Sy7Uy6Wz6Yz5_<3>f5Ma5IW4E<2>_4H<3>P3DN\ 2CK2A<3>805G0BO0G<3>g0Ul0Xq0`v0d<2>y0fz0gy0h<3>u1mt1n\ s1or2q<2>v2u<3>c5eZ6`U6X<2>F9LAAG7FO4KW0Qc<3>5Xc6Zc7`\ c7aa7c_7eY<3>FcgHciJbl<3>S_v<3>civflvinvlqvotvsww<2>z\ zz<3>rwzovzhsw<3>Gch8_d8Xa<3>8JP8FL8CI<3>SCCXCAaB9<3>\ uA2zA0xA0<12>SA1QA1NA1<3>D92<6>UXAW`BYcC<3>hrI<3>UnXR\ m_NlcJkgFfpAaz<3>PJoSFlWAi_5fc0ce7_jFRoNIzb0zj0zr0 }

-------------------------------start-frm----------------------------------- FRM:Multifractal { ;Albrecht Niekamp May, 03 ;only integers as first input, second input 5 digits to the right ;real(p2) factor1,border1 ;imag(p2) (-)maxiter1,input bas.frm1_2digits input bas.frm2_2digits ;real(p3) bailout,hyb.mandel: number of sides (Many_mods L.Allison) ;imag(p3) factor2,border2 ;real(p4) maxiter2,factor3 ;imag(p4) border3,maxiter3 ;real(p5) 1digit_shape only 5digits: shape,out1,out2,in1,in2 ; 1_mand 2_jul 3_hyb.mand 4_hyb.jul +5_reset (not shape) <0_no in/out1 ; optional basic frm2: out-nbr 1digit in-nbr 1digit 3_both +5_shape ;imag(p5) 1digit : 1_iter1reset 2_iter2reset 3_both +5_shape effect ; 2digits : many_mods multipl. shutoff +10_in/out1 +20_inout2 +30_both ; optional input2: frequency_2digits level_2digits amplitude_2digits ; d=real(p2) fac1=trunc(d) b1=(d-fac1)*100000 ; d=imag(p2) da=(d<0) if (da) d=-d endif mi1=trunc(d) d=round((d-mi1)*10000) p6=trunc(d/100)/10 d=d-1000*p6 if (da) p6=-p6 endif p7=d/10 ; d=real(p3) ba=trunc(d) mm=round((d-ba)*100000) ; d=imag(p3) fac2=trunc(d) b2=(d-fac2)*100000 ; d=real(p4) mi2=trunc(d) fac3=round((d-mi2)*100000) ; d=imag(p4) b3=trunc(d) mi3=round((d-b3)*100000) ; da=real(p5) t=(da<0) if (t) da=-da endif start=2-t dd=trunc(da) if (dd<5) start=0 endif vb=(dd==3)+(dd==4) da=round((da-dd)*100) d=trunc(dd/10000) vb=(d==3)+(d==4)+vb dd=dd-d*10000 d=trunc(dd/1000) or1=(d>5) d=d-5*or1 vv1=(d==3) vv2=(d==4) dd1=(d==2)+(d==4) dd=dd-d*1000 d=trunc(dd/100) or2=(d>5) d=d-5*or2 vv3=(d==3) vv4=(d==4) dd2=(d==2)+(d==4) dd=dd-d*100 d=trunc(dd/10) inr1=(d>5) d=d-5*inr1 v1=(d==3) v2=(d==4) d1=(d==2)+(d==4) dd=dd-d*10 d=trunc(dd) inr2=(d>5) d=d-5*inr2 v3=(d==3) v4=(d==4) d2=(d==2)+(d==4) d=trunc(da/10) ab=(d>=5) d=d-5*ab da=da-10*d bb1=(d==1) bb2=(d==2) d=da ab=(d>=5) d=d-5*ab ab1=(d==1) ab2=(d==2) ; d=imag(p5) dd=trunc(d) d=round((d-dd)*1000000) le=(d>10000) da=trunc(dd/10) so1=((da==1)+(da==3)==0) so2=((da==2)+(da==3)==0) dd=dd-10*da wo=(dd>=5) dd=dd-5*wo ir1=(dd==1)+(dd==3) ir2=(dd==2)+(dd==3) if (le) freq=round((trunc(d/10000))*10) ;frequency_lake effect by S.Gallet d=d-freq*1000 level=(trunc(d/100))/100 ;water level d=d-level*10000 ampl=d/100 ;amplitude of the wave angle=real(rotskew*pi/180) t=exp(-flip(angle)) h=1/real(magxmag) q=h/0.75*imag(magxmag) tanskew=tan(imag(rotskew*pi/180)) w=2*q*t v=2*h*(tanskew+flip(1))*t z3rd=center+(-q-h*tanskew-flip(h))*t z=pixel-z3rd s=imag(conj(w)*z)/imag(conj(w)*v) if (s<=level) da=level-s z=z+2*da*(1+ampl*sin(freq*da^0.2))*v endif z=z+z3rd endif if (ismand) if (vb) c=0.4*log(sqr(pixel^mm)) z=z*le else c=z*le+pixel*(le==0) z=0 endif else c=p1 z=z*le+pixel*(le==0) endif t=0 d3=(ismand==0) u=d3 : if (vb) if (d3) z=(z*z-real(c))^(z*u+imag(c)) ;frm: Albrecht Niekamp else z2=fn1(z)+c ;frm: Many_mods Linda Allison sqz2=cos(z2) z=c*(1-sqz2)/(1+sqz2) endif else if (ab) z=z*z+c+c*c-p7 ;frm: Puskás István else z2=z*z ;frm: Puskás István modified z=z2*z2+(p6+u)*z2+c-p1*(d3==0) endif bo=|z| If (wo) t=t+1 if ((t<mi1)+(bo>b1)) u=2*(fn1(t/fac1)) if (ismand) z=z*u if (vb) c=0.4*log(sqr(pixel^mm)) else c=z*le+pixel*(le==0) endif else z=z*le+pixel*(le==0) c=p1*u endif wo=0 if (ir1) t=0 endif endif elseif (start) t=t+1 if (start==2) if (bo>b2) u=2*(fn2(t/fac2)) rs=or1 ab=bb1 if (dd1) if (rs) z=pixel endif c=p1*u vb=vv2 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=vv1 if (vb) if (so1) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif start=1 endif elseif (t>mi2) u=2*(fn2(t/fac2)) rs=inr1 ab=ab1 if (d1) if (rs) z=pixel endif c=p1*u vb=v2 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=v1 if (vb) if (so1) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif endif start=1 if (ir2) t=0 endif endif elseif (bo>b3) u=2*(fn3(t/fac3)) ab=bb2 rs=or2 if (dd2) if (rs) z=pixel endif c=p1*u vb=vv4 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=vv3 if (vb) if (so2) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif start=0 endif elseif (t>mi3) u=2*(fn3(t/fac3)) ab=ab2 rs=inr2 if (d2) if (rs) z=pixel endif c=p1*u vb=v4 d3=vb else d3=0 z=z*u c=z if (rs) z=0 endif vb=v3 if (vb) if (so2) mm=mm+mm endif c=0.4*log(sqr(pixel^mm)) endif endif start=0 endif endif bo<=ba } -------------------------------------------end-----------------------------

Jonathan asked:

Can you take a look at this? I see the problem at 1024x768 when the calculations get to the lower left corner. Fractint keeps on calculating, but no new pixels appear on the screen.

I'll have a look. The formula is horendously complex, perhaps some array is over-run. Tim