On Mon, 11 Nov 2002, Tim Wegner wrote:
Not very hard.. speaking of which.. I've rewritten the framebuffer code four times now and I still can't get it to switch back and forth between text and graphics mode in any predictable manner. Otherwise it works
I don't quite see the point of switching between text and graphics, since the two-window Xfractint version avoids the problem altogether. Have you seen Winfract work? It works like Xfractint, with separate text and graphics screens, but it also has a GUI interface.
Xfractint has two windows, which is why it never has to switch back and forth between them. On the console however I currently only have one window so to speak. Also I should explain, when Linux is using the framebuffer for the console, it is always in graphics mode, the 'text' terminals are drawn by the kernel with the video card set to your favorite graphic mode. If you've drawn something onto the framebuffer, and then the console prints some text, it will draw it ontop of your graphics. This isn't much of a problem as I can keep a copy of the graphics elsewhere in memory and copy it back to the screen, but in Xfractint there's no odvious function that signals *when* to do this. The flow is like this, Xfractint starts, calls UnixInit(), initUnixWindow(), setvideotext(), ..., startvideo(), setforgraphics()... and then doesn't call discardgraphics() and setvideotext() until you exit the program. So when you're at the "Press operation key..." prompt and you escape back to the menu... the menu gets drawn ontop of the graphics 'window' on the framebuffer, nothing was called except for maybe unstackscreen() and stackscreen(), when you select "return to image" it'll redraw the "Press operation key" prompt and /not/ signal in anyway that the graphics should infact be redrawn. The closest function I've found is resizeWindow(), but using that for redraws has quirks. Anyway, I just need to 1. redraw and not-redraw the image at the right time. 2. reset the pallette too when going back to the menus, and 3. clearing the screen at the right times, and not at the wrong times. I would think that setvideotext() would do that, but it never gets called in Xfractint until exit. Otherwise this version seems to work perfectly (read, identical to X11) I can probabily do a svgalib version as well once this is done just by replacing a few functions with their svgalib equivalants. With svgalib I might not even have the above problem as text and graphics don't live in the same memory, it's much closer to DOS and X11 in that respect.
If you really want a console version that cannot have two windows, why not do the simple, brute force thing and save the entire graphics image to large array in memory? This can be coded in a few min utes. Fractint's original tricks with video memory were due to severe memory constraints. Even fairly old machines no longer have limitations of memory that prevent saving the graphics screen.
This is was I had to resort to.
I am sure you are aware (don't mean to preach) that the rule about optimizing is only optimize if there is a demonstrable bottleneck.
From experience, I'd say we almost always saw significant benefit from carefully coding the inner fractal loop. The formula parser (a central feature of Fractint that must be preserved, and probably expanded) also benefited a lot from the assembler rewrite.
My philopsophy for where to optomize first: Code that gets called a few million times (math) => fast Code that gets called once or twice (like menus) => doesn't matter
In any case, we can optimize later. The second rule of optimizing is get the algorithm right, then optimize. The third rule is all rules have exceptions (except this one). :-)
(nodnodnod)
want to look into using subversion instead of CVS. CVS does not have the notion of a multi-file patch (same reason Linux doesn't use CVS).
I've been looking into bitkeeper and subversion. I'm leaning towards subversion, but I havn't had much experience with either yet.
And also I've been wondering.. if Fractint no longer has any interger math in it... then is it really still fractINT?
My initial response is that we want to keep the names Fractint and Xfractint for historical reasons, even when the integer math is gone.
It's like the ax, that you replace the blade, and then replace the handle... is it still the same ax as it was before? Over the last few years I've replaced each part of my computer. Do I still have the same computer which I had originally?