No direct video buffer access on WM2003 Second Edition

[Guest The PocketTV Team]

See article here:

http://www.pocketpcthoughts.com/forums/vie...p=232721#232721

[Guest Arisme]

Uh, they broke GAPI ? :shock:

you should post that on PocketMatrix dev. section btw

[Guest The PocketTV Team]

> Uh, they broke GAPI ? :shock:

Basically: yes.

And they will probably get rid of GAPI totally in future versions (WinCE 5.0 with Direct Draw)

> you should post that on PocketMatrix dev. section btw

You can post that there, if you want. Note that GETRAWFRAMEBUFFER is almost equivalent to GAPI, if it is implemented.

[Guest midnight]

or just use PocketHAL, which is faster than GAPI anyways :)

[Guest The PocketTV Team]

or just use PocketHAL, which is faster than GAPI anyways :)

You cannot be "faster that GAPI" since all GAPI does (in most cases) is give you a pointer to the raw frame buffer and how it is organized. Nothing else.

Then once you have the information about the raw frame buffer, your application can write into it directly or use libraries. So PocketHAL is not faster than GAPI, since GAPI does nothing!

In most cases, all the other libraries that access the frame buffer directly use GAPI to get the address of the raw frame buffer of the device, so when GAPI is broken, they will be broken too, and they will have to rely on GETRAWFRAMEBUFFER or use hard-coded information when they recognize the device.

Which is why it is *critically* important that GETRAWFRAMEBUFFER be implemented by all OEM's in all WM2003-SE devices, as I explain.

If GETRAWFRAMEBUFFER is not implemented, there will be no easy way to access the raw frame buffer in a generic way on every device, i.e. each application will have to somehow detect exactly what type of device they run on (not always possible, since some OEM's like Mitac also forget to properly define the string returned by SystemParametersInfo(SPI_GETOEMINFO,...)), and use hardcoded frame buffer information if they can recognize the device. Not a good solution.

So Midnight, you may not realize it now, but this will be a big problem when you will see devices on which many games will not run.

If you know how to contact the author of PocketHAL, you should probably tell him about this thread, since it will certainely have some impact on this library. For example, if PocketHAL sees that GAPI is available, it may use it to get some info, which will probably not work on WM2003-SE - i.e. may freeze the device!

[Guest midnight]

errr, pockethal is a replacement for gapi, it doesnt use gapi, so lack of gapi wont affect it i beleive...

Description:

PocketHAL is a C++ library that gives you the fastest access possible to your Pocket PC hardware. You can see it as a much more efficient alternative to GAPI. The first installment of PocketHAL provides buffered access to the display memory and a way to retrieve the key codes for all the buttons on your device (not only those reported by GAPI).

Orientation and alignment issues that are the norm with GAPI have been eradicated. Usual alternatives (such as pre-rotating all images) are inefficient: loaded images need to be pre-rotated and direct access to the pixels require complex pointer manipulations. Not so with PocketHAL. Every graphic surface returned by the API is a straight surface without any concept of "orientation". This is to say, all graphic surfaces are "normal". Performances have NOT been sacrificed. Au contraire, PocketHAL is blazing fast and can rotate surfaces faster then using a simple copy with GAPI.

[Guest Arisme]

I think PocketHAL is faster than GAPI because its author worked under specific NDAs from chipset manufacturers, and used them to access the display controller faster than CE drivers ...

anyway PocketHAL is not an option for me considering the licence issues - if I want to use PocketHAL code in a GPL library, I can't do it, since it's a static library. Otherwise I'd really have appreciated a PocketHAL backend for SDL ...

Distribution of the PocketHAL library (by itself or as part of another library distribution) is strictly prohibited.

While I'm not worrying too much regarding games developed right now once this bug is known, it's still amazing to consider MS can break 99% of existing games and not give a damn ...

[Guest The PocketTV Team]

I know PocketHAL.

The author only says that it is faster to copy a bitmap to the display with PocketHAL rather than with using a simple copy (memcpy) to the raw frame buffer provided by GAPI.

This only means that PocketHAL that a blitter that is faster than memcpy. This is correct, and in fact memcpy is in general not the fastest way to copy bitmap in the frame buffer.

But if you know GAPI (which you don't, based on the comments you made), you would know that GAPI does nothing, it just merely returns the address of the raw frame buffer (in most cases).

So you cannot be faster than GAPI. But yes, you can be faster than memcpy to blit a bitmap to the display.

In any case, when it is not possible to access the raw frame buffer directly, it will impact all the game libraries.

You wonder why Microsoft managed to break 99% of existing games and not give a damn ? That's because they don't make any money with those games. As long as "Solitaire" and "Jawbreaker" are working, Microsoft is happy :)

> anyway PocketHAL is not an option for me considering the licence issues - if I want to use PocketHAL code in a GPL library, I can't do it, since it's a static library.

It's forbidden to use a proprietary binary library in a GPL project (in fact you do that all the times, e.g. any GPL application for Unix/Linux will use "libc" or "glibc". On linux, glibc is GPL, but on other Unix like Solaris, it is not GPL). Only the opposit is forbidden, i.e. having a non-GPL project that uses a GPL library (you can only use LGPL libraries). For example, PocketTV uses "pthread-win32", which is a LGPL library that we have ported to WinCE.

Now the question of redistributing the library binary with the source of your GPL game is different. You should ask for permission to do so. It is possible that the library author will grant you permission to redistribute the library at no charge. The main reason why the author does not want the library to be redistributed is probably to avoid having people redistributing old/obsolete versions of it.

[Guest Arisme]

But if you know GAPI (which you don't, based on the comments you made),  

jpzr-style comments are not necessary.

So you cannot be faster than GAPI. But yes, you can be faster than memcpy to blit a bitmap to the display.  

And as a conclusion, a game using PocketHAL will be faster than a game using GAPI. Thanks, I think it was the point of every poster since the beginning of this thread. Apologies for not choosing the exact right words :roll:

btw this is discussed on PM here http://www.pocketmatrix.com/forums/viewtop...pic.php?t=16028

[Guest The PocketTV Team]

> jpzr-style comments are not necessary.

I'm just curious, have you ever used GAPI ?

Do you realize that GAPI does not have any drawing routine, not even a bit-blit ?

> And as a conclusion, a game using PocketHAL will be faster than a game using GAPI.

Not necessarily. It totally depends on the routines that you use to access the raw frame buffer.

But here the problem has nothing to do with this question. The problem is: How will it be possible to access the raw frame buffer. Regardless of what library you want to use.

There are other unrelated issues that will impact games, too, in WM2003-SE Smartphones. For example, many of the new Smartphones running WM2003-SE will have a different screen resolution, so games will have to use new resources (bitmaps) with different sizes, and install the appropriate resources at install time, i.e. using a cesetp.dll to detect the Smartphone resolution during installation - or install resources for both resolution, which will waste a lot of memory space.

[Guest SpaceRain]

But here the problem has nothing to do with this question.  The problem is: How will it be possible to access the raw frame buffer.  Regardless of what library you want to use.

I couldn't agree more. Even PocketHAL must use at least GXOpenDisplay(), GXBeginDraw(), GXEndDraw() and GXCloseDisplay(), right? Their website says: "Doesn't rely on GAPI (but might use it if available)." Then they have some tables that show how much faster PocketHAL is than GAPI, like:

iPAQ 3900

Rotation: 270 degrees

GAPI: 11.5 ms

PocketHAL: 2.4 ms

That doesn't make any sense! GAPI doesn't rotate anything, GAPI is just a small collections of functions you use to get direct access to the video memory. You'll have to code the rotation functions yourself or use a library. If you choose to code these things yourself, then depending on how good you are, your algorithm will be faster or slower than the 2.4 ms PocketHAL uses, where do they get the number 11.5 ms from? Are they confusing GAPI with GapiDraw? The FAQ says: "Does GAPI needs to be installed in order to use PocketHAL?" What are they talking about, "installing GAPI"? Isn't that like asking whether CreateWindow() or PostMessage() needs to be installed to use PocketHAL? I only know about Smartphones, of course, can you install GAPI on other devices?

As far as I know, GAPI is the ONLY way to get direct access to the video memory and the actual functions you use for this are GXBeginDraw() and GXEndDraw(). Calling both these functions takes less than 0.03 ms in total on my E200, so getting direct access to the video memory is really fast as hell. Putting something on the screen is what takes time, but that really doesn't have anything to do with GAPI. By now you have a pointer to the video memory, how fast you do things from here is entirely up to you. If your rotation algorithm is slow, then it's not GAPI's fault, it's your own. All GAPI does is tell you where to find the video memory.

Could someone please explain these things to me? PocketHAL is here. I don't understand how they can talk about GAPI rotating anything or how PocketHAL is faster than GAPI. Are they confusing GAPI with GapiDraw?

[Guest The PocketTV Team]

You are completely right, SpaceRain.

> Are they confusing GAPI with GapiDraw?

Possibly...

[Guest spacemonkey]

OK, I'm willing to be flamed by PocketTV cos he knows best... but...

Gapi does 2 things it gives you access directly to the back buffer and when you EndDraw, it flips the back buffer to the front buffer.

Now the PocketHal speed testing stuff is all to do with the speed of this buffer flip rather than the speed of blting bitmaps or anything. As to rotation? Well, I can't find the definative answer but it appears (in a loosely documented way) that gapi will allow for other screen orientations via other global settings like ChangeDisplaySettingsEx maybe. If my understanding is right (which it may not be) then the back buffer become oriented as per the display settings, GAPI gives you raw access to this backbuffer, and then GAPI flips it into the actual orientation hardware screen memory.

As to not needing to "install" gapi... well, gapi does not come by default on a number of the older PocketPCs. This is what it's talking about. New pocket pcs and smartphones all come with gapi, but some of the old gear needed it to be installed as an addon.

As to Windows Mobile 2003 SE. It might not be so much that microsoft doesn't give a XXXX about us. They changed 2003 SE so it does multi screen resolutions, automatic letterboxing for old apps etc, I imagine that the missing gx.dll is probably because no one had the time to fix it to work properly with the new architecture. Just like WTL and a number of other feature missing out of previous SDKs.

Equally though, PocketHal will likely need updates to work properly on 2003 SE devices because it will quite possibly be making assumptions about the video system that will no longer be true.

[Guest The PocketTV Team]

Actually there are even more depressing news for game developers on Pocket PC:

http://www.pocketpcthoughts.com/forums/vie...p=233239#233239

[Guest The PocketTV Team]

> Gapi does 2 things it gives you access directly to the back buffer and when you EndDraw, it flips the back buffer to the front buffer.

The only device that I know has two buffers is the Casiopeia E-115 (if I am correct), and some iPaq 3800 (but there was a work-around, since the double-buffer was mostly the result of a bad decision by an HP engineer).

None of the other Pocket PC's have two buffers.

So in general, GXEndDraw does just nothing, and GAPI does not flip any buffer.

> Now the PocketHal speed testing stuff is all to do with the speed of this buffer flip rather than the speed of blting bitmaps or anything.

All the recent devices I know have only one video frame buffer, so the answer is: no.

> to rotation? Well, I can't find the definative answer but it appears (in a loosely documented way) that gapi will allow for other screen orientations via other global settings like ChangeDisplaySettingsEx maybe.

Well, GAPI gives you the frame buffer address and the horizontal and vertical pitch values. By doing an extremely simple mathematical transformation on those values, you can cause the buffer to appear "rotated", but what's important is how you write data in the buffer, i.e. in what order, etc.

> If my understanding is right (which it may not be) then the back buffer become oriented as per the display settings, GAPI gives you raw access to this backbuffer, and then GAPI flips it into the actual orientation hardware screen memory.

Correct, but there is no back buffer on the vast majority of devices that have GAPI. So in general, GAPI just gives you the address of the raw frame buffer and its organization.

> As to not needing to "install" gapi... well, gapi does not come by default on a number of the older PocketPCs.

It was missing from a a few Pocket PC 2000. Since Pocket PC 2002, it has been in all ROM's. And when it is missing, then you can ship your own gx.dll that you place in the home folder of your app.

> This is what it's talking about. New pocket pcs and smartphones all come with gapi, but some of the old gear needed it to be installed as an addon.

So, it has never been a problem. I think gx.dll is only a few KB in size.

> As to Windows Mobile 2003 SE. It might not be so much that microsoft doesn't give a XXXX about us. They changed 2003 SE so it does multi screen resolutions,

But it does not change resolution, i.e. each device has a fixed resolution. But you will have Smartphones that are 240x320 while others are 176x220.

> automatic letterboxing for old apps etc, I imagine that the missing gx.dll

gx.dll is not missing from WM2003-SE.

It is broken, that's different.

> is probably because no one had the time to fix it to work properly with the new architecture. Just like WTL and a number of other feature missing out of previous SDKs.

Yes, well, on this one, you are correct: it was not important for MSFT to fix it. But now the situation is much more serious (see my previous posting).

> Equally though, PocketHal will likely need updates to work properly on 2003 SE devices because it will quite possibly be making assumptions about the video system that will no longer be true.

Correct, and based on what I have discovered, it may just be impossible to use it without taking a change to crash the device (on devices that can change orientation on the fly, i.e. Pocket PCs).

[Guest SpaceRain]

Gapi does 2 things it gives you access directly to the back buffer and when you EndDraw, it flips the back buffer to the front buffer.

What back buffer? There's no back buffer. When you call GXBeginDraw() you get a pointer to the video memory. If you change anything here, the screen will immediately reflect the update. Some developers only call GXBeginDraw() once when their application is launched and GXEndDraw() once when their applications exits, which would never put anything on the screen if you were right about the backbuffer. GXEndDraw() doesn't do any flipping, where did you read this?

As to not needing to "install" gapi... well, gapi does not come by default on a number of the older PocketPCs.  This is what it's talking about.  New pocket pcs and smartphones all come with gapi, but some of the old gear needed it to be installed as an addon.

Thank you for clearing that up for me.

[Guest The PocketTV Team]

What back buffer? There's no back buffer. When you call GXBeginDraw() you get a pointer to the video memory. If you change anything here, the screen will immediately reflect the update. Some developers only call GXBeginDraw() once when their application is launched and GXEndDraw() once when their applications exits, which would never put anything on the screen if you were right about the backbuffer. GXEndDraw() doesn't do any flipping, where did you read this?

GXEndDraw does flip buffers if GXIsDRAMBuffer returns TRUE, but that's a very, very rare case, it occurs only on a couple of devices.

But the case should be handled properly if you want to run on those devices, i.e. you should always call GXEndDraw when GXIsDRAMBuffer returns TRUE.

One of them was a Casio device that had a 16-bit bus to the video frame buffer, so writing into it with 32-bit instructions would not work. That's why they came with this double-buffer scheme, so that they would not break all existing 32-bit code.

[Guest SpaceRain]

GXEndDraw does flip buffers if GXIsDRAMBuffer returns TRUE, but that's a very, very rare case, it occurs only on a couple of devices.

But the case should be handled properly if you want to run on those devices, i.e. you should always call GXEndDraw when GXIsDRAMBuffer returns TRUE.

Ah, right, well has there ever been a smartphone with double buffering? I think the devices you've mentioned so far have all been PocketPCs, which most of us aren't into.

[Guest The PocketTV Team]

> Ah, right, well has there ever been a smartphone with double buffering?

Not that I know of.

> I think the devices you've mentioned so far have all been PocketPCs, which most of us aren't into.

Most smart Smartphone developers make applications for both Smartphone and Pocket PC, since the OS is 99% the same, the development effort of making code that works on both is very small, and the gain is big!

[Guest SpaceRain]

Most smart Smartphone developers make applications for both Smartphone and Pocket PC, since the OS is 99% the same, the development effort of making code that works on both is very small, and the gain is big!

We're going a bit off-topic now, but I personally don't develop for Pocket PCs, only for smartphones. I don't own a Pocket PC (and don't really want one), so I wouldn't even be able to test my stuff (except for in the emulator, but that really wouldn't prove the game ran fast enough and other things are less than perfect on the emulator too). Of course, if I was into this for the money, I'd just buy a Pocket PC and start developing for that too, but with all the warez going around, I don't really see the point in developing payware. You only sell one copy and the next day you get 200 e-mails from people telling you how much they love your game. :)

Anyway, most of us just do this for fun and because smartphones need more games. I personally couldn't care less about Pocket PCs or the "big gain", you're talking about. :)

[Guest The PocketTV Team]

I was talking about companies or professional developers for which this is a business, not about individual developing just for the fun of it.

[Guest SpaceRain]

All right, we just don't have many of those here. Whether that is because of the warez, I can't say, but anyway... Let's get back on topic. :)

[Guest Arisme]

Let's try again, because I enjoy the flames :D

In my understanding, PocketHAL is exactly on GAPI level - i.e., as you said, just a mean to access the screen. But it does it "better" than GAPI, because it'll use some hardware acceleration tricks that CE drivers aren't aware of. PocketHAL replaces GAPI.

GAPI -> PocketHAL

GAPIDraw -> PocketFrog

[Guest spacemonkey]

OK, Gapi doesn't do backbuffer stuff.

BUT PocketHAL does. PocketHAL gives you double buffering on any platform with orientation where the back buffer is in whatever orientation you asked for and PocketHAL does the rest. And it does the flips fast.

I presume since my list of random GAPI assumptions was wrong that the PocketHAL performance chart is based on a double buffering rotation solution on top of GAPI which is kind of a biased way of testing thing since that double buffer solution could be anything and is independant of GAPI.

Result -> aside from licensing issues, PocketHAL gives you an effective GAPI replacement, with additionally double buffering and orientation built in. So the only important question left, will PocketHAL work properly on 2003 SE

[Guest The PocketTV Team]

Let's try again, because I enjoy the flames  :D  

In my understanding, PocketHAL is exactly on GAPI level - i.e., as you said, just a mean to access the screen. But it does it "better" than GAPI, because it'll use some hardware acceleration tricks that CE drivers aren't aware of. PocketHAL replaces GAPI.

GAPI -> PocketHAL

GAPIDraw -> PocketFrog

No, PocketHAL is absolutely not at the same level as GAPI.

GAPI is lower level, it is not capable of blitting anything in the screen surface, it just provides the address of the screen buffer.

Really, I feel sorry that I even posted serious information in the MoDaCo forum.

I don't have time to waste arguing about PocketHAL, since this is not the topic here. I just hope the few people who understand the seriousness of the issues with WM2003-SE will help resolving them.