Any Good news regarding PB 64bit compiler?

[Patrice Terrier]

Code Select Expand

I suspect that 90% of the effort goes into the final 10% of each project
Yes, Charles, you guess it right 

When dealing with 3D art work, we must be very meticulous especially with the details, because we can inspect each mesh very closely. Some of the models i have, could easily have taken monthes of work all in one. 

[Mike Lobanovsky]

(On behalf of Patrice and myself: sorry for somewhat hijacking the thread, guys...)

Our o2 Opengl framework uses GDI+ both for loading textures and producing image files.

Currently, the opengl buffer bits are transferred pixel by pixel into a gdi+ bitmap.

Hi Charles,

GDI+ API can be (and is) safely used to load and save many common 24- and 32-bit image formats as OpenGL textures in low-end image viewers and simpler engines. But GDI+ is noticeably slow even if compared to GDI routines.

One way to speed up the loading of really large discrete textures and their atlases (multiple textures as single image), say 4Kx4K or 8Kx8K pxs large, is to carefully select a palette of simpler image formats of relatively low level of compression and simpler compression algos (like RLE TGAs and BMPs, 100% JP(E)Gs or full-color GIFs) to support, and maintain one's own library of simplified routines to (de)compress them efficiently in memory as needed. There are pieces of code available on the net that are compatible with common libraries/algos like e.g. zlib (for jpegs and pngs) while working significantly faster than those.

Another way is to work with Microsoft's DDS (direct draw surface) texture formats that both OpenGL and Direct3D can load and display without prior explicit decoding/decompression. (actually, (de)coding is done automatically by the renderer hardware on the fly when the texture gets bound to the render target)

Currently, the opengl buffer bits are transferred pixel by pixel into a gdi+ bitmap. Though I wonder if there is a more efficient way of making the transfer, bearing in mind that the red and blue colors of each pixel have to be swapped.

No, you cannot speed up glReadPixels() which seems to be by far the slowest OpenGL API that's even slower than GDI+ routines. The only way to boost the frame-to-image rendering speed to real on-screen 3D motion capture is use frame- and renderbuffer objects (FBOs/RBOs) in the GLSL hardware-accelerated programmable pipeline. It allows, for instance, ObjReader to successfully render and capture simple animation (currently rotation/translation/scaling) of arbitrary meshes (pieces/submodel chunks) in a full-screen scene at a speed not less than 30FPS (typically 60+FPS) for scenes as complicated as 10 million polygons (ca. 30 million vertices) and more. FBO hardware-assisted blitting occurs perhaps 100 times faster than regular glReadPixels(), especially for non-antialiased framebuffers.

But the good news is yes, you can eliminate the need to swap pixels while loading or saving images from or to GDI+. The two major OpenGL APIs you use for creating/saving the textures (or the OpenGL screen pictures) , glTexImage2D() and glReadPixels(), as well as some others, use a parameter called format (not to be confused with internalFormat!) that can be typically either GL_RGBA or GL_BGRA. Use GL_RGBA with common image formats like BMP or JPG for "straight" color bits order, or GL_BGRA, for "linuxoid" textures like PPM/PGM/PNM or GDI+ PNG image formats. In this case, OpenGL will do R and B byte swapping for you automatically at texture creation/on-disk dumping, leaving the G and A bytes in place.

[Chris Chancellor]

please can someone provide some GDI examples codes in O2?

i really do need some example codes so as to resurrect some interest back into O2
Thanxx to all

[Charles Pegge]

Hi Mike,

Thank you! It's definitely time for another round of Opengl  

I've been looking at some of the documentation concerning FrameBuffer objects, RenderBuffer objects, and so forth, but I'm not yet clear how to transfer the data from these buffers to the client - for instance delivering a rendered bitmap larger than the window client area.


Hi Chris,

There is a folder dedicated to GDI demos (Peter Wirbelauer), which you might find useful: projectsB\GDI. Also ProjectsB\GdiPlus.

correction: ProjectsB

[Chris Chancellor]

Thanxx a lot Charles

they are actually located in \projectsB\GDI and \projectsB\GDIplus folders

i will try compiling them to look how they can be applicable to my needs

There is some kinda of Lisp programming too in the folder \projectsA\LeanLisp

what does Lisp do?  is it similar to AutoLisp ?

[Charles Pegge]

Hi Chris,

Yes, ProjectsB, not ProjectsA. Sorry. I think they will need some 64bit attention, but you can see how they work.

There are many LISPS about. LeanLisp is an experimental interpretive LISP with a tokeniser. There is also a standard version of SCHEME ported by Mike Lobanovsky, very similar to LISP, in ProjectsC.

[Peter Weis]

I find this discussion slowly a bit bored it can't be that you convert 32 bit pointers to 64 bits. Why is no one able to create a decent 64 bit version on the PB10 version. There will only be 64 bit versions based on Freebasic. They don't have a good debugger. I think will slowly switch to C++ or Visual Net   

[Brian Alvarez]

What do you mean "it can't be that you convert 32 bit pointers to 64 bits" ?

Oxygen's pointers work very nice for 32/64 bit compilations and AFAIK when coded correctly, they require no conversion to compile for one or the other.

[Peter Weis]

That's what I meant! If the compiler is programmed correctly structured, you set only one directive and the compiler generates 64Bit Pointer Brain instead of 32Bit Pointer!

[Patrice Terrier]

WinDev uses the SYSTEM INTEGER (short SYSTEM)

automatically adapts to the size supported by the compilation mode (4 bytes for a program compiled in 32 bits, 8 bytes for a program compiled in 64 bits).

Example:

i is system int

[Brian Alvarez]

In Oxygen it is called sys. In 32bit mode it is 4 byte, in 64bit mode it is 8.

Code Select Expand

sys hAddress

In PluriBASIC (oxygen based) it is called handle.

Code Select Expand

LOCAL hAddress AS HANDLE

[Chris Chancellor]

Yup Brian you are correct

      In 64bit O2,  handles and pointers must be converted to sys

        PB handles  conversion to  O2           
        DWORD  -->  sys
        LONG      -->  sys

        sys  is mainly  applicable to window handles and pointers, while all other variables remain unchange

     

[Anthon Com]

Pluribasic and OxygenBasic is the way to go 64bit and you can forget about the 32bit Powerless Basic

[Patrice Terrier]

For a buisiness work, a compiler { that is a strategic choice }, must be not only rock solid, but offer a real guarantee that it will be maintained in the long range, to avoid the single man Zale's syndrom.

Hobbyist, of course, do what ever you want 

[Anthon Com]

Bob Zale syndrome is difficult to gauge, what we need is a compiler urgently that can do the work for the time being, something
that can translate Powerbasic programs directly, without the steep learning curve such as C++ programming language

Look at Freebasic,  which is already dead and so is QuickBasic64  and those other old basic languages are either dead or dying.
We can't afford the time to convert to other languages as business is an ongoing concern.

We can't wait for Drake to put up another compiler for 64bits -- looks like NEVER. Since Drake isn't listening to its own customers
so Pluribasic and OxygenBasic  are the only answer now.