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.