PocketMatrix

I have PocketGL working inside PF.
Currently I copy PocketGLs buffer to PocketFrog's buffer for blitting but I realised (once I heard that another PGL user had pointed PGL to using GapiDraw's back buffer) that I should be doing something similar in PocketFrog to save on a big copy every frame.

The PGL data is created as follows:-
header file has
extern unsigned short VScreen[DISP_X*DISP_Y]
and the PGL cpp has
unsigned short VScreen[DISP_X*DISP_Y]

and what I want to do is get that data blitted without having to lock, copy, blit, unlock in PF as this takes too long

Having spent a couple of hours messing with my code ( & thank goodness I made a backup first ) I still don't see how to get this to happen.
I thought I could get PGL to simply look at PFs back buffer in some way or get PF to treat PGLs data as a surface so it could be blitted but my C++ is letting me down

Does anyone have any suggestions on how to approach this?

thanks in advance

Keep in mind that I'm just thinking out loud without thinking terribly hard about it, or researching in the slightest, so this may be worth less than the electrons used to render it on your screen...

I don't think there's any way, give PF's public interface, that you will be able to do anything but the lock/copy/unlock cycle you are already doing.

I think a minor PF hack might do the trick though, and I *THINK* this may work...

If you modify display.h and make m_backSurface public instead of private, I believe that will give you access to the pointer to the back buffer, and you can then hand that off to PGL to render to. I think that's all that would be required. You will still need to do a lock/unlock at some point to get the pitch to work with, assuming PGL doesn't handle that for you, but that should only have to be done once.

Let me know if that works out. If so, I might be inclined to make that change for the next PF revision as it seems like something that might give everyone more flexibility without breaking anything.

ok, when time allows I will have a look however I use the line hline vline & circle functions so if GD does not already have them I will need to port.

With the reference to a possible PF2 coming along there is the possibility of not needing to change of course.