PureBasic Forums - English

Seriously. It's that good. This thing has unlimited possibilities when it comes to rapid-smooth graphics rendering combined with comprehensive keyboard and mouse events. To find a library of this quality in a BASIC language is truly unheard of. To Freak and Fred who designed and built this thing (and I'm guessing Freak took point on this one), I can only say this: Thank you. You've done it again. The CanvasGadget alone is worth the price of the PureBasic compiler, and that's no BS. Just try to find a library on the market to match this one and see what they're asking you to pay for it. All by itself.

I haven't done much with the CanvasGadget yet. Is it really that fast? I'll be trying it out soon for an animated 2D GUI. Is it better to use a single large canvas and update it based on mouse and keyboard events, or use several small canvases?

Is it better to use a single large canvas and update it based on mouse and keyboard events, or use several small canvases?

I can't answer that in a generic way. It would depend on the application. I can tell you that you won't be disappointed in the performance. The only comparable technology would be DirectX on Windows, and that should be superior. But surprisingly, not as much as one might think. I'd be completely comfortable writing say, PacMan, Tetris, Mario, DigDug, DonkeyKong, that whole genre of games just on the canvas gadget. It's got the parts to bring it off.

netmaestro wrote:

Is it better to use a single large canvas and update it based on mouse and keyboard events, or use several small canvases?

I can't answer that in a generic way. It would depend on the application. I can tell you that you won't be disappointed in the performance. The only comparable technology would be DirectX on Windows, and that should be superior. But surprisingly, not as much as one might think. I'd be completely comfortable writing say, PacMan, Tetris, Mario, DigDug, DonkeyKong, that whole genre of games just on the canvas gadget. It's got the parts to bring it off.

How do you play sounds with the canvasgadget or react on joystick/gamepad input?

Usually to get that kind of performance you're talking about, some form of hardware acceleration is used. Whether it be DirectX or OpenGL. Did they come up with something new or is OGL on the backend of this?

netmaestro wrote:

Is it better to use a single large canvas and update it based on mouse and keyboard events, or use several small canvases?

I can't answer that in a generic way. It would depend on the application. I can tell you that you won't be disappointed in the performance. The only comparable technology would be DirectX on Windows, and that should be superior. But surprisingly, not as much as one might think. I'd be completely comfortable writing say, PacMan, Tetris, Mario, DigDug, DonkeyKong, that whole genre of games just on the canvas gadget. It's got the parts to bring it off.

Ok, thanks! I suppose it's a great choice for a fairly static 2D app. But for rapidly updating graphics and animations I'd like to see some test code first...

Well I wouldn't go that far, it slowed my rendering for the TextEdiGgadgetEx by 2 to 3 times when I switched to it.
Before when I was just using images and callbacks for mouse and keys, it was way faster.
Though the performance only seems to take a hit when your using alpha channels.
I give it a 9 out of 10, it's a got a lot of utility.

How do you play sounds with the canvasgadget or react on joystick/gamepad input?

API or the PureBasic DX libs. I'm only talking about graphics rendering. But you already know that.

Usually to get that kind of performance you're talking about, some form of hardware acceleration is used. Whether it be DirectX or OpenGL. Did they come up with something new or is OGL on the backend of this?

If I had to guess I'd say there isn't any backend behind it of the sort that you mention. What there does seem to be is a custom implementation of double-buffering that allows for some surprising performance in simple animation. It's not a case of applying WS_EX_COMPOSITED or something, this has been thought out and the design suits the purpose.

netmaestro wrote:If I had to guess I'd say there isn't any backend behind it of the sort that you mention. What there does seem to be is a custom implementation of double-buffering that allows for some surprising performance in simple animation. It's not a case of applying WS_EX_COMPOSITED or something, this has been thought out and the design suits the purpose.

Either way it sounds like you could do some cool things with it. Maybe even a cool animated "about" window.

netmaestro wrote:

How do you play sounds with the canvasgadget or react on joystick/gamepad input?

API or the PureBasic DX libs. I'm only talking about graphics rendering. But you already know that.

Yes, but what is a game without sounds? If you need API or InitSound .. you already require either platform dependence with API or DirectX (which is platform dependent, too). Do you understand this problem? Sure, the canvasgadget is fine for graphics and simple keyboard/mouse input, but I don't want to play a very silent game where I only listen to the noise of my computer.

Why not use the normal sound library?
Is there some restriction that you can only use that with a screen?
There are people who wished for several windowed screens, but it's not possible.
Now there is.

TomS wrote:Why not use the normal sound library?

It requires DirectSound or SDL .. and then you have access to hardware accelerated techniques already, why not use them?

DarkDragon wrote:

TomS wrote:Why not use the normal sound library?

It requires DirectSound or SDL .. and then you have access to hardware accelerated techniques already, why not use them?

I suppose the reason is that using DX (screens in PB) is much more involved, and not guaranteed to run well on all machines. DirectX audio runs ok on almost any machine though.

eesau wrote:

DarkDragon wrote:

TomS wrote:Why not use the normal sound library?

It requires DirectSound or SDL .. and then you have access to hardware accelerated techniques already, why not use them?

I suppose the reason is that using DX (screens in PB) is much more involved, and not guaranteed to run well on all machines. DirectX audio runs ok on almost any machine though.

Well but I think then the users won't have time to play your game, because it is either a extremely old computer (even onboard graphics support directx 9 today - it must be that old that it runs windows 95) or a computer for working and they won't play games on such a system.

The only reason for creating a game on a canvasgadget is that you can handle multiple screens.

DarkDragon wrote:Well but I think then the users won't have time to play your game, because it is either a extremely old computer (even onboard graphics support directx 9 today - it must be that old that it runs windows 95) or a computer for working and they won't play games on such a system.

Even if it runs, there is usually a lot of compatibility issues with textures et cetera, that was mainly what I was aiming at. I've had lots of troubles with onboard graphics in the past.

The only reason for creating a game on a canvasgadget is that you can handle multiple screens.

Or ease of use? Granted, I still don't know whether the canvasgadget can handle rapidly updating graphics.