- Fractdev - mailman.xmission.com

re: [Fractdev] <Paul> Recoloring an RGB triplet-colored fractal at a later time.
by charlie chernohorsky 05 Feb '07

05 Feb '07

Rich wrote: > [fullscreen] But I gotta be honest and say there's still more plumbing > that needs to change before those things are going to materialize. no hurry here, we just want to be sure that you won't lock the backdoor for such things to be able to sneak in later when their time comes... > There are two things here. The image and the iteration counts. Both > PNG and GIF image formats have extension chunks (there's one > registered for fractint, but its not been specced out according to Tim). > > So you can encode the iteration counts as a PNG image and stick that in > an extension block designed to hold iteration counts. i'm somewhat aware of chunks (er, a general idea), but even if you hack it to contain a regular png image, still you need a way to make the binary data, something like libpng api.. then, you will need to pretend it's not a grayscale to get more than 16 bits.. > > with infinite iterations (more comes bellow) it's easy to get over 2^32.. > > OK, I see what you mean now about infinite iterations and I'd already > considered that as something that's desirable before. glad to hear it.. again, no hurry, just leave the backdoor.. > The question is -- is it worth having a multiple precision > 'int' to store the iteration counts then? (within an image) oh no, i don't think so, 2^32 is enough, since it's primary use will be recoloring.. (or maybe resuming calculation?) if it's not enough, you can opt for RGBA 16 bits per channel > [SVG / HPGL] When things stabilize (i.e. plumbing changes are done), > adding new save formats should be easy. ...I'm reluctant to divert my > plumbing activity into new features until the plumbing is done. ..and again, no hurry, just try to keep all those in mind please when making any architectural decisions concerning plugability.. good-nite /charlie/

3 4

x11 update
by Richard 05 Feb '07

05 Feb '07

OK, I've got everything linking now on X11 with the exception of one unresolved symbol which I'm tracking down... This is just stubs on some routines on the X11 side, but at least I've gotten the driver back in sync. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

4 21

bignum.c: misleading indentation in unsafe_full_mult_bn
by Richard 03 Feb '07

03 Feb '07

Look at the first paragraph of code after the declarations in this function: if ((sign1 = is_bn_neg(n1)) != 0) /* =, not == */ neg_a_bn(n1); samevar = (n1 == n2); if (!samevar) /* check to see if they're the same pointer */ if ((sign2 = is_bn_neg(n2)) != 0) /* =, not == */ neg_a_bn(n2); The indentation clearly indicates that all this code goes with the true clause of the first if statement, but the compiler sees: if ((sign1 = is_bn_neg(n1)) != 0) /* =, not == */ neg_a_bn(n1); samevar = (n1 == n2); if (!samevar) /* check to see if they're the same pointer */ if ((sign2 = is_bn_neg(n2)) != 0) /* =, not == */ neg_a_bn(n2); Which is the true intention? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

2 1

extraseg, printer: gone
by Richard 01 Feb '07

01 Feb '07

All traces of extraseg and the printer driver code are now gone on the branch... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

1 0

printing
by Tim Wegner 31 Jan '07

31 Jan '07

One note since printing was mentioned: If it's not already gone, let's get rid of the built-in printer driver. I would think virtually everyone prints outside of fractint these days from the GIF. Which is not to say we couldn't add printing back in after we start "GUIizing" the code, but I'd still think that would be low priority. Tim

2 1

How you can help (was: [Fractdev] beta 3)
by Richard 30 Jan '07

30 Jan '07

I was originally writing this to Paul, but it became a general audience message :-). In article <002201c74408$28210bf0$0301a8c0@Production>, "Paul" <pdeleeuw(a)deleeuw.com.au> writes: > Let me know how I can help. How's your x86 assembly? :-P Seriously, we could really use some help on getting C versions of the existing x86 assembly fractal code. I've already taken care of the code in the non-fractal computing assembly files, with C code created for the X11 port and my driver abstraction (which takes care of the keyboard and video stuff). This could be done by tweaking the assembly and putting it in an __asm {} block, or it could be done by translating the assembly code into C, whichever is easiest for whoever does it :-). > One other thing I would like to do is real time 3d > transforms rather than all the tedious mucking about with files. For the 3D stuff, trust me I soooo understand what you're talking about! However, going back to the roadmap I posted earlier, there is more work to do on the 'basics' of the application before I think we should add more features. I mean, its great the way fractint evolved organically but that evolution has run up a cul-de-sac with the 16-bit assembly and DOSisms. Right now, we're still saddled with them -- I'm mostly dodging bullets and faking things out! I like the things you want to add -- but we still have to gut this house and reconstruct it a little bit more. Its like Katrina hit the fractint code and I've made it so the roof doesn't leak anymore, but don't try to use the bathroom! :) I haven't even gotten the X11 driver up and working yet. We need to do that in this "limp along" world so that we can merge back onto the HEAD. It makes sense for me to do this as i) I know X11, ii) I know the driver code having done 2 drivers for it so far (Win32 disk and Win32 GDI), iii) I know the code as it stands on the branch. Also, the sound code is not there yet. It should probably use DirectSound or some such. How's your knowledge of the sound stuff? The code on the branch is completely gutted of all the weird overlay and 16-bit isms that are still on the HEAD. All near/medium/far pointer stuff is GONE. All overlay stuff is GONE. All the assembly code is GONE. (Well, there's a tiny bit that I inlined as __asm {} blocks as a stopgap for the moment; I don't know if it works right.) The priorities right now are: - get C/__asm versions of all the assembly fractal computing code - get the X11 driver working - get the sound support back - get the Win32 code working in indexed color desktops *That* will be the end of the beta, and that's still quite a bit of work. Once we are that stage, then I want to: - separate engine from UI code - change the UI from polling to event driven - create a real Win32 UI (what we have now is Win32 pretending to look like CGA text screens) Then I will feel like its time to add new features. I know that probably dampens your enthusiasm as none of the things I outlined above are "fun". They're plodding, boring and require fairly extensive reworks to the existing code base. The application architecture of fractint is as old as fractint itself -- 15+ years -- and it shows. I wasn't there at the time, but when the Windows 3.1 port was done, IMO it should have gutted the DOS architecture and gone whole hog Windows. I can only guess that it didn't happen that way because screen updates in 3.1 were slow compared to DOS, which is why DOOM was written as a DOS app and not as a Windows app. However, clinging to the DOS world -- while initially a reasonable compromise -- has left us in the situation we have today. People just aren't interested in working on it that much until it becomes like a "normal" Win32 application. Even though I've made it *work* under Win32, its still far from "normal". Places where others could help out today: - get C versions of the assembly code that computes fractal types - work on the X11 driver (anyone could do it if they know X11; I just don't think anyone else is interested!) - add more fractal types (can you ever have enough?!?) this sort of feature is not impacted by the UI much - implement Win32 sound support As I say above, I know these aren't "fun" but they are necessary if we want fractint to continue... All my opinion, of course; who else's opinion would it be? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

3 4

beta 3
by Richard 28 Jan '07

28 Jan '07

OK, this is the one we want to spread out to the wider audiences... <http://www.xmission.com/~legalize/fractals/fractdev/FractIntSetup-21.00.bet…> or <http://tinyurl.com/ysgsdq> I believe this fixes all the bugs reported so far. Known issues: - Probably won't work right on an 8-bit (or less) windows desktop with a real hardware colormap; 16-bit, 24-bit and 32-bit desktops should be fine. This will be fixed at some point. - Ctrl NumPad+/NumPad- should work now, but my laptop doesn't have a separate number pad, so... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

3 9

assembly code migration
by Richard 28 Jan '07

28 Jan '07

Tim, Earlier you mentioned that you would be interested in seeing how you could help out with the new code on the branch. One thing that would be really great is if we could get the existing assembly code migrated to 32-bit assembly and inlined as asm {} blocks. Currently on the branch (post beta 3) I've added stub routines for the missing assembly code. They are all in the win32 folder. I've removed the #ifdefs that prevented the L_MATH and M_MATH routines from being linked into the code. Stub routines were added with _ASSERTEs that will throw up a dialog box when they are called in the debug build. In release, they will probably have unexpected behavior as I just return 0 all the time for any return value and that's probably not a good thing for all these functions. The stub routines are: mpmath_c.c: MP2d086 MP2d386 MPadd MPadd086 MPadd386 MPcmp MPcmp086 MPcmp386 MPdiv MPdiv086 MPdiv386 MPmul MPmul086 MPmul386 d2MP d2MP086 d2MP386 fg2MP calmanfp.c: calcmandfpasm_287 calcmandfpasm_87 calmanfp5.c: calcmandfpasm_p5 calcmandfpasmstart_p5 parsera.c: Img_Setup fFormula fStkACos fStkACosh fStkAND fStkANDClr2 fStkASin fStkASinh fStkATan fStkATanh fStkAbs fStkAdd fStkCAbs fStkCeil fStkClr1 fStkClr2 fStkCoTan fStkCoTanh fStkConj fStkCos fStkCosXX fStkCosh fStkDbl fStkDiv fStkEQ fStkEndInit fStkExp fStkFlip fStkFloor fStkGT fStkGT2 fStkGTE fStkIdent fStkImag fStkImagFlip fStkJump fStkJumpLabel fStkJumpOnFalse fStkJumpOnTrue fStkLT fStkLT2 fStkLTE fStkLTE2 fStkLod fStkLodAdd fStkLodConj fStkLodDbl fStkLodDup fStkLodEQ fStkLodGT fStkLodGT2 fStkLodGTE fStkLodGTE2 fStkLodImag fStkLodImagAbs fStkLodImagAdd fStkLodImagFlip fStkLodImagMul fStkLodImagSub fStkLodLT fStkLodLT2 fStkLodLTE fStkLodLTE2 fStkLodLTEAnd2 fStkLodLTEMul fStkLodLTMul fStkLodMod2 fStkLodMul fStkLodNE fStkLodReal fStkLodRealAbs fStkLodRealAdd fStkLodRealC fStkLodRealFlip fStkLodRealMul fStkLodRealPwr fStkLodRealSub fStkLodSqr fStkLodSqr2 fStkLodSub fStkLodSubMod fStkLog fStkMod fStkMod2 fStkMul fStkNE fStkNeg fStkOR fStkORClr2 fStkOne fStkPLodAdd fStkPLodSub fStkPull2 fStkPush2 fStkPush2a fStkPush4 fStkPwr fStkReal fStkReal2 fStkRealFlip fStkRecip fStkRound fStkSin fStkSinh fStkSqr fStkSqr0 fStkSqr3 fStkSqrt fStkSto fStkSto2 fStkStoClr1 fStkStoClr2 fStkStoDbl fStkStoDup fStkStoMod2 fStkStoSqr fStkStoSqr0 fStkSub fStkTan fStkTanh fStkTrunc fStkZero fform_per_pixel -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

2 4

mpmath_a.asm
by Richard 28 Jan '07

28 Jan '07

Did this code ever exist as C code before being written as assembly? Maybe I could steal C implementations from earlier releases.... -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

1 0

memory leak in miscres.c (ifs_defn)
by Richard 24 Jan '07

24 Jan '07

In miscres.c, routine ifsload(), line 1438 is this code: if ((ifs_defn = (float far *)farmemalloc( (long)((NUMIFS+1)*IFS3DPARM*sizeof(float)))) == NULL) { which allocates some memory into ifs_defn. Earlier in this same function, the same pointer is checked to see if it is non-NULL and if so, it is freed before being allocated later in the function. However, once allocated, this memory will always be allocated because it will only be freed right before we're ready to allocate memory for it again. So, you get a memory leak. What's the right place to release the memory? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://www.xmission.com/~legalize/book/download/index.html> Legalize Adulthood! <http://blogs.xmission.com/legalize/>

2 4