Quote:Sorry about dummy question but is this pure QBasic?
Yes, its is...
For a very simple reason: I have forgotten everything I had learnt 20 years ago about the other languages (ASM, machine language, Fortran, Pascal,...).
I have written an HTML page with graphics and the source code, I will try to post that during lunch time (I have problems here to access the FTP server of my provider)
how the crap can QB do that?? your not running in 640k, right?
He outputs the results to a BMP file.
Quote:how the crap can QB do that?? your not running in 640k, right?
I never took time to learn the XMS/EMS stuff... All my progs are made of plain QB instructions, to start with this one. I launch QB with qb.qlb and Ffix, and I never compile my progs.
The only exceptions I made as for today are the interruptions I used for the SVGA modes and the mouse management. I used that for TC-Draw and TC-Mdb, which are interactive, mouse-driven progs you can download from
http://mandelbrot.dazibao.free.fr/Tclib/Tclib.htm
The best and most reliable way to generate Hi-Res graphics remains bitmaps generation, which require only classical QB instructions.
Note that if you want to see the picture rendering in real time, all you have to do is to replace the TcBmp.bas file by TcLib17.bas from the IDE: they have the same syntax. TcBmp creates a bitmap file used as a virtual screen, while the TCLib is a true colour oriented Vesa library (written in pure QB). I have also created a light version TcLib17L.bas which has only the basic Vesa modules (the complete version is sometimes too heavy for the progs, such as TC-Ray).
For long renderings, the TcBmp library is the most convenient...
In fact no game library is suitable for what Jark does.
Every pixel is the result of a long calculation including light reflection, shadowing and textures. It's raytracing.
As calculation time is much longer than displaying time, using an asm SVGA library would give exactly the same timings. It was the same in my JPEG viewer, all ports to Future or UGL are in fact slower than the original pure QB
3d functions in gaming librairies are designed to be fast and display several images per second, not for precision. Libraries do textures by rescaling a bitmap stored in memory (this needs a lot of memory to store bitmaps). Jark does it calculating it pixel by pixel.
For memory, the only big array you need in raytracing is to store the resulting image, but you can use for that screen memory or a bitmap file.
Did you use direct DC framebuffer access? You should get the same timing (or faster depending on what you're doing) as your PureQB version.
Speaking of which, want me to port it to C as a UGL plugin ?
Jark, I'm having a hard time understanding this:
Code:
1. Scan the main cube
2. Get the entry side in the plain cube
3. Scan the 28 squares shape that corresponds to this entry side
4. Get the sub-square position and orientation
5. Iterate until the holes get too small for the pixels
I'm really confused. What if the polygon iteration calls for a big displacement that will not cover the entire area of the previous iteration?
Quote:Did you use direct DC framebuffer access? You should get the same timing (or faster depending on what you're doing) as your PureQB version.
I don't know what a DC framebuffer is... Can you tell me more ? :???:
Quote:Speaking of which, want me to port it to C as a UGL plugin ?
All the progs on the Mandelbrot Dazibao are distributed with the GNU-GPL license system:
http://mandelbrot.dazibao.free.fr/Copy.htm should provide you all necessary information :wink: