July 2007 - Fractdev - mailman.xmission.com

Paul?
by Richard 19 Nov '09

19 Nov '09

Hey, did Paul get CVS access? Paul, were you able to compile the branch with VC++ 2005 Express? I did put some tweaks in there to get everything to compile with no warnings on the Express edition. I haven't put a copy of VS.NET 2003 Academic Edition in the mail for you yet, but its coming... -- "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/>

6 42

Athlon woes
by Tim Wegner 02 Sep '08

02 Sep '08

I built a computer last year using an Athlon with a Gigabyte motherboard. I had troubles with Fractint - with any SVGA mode the computer would hang after the completion of the image. I always assumed this was an Windows XP issue. Today I tried Fractint with freedos on the same computer, with the same results. So apparently it's an incompatability bgetween fractint and my compuiter. Truecolor, 320x200, diskvideo, and even tweaked modes work. SCGA modes fail, and only after the image completes. This behavior appears to have nothing to do with recent versions. Has anyone else had trouble with Athlon? Hmm, maybe I need to look at bios settings. Tim

7 21

PNG fRAC chunk (was [Fractdev] 6-bit to 8-bit color channels )
by Tim Wegner 24 Sep '07

24 Sep '07

Rich wrote: > I guess I'll have to wait until you expound upon this later, > though. My original idea (in broad terms) was this. 1. Define a number of "subchunks" for fRAc, and treat them a lot like PNG treats chunks, but inside fRAc. I doubt sunchunk is an official PNG idea, so we'd need to extend the PNG API for fRAc purposes. 2. Define separate subchunks for obvious data items like corners or center mag. As much as possible make these universal so other fractal programs could use them (not that we're going to drive what other prograns do any more). 3. Then there are bound to be other fractint-specific items, maybe a lot of them, that we can't avoid. Figure out how to deal with them. Maybe fRAc, or at least parts of fRAc, will be "Stone Soup" spefcific. This is just a start. No big rush because the GIF extension facility will work fine for a while. Tim

2 3

PEND_OP.p -- what does it do?
by Richard 18 Jul '07

18 Jul '07

It gets set to a magic number during parsing and then is used in RecSortPrec, but I don't understand what 'p' is supposed to be doing. What is the meaning of the value assigned to it? -- "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 3

Re: [Fractdev] the future of FractInt is OpenGL
by Richard 16 Jul '07

16 Jul '07

In article <23576011.1184357720510.JavaMail.root@web01sl>, Paul <pdeleeuw(a)bigpond.com> writes: > The first step would be to completely separate the fractal code from > the screen rendering code so that the developer can choose what > method of rendering is done. This is already done with the driver that I introduced. However, you'll find that although this does impose a layer of abstraction, that lots of the code is tightly coupled to the idea of "a pixel is an index into a color lookup table". > My difficulty with fractint code has been the interdependence of fractal > code and screen code. Its getting better, but there is still some coupling. > I am also concerned with converting fractint to something > that needs hardware that is only 5 years old. We're back to "evolve or die" on this one. If people want to use old hardware, there is nothing stopping them from using an old version of FractInt! We're looking forward now, not backward. This obsession with supporting ancient hardware is holding back FractInt from evolving into better code that takes advantage of current hardware. Frankly, supporting old hardware is nowhere on my agenda. Use the DOS FractInt if you have old hardware. It still works and will continue to work on that old hardware. I want to turn the equation around. I don't want us to say "we need to keep the code looking backwards because users have old hardware"; I want users to say "I will buy new hardware because of the cool things FractInt is doing". Consider 5 year old NVidia cards. That would be cards introduced before July of 2002: GeForce 4 MX 460, 440, 420 and earlier generations: <http://en.wikipedia.org/wiki/Comparison_of_NVIDIA_Graphics_Processing_Units> These cards are available on ebay for $10 or less! This is hardly an expense that's crushing anyone's wallet. Of course you will need a machine with an AGP slot, preferably 4x or 8x. But guess what! Because that system configuration is also 5 years old, I can find systems for $200 or less on ebay as well! So we're talking about $200 to have a 5 year old machine. Hell, if you ask around I bet you can find someone who will *give* you a 5 year old machine with an AGP slot. These cards have screaming texture capabilities, alpha blending, stencil buffer support, large memories for textures and 3D models and so-on. They only have shader model 1.x support, but that still gives you lots of interesting things you could do with fractals. Treating these cards as "get pixel, set pixel" type cards is like buying a high end Cadillac just to store your golf clubs in the trunk. What a waste! FractInt should have the ability to leverage your graphics card to the MAXIMUM IT CAN ACHIEVE, degrading gracefully on weaker cards within reason. A 5-year card window is more than most game studios would tolerate and since the DOS version of FractInt supports these older configurations just fine, I see absolutely no reason why the modernization effort of the current code base must be held back because some people want to use old hardware. > If we can generate fractal libraries that can be linked into any > platform, th at would be the first task. Separating rendering from presentation is a good idea, but the existing code was never created with this separation in mind and its a rough refactoring. The main reason that people want to separate rendering from presentation is to put a more modern UI onto FractInt. I have a feeling that most of this desire will disappear once FractInt is moved to wxWidgets and an updated UI (i.e. real dialogs and not emulated CGA screens). The only other reason I can think of for separating the rendering from presentation is to create networked rendering where no presentation is needed. This is a worthwhile goal, but one that is much farther away on the roadmap. To me the roadmap looks like this: - Refactor polling input to event-driven input - Remove 0-63 color channel limitation - Create CGA screen control for wxWidgets - Refactor to wxWidgets application (X11 and Mac "port" comes for free here) - Refactor rendering to OpenGL - Refactor UI to wxWidgets native dialogs/controls - Enhancements (coloring formulas, RGBA support, PNG support, etc.) Its roughly in order of how I'll work, although PNG support might come earlier than this indicates. There's also some stuff I've probably not put on that list that should be there. -- "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 7

the future of FractInt of OpenGL
by Richard 12 Jul '07

12 Jul '07

The more I think about where I want to take FractInt, the more convinced I've become that its future is more OpenGL than SetPixel/GetPixel style graphics. OpenGL allows us to perform interactive manipulation of 3D fractals and orbit visualizations more efficiently and with less code than we do now. OpenGL leverages the graphics card more fully than any other cross-platform API. OpenGL graphics rendering is integrated into the wxWidgets framework. OpenGL shading language provides a mechanism for executing fractal formulas directly on the GPU. Unless someone offers a compelling reason not to do this, OpenGL is going to become the rendering engine on the roadmap. -- "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 2

freeware complexity measurement tool
by Richard 08 Jul '07

08 Jul '07

<http://www.campwoodsw.com/sourcemonitor.html> The more complex a piece of source code is, the harder it is for other people to understand, maintain and extend it. The more complex a function, the harder it is to write unit tests for it. Give this tool a try and compare the DOS HEAD in SVN to the Win32 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

Re: [fractdev] Patch 6 to Fractint version 20.4
by Tim Wegner 02 Jul '07

02 Jul '07

(I actually meant to post this here in fractdev, not that it matters that I posted to the fractint list.) First, for lurkers, Jonathan and I met on June 15th in Iowa while I was on my way to my mother's memorial service in Minnesota. My wife and I had dinner with Jonathan, his wife, and his daughter. We had a great time. We've only met one time before quite a few years ago when Jonathan and his family drove all the way from Cedar Rapids to highway 35 north of Des Moines to meet us. This time we headed east and met up in Jonathan's home in a northeaster Cedar Rapids suburb. The main decision from our conversation was to release fractint, xfractint, and winfract at essentially the current patchlevel. You've done a tremendous amount of work getting three versions synched up (more or less), truly amazing! Some questions for Jonathan: 1. What version? The last official release was 20.0. The help file mentions versions like 20.4, or did you mean 20.04. Is the next version 20.1? Or 20.5? or since nearly a decade has gone by, maybe a major version to 21.0 is justified :-). 2. If we follow the style of previous releases, we should consolidate the patchelevel change history in the revision history and remove references to patches. I could do this, though you would need to check it. 3. I need to very quickly decide about the new fractal type that you know I am working on. 4. Have there been any additions to debugfla.txt? It mentions being complete as of version 20. I'm sure there are more questions that I'll think of later. Tim

3 2