Re: [Fractint] Multi-tasking with FracTint
It turns out that running fractint in different directories does not solve the problem of cross-talk between concurrent copies of fractint, either. I did not examine my test on running fractint in different directories very thoroughly. I still think that FracTint is using a static name for a temporary file. Perhaps it is being created in FracTint's home directory.
In article <0F9524012BC740DD85E57D6E5A246DF4@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
It turns out that running fractint in different directories does not solve the problem of cross-talk between concurrent copies of fractint, either. I did not examine my test on running fractint in different directories very thoroughly.
If you use the beta5 you won't have this problem. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
In article <0F9524012BC740DD85E57D6E5A246DF4@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
It turns out that running fractint in different directories does not solve the problem of cross-talk between concurrent copies of fractint, either. I did not examine my test on running fractint in different directories very thoroughly.
If you use the beta5 you won't have this problem.
Okay, so you are Windows 7 friendly. Where are your release notes, summarizing your changes? Are you back-porting anything into the code you are using? Are you working more with code from WinFract, Xfractint, or DOS fractint? I like being able to record things (under DosBOX). Often, Teseral renderings are identical to single-pass output. Teseral renderings offer an excellent compromise on speed and quality. Did you manage to use it? Did you include sound capabilities (OPL)? I can upgrade this thing to four gigabytes of RAM. Does that mean I could do a gigapixel (think outdoor sign) without batch files using beta5?
In article <7EA9EF5DA40B4EB7BA18C4A458AB5E64@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Where are your release notes, summarizing your changes?
The beta 5 is a port; there aren't any functinoal changes, although there are some bugs. The bugs are in the issue tracker on codeplex.
Are you back-porting anything into the code you are using?
I'm not sure what you mean by "back-porting".
Are you working more with code from WinFract, Xfractint, or DOS fractint?
Its the DOS code with assembly bits replaced by the C implementation that's used by Xfractint. You don't want to use the assembly anyway as its not relevant for modern CPUs.
I like being able to record things (under DosBOX).
If you're talking recording the keystrokes, that facility is there.
Often, Teseral renderings are identical to single-pass output.
Tesseral renderings don't work for any image size > 2048, even in DOS fractint.
Teseral renderings offer an excellent compromise on speed and quality. Did you manage to use it?
If its in DOS fractint and it still makes sense, its there.
Did you include sound capabilities (OPL)?
Currently, I don't think it outputs any sound but the infrastructure is still there. I spent some time looking at a portable audio library, but haven't glued it in yet.
Does that mean I could do a gigapixel (think outdoor sign) without batch files using beta5?
I think disk video has *some* limit on things, but it works similarly to xfractint where I routinely render images at 4800x3600 with no difficulty (other than tesseral not working at > 2048). -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
In article <7EA9EF5DA40B4EB7BA18C4A458AB5E64@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Does that mean I could do a gigapixel (think outdoor sign) without batch files using beta5?
I think disk video has *some* limit on things, but it works similarly to xfractint where I routinely render images at 4800x3600 with no difficulty (other than tesseral not working at > 2048).
IIRC, the image size limit (dimensions) for DOS Fractint is 32768x32768. Not gigapixel sizes, but I believe you can batch together rendering parts of larger images and pulling them together? -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <4DAF231B.3070503@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
IIRC, the image size limit (dimensions) for DOS Fractint is 32768x32768.
At 8bpp that requires a gigabyte just for the framestore alone. Going to larger image sizes would almost certainly require some sort of disk rendering anyway, even on a modern machine with 4GB address spaces for a process.
Not gigapixel sizes, but I believe you can batch together rendering parts of larger images and pulling them together?
Yes, you can generate a PAR file that breaks up the image into chunks and render the chunks and combine them yourself in some imaging tool. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
In article <4DAF231B.3070503@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
IIRC, the image size limit (dimensions) for DOS Fractint is 32768x32768.
At 8bpp that requires a gigabyte just for the framestore alone. Going to larger image sizes would almost certainly require some sort of disk rendering anyway, even on a modern machine with 4GB address spaces for a process.
Modern machines are 64-bit. Even my years-old desktop machine running an AMD Sempron processor is 64-bit. Of course, my little Intel Celeron laptop is only 32 bit, and memory maxes out at 2GB.
Not gigapixel sizes, but I believe you can batch together rendering parts of larger images and pulling them together?
Yes, you can generate a PAR file that breaks up the image into chunks and render the chunks and combine them yourself in some imaging tool.
That's what I was thinking of. -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <4DAFEC4A.7000402@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Richard wrote:
In article <4DAF231B.3070503@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
IIRC, the image size limit (dimensions) for DOS Fractint is 32768x32768.
At 8bpp that requires a gigabyte just for the framestore alone. Going to larger image sizes would almost certainly require some sort of disk rendering anyway, even on a modern machine with 4GB address spaces for a process.
Modern machines are 64-bit. Even my years-old desktop machine running an AMD Sempron processor is 64-bit.
Good point, but hogging up 4GB of ram just for the image buffer is still pretty piggy. Without a 64-bit OS, you won't even be able to allocate it from the free store. Either way, one of the whole points of going to native Win32 was to get away from all those limits imposed by DOS. Now the limits are more in the code. I raise/remove them when I can. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
In article <4DAFEC4A.7000402@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
Richard wrote:
In article <4DAF231B.3070503@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
IIRC, the image size limit (dimensions) for DOS Fractint is 32768x32768. At 8bpp that requires a gigabyte just for the framestore alone. Going to larger image sizes would almost certainly require some sort of disk rendering anyway, even on a modern machine with 4GB address spaces for a process. Modern machines are 64-bit. Even my years-old desktop machine running an AMD Sempron processor is 64-bit.
Good point, but hogging up 4GB of ram just for the image buffer is still pretty piggy. Without a 64-bit OS, you won't even be able to allocate it from the free store. Either way, one of the whole points of going to native Win32 was to get away from all those limits imposed by DOS. Now the limits are more in the code. I raise/remove them when I can.
I got away from Windows to remove limits. ;-) -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <4DB08C22.8070207@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
I got away from Windows to remove limits. ;-)
The limits I'm talking about are still present in xfractint. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
david writes:
I got away from Windows to remove limits. ;-)
The limits I'm talking about are still present in xfractint.
There are many limits in it, I suspect, because from what I understand, the Fractint code is a tightly-knotted ball of string, much of it assembly code optimized for the DOS' x86 medium memory model. So hard to reverse-engineer and rebuild. I have ONCE made a single max-size fractal using XFractint. The image opens on my machines. I did it from curiosity, just to see how it would go. I've made much bigger panoramic photos (I have one that was a 750MB TIF file). It opened and I was able to edit and do stuff on it. -- David gnome@hawaii.rr.com authenticity, honesty, community
In article <4DB12570.9000100@hawaii.rr.com>, david <gnome@hawaii.rr.com> writes:
There are many limits in it, I suspect, because from what I understand, the Fractint code is a tightly-knotted ball of string, much of it assembly code optimized for the DOS' x86 medium memory model. So hard to reverse-engineer and rebuild.
Yes it is a big ball of mud, but only a few bits are assembly. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
In article <7EA9EF5DA40B4EB7BA18C4A458AB5E64@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Where are your release notes, summarizing your changes?
The beta 5 is a port; there aren't any functinoal changes, although there are some bugs. The bugs are in the issue tracker on codeplex.
Are you back-porting anything into the code you are using?
I'm not sure what you mean by "back-porting".
Now that I think about it, I mean that there is recording capability in DOS fractint under DOSbox, SO, you might want to take some OPL simulation capability from the DOSbox project.
Are you working more with code from WinFract, Xfractint, or DOS fractint?
Its the DOS code with assembly bits replaced by the C implementation that's used by Xfractint. You don't want to use the assembly anyway as its not relevant for modern CPUs.
I am under the impression that optimizing compilers can often beat humans when it comes to assembly. It depends on how many assembly coders there are, and how creative they are. Back in the eighties, three to five of them sat for months just cramming code down into 64KB. Four KB is a lot of space for an assembly programmer to fill. For example, if you wrote code for MMX (SIMD), then integer math might again beat floating-point, because there are at least six parallel rejisters there. Function before performance, though. The main reason I backed out of an UltraFract purchase was because it only did 180 colours on grayscales, and I recognized _that_.
I like being able to record things (under DosBOX).
If you're talking recording the keystrokes, that facility is there.
I am talking about the audio and video recordings. Seventy frames per second is about three standard deviations beyond human perception: The mean stops at about fifty. In other words, *most* people are unaware of fluorescent bulb flicker at 60Hz. A few people are though, and these new monitors going at 240Hz is insanely beyond human perception. Again, it would be a sophisticated cut and paste from DOSbox.
Often, Teseral renderings are identical to single-pass output.
Tesseral renderings don't work for any image size > 2048, even in DOS fractint.
They do in batch files.
Teseral renderings offer an excellent compromise on speed and quality. Did you manage to use it?
If its in DOS fractint and it still makes sense, its there.
Did you include sound capabilities (OPL)?
Currently, I don't think it outputs any sound but the infrastructure is still there. I spent some time looking at a portable audio library, but haven't glued it in yet.
That is good to hear. I hav a package or two under Windows that uses GTK+, (Graphics Tool Kit, methinks, and it could be "gnome" or "gnu") which was designed under Linux.
Does that mean I could do a gigapixel (think outdoor sign) without batch files using beta5?
I think disk video has *some* limit on things, but it works similarly to xfractint where I routinely render images at 4800x3600 with no difficulty (other than tesseral not working at > 2048).
I was concluding that DPMI 0.9 had fewer limitations than XMS and EMS a while ago. I suspect that there are native windows calls for RAM allocation that you could make, somehow, though. I was lately wondering how DOS fractint could load at all at 1.4MB, and I suppose that Osuch was already using DPMI or 32bit support or something with the loader. How did you cut the size of executable down to about half? That's about what zip compression will do on executables.
In article <A6C7091596E2474B83A43393BC19F4B5@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Often, Teseral renderings are identical to single-pass output.
Tesseral renderings don't work for any image size > 2048, even in DOS fractint.
They do in batch files.
No, they don't. The code turns off tesseral rendering when the image size is > 2048. It doesn't matter whether or not you're running fractint from a batch file or not. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
Richard wrote:
In article <A6C7091596E2474B83A43393BC19F4B5@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Often, Teseral renderings are identical to single-pass output.
Tesseral renderings don't work for any image size > 2048, even in DOS fractint.
They do in batch files.
No, they don't. The code turns off tesseral rendering when the image size is > 2048. It doesn't matter whether or not you're running fractint from a batch file or not.
If I do a ten by ten batch file at 800x600 per image, each component image will get calculated with tesseral, and the final image (after fractmig and simplgif processing) will be 8000x6000.
In article <544A9F3D21564DAAACAAEC1D8978C789@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Richard wrote:
In article <A6C7091596E2474B83A43393BC19F4B5@terabyte.com>, "Jay Litwyn" <brewhaha@freenet.edmonton.ab.ca> writes:
Often, Teseral renderings are identical to single-pass output.
Tesseral renderings don't work for any image size > 2048, even in DOS fractint.
They do in batch files.
No, they don't. The code turns off tesseral rendering when the image size is > 2048. It doesn't matter whether or not you're running fractint from a batch file or not.
If I do a ten by ten batch file at 800x600 per image [...]
800 < 2048. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
participants (3)
-
david -
Jay Litwyn -
Richard