PureBasic Forum

No.


OpenGL is default on MacOS.
Win64 executables don't work on MacOS.


I'm using v5.20 b15 here on Mac OS X 10.8.4

Ok I didn't rememberer you were on MacOSX.

This seems to be a PB bug on MacOSX to me.

From the source code, I see no reason why it would work on Windows and not on MacOSX, both using OpenGL.

Would be interesting to see what happens on Linux.

I've just tested it with v5.20 b15 on Windows x86 & x64 with OpenGL subsystem.

Works as expected.

I just get a window on linux 5.20b13 x64
the screen only shows if you change it to less than or equal to the window size

Thanks for the Linux input.
Looking at the documentation there seems to be nothing that prevent to have a WindowedScreen larger than the parent Window.
Is it a bug ? A limitation ? Or are we not supposed to create a WindowedScreen larger than the parent Window in any case ?


Btw, I just realized that we can only have one WindowedScreen per application, not even per Window.. (or did I missed something?). As my application must support multiple Windows, this is a showstopper anyway, and here, I don't see any possible workaround..

I think I'll have to stick with the CanvasGadget for now, waiting for a possible solution to have usable hardware accelerated surfaces for this kind of application.

I think the screen size issue is a gtk limitation on linux

if you want multiple openGL viewports you'll need to resort to native openGL
or use some library like clutter

there's a glAreaGadget for linux
and it would be easy enough to do the same for windows but I've got no idea about OSX

Yes I could use an alternative library, even the old mighty SDL.

And really, I don't mind using external libraries but for the windowing management, this is really the back bone of any graphical application, so if I have to do it for this, I'll loose all the benefit of every PB 'build-in' features related to windowing, drawing, events, etc.. It's almost like going back to plain C/C++ then.

This is very frustrating because everything I need for the GUI is in PB except for these hardware accelerated (multiple) windowing issues.

So for now my choices here are:

1) Using CanvasGadgets, no issue here except I won't get hardware accelerated surfaces.
2) Using the WindowedScreen but I'm allowed to only one Window (plus the resizing workaround is finally not allowed on Linux/MacOSX).
3) Using an external library but then I have to code everything myself and not use the PB windowing/drawing/event/etc.. built-in features.

See the frustration ?

Yep,

That's what I am doing for several years now for my CAD/CAM/CNC program,
(re)designing and (re)writing everything myself, and yes, it is almost C++.
after my last test with 'canvas gadget', my last step is converting it all from 'canvas gadget' to sprites ...
You lose all the benefits of PB ...

Marc

There is some examples to have a GL area on your window for Linux and Windows. You could probably add Cocoa one as well

viewtopic.php?f=12&t=48860&hilit=opengl
viewtopic.php?f=12&t=49583&hilit=opengl

Would it be possible to combine the canvas and screen ?
I'm thinking about a windowed screen on an invisible window, use the accelerated screen to composite everything, grab the output and draw that onto the canvas.

Hi wilbert,



I'm working for 4 years now on my software, and I tested all this things,
thats why I'm working 4 years now, not only the program itself, but all that testing !!

- Why copying something you have on screen in to a canvas gadget ??

I wrote my own 'CLIPPING' routine, so you can draw it all in separated boxes.

Edit: I'm rewriting it all, and I need tons of variables for all that.
Example: For a box, I store the PosX, PosY, Width, Height, FrontColor, BackColor, ScaleX, ScaleY, ...
So, if you want to 'Resize' it, I use the 'Scale' to redraw it.

And yes, it is a lot of work,
but if you want a professional looking program, you have to do it ...


marc,

The only reason would be that the events the canvas offers are useful.

wilbert,

this comes from the first post,



So, what you need is speed, speed and speed ...
every time you convert from one to another, you lose time ...
Even in my program, written now using sprites (hardware accelerated) , speed is still very critical ...

If you want to edit MESHES, I have meshes for more than 1.000.000 vertices and 100.000sts of faces.
In an mesh editor you have to draw all these lines(edges) and points(vertices)
so, every time you rescale, or rotate your mesh, you need to recalculate these points.
Not to forget the detection of the mouse for selecting these vertices or edges.


Marc,

Thanks for the links Fred, those are definitively interesting.

Understand though (but I think you do already), and I'm speaking also for Marc I think (I hope you don't mind Marc), that the real issue we have here is not really how to create and handle an hardware accelerated surface (OpenGL/DirectX..). I think we both know how to do this in C/C++.

The real issue we have here is that, in fact, by doing this, we loose the very beauty of PureBasic and its features. We loose all the integrated Events system, we loose all the Drawing features, etc.. And what is very frustrating is that PureBasic does not miss a lot of things to correct the situation.

In fact almost nothing: We just need either a hardware accelerated CanvasGadget or the possibility to have multiple resizeable WindowedScreens.

That's basically all we need, really, and we are set !

Marc had the courage (congrats) and possibly the time to recode everything to handle his needs, I don't. Or lets say, in this case, I would rather prefer to do it straight in C/C++. But I want to stick to PureBasic because of its simplicity, its beauty and its 'easy' cross-platform nature.

PureBasic has 99.9% of what we need to tackle this kind of applications, we just miss this last 0.1% 'thing'

Yep,

maybe if we ask very gently
for 6st of December
a hardware accelerated canvas gadget

marc