Author Topic: Any Good news regarding PB 64bit compiler?  (Read 912 times)

0 Members and 1 Guest are viewing this topic.

Online Patrice Terrier

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2009
    • www.zapsolution.com
Re: Any Good news regarding PB 64bit compiler?
« Reply #15 on: September 05, 2019, 03:44:40 PM »
Code: [Select]
I suspect that 90% of the effort goes into the final 10% of each projectYes, 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.  ???

« Last Edit: September 05, 2019, 05:27:37 PM by Patrice Terrier »
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Offline Mike Lobanovsky

  • Jr. Member
  • **
  • Posts: 96
Re: Any Good news regarding PB 64bit compiler?
« Reply #16 on: September 05, 2019, 09:36:46 PM »
(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)

Quote
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. :)
Mike
(3.6GHz Intel Core i5 w/ 16GB RAM, 2 x GTX 650Ti w/ 2GB VRAM, Windows 7 Ultimate Sp1)

Offline Chris Chancellor

  • Sr. Member
  • ****
  • Posts: 333
Re: Any Good news regarding PB 64bit compiler?
« Reply #17 on: September 08, 2019, 05:01:41 AM »
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

Offline Charles Pegge

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 704
    • Charles Pegge
Re: Any Good news regarding PB 64bit compiler?
« Reply #18 on: September 08, 2019, 11:53:55 AM »
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



« Last Edit: September 09, 2019, 06:52:52 AM by Charles Pegge »

Offline Chris Chancellor

  • Sr. Member
  • ****
  • Posts: 333
Re: Any Good news regarding PB 64bit compiler?
« Reply #19 on: September 09, 2019, 04:58:22 AM »
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 ?

Offline Charles Pegge

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 704
    • Charles Pegge
Re: Any Good news regarding PB 64bit compiler?
« Reply #20 on: September 09, 2019, 06:50:14 AM »
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.

Offline Peter Weis

  • Sr. Member
  • ****
  • Posts: 334
Re: Any Good news regarding PB 64bit compiler?
« Reply #21 on: September 11, 2019, 09:30:57 PM »
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   

Offline Brian Alvarez

  • Moderator
  • Full Member
  • *****
  • Posts: 164
    • PluriBASIC
Re: Any Good news regarding PB 64bit compiler?
« Reply #22 on: September 12, 2019, 08:15:13 PM »
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.
« Last Edit: September 12, 2019, 08:34:58 PM by Brian Alvarez »

Offline Peter Weis

  • Sr. Member
  • ****
  • Posts: 334
Re: Any Good news regarding PB 64bit compiler?
« Reply #23 on: September 13, 2019, 07:45:27 PM »
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!

Online Patrice Terrier

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2009
    • www.zapsolution.com
Re: Any Good news regarding PB 64bit compiler?
« Reply #24 on: September 13, 2019, 09:58:00 PM »
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
Patrice Terrier
GDImage (advanced graphic addon)
http://www.zapsolution.com

Offline Brian Alvarez

  • Moderator
  • Full Member
  • *****
  • Posts: 164
    • PluriBASIC
Re: Any Good news regarding PB 64bit compiler?
« Reply #25 on: September 13, 2019, 11:42:18 PM »
In Oxygen it is called sys. In 32bit mode it is 4 byte, in 64bit mode it is 8.

Code: [Select]
sys hAddress
In PluriBASIC (oxygen based) it is called handle.

Code: [Select]
LOCAL hAddress AS HANDLE
« Last Edit: September 13, 2019, 11:44:02 PM by Brian Alvarez »

Offline Chris Chancellor

  • Sr. Member
  • ****
  • Posts: 333
Re: Any Good news regarding PB 64bit compiler?
« Reply #26 on: September 14, 2019, 08:50:02 PM »
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