Spv C550 - Not For Gaming!

[Guest muff]

as I said old GAPI calls only access the compatability mode. see this article :-

http://msdn.microsoft.com/library/default....i_awareness.asp

as for your framebuffer, well that's up to you and how you are coding it - the actual device is 16bit, tho the screen is probably capable of more

[Guest nIghtorius]

as I said old GAPI calls only access the compatability mode. see this article :-

http://msdn.microsoft.com/library/default....i_awareness.asp

as for your framebuffer, well that's up to you and how you are coding it - the actual device is 16bit, tho the screen is probably capable of more

<{POST_SNAPBACK}>

I have found this article already.. but things aren't going a "smooth" as I wanted it to be.. for some reason the ExtEscape does nothing to my "RawFrameBufferInfo" structure..

the code.

HDC hdc = GetDC (NULL);

	ExtEscape (hdc, GETRAWFRAMEBUFFER, 0, NULL, sizeof (RawFrameBufferInfo), (char *) &rfbi);

	ReleaseDC (NULL, hdc);	// thank you..

the defines

#define GETRAWFRAMEBUFFER   0x00020001


#define FORMAT_565 1

#define FORMAT_555 2

#define FORMAT_OTHER 3

What am I doing wrong here?? getting frustrated.. could it be that my C500 (which is using 2003SE) does not support the ExtEscape (xx, GETRAWFRAMEBUFFER, xx, xx, xx) function?

I write the results binary to a file named "debug.dat" and it only shows zeroes.. meaning nothing is in there.. not even the width, height & pitches of the resolution.. extremely bothersome.

I have upped my "alpha" hi-res version (which I do not know if it even works or not on a C550).

I hate Microsoft for doing those things.. really.. but really bothersome.

if you run the binary.. please upload the debug.dat file it creates... I am really curious how a C550 fills in this structure..

colc550.exe

Edited July 27, 2005 by nIghtorius

[Guest AIM-Koen]

Do you mean new games or porting existing games ?

<{POST_SNAPBACK}>

I mean porting some of our existing games. New games will definitely be supporting the new resolutions (I am working on one right now :) ).

It used to be simple for PocketPC and Smartphone Game development: only 240x320 and 176x220. We just kept 2 separate code bases. But now this is going to change because so many resolutions need to be supported (also for PocketPC): 240x320, 480x640, 176x220, 240x240 and who knows what the future brings.

[Guest AIM-Koen]

Yes Koen,

Please please do Dougie Lampkins. I'd given up on this game due to the Button multipress issue on theC500, And now the C550 works fine I can start on my character creations again :) but the game doesn't run on the c550  :cry:

<{POST_SNAPBACK}>

Ah, great to hear this! I'm definitely going to convince my boss on this one, since Trial Challenge is one of my "babies" :D .

[Guest muff]

What am I doing wrong here?? getting frustrated.. could it be that my C500 (which is using 2003SE) does not support the ExtEscape (xx, GETRAWFRAMEBUFFER, xx, xx, xx) function?

I write the results binary to a file named "debug.dat" and it only shows zeroes.. meaning nothing is in there.. not even the width, height & pitches of the resolution.. extremely bothersome.

I have upped my "alpha" hi-res version (which I do not know if it even works or not on a C550).

I hate Microsoft for doing those things.. really.. but really bothersome.

if you run the binary.. please upload the debug.dat file it creates... I am really curious how a C550 fills in this structure..

first off, make sure you have put in the resource entry as specified in the article to tell the device that the app is hires aware

second, your 500 does not HAVE any different res to report - unless the device has hires support then it will either return 0's or else return the same info as the old GAPI requests

Edited July 27, 2005 by muff

[Guest nIghtorius]

first off, make sure you have put in the resource entry as specified in the article to tell the device that the app is hires aware

second, your 500 does not HAVE any different res to report - unless the device has hires support then it will either return 0's or else return the same info as the old GAPI requests

<{POST_SNAPBACK}>

with SPVMan.. I know that you succeeded getting 240x320 support.. but one question.. Do you own a C550 (your posts in the SPV C550 tv-3 topic suggests you have not)..

what happens when you run SPVMan 550 on a device which only supports 176x220.. does it return 0's or 176x220??

I was expecting my C500 to report back 176x220.. instead it reports 0, 0 and the framebuffer being at 0x00000000.. (with the resourcething "CUEX" "HI_RES_AWARE" 0x0001) which can't be right.

I have made another binary.. which spits out a more readable debug file. if anyone with a C550 wants to try please do so.. and upload the debug.txt file here.. So I can see if it goes wrong.. why it goes wrong..

this is what I am getting with my C500

GXGFX Engine 0.32a Alpha Hi-Res Version

debug file


GXGetDisplayProperties() returns

.cxWidth  = 176

.cyHeight = 220

.cbxPitch = 2

.cbyPitch = 352



Library assuming hi-res support: 0


rfbi (RawFrameBufferInfo) returns

.cxPixels      = 0

.cyPixels      = 0

.cxStride      = 0

.cyStride      = 0

.pFramePointer = 0

.wFormat       = 1

.wBPP          = 0

Can anyone confirm that this is correct behaivor of a C500?

colc550.exe

Edited July 27, 2005 by nIghtorius

[Guest muff]

with SPVMan.. I know that you succeeded getting 240x320 support.. but one question.. Do you own a C550 (your posts in the SPV C550 tv-3 topic suggests you have not)..

nope, I dont have a C550

what happens when you run SPVMan 550 on a device which only supports 176x220.. does it return 0's or 176x220??

I was expecting my C500 to report back 176x220.. instead it reports 0, 0 and the framebuffer being at 0x00000000.. (with the resourcething "CUEX" "HI_RES_AWARE" 0x0001) which can't be right.

when u attempt to access the hires values on a device that does not have hires - these extended GAPI function calls will indeed return 0's

the best route I've thought of is the following :-

1 - use GetSystemMetrics to get the screen dimensions as the OS sees them

2 - then use the GXGetDisplayProperties to get the dimensions as the old GAPI functions see them

and if they dont match THEN

3 - you call the ExtEscape functions to get the hires values

and assuming that doesn't return 0's then you know the capabilities of the device

with these 3 checks you will 100% know what the device is capable of

you will then either have to :-

1 - write 2 different blit-to-screen functions (one lores, one hires) and then use pathing applicable to which one u want to use

OR

2 - using the info returned from the above functions, set some global vars that are then used by the blit-to-screen function

hope that helps

muff

p.s. also be aware that square screen res's are around the corner, as well as portrait OR landscape as default

[Guest nIghtorius]

nope, I dont have a C550

when u attempt to access the hires values on a device that does not have hires - these extended GAPI function calls will indeed return 0's

the best route I've thought of is the following :-

1 - use GetSystemMetrics to get the screen dimensions as the OS sees them

2 - then use the GXGetDisplayProperties to get the dimensions as the old GAPI functions see them

and if they dont match THEN

3 - you call the ExtEscape functions to get the hires values

and assuming that doesn't return 0's then you know the capabilities of the device

with these 3 checks you will 100% know what the device is capable of

you will then either have to :-

1 - write 2 different blit-to-screen functions (one lores, one hires) and then use pathing applicable to which one u want to use

OR

2 - using the info returned from the above functions, set some global vars that are then used by the blit-to-screen function

hope that helps

muff

p.s. also be aware that square screen res's are around the corner, as well as portrait OR landscape as default

<{POST_SNAPBACK}>

if you say it's true.. then technically my latest binary might support the C550.. unless c(x)(y)Stride does something different from what I expect.. (I expect the stride var's to equal function as the Pitch vars)

[Guest muff]

if you say it's true.. then technically my latest binary might support the C550.. unless c(x)(y)Stride does something different from what I expect.. (I expect the stride var's to equal function as the Pitch vars)

yeah, stride is indeed pitch

look at the debug.txt file in the post at the bottom of page

http://www.modaco.com/SPVMan_port_for_550_...223593-s15.html

you'll see the debug returns that I did on SPVMan

[Guest nIghtorius]

yeah, stride is indeed pitch

look at the debug.txt file in the post at the bottom of page

http://www.modaco.com/SPVMan_port_for_550_...223593-s15.html

you'll see the debug returns that I did on SPVMan

<{POST_SNAPBACK}>

yeah.. my brother just got home.. He has a T-Mobile MDA (pocketpc).. I tried my binary on that thing. although GX reports 240,320 back (as it should).. I was curious if that thing also returned zeroes.. but it was not the case..

GXGFX Engine 0.32a Alpha Hi-Res Version

debug file


GXGetDisplayProperties() returns

.cxWidth  = 240

.cyHeight = 320

.cbxPitch = 2

.cbyPitch = 480



Library assuming hi-res support: 0


rfbi (RawFrameBufferInfo) returns

.cxPixels      = 240

.cyPixels      = 320

.cxStride      = 2

.cyStride      = 480

.pFramePointer = a8500020

.wFormat       = 1

.wBPP          = 16

This means it was still using GXBeginDraw(); GXEndDraw(); functions.. but upon forcing the new method (ExtEscape).. it rendered the game flawlessy on the device.. meaning both functions were functioning.. I have good reason to believe that this latest binary will run 100% fine on a C550 including the HQ scaling routine (linear filtering)..

I am a happy coder now :)

You can download the Full Version (0.33a) here.. it's a CAB installer.

Edited July 27, 2005 by nIghtorius

[Guest max1956bikes]

Ah, great to hear this! I'm definitely going to convince my boss on this one, since Trial Challenge is one of my "babies" :) .

<{POST_SNAPBACK}>

ah a subject close to my heart dougie lampkin mbe trial challenge i have still got my first spv 100 in which i got to last 3 sections.this has got to be best game ever made for phone.but i then bought c500 a super phone but one big problem it dont play game very well as no volume on side of phone to rev bike very hard to play.no to the point of me going on about my favorite subject.if trials can be made to play well on c550 i will buy one and love aim koen for ever.

[Guest bitbank]

I just got a C550 and it does not appear to respect the "HI_RES_AWARE" flag. The test I use is to see if IsDRAMBuffer() returns TRUE; if so, then I use the GetRawFrameBuffer ESCAPE and that seems to work fine.

Larry B.

[Guest muff]

http://msdn.microsoft.com/library/default....i_awareness.asp

[Guest Newk]

so if i understand this clear then it basicly means that only the prorammers of the software could fix this problem? not the users themselfs? (unless they start learning to code)

or is there a way to fix this in windows itself?

[Guest muff]

no, the fix has to be placed in the software's code

which also means that they have to make their software layouts etc support BOTH resolutions

Edited August 24, 2005 by muff

[Guest peekie]

well soon they wont have a choice with all the future smartphones having the new screen

[Guest muff]

For a while at least programmers still need to support both resolutions (due to the shear number of Smartphones already out there with the 'old' res)

The real fun part is that across PPC and Smartphone we have a load of resolutions to support now

176x220

240x320

480x640

and their landscape equivalents. As well as the square resolutions,

240x240

480x480

So programming apps and games up for this lot is really going to put the cat amongst the pigeons

[Guest hecatae]

Ah, great to hear this! I'm definitely going to convince my boss on this one, since Trial Challenge is one of my "babies" ;) .

Has Dougie Lampkins been updated yet?