Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Because it is one of my BREW pet peeves and because there are still incorrect emulator skins popping up I have decided to start this thread and I will stick in it whatever emulator skin errors I come across. Maybe Max or someone can use this thread to go back and clean up these skins at one point or another and make proper skins available through the Extranet.

So, here we go with the frist one.

vx4700

  • incorrect display width and height coordinates
  • incorrect memory settings

fixed

fixed

:cool:
Thanks, Max. The army of Brew developers wil be thankful to you.

:cool:
Thanks, Max. The army of Brew developers wil be thankful to you.

The CDM8600 skin is also messed up. The height is too tall...
mohlendo wrote:fixed

The CDM8600 skin is also messed up. The height is too tall...
mohlendo wrote:fixed

accolade wrote:The CDM8600 skin is also messed up. The height is too tall...
fixed

accolade wrote:The CDM8600 skin is also messed up. The height is too tall...
fixed

And another one...
vx8000

Display dimensions are totally off in this skin. The actual skin bitmap is way too small for this phone and needs to be much larger in order to properly accomodate the handsets display resolution.
Memory settings are off. Handset has over 6MB of memory and the emu skin erroneously limits it to 400K

And another one...
vx8000

Display dimensions are totally off in this skin. The actual skin bitmap is way too small for this phone and needs to be much larger in order to properly accomodate the handsets display resolution.
Memory settings are off. Handset has over 6MB of memory and the emu skin erroneously limits it to 400K

Dragon wrote:And another one...
vx8000
fixed

Dragon wrote:And another one...
vx8000
fixed

Doesn't it make you feel bad by now that you have to constantly go back and fix emulator skins that should have been released correctly in the first place? ;)
Wouldn't it be so much easier - not to say less embarassing - to double-check them BEFORE putting them on the extranet instead of pointing fingers? It takes about 30 seconds per skin to check and correct them in 99% of the cases.

Doesn't it make you feel bad by now that you have to constantly go back and fix emulator skins that should have been released correctly in the first place? ;)
Wouldn't it be so much easier - not to say less embarassing - to double-check them BEFORE putting them on the extranet instead of pointing fingers? It takes about 30 seconds per skin to check and correct them in 99% of the cases.

Hey now...as I said in the previous thread, we're getting a process together for this purpose. The wheels may grind exceedingly slowly, but they are grinding.

Hey now...as I said in the previous thread, we're getting a process together for this purpose. The wheels may grind exceedingly slowly, but they are grinding.

Max,
Please trust me that this is nothing personal and I hope you noticed my ;) winking icon in the post.
It is just becoming so unbelievably aggravating and increasingly hard to contain when you try to do you work, and left and right you're blocked out by some Qualcomm paranoia, policy or grind. I've been doing this for quite some time now and frankly I have not seen any notable improvement on many ends, to be honest. Yes, the forums took a significant upswing when you came on and started to take care of things and I am as grateful for that as the next guy, but everything else just seems to be going along at the same the-developer-is-of-no-value-to-us level as ever and may actually have gotten worse on some ends.
I know how hard it can be in corporate environments to push for change but I just can't believe that within these past 2 years or so there was no one in Qualcomm to stand on his/her hindlegs and say "People, this is not how you treat your partners." Will it really have to go as far as for Wall Street to take notice of the problems in the Brew developer community, affecting the stock price, before Qualcomm will finally start to wake up and smell the coffee?
All in all, I think Qualcomm needs a few experienced developers on their board/staff that can help make real-life decisions and do not have the tunnel vision of lab rats. No offense...

Max,
Please trust me that this is nothing personal and I hope you noticed my ;) winking icon in the post.
It is just becoming so unbelievably aggravating and increasingly hard to contain when you try to do you work, and left and right you're blocked out by some Qualcomm paranoia, policy or grind. I've been doing this for quite some time now and frankly I have not seen any notable improvement on many ends, to be honest. Yes, the forums took a significant upswing when you came on and started to take care of things and I am as grateful for that as the next guy, but everything else just seems to be going along at the same the-developer-is-of-no-value-to-us level as ever and may actually have gotten worse on some ends.
I know how hard it can be in corporate environments to push for change but I just can't believe that within these past 2 years or so there was no one in Qualcomm to stand on his/her hindlegs and say "People, this is not how you treat your partners." Will it really have to go as far as for Wall Street to take notice of the problems in the Brew developer community, affecting the stock price, before Qualcomm will finally start to wake up and smell the coffee?
All in all, I think Qualcomm needs a few experienced developers on their board/staff that can help make real-life decisions and do not have the tunnel vision of lab rats. No offense...

Hi Max,
Can you check the KX414 skin? Not 100% sure, but I think its left and right softkeys are mapped incorrectly.
mohlendo wrote:fixed

Hi Max,
Can you check the KX414 skin? Not 100% sure, but I think its left and right softkeys are mapped incorrectly.
mohlendo wrote:fixed

Here's another totally wacked skin... and again it's virtually brand new!
CDM-8910

Display window size incorrect - off by over 10 pixels!!!
Display resolution off by over 10 pixels!!!
Color depth incorrect

Here's another totally wacked skin... and again it's virtually brand new!
CDM-8910

Display window size incorrect - off by over 10 pixels!!!
Display resolution off by over 10 pixels!!!
Color depth incorrect

accolade wrote:Hi Max,
Can you check the KX414 skin? Not 100% sure, but I think its left and right softkeys are mapped incorrectly.
They look OK to me...

accolade wrote:Hi Max,
Can you check the KX414 skin? Not 100% sure, but I think its left and right softkeys are mapped incorrectly.
They look OK to me...

Dragon wrote:Here's another totally wacked skin... and again it's virtually brand new!
CDM-8910

Display window size incorrect - off by over 10 pixels!!!
Display resolution off by over 10 pixels!!!
Color depth incorrect

fixed

Dragon wrote:Here's another totally wacked skin... and again it's virtually brand new!
CDM-8910

Display window size incorrect - off by over 10 pixels!!!
Display resolution off by over 10 pixels!!!
Color depth incorrect

fixed

Speaking of softkeys, it does not look like KX414 has any softkeys. Is that correct?
I mean, I can't see anything representing the softkeys and they don't work in the emu...
The same code worked fine for many other phones...
:D
mohlendo wrote:They look OK to me...

Speaking of softkeys, it does not look like KX414 has any softkeys. Is that correct?
I mean, I can't see anything representing the softkeys and they don't work in the emu...
The same code worked fine for many other phones...
:D
mohlendo wrote:They look OK to me...

I'm not entirely sure what you're asking about...the KX414 doesn't have softkeys - it has the OK and CLR keys in the typical softkey location.

I'm not entirely sure what you're asking about...the KX414 doesn't have softkeys - it has the OK and CLR keys in the typical softkey location.

mohlendo wrote:I'm not entirely sure what you're asking about...the KX414 doesn't have softkeys - it has the OK and CLR keys in the typical softkey location.
Sorry for the confusion, I wanted to confirm the KX414 has no softkeys and do not generate any AVK_SOFTX events... :D
Speaking of tiny phones, the C343, on the emulator, I could not find a key that would generate the AVK_CLR event... :confused:

mohlendo wrote:I'm not entirely sure what you're asking about...the KX414 doesn't have softkeys - it has the OK and CLR keys in the typical softkey location.
Sorry for the confusion, I wanted to confirm the KX414 has no softkeys and do not generate any AVK_SOFTX events... :D
Speaking of tiny phones, the C343, on the emulator, I could not find a key that would generate the AVK_CLR event... :confused:

The c343 doesn't have a CLR key. Like the t720 it only has two softkeys.

The c343 doesn't have a CLR key. Like the t720 it only has two softkeys.

Dragon wrote:The c343 doesn't have a CLR key. Like the t720 it only has two softkeys.
So, you are saying that there are no keys on the c343 which generates the AVK_CLR event?
:confused:

Dragon wrote:The c343 doesn't have a CLR key. Like the t720 it only has two softkeys.
So, you are saying that there are no keys on the c343 which generates the AVK_CLR event?
:confused:

I do believe so, yes. Like the OS it would make sense to use AVK_SOFT1 for that purpose.

I do believe so, yes. Like the OS it would make sense to use AVK_SOFT1 for that purpose.

On the C343, the left softkey sends the AVK_CLR event, and the right softkey sends the AVK_SELECT event. The middle button sends AVK_SOFT1. The emulator has been changed to reflect this.

On the C343, the left softkey sends the AVK_CLR event, and the right softkey sends the AVK_SELECT event. The middle button sends AVK_SOFT1. The emulator has been changed to reflect this.

Max,
The emulator skin for the Audiovox CDM-8910 is also defective with incorrect screen dimensions etc, and the skin for the Nokia 6255i clamshell phone is also completely off the wall.
Just thought I'd let you know.

Max,
The emulator skin for the Audiovox CDM-8910 is also defective with incorrect screen dimensions etc, and the skin for the Nokia 6255i clamshell phone is also completely off the wall.
Just thought I'd let you know.

I fixed the screen dimensions of the 8910 on 8/31/04.
As for the 6255, I don't see an emulator skin available. :confused:

I fixed the screen dimensions of the 8910 on 8/31/04.
As for the 6255, I don't see an emulator skin available. :confused:

Also make sure to correct the color depth on the 8910. It is set to 8 bit.
As for the 6255i, yes I couldn't remember if I got it from the Extranet or from Nokia directly. Since you can't find it, I may have gotten it directly from the Nokia guys. Sorry to be a bother in that case.

Also make sure to correct the color depth on the 8910. It is set to 8 bit.
As for the 6255i, yes I couldn't remember if I got it from the Extranet or from Nokia directly. Since you can't find it, I may have gotten it directly from the Nokia guys. Sorry to be a bother in that case.

It's set to 16-bit on the posted skin. ;)
One of the many errors that was noted in the other emulator skin thread. Keep 'em coming though. :D

It's set to 16-bit on the posted skin. ;)
One of the many errors that was noted in the other emulator skin thread. Keep 'em coming though. :D

Max,
The VX32000 emu skin needs some TLC. Its Display Window Width and Height are incorrect and the DeviceID is missing. Additionally with 900kB the heap size doesn't seem to be right - should be 500kB, I suppose.
:(
Same goes for the vx4700. Display Window Width and Height are off, and according to the emulator skin the handset has ZERO memory.
:mad:
And while we're at it, add the vx6100 to the list as well. It's Window Width and Height are incorrect, it's display resolution height is incorrect and the meory setting as well.
I jus't can't believe how sloppy these emulator skins are being treated after the developer community has been pointing out these issues over and over and over again. Is it REALLY that hard to have someone have a pass at these skins before they go live? Send them to me, for crying out loud!
:mad: :mad: :mad:

Max,
The VX32000 emu skin needs some TLC. Its Display Window Width and Height are incorrect and the DeviceID is missing. Additionally with 900kB the heap size doesn't seem to be right - should be 500kB, I suppose.
:(
Same goes for the vx4700. Display Window Width and Height are off, and according to the emulator skin the handset has ZERO memory.
:mad:
And while we're at it, add the vx6100 to the list as well. It's Window Width and Height are incorrect, it's display resolution height is incorrect and the meory setting as well.
I jus't can't believe how sloppy these emulator skins are being treated after the developer community has been pointing out these issues over and over and over again. Is it REALLY that hard to have someone have a pass at these skins before they go live? Send them to me, for crying out loud!
:mad: :mad: :mad:

Fixed the 3200 and 6100...4700 was fixed a couple months ago.
Check your pms. :)

Fixed the 3200 and 6100...4700 was fixed a couple months ago.
Check your pms. :)

Max,
The skin for the Samsung n330 is also defective... what a surprise.
The Display Widonws Width and Height is incorrect and the skin does not contain a platformID for the device.

Max,
The skin for the Samsung n330 is also defective... what a surprise.
The Display Widonws Width and Height is incorrect and the skin does not contain a platformID for the device.

Yes, shocking. :mad:
Fixed.

Yes, shocking. :mad:
Fixed.

You're the man, Max.

You're the man, Max.

I just ran across this thread last week. I really liked how Dragon, you were finding these and then Max was fixing them. Then, yesterday I ran across one of my own. The vx4400 skin is setup to report that the bit depth is 8bit but in fact the phone is 16bit. Also, kind of the same thing with the T720 (and I would assume the T730 as well) but instead of the phone being 16bit the screen is actually 12bit. This is all going off of the phone specs on the extranet. But, they definitly are not 8bit because 8bit would cause the app to crash :)
-jeff

I just ran across this thread last week. I really liked how Dragon, you were finding these and then Max was fixing them. Then, yesterday I ran across one of my own. The vx4400 skin is setup to report that the bit depth is 8bit but in fact the phone is 16bit. Also, kind of the same thing with the T720 (and I would assume the T730 as well) but instead of the phone being 16bit the screen is actually 12bit. This is all going off of the phone specs on the extranet. But, they definitly are not 8bit because 8bit would cause the app to crash :)
-jeff

Fixed and fixed, thanks!

Fixed and fixed, thanks!

I posted here before because of an emulator discrepency but I have a question about a phone spec on the extranet. The samsung a530 says that it has an 8bit screen on the phone spec but everywhere else I look it says it is 16bit? I know the screen looks bad so I guess it could be making the images 16bit and then displaying them on an 8bit screen but I'm not sure what the case is.
Plus, another phone spec thing. The audiovox 9900 says that is has 655,366 RAM but if I do the ###3 at the app manager it only shows 420 kb. Is it just taking alot of memory to load up the mif icons and whatever else it loads at that screen. Or does the phone actually have less ram then the spec says it does?
Thanks,
jeff

I posted here before because of an emulator discrepency but I have a question about a phone spec on the extranet. The samsung a530 says that it has an 8bit screen on the phone spec but everywhere else I look it says it is 16bit? I know the screen looks bad so I guess it could be making the images 16bit and then displaying them on an 8bit screen but I'm not sure what the case is.
Plus, another phone spec thing. The audiovox 9900 says that is has 655,366 RAM but if I do the ###3 at the app manager it only shows 420 kb. Is it just taking alot of memory to load up the mif icons and whatever else it loads at that screen. Or does the phone actually have less ram then the spec says it does?
Thanks,
jeff

Audiovox 9900 is braindead phone from hell. Yes it is as screwed as it appears to be; 240x292 screen with ~440k heap? f'ked up. The emu skin lies of course.
See other postings on this matter.
[angry addendum]
BASTARDS! The 6100 skin was completely the wrong display size! I did and delivered app for 128x160 display, and you made me look like a total dick to my publisher. Now I come on here and see it's wrong, and you've fixed it, and you've still got the f'king display depth wrong. Is it 8 bit? I think not.
PLEASE TRY MUCH, *MUCH* HARDER THAN THIS TO GET STUFF RIGHT!
Sorry that was just the latest of a long series of utterly stupid errors in Brew and I am frustrated beyond belief with this crap.

Audiovox 9900 is braindead phone from hell. Yes it is as screwed as it appears to be; 240x292 screen with ~440k heap? f'ked up. The emu skin lies of course.
See other postings on this matter.
[angry addendum]
BASTARDS! The 6100 skin was completely the wrong display size! I did and delivered app for 128x160 display, and you made me look like a total dick to my publisher. Now I come on here and see it's wrong, and you've fixed it, and you've still got the f'king display depth wrong. Is it 8 bit? I think not.
PLEASE TRY MUCH, *MUCH* HARDER THAN THIS TO GET STUFF RIGHT!
Sorry that was just the latest of a long series of utterly stupid errors in Brew and I am frustrated beyond belief with this crap.

god damn it's happened again! I got screwed over twice in two days!
f*kin V710 emu skin reports screen as 176x205 high, when in fact it's 204 high. You might thing that's no big deal but it damn well matters to me. It's an 18-bit display on the device and the emu reports 16-bit of course, but I had that problem reported to me a while back and avoided it.
Look QComm - can you hire say a slightly bored 12 year-old to go check this stuff?
Screen height, width, depth. THREE NUMBERS.. Unbelievable.
Hey, how about checking ram size, and maybe even softkeys? Go on, be a devil.
I know I am really starting to rant about this but it has caused me an *incredible* amount of annoyance and cost me money and sleep and a LOT of publisher goodwill.
My bad - I am clearly an idiot for ever thinking this stuff would have been correct.
Grrr. :mad:
P.S. Ok, ok, I will calm down and stop ranting but can I just stress that this kind of thing is *really* important to get right. Really, really really. I have enough other stuff to sort out without having to worry about whether I am being fed bullshit by the API. The thing mentioned in my previous post with the 6100 emu display just being totally wrong was unforgivable. Please spend a day or two thoroughly reviewing all your emu skins and correct them. Oh and hey, post a list of what was screwed up so we all know. I am mystified why we developers are expected to debug your broke-ass shit for you.
This is the sort of thing that gives Qualcomm a really bad name with developers, if that matters.

god damn it's happened again! I got screwed over twice in two days!
f*kin V710 emu skin reports screen as 176x205 high, when in fact it's 204 high. You might thing that's no big deal but it damn well matters to me. It's an 18-bit display on the device and the emu reports 16-bit of course, but I had that problem reported to me a while back and avoided it.
Look QComm - can you hire say a slightly bored 12 year-old to go check this stuff?
Screen height, width, depth. THREE NUMBERS.. Unbelievable.
Hey, how about checking ram size, and maybe even softkeys? Go on, be a devil.
I know I am really starting to rant about this but it has caused me an *incredible* amount of annoyance and cost me money and sleep and a LOT of publisher goodwill.
My bad - I am clearly an idiot for ever thinking this stuff would have been correct.
Grrr. :mad:
P.S. Ok, ok, I will calm down and stop ranting but can I just stress that this kind of thing is *really* important to get right. Really, really really. I have enough other stuff to sort out without having to worry about whether I am being fed bullshit by the API. The thing mentioned in my previous post with the 6100 emu display just being totally wrong was unforgivable. Please spend a day or two thoroughly reviewing all your emu skins and correct them. Oh and hey, post a list of what was screwed up so we all know. I am mystified why we developers are expected to debug your broke-ass shit for you.
This is the sort of thing that gives Qualcomm a really bad name with developers, if that matters.

FryingLizard wrote:god damn it's happened again! I got screwed over twice in two days!
etc
I dislike when the emulator skins are off also.
However, I believe that the application should handle all
the dynamic sizing it needs to do at runtime. IOW
something like 200x180 versus 205x180 shouldn't matter.
Stretching a bitmap by 5 pixels should hardly be noticable
even by the most brute force methods. (And there are other options
for dynamic sizing).
That being said, there is no substitute for testing on the device.
There are many little quirks that the OEMs introduce by their
apparent altering of the BREW code base. And anything other than
BitBlt may or may not work properly from device to device.
This is the Brew World. Start reading through the known issues and
you will understand....

FryingLizard wrote:god damn it's happened again! I got screwed over twice in two days!
etc
I dislike when the emulator skins are off also.
However, I believe that the application should handle all
the dynamic sizing it needs to do at runtime. IOW
something like 200x180 versus 205x180 shouldn't matter.
Stretching a bitmap by 5 pixels should hardly be noticable
even by the most brute force methods. (And there are other options
for dynamic sizing).
That being said, there is no substitute for testing on the device.
There are many little quirks that the OEMs introduce by their
apparent altering of the BREW code base. And anything other than
BitBlt may or may not work properly from device to device.
This is the Brew World. Start reading through the known issues and
you will understand....

Mmmm yep thanks for that mildly patronising reply. ;-) Fair 'nuff if you think I'm being an asshole about this but you have to admit the skin thing is intensely and continually annoying.
Your point about almost nothing consistently working across all handsets is well made as we are all painfully aware - why is it that the the testing that NSTL apply to our apps appears to be far more rigorous than the compliance testing that QC do on the frickin handset firmware?
BTW Max, I appreciate your help here and none of this is aimed directly at you per se; this is public forum (that gets crawled by Google) hence what developers say here does reach further than you and hopefully notice gets taken. Hopefully..

Mmmm yep thanks for that mildly patronising reply. ;-) Fair 'nuff if you think I'm being an asshole about this but you have to admit the skin thing is intensely and continually annoying.
Your point about almost nothing consistently working across all handsets is well made as we are all painfully aware - why is it that the the testing that NSTL apply to our apps appears to be far more rigorous than the compliance testing that QC do on the frickin handset firmware?
BTW Max, I appreciate your help here and none of this is aimed directly at you per se; this is public forum (that gets crawled by Google) hence what developers say here does reach further than you and hopefully notice gets taken. Hopefully..

FryingLizard wrote:god damn it's happened again! I got screwed over twice in two days!
f*kin V710 emu skin reports screen as 176x205 high, when in fact it's 204 high. You might thing that's no big deal but it damn well matters to me. It's an 18-bit display on the device and the emu reports 16-bit of course, but I had that problem reported to me a while back and avoided it.
Look QComm - can you hire say a slightly bored 12 year-old to go check this stuff?
Screen height, width, depth. THREE NUMBERS.. Unbelievable.
I've fixed this skin as well. We've already instituted a policy for reviewing the skins on all upcoming handsets before they're posted to ensure that the critical attributes (key mappings, heap size, screen resolution, etc.) are verified. Unfortunately, there are still a few legacy skins on the extranet with errors. As you've probably noticed, I'm working to correct these errors as they're reported; unfortunately, I simply don't have the time to inspect every one of the 100+ skins already posted.

FryingLizard wrote:god damn it's happened again! I got screwed over twice in two days!
f*kin V710 emu skin reports screen as 176x205 high, when in fact it's 204 high. You might thing that's no big deal but it damn well matters to me. It's an 18-bit display on the device and the emu reports 16-bit of course, but I had that problem reported to me a while back and avoided it.
Look QComm - can you hire say a slightly bored 12 year-old to go check this stuff?
Screen height, width, depth. THREE NUMBERS.. Unbelievable.
I've fixed this skin as well. We've already instituted a policy for reviewing the skins on all upcoming handsets before they're posted to ensure that the critical attributes (key mappings, heap size, screen resolution, etc.) are verified. Unfortunately, there are still a few legacy skins on the extranet with errors. As you've probably noticed, I'm working to correct these errors as they're reported; unfortunately, I simply don't have the time to inspect every one of the 100+ skins already posted.

Mkay thanks,
I will now shut up and stop complaining so vociferously & be nothing but sweetness and light. Sorry to hear about the lack of resources for checking existing skins, but 12 year-olds _are_ cheap to employ y'know. You could just offer them a free CDM9900 or something. :rolleyes:
FL

Mkay thanks,
I will now shut up and stop complaining so vociferously & be nothing but sweetness and light. Sorry to hear about the lack of resources for checking existing skins, but 12 year-olds _are_ cheap to employ y'know. You could just offer them a free CDM9900 or something. :rolleyes:
FL

No, we can't even GIVE those things away....
:D

No, we can't even GIVE those things away....
:D

i wonder if cellphones can be nominated for the darwin award, if so i nominate the 9900

i wonder if cellphones can be nominated for the darwin award, if so i nominate the 9900

I'm writing this on our office 9900 right now! It's not so bad, I like the big scr*MALLOC FAIL - OUT OF MEMORY ERROR*

I'm writing this on our office 9900 right now! It's not so bad, I like the big scr*MALLOC FAIL - OUT OF MEMORY ERROR*

Oh lordy the hilarity only lasts a few minutes before my inbox fills once again with emu-skin-related screaming and shouting.
- Max, can you forcibly provide NSTL testers with correct skins please? They've just kicked back two of my apps because they fail to run in 8-bit mode on the emu with a broken emulator skin - when they don't frickin' need to in real life as the handsets (KX414 & SE47 in this case) are 16 bit. Naturally we are contesting this because it's total bullshit, but once again I have unhappy clients.
(Oh and no smart-ass comments along the lines of 'well your app should run in 8 bit mode!' please jmiller2 or I shall hunt you down like a dog and make you work for QComm dev support for the rest of your days)
Muchos gracias, and sweetness :-) and light :-) as promised above - just sort it out pls.
Big hugs,
FL.

Oh lordy the hilarity only lasts a few minutes before my inbox fills once again with emu-skin-related screaming and shouting.
- Max, can you forcibly provide NSTL testers with correct skins please? They've just kicked back two of my apps because they fail to run in 8-bit mode on the emu with a broken emulator skin - when they don't frickin' need to in real life as the handsets (KX414 & SE47 in this case) are 16 bit. Naturally we are contesting this because it's total bullshit, but once again I have unhappy clients.
(Oh and no smart-ass comments along the lines of 'well your app should run in 8 bit mode!' please jmiller2 or I shall hunt you down like a dog and make you work for QComm dev support for the rest of your days)
Muchos gracias, and sweetness :-) and light :-) as promised above - just sort it out pls.
Big hugs,
FL.

yeah i wonder about this too, another board member had told me that it wasn't necessary to submit simulator builds to NSTL , i haven't tested that theory yet.
I do wonder about an app thats about to go in that relies on platform IDs, it has a database of them all so it matches correctly, however i've noticed a lot of the skins just just 0 as the platform id, in which case due to the way the app was designed (elsewhere) it'll fail to run properly,since it requires other info too
i have an app thats written in about 90% assembler too, so thats going to be interesting since there is no simulator version, i have nightmares of nstl demanding i write a C version so they can test it ;)

yeah i wonder about this too, another board member had told me that it wasn't necessary to submit simulator builds to NSTL , i haven't tested that theory yet.
I do wonder about an app thats about to go in that relies on platform IDs, it has a database of them all so it matches correctly, however i've noticed a lot of the skins just just 0 as the platform id, in which case due to the way the app was designed (elsewhere) it'll fail to run properly,since it requires other info too
i have an app thats written in about 90% assembler too, so thats going to be interesting since there is no simulator version, i have nightmares of nstl demanding i write a C version so they can test it ;)

Well I def. just got a kick in the teeth from NSTL about that (broke emu skin), although on previous apps with same requirement they _haven't_ complained about it. I also know from my server logs that they don't always test the emulator builds we provide - sometimes yes, sometimes no, and when they do, and they find something that's bust due to the skin being broken, sometimes they try to fail me (see above) and I have to have someone shout at them, sometimes I get a 'passed with notes'. Grrr etc etc etc yawn.
With the do-you-need Emulator DLL requirement, it's dunno having not tried it, although I would expect them to give you grief if you don't provide one in your submission, but hey - see what you can get away with. Maybe just give them something that _looks_ like a Win DLL, but just prints up something like "BAD EMULATOR SKIN" when started. ;-)
If they really give you crap you could write an ARM-to-C converter (I did a MIPS-to-C the other day and it was surprisingly easy) or you could just come on here and complain about everything like I do ;-)
My app also uses platform IDs - in some cases the actual device returns you 0 (CDM8600 comes to mind; I detect it with a combination of screen size and RAM -
if (ScreenW==128 && ScreenH==112 && RamTotal==409600)
{
DeviceID=16006; //CDM8600 broke
}
Also beware the gazillion duplicated platform IDs there are out there. IIRC the KX414 has about 30 different ones. Just recently (November?) a PDF doc went up on the developer XXXXtranet listing them. Not sure if it's complete tho. In fact, come to think of it I wouldn't trust it as far as a small, arthritic ant could carry it, but them's the breaks.
Sorry, yet another long night of hacking my way around broke ass brew shit. Last night included such delights as the CDM8600's crash-prone TCP stack that reboots the phone when it feels like it (yay!), the CDM8910's hanging when it receives a voice call after a data connection (more yay)! etc. Fabulous.
Am starting to develop mortal fear anything beginning with "CDM". Any thoughts on what that TLA stands for?
On the brighter side, I do actually rather love the VX7000. Yay something!

Well I def. just got a kick in the teeth from NSTL about that (broke emu skin), although on previous apps with same requirement they _haven't_ complained about it. I also know from my server logs that they don't always test the emulator builds we provide - sometimes yes, sometimes no, and when they do, and they find something that's bust due to the skin being broken, sometimes they try to fail me (see above) and I have to have someone shout at them, sometimes I get a 'passed with notes'. Grrr etc etc etc yawn.
With the do-you-need Emulator DLL requirement, it's dunno having not tried it, although I would expect them to give you grief if you don't provide one in your submission, but hey - see what you can get away with. Maybe just give them something that _looks_ like a Win DLL, but just prints up something like "BAD EMULATOR SKIN" when started. ;-)
If they really give you crap you could write an ARM-to-C converter (I did a MIPS-to-C the other day and it was surprisingly easy) or you could just come on here and complain about everything like I do ;-)
My app also uses platform IDs - in some cases the actual device returns you 0 (CDM8600 comes to mind; I detect it with a combination of screen size and RAM -
if (ScreenW==128 && ScreenH==112 && RamTotal==409600)
{
DeviceID=16006; //CDM8600 broke
}
Also beware the gazillion duplicated platform IDs there are out there. IIRC the KX414 has about 30 different ones. Just recently (November?) a PDF doc went up on the developer XXXXtranet listing them. Not sure if it's complete tho. In fact, come to think of it I wouldn't trust it as far as a small, arthritic ant could carry it, but them's the breaks.
Sorry, yet another long night of hacking my way around broke ass brew shit. Last night included such delights as the CDM8600's crash-prone TCP stack that reboots the phone when it feels like it (yay!), the CDM8910's hanging when it receives a voice call after a data connection (more yay)! etc. Fabulous.
Am starting to develop mortal fear anything beginning with "CDM". Any thoughts on what that TLA stands for?
On the brighter side, I do actually rather love the VX7000. Yay something!

OMG! Another one! Just got kicked in the head AGAIN by NSTL because my app don't work on the broken 6100 emu skin!! F'king hell!
Max can you send out some kind of general email notification to NSTL telling them that they MUST GET CORRECTED SKINS before testing on emu? please? please? This is *insanity*.
It's certainly driving _me_ insane, if you hadn't already noticed. I used to be a mild mannered reporter before I stepped into the phone booth that is Brew develoment and emerged as RANTERMAN!
----
Addendum: Ok, in fact NSTL getting latest skin wouldn't help on 6100 because the extranet one is _still broken_.
SCREEN 75 149 203 295 AVS_SCREEN_0 128 146 0.000000 0.000000 INCH 8 1
8 Bit?!?! *For the love of god NO IT'S NOT!*
Ok, ok, clearly my endlessly frustrated (some might say loud + obnoxious) behavior is winning me no friends here. I just don't know what I am supposed to do.
I write apps that in some cases use the display buffer directly for obvious reasons and these apps DO NOT work on 8BPP displays, because there aren't any 8BPP handsets left. If there were, I would write code to support them in some ugly-ass way, and I would test it, and it would frickin' work, and then I would submit it. But there but there aren't any 8bpp phones I care about, and so I haven't.
Tell me what I am supposed to do please? I just cannot win. - NSTL are failing my apps because of issues that are just bullshit, the client is getting understandably pissed and this is obviously significantly damaging our reputation with them and costing everyone time and money. WTF am I supposed to do? Can I submit an actual correct emu skin with each app I submit and tell them to use that? Shall I change my emu app so instead of reporting that the display is unusable, it opens a browser window pointing to this page, and patiently explains that they shouldn't expect it to work on the emu because half the skins are screwed? Should I go and write a significant chunk of 8bpp rendering code to compensate for the fact that OEMs seem incapable of typing one number correctly? What?!?

OMG! Another one! Just got kicked in the head AGAIN by NSTL because my app don't work on the broken 6100 emu skin!! F'king hell!
Max can you send out some kind of general email notification to NSTL telling them that they MUST GET CORRECTED SKINS before testing on emu? please? please? This is *insanity*.
It's certainly driving _me_ insane, if you hadn't already noticed. I used to be a mild mannered reporter before I stepped into the phone booth that is Brew develoment and emerged as RANTERMAN!
----
Addendum: Ok, in fact NSTL getting latest skin wouldn't help on 6100 because the extranet one is _still broken_.
SCREEN 75 149 203 295 AVS_SCREEN_0 128 146 0.000000 0.000000 INCH 8 1
8 Bit?!?! *For the love of god NO IT'S NOT!*
Ok, ok, clearly my endlessly frustrated (some might say loud + obnoxious) behavior is winning me no friends here. I just don't know what I am supposed to do.
I write apps that in some cases use the display buffer directly for obvious reasons and these apps DO NOT work on 8BPP displays, because there aren't any 8BPP handsets left. If there were, I would write code to support them in some ugly-ass way, and I would test it, and it would frickin' work, and then I would submit it. But there but there aren't any 8bpp phones I care about, and so I haven't.
Tell me what I am supposed to do please? I just cannot win. - NSTL are failing my apps because of issues that are just bullshit, the client is getting understandably pissed and this is obviously significantly damaging our reputation with them and costing everyone time and money. WTF am I supposed to do? Can I submit an actual correct emu skin with each app I submit and tell them to use that? Shall I change my emu app so instead of reporting that the display is unusable, it opens a browser window pointing to this page, and patiently explains that they shouldn't expect it to work on the emu because half the skins are screwed? Should I go and write a significant chunk of 8bpp rendering code to compensate for the fact that OEMs seem incapable of typing one number correctly? What?!?

Huh...I had no idea NSTL would fail your app if it does not run properly on the emu.
Our experience has been that if it runs on the phone a-ok, then the app is a-ok.
:confused:
FryingLizard wrote:OMG! Another one! Just got kicked in the head AGAIN by NSTL because my app don't work on the broken 6100 emu skin!! F'king hell!
Max can you send out some kind of general email notification to NSTL telling them that they MUST GET CORRECTED SKINS before testing on emu? please? please? This is *insanity*.
It's certainly driving _me_ insane, if you hadn't already noticed. I used to be a mild mannered reporter before I stepped into the phone booth that is Brew develoment and emerged as RANTERMAN!
----
Addendum: Ok, in fact NSTL getting latest skin wouldn't help on 6100 because the extranet one is _still broken_.
SCREEN 75 149 203 295 AVS_SCREEN_0 128 146 0.000000 0.000000 INCH 8 1
8 Bit?!?! *For the love of god NO IT'S NOT!*
Ok, ok, clearly my endlessly frustrated (some might say loud + obnoxious) behavior is winning me no friends here. I just don't know what I am supposed to do.
I write apps that in some cases use the display buffer directly for obvious reasons and these apps DO NOT work on 8BPP displays, because there aren't any 8BPP handsets left. If there were, I would write code to support them in some ugly-ass way, and I would test it, and it would frickin' work, and then I would submit it. But there but there aren't any 8bpp phones I care about, and so I haven't.
Tell me what I am supposed to do please? I just cannot win. - NSTL are failing my apps because of issues that are just bullshit, the client is getting understandably pissed and this is obviously significantly damaging our reputation with them and costing everyone time and money. WTF am I supposed to do? Can I submit an actual correct emu skin with each app I submit and tell them to use that? Shall I change my emu app so instead of reporting that the display is unusable, it opens a browser window pointing to this page, and patiently explains that they shouldn't expect it to work on the emu because half the skins are screwed? Should I go and write a significant chunk of 8bpp rendering code to compensate for the fact that OEMs seem incapable of typing one number correctly? What?!?

Huh...I had no idea NSTL would fail your app if it does not run properly on the emu.
Our experience has been that if it runs on the phone a-ok, then the app is a-ok.
:confused:
FryingLizard wrote:OMG! Another one! Just got kicked in the head AGAIN by NSTL because my app don't work on the broken 6100 emu skin!! F'king hell!
Max can you send out some kind of general email notification to NSTL telling them that they MUST GET CORRECTED SKINS before testing on emu? please? please? This is *insanity*.
It's certainly driving _me_ insane, if you hadn't already noticed. I used to be a mild mannered reporter before I stepped into the phone booth that is Brew develoment and emerged as RANTERMAN!
----
Addendum: Ok, in fact NSTL getting latest skin wouldn't help on 6100 because the extranet one is _still broken_.
SCREEN 75 149 203 295 AVS_SCREEN_0 128 146 0.000000 0.000000 INCH 8 1
8 Bit?!?! *For the love of god NO IT'S NOT!*
Ok, ok, clearly my endlessly frustrated (some might say loud + obnoxious) behavior is winning me no friends here. I just don't know what I am supposed to do.
I write apps that in some cases use the display buffer directly for obvious reasons and these apps DO NOT work on 8BPP displays, because there aren't any 8BPP handsets left. If there were, I would write code to support them in some ugly-ass way, and I would test it, and it would frickin' work, and then I would submit it. But there but there aren't any 8bpp phones I care about, and so I haven't.
Tell me what I am supposed to do please? I just cannot win. - NSTL are failing my apps because of issues that are just bullshit, the client is getting understandably pissed and this is obviously significantly damaging our reputation with them and costing everyone time and money. WTF am I supposed to do? Can I submit an actual correct emu skin with each app I submit and tell them to use that? Shall I change my emu app so instead of reporting that the display is unusable, it opens a browser window pointing to this page, and patiently explains that they shouldn't expect it to work on the emu because half the skins are screwed? Should I go and write a significant chunk of 8bpp rendering code to compensate for the fact that OEMs seem incapable of typing one number correctly? What?!?

FryingLizard wrote:Tell me what I am supposed to do please? I just cannot win. - NSTL are failing my apps because of issues that are just bullshit, the client is getting understandably pissed and this is obviously significantly damaging our reputation with them and costing everyone time and money. WTF am I supposed to do? Can I submit an actual correct emu skin with each app I submit and tell them to use that? Shall I change my emu app so instead of reporting that the display is unusable, it opens a browser window pointing to this page, and patiently explains that they shouldn't expect it to work on the emu because half the skins are screwed? Should I go and write a significant chunk of 8bpp rendering code to compensate for the fact that OEMs seem incapable of typing one number correctly? What?!?
You can start by responding to the PM I sent yesterday asking for the relevant information about your application (title, version, etc), so I can talk with NSTL about this situation. ;)
As for skins, I suppose we're running into the same old problem developers have been complaining about for a while -- that there's no notification given when a file changes on the extranet, and thus no way to know when a more recent version is available. I'm going to have a chat with our web team about what sort of notifications would be possible (once people get back from vacations next week).
I'm sorry your experience with BREW development has been this godawful, hopefully I can smooth things over with NSTL.
On a sidenote, when issues of this sort arise (that require Qualcomm intervention with NSTL), it's a good idea to open up a request through the official channels -- eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')) in this case.

FryingLizard wrote:Tell me what I am supposed to do please? I just cannot win. - NSTL are failing my apps because of issues that are just bullshit, the client is getting understandably pissed and this is obviously significantly damaging our reputation with them and costing everyone time and money. WTF am I supposed to do? Can I submit an actual correct emu skin with each app I submit and tell them to use that? Shall I change my emu app so instead of reporting that the display is unusable, it opens a browser window pointing to this page, and patiently explains that they shouldn't expect it to work on the emu because half the skins are screwed? Should I go and write a significant chunk of 8bpp rendering code to compensate for the fact that OEMs seem incapable of typing one number correctly? What?!?
You can start by responding to the PM I sent yesterday asking for the relevant information about your application (title, version, etc), so I can talk with NSTL about this situation. ;)
As for skins, I suppose we're running into the same old problem developers have been complaining about for a while -- that there's no notification given when a file changes on the extranet, and thus no way to know when a more recent version is available. I'm going to have a chat with our web team about what sort of notifications would be possible (once people get back from vacations next week).
I'm sorry your experience with BREW development has been this godawful, hopefully I can smooth things over with NSTL.
On a sidenote, when issues of this sort arise (that require Qualcomm intervention with NSTL), it's a good idea to open up a request through the official channels -- eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')) in this case.

i aways wonder why oems etc don't just put stuff inside a revision control system such as cvs/subversion and just allow developers read only access to that.
a structured layout with the skins, pdfs etv even the sdk so updates can be applied uniformly with logging, and the ability to go back easily

i aways wonder why oems etc don't just put stuff inside a revision control system such as cvs/subversion and just allow developers read only access to that.
a structured layout with the skins, pdfs etv even the sdk so updates can be applied uniformly with logging, and the ability to go back easily

yep curitel handsets are garbage, almost as bad as sony/ericsson phones
i get more problems with those than any other, although the motorolas are becoming a very close second
accolade, i've had apps fail for emulator problems, even when it works on the phone, there was a bug in the 2.0 emulator if i remember that didn't release all the memory properly so came up with an error at exit , and then there was another sound related issue that caused the emulator to crash with a double free, in both instances apps would be fine on the phone
the lg7000 is ok, it has some sound issues though
as for an arm->c convertor thats the joke, they'd be testing the stability of the arm2c convertor not the original code.

yep curitel handsets are garbage, almost as bad as sony/ericsson phones
i get more problems with those than any other, although the motorolas are becoming a very close second
accolade, i've had apps fail for emulator problems, even when it works on the phone, there was a bug in the 2.0 emulator if i remember that didn't release all the memory properly so came up with an error at exit , and then there was another sound related issue that caused the emulator to crash with a double free, in both instances apps would be fine on the phone
the lg7000 is ok, it has some sound issues though
as for an arm->c convertor thats the joke, they'd be testing the stability of the arm2c convertor not the original code.

Maybe you could just blast an email via developer relations? :D
mohlendo wrote:You can start by responding to the PM I sent yesterday asking for the relevant information about your application (title, version, etc), so I can talk with NSTL about this situation. ;)
As for skins, I suppose we're running into the same old problem developers have been complaining about for a while -- that there's no notification given when a file changes on the extranet, and thus no way to know when a more recent version is available. I'm going to have a chat with our web team about what sort of notifications would be possible (once people get back from vacations next week).
I'm sorry your experience with BREW development has been this godawful, hopefully I can smooth things over with NSTL.
On a sidenote, when issues of this sort arise (that require Qualcomm intervention with NSTL), it's a good idea to open up a request through the official channels -- eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')) in this case.

Maybe you could just blast an email via developer relations? :D
mohlendo wrote:You can start by responding to the PM I sent yesterday asking for the relevant information about your application (title, version, etc), so I can talk with NSTL about this situation. ;)
As for skins, I suppose we're running into the same old problem developers have been complaining about for a while -- that there's no notification given when a file changes on the extranet, and thus no way to know when a more recent version is available. I'm going to have a chat with our web team about what sort of notifications would be possible (once people get back from vacations next week).
I'm sorry your experience with BREW development has been this godawful, hopefully I can smooth things over with NSTL.
On a sidenote, when issues of this sort arise (that require Qualcomm intervention with NSTL), it's a good idea to open up a request through the official channels -- eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%22%20%63%6c%61%73%73%3d%22%62%62%2d%65%6d%61%69%6c%22%3e%62%72%65%77%2d%73%75%70%70%6f%72%74%40%71%75%61%6c%63%6f%6d%6d%2e%63%6f%6d%3c%2f%61%3e%27%29%3b')) in this case.

Uhm...for every extranet change? That would be more than daily, and I'd imagine people would want a different list for filtering purposes.

Uhm...for every extranet change? That would be more than daily, and I'd imagine people would want a different list for filtering purposes.

Not every change, just went the phone details have been updated.
As is, from time to time, I redownload all the phone emu files every so often, which is a pain. Now, if I could just trust that I get a notification when a phone emu files change, I'd be a very happy camper...
:)
mohlendo wrote:Uhm...for every extranet change? That would be more than daily, and I'd imagine people would want a different list for filtering purposes.

Not every change, just went the phone details have been updated.
As is, from time to time, I redownload all the phone emu files every so often, which is a pain. Now, if I could just trust that I get a notification when a phone emu files change, I'd be a very happy camper...
:)
mohlendo wrote:Uhm...for every extranet change? That would be more than daily, and I'd imagine people would want a different list for filtering purposes.

You are right. We never had problems a la memory leak or crash on the emulators. I was thinking more about a slight misalignment in graphics and such... ;)
charliex wrote:yep curitel handsets are garbage, almost as bad as sony/ericsson phones
i get more problems with those than any other, although the motorolas are becoming a very close second
accolade, i've had apps fail for emulator problems, even when it works on the phone, there was a bug in the 2.0 emulator if i remember that didn't release all the memory properly so came up with an error at exit , and then there was another sound related issue that caused the emulator to crash with a double free, in both instances apps would be fine on the phone
the lg7000 is ok, it has some sound issues though
as for an arm->c convertor thats the joke, they'd be testing the stability of the arm2c convertor not the original code.

You are right. We never had problems a la memory leak or crash on the emulators. I was thinking more about a slight misalignment in graphics and such... ;)
charliex wrote:yep curitel handsets are garbage, almost as bad as sony/ericsson phones
i get more problems with those than any other, although the motorolas are becoming a very close second
accolade, i've had apps fail for emulator problems, even when it works on the phone, there was a bug in the 2.0 emulator if i remember that didn't release all the memory properly so came up with an error at exit , and then there was another sound related issue that caused the emulator to crash with a double free, in both instances apps would be fine on the phone
the lg7000 is ok, it has some sound issues though
as for an arm->c convertor thats the joke, they'd be testing the stability of the arm2c convertor not the original code.

accolade wrote:Not every change, just went the phone details have been updated.
As is, from time to time, I redownload all the phone emu files every so often, which is a pain. Now, if I could just trust that I get a notification when a phone emu files change, I'd be a very happy camper...
:)
I'll look into whether this can be done. There's no current system in place that would handle this, so we'd have to rig something up.

accolade wrote:Not every change, just went the phone details have been updated.
As is, from time to time, I redownload all the phone emu files every so often, which is a pain. Now, if I could just trust that I get a notification when a phone emu files change, I'd be a very happy camper...
:)
I'll look into whether this can be done. There's no current system in place that would handle this, so we'd have to rig something up.

[ ^^^ The forthcoming Curitel CDM1337 - 4x1 Nixie Tube display, Ferrite-Core RAM, 150Mhz ARM9 CPU]
Not a bad idea. Anonymous CVS is of course one way, if you can get your web people to set it up.
Another strictly client-side way would be a batch script using the standard 'wget'
cmdline tool (GPL'd, linux + windows builds) which goes and pulls the skin zips down. Works with HTTPS too, handily enough, and you can set it to skip files that haven't changed size or date etc.
In an effort to contribute something to this forum other than foul-mouthed complaints, I started sorting out a script to do just this but then someone very pointedly reminded me that I have more than enough real work to be getting on with so maybe another day.
Incidentally, in my pet collection of individually fixed, non-broken skins (which also have the emu:window pixel ratio set to 1:1 so apps don't look like ass - hint hint), I converted all the BMPs to be 8-bit, which saves a lot of download (more than 50% as they zip better too due to extra huffman loving) and still work fine in the emu. They don't look any more ugly than they did before either. ;-)
FL
Wot? No rant? - I must still be drunk from NYE.

[ ^^^ The forthcoming Curitel CDM1337 - 4x1 Nixie Tube display, Ferrite-Core RAM, 150Mhz ARM9 CPU]
Not a bad idea. Anonymous CVS is of course one way, if you can get your web people to set it up.
Another strictly client-side way would be a batch script using the standard 'wget'
cmdline tool (GPL'd, linux + windows builds) which goes and pulls the skin zips down. Works with HTTPS too, handily enough, and you can set it to skip files that haven't changed size or date etc.
In an effort to contribute something to this forum other than foul-mouthed complaints, I started sorting out a script to do just this but then someone very pointedly reminded me that I have more than enough real work to be getting on with so maybe another day.
Incidentally, in my pet collection of individually fixed, non-broken skins (which also have the emu:window pixel ratio set to 1:1 so apps don't look like ass - hint hint), I converted all the BMPs to be 8-bit, which saves a lot of download (more than 50% as they zip better too due to extra huffman loving) and still work fine in the emu. They don't look any more ugly than they did before either. ;-)
FL
Wot? No rant? - I must still be drunk from NYE.

with cvs/svn you get the history which you dont with a wget style script, also the chance to go back to old skins if needed.
you can already do the wget style download thats how i do it now, (i just use flashget instead), but you have to manually make sure its looking at the right pages.
professionals use asset management and source control, its just that simple.

with cvs/svn you get the history which you dont with a wget style script, also the chance to go back to old skins if needed.
you can already do the wget style download thats how i do it now, (i just use flashget instead), but you have to manually make sure its looking at the right pages.
professionals use asset management and source control, its just that simple.

Another one that I noticed back in the Spring of last year and just checked to be certain... CDM-9900. It has an on-screen size approximately (but not exactly) 1/4 the actual screen dimensions. True, it fits the picture in the skin, but us developers need 1:1 pixel accuracy when we're working on games.
The screen dimesions match those in the data sheet at 240 x 292, but the emulator skin squeezes that into 145 x 178.
I don't particularly care if the picture of the phone is perfect. If the "screen" area of the picture needs to be larger, proportionately, than the keyboard, that's fine.
(Edit: I didn't read all 4 pages before entering this on...I see it's already been mentioned...but it's still not fixed on the extranet)

Another one that I noticed back in the Spring of last year and just checked to be certain... CDM-9900. It has an on-screen size approximately (but not exactly) 1/4 the actual screen dimensions. True, it fits the picture in the skin, but us developers need 1:1 pixel accuracy when we're working on games.
The screen dimesions match those in the data sheet at 240 x 292, but the emulator skin squeezes that into 145 x 178.
I don't particularly care if the picture of the phone is perfect. If the "screen" area of the picture needs to be larger, proportionately, than the keyboard, that's fine.
(Edit: I didn't read all 4 pages before entering this on...I see it's already been mentioned...but it's still not fixed on the extranet)

As for the A530...
We did some direct bitmap munging on this one...so I can speak with some authority.
The screen is an 8-bit display, but all the in-memory bitmaps are 16 bits. It pulls the top 3-2-3 bits from Red, Green, Blue for the display.

As for the A530...
We did some direct bitmap munging on this one...so I can speak with some authority.
The screen is an 8-bit display, but all the in-memory bitmaps are 16 bits. It pulls the top 3-2-3 bits from Red, Green, Blue for the display.

Is there a version of the Nokia_xx86i.qsc emulator file that doesn't stretch the screen. It's difficult to test the graphics on the emulator since it stretches them in odd ways.
Thanks,
Mark

Is there a version of the Nokia_xx86i.qsc emulator file that doesn't stretch the screen. It's difficult to test the graphics on the emulator since it stretches them in odd ways.
Thanks,
Mark

just edit it in the skin editor

just edit it in the skin editor

The QSC file I just downloaded from https://brewx.qualcomm.com/bws/content/docx/devices/emulator/kyocera/KWC... specifies that the Kyocera SE47 device id is "5013" when the data sheet says "5037".
The QSC also states that the color depth is "8" and the data sheet specifies the color depth as "16".
Which is correct?
Thanks,
Mark

The QSC file I just downloaded from https://brewx.qualcomm.com/bws/content/docx/devices/emulator/kyocera/KWC... specifies that the Kyocera SE47 device id is "5013" when the data sheet says "5037".
The QSC also states that the color depth is "8" and the data sheet specifies the color depth as "16".
Which is correct?
Thanks,
Mark

The platform ID will change between carriers and software builds. You should not assume that it will remain static. As such, you may very well notice emulator skin platform IDs not matching up with the most recent commercial build.

The platform ID will change between carriers and software builds. You should not assume that it will remain static. As such, you may very well notice emulator skin platform IDs not matching up with the most recent commercial build.

the se47 is 16bit "ish"

the se47 is 16bit "ish"

johnse wrote:As for the A530...
We did some direct bitmap munging on this one...so I can speak with some authority.
The screen is an 8-bit display, but all the in-memory bitmaps are 16 bits. It pulls the top 3-2-3 bits from Red, Green, Blue for the display.
Can u say something about this
"Direct Bitmap Munging"
What is it exactly

johnse wrote:As for the A530...
We did some direct bitmap munging on this one...so I can speak with some authority.
The screen is an 8-bit display, but all the in-memory bitmaps are 16 bits. It pulls the top 3-2-3 bits from Red, Green, Blue for the display.
Can u say something about this
"Direct Bitmap Munging"
What is it exactly

I just downloaded the latest emulator package for the Motorola C343 and I can't load it as a device in the BREW SDK Emulator.
I get the following error "Failed to initialize the device. There may be syntax error in the phone configuration file. Please select another phone configuration file.."
It appears to be the color depth that is causing the error.
Can this be fixed? My previous copy of this emulator worked fine, except for the bitmap being kinda crappy.

I just downloaded the latest emulator package for the Motorola C343 and I can't load it as a device in the BREW SDK Emulator.
I get the following error "Failed to initialize the device. There may be syntax error in the phone configuration file. Please select another phone configuration file.."
It appears to be the color depth that is causing the error.
Can this be fixed? My previous copy of this emulator worked fine, except for the bitmap being kinda crappy.

I added a readme to the zip explaining the color depth problem.

I added a readme to the zip explaining the color depth problem.

In emulator skin file of 8600, the AVK_SOFT2 is mapped as UNDFINED.
I think it is emulator bug which has to be rectified.
regards

In emulator skin file of 8600, the AVK_SOFT2 is mapped as UNDFINED.
I think it is emulator bug which has to be rectified.
regards

AUDIOVOX 8600 EMULATOR is not launching in SIMULATOR.
It fails when we tried to launch from SIMULATOR
best regards

AUDIOVOX 8600 EMULATOR is not launching in SIMULATOR.
It fails when we tried to launch from SIMULATOR
best regards

tm_sathisha wrote:In emulator skin file of 8600, the AVK_SOFT2 is mapped as UNDFINED.
I think it is emulator bug which has to be rectified.
regards
Fixed it...

tm_sathisha wrote:In emulator skin file of 8600, the AVK_SOFT2 is mapped as UNDFINED.
I think it is emulator bug which has to be rectified.
regards
Fixed it...

The LGE PD8380 for Pelephone differs between the Data sheet and the Emulator QSC.
The Data Sheet lists it's resolution as 176x203 while the emulator is set to 172x203.

The LGE PD8380 for Pelephone differs between the Data sheet and the Emulator QSC.
The Data Sheet lists it's resolution as 176x203 while the emulator is set to 172x203.

The emulator files for the Samsung SCH-N415 are incorrect.
They specify that the key in the center of the directional pad sends the code AVK_SELECT. On the real handset it doesn't (not sure what it does send).
The emulator file also specifies that the right soft key sends the code AVK_SOFT2 when on the real phone it sends AVK_SELECT.

The emulator files for the Samsung SCH-N415 are incorrect.
They specify that the key in the center of the directional pad sends the code AVK_SELECT. On the real handset it doesn't (not sure what it does send).
The emulator file also specifies that the right soft key sends the code AVK_SOFT2 when on the real phone it sends AVK_SELECT.

Yeah...the problems with US-reviewed emulator skin verifications were mainly fixed, but then the regional offices started performing their own reviews and some mistakes got through. We've moved all the verification to one central point though, so it should be handled in the future.

Yeah...the problems with US-reviewed emulator skin verifications were mainly fixed, but then the regional offices started performing their own reviews and some mistakes got through. We've moved all the verification to one central point though, so it should be handled in the future.

I've just downloaded the samsung A790 skin and have been having problems with file creation and writing - turns out it was because the skin limited the number of files to 112. I've fixed it for my emulator, can you fix this for the emulator download page please.

I've just downloaded the samsung A790 skin and have been having problems with file creation and writing - turns out it was because the skin limited the number of files to 112. I've fixed it for my emulator, can you fix this for the emulator download page please.

The emulator files for the Samsung A790 shows the height as 202 where as the device data sheet shows this as 204.
My application is stuck at NSTL as I check the screen dimension in code when the game is running.
Can this be corrected please??

The emulator files for the Samsung A790 shows the height as 202 where as the device data sheet shows this as 204.
My application is stuck at NSTL as I check the screen dimension in code when the game is running.
Can this be corrected please??

I believe there is emulator skin defect in the KX414 emulator. The QSC file specifies a screen resolution of 104x68. This matches the data sheet, however the data sheet also specifies that 12 of those pixels are reserved for annunciators. Which means it should have an effective resolution of 104x56.

I believe there is emulator skin defect in the KX414 emulator. The QSC file specifies a screen resolution of 104x68. This matches the data sheet, however the data sheet also specifies that 12 of those pixels are reserved for annunciators. Which means it should have an effective resolution of 104x56.

The V810 emulator skin has three keys that are undefined in the emulator. I would guess that they are SOFT1, MENU and SOFT2. Can the emulator files be updated please?

The V810 emulator skin has three keys that are undefined in the emulator. I would guess that they are SOFT1, MENU and SOFT2. Can the emulator files be updated please?

Just a FYI so you can fix it if you want: The LG MX500 skin has incorrect height, width, and bitdepth. (at this time it's showing as 177X207 8bit which is incorrect)

Just a FYI so you can fix it if you want: The LG MX500 skin has incorrect height, width, and bitdepth. (at this time it's showing as 177X207 8bit which is incorrect)

The Moto V325 and V3C skins have the incorrect screen sizes and bit depths. Also the V325 screen isn't centered in the bitmap correctly.
And it would be nice if these skins included a secondary display.
-Erik

The Moto V325 and V3C skins have the incorrect screen sizes and bit depths. Also the V325 screen isn't centered in the bitmap correctly.
And it would be nice if these skins included a secondary display.
-Erik

They will never learn, I suppose. No matter how much you rattle the cage, Qualcomm just doesn't get their act together when it comes to these emu skins.

They will never learn, I suppose. No matter how much you rattle the cage, Qualcomm just doesn't get their act together when it comes to these emu skins.

There are certain device skin issues for the folowing handsets:
1] KX16:
pixels/row = 151
pixels/column = 157
According to DDS it has to be :
pixels/row = 128
pixels/column = 116
2] Motorola V3C :
pixels/row = 171
pixels/column = 218
Width= 176
height = 220
color depth= 8
According to DDS it has to be :
pixels/row = 176
pixels/column = 204
Width= 176
height = 204
color depth= 16
3] Motorola V325 :
pixels/row = 127
pixels/column = 209
color depth= 8;
According to DDS it has to be :
pixels/row = 176
pixels/column = 204
color depth= 16;
Will NSTL make these changes in the Device skins using the device configurator before they test our application on the emulator?If they do not, Will our application fail TBT since our application did not open in these faulty emulators?
It would be good if qualcom could test the emulator skins before posting them on the extranet to avoid such queries from developers .
regards,
Smita

There are certain device skin issues for the folowing handsets:
1] KX16:
pixels/row = 151
pixels/column = 157
According to DDS it has to be :
pixels/row = 128
pixels/column = 116
2] Motorola V3C :
pixels/row = 171
pixels/column = 218
Width= 176
height = 220
color depth= 8
According to DDS it has to be :
pixels/row = 176
pixels/column = 204
Width= 176
height = 204
color depth= 16
3] Motorola V325 :
pixels/row = 127
pixels/column = 209
color depth= 8;
According to DDS it has to be :
pixels/row = 176
pixels/column = 204
color depth= 16;
Will NSTL make these changes in the Device skins using the device configurator before they test our application on the emulator?If they do not, Will our application fail TBT since our application did not open in these faulty emulators?
It would be good if qualcom could test the emulator skins before posting them on the extranet to avoid such queries from developers .
regards,
Smita

The skin and details you have on your site on the kx13 show a different cellphone than the one kayocera is showing as the kx13.
Here is a link to your data sheet
https://brewx.qualcomm.com/bws/content/docx/devices/datasheets/kyocera/K...
and here are some links to pages containing info on the real kx13
http://www.kyocera-wireless.com/dorado-phone/support.htm
http://mobilewhack.com/reviews/2005/06/kyocera_kx13_ce.html
http://www.phonescoop.com/phones/phone.php?p=756
Please fix this thing and provide us with a kx13 emulator
10x
Roi

The skin and details you have on your site on the kx13 show a different cellphone than the one kayocera is showing as the kx13.
Here is a link to your data sheet
https://brewx.qualcomm.com/bws/content/docx/devices/datasheets/kyocera/K...
and here are some links to pages containing info on the real kx13
http://www.kyocera-wireless.com/dorado-phone/support.htm
http://mobilewhack.com/reviews/2005/06/kyocera_kx13_ce.html
http://www.phonescoop.com/phones/phone.php?p=756
Please fix this thing and provide us with a kx13 emulator
10x
Roi

"It would be good if qualcom could test the emulator skins before posting them on the extranet to avoid such queries from developers ."
...y'know... there.... might... just.. be.... the germ of an an idea there somewhere... I think we should suggest it to the proper authorities.
...Maybe they'd take notice!
P.S. No, but seriously, happy christmas Qualcomm Support People - we'd rather have you here than not here. Thanks!

"It would be good if qualcom could test the emulator skins before posting them on the extranet to avoid such queries from developers ."
...y'know... there.... might... just.. be.... the germ of an an idea there somewhere... I think we should suggest it to the proper authorities.
...Maybe they'd take notice!
P.S. No, but seriously, happy christmas Qualcomm Support People - we'd rather have you here than not here. Thanks!

Roi wrote:The skin and details you have on your site on the kx13 show a different cellphone than the one kayocera is showing as the kx13.
Here is a link to your data sheet
https://brewx.qualcomm.com/bws/content/docx/devices/datasheets/kyocera/K...
and here are some links to pages containing info on the real kx13
http://www.kyocera-wireless.com/dorado-phone/support.htm
http://mobilewhack.com/reviews/2005/06/kyocera_kx13_ce.html
http://www.phonescoop.com/phones/phone.php?p=756
Please fix this thing and provide us with a kx13 emulator
10x
Roi
It has been a month and a half and still nothing has changed.
BREW support, please fix this thing.

Roi wrote:The skin and details you have on your site on the kx13 show a different cellphone than the one kayocera is showing as the kx13.
Here is a link to your data sheet
https://brewx.qualcomm.com/bws/content/docx/devices/datasheets/kyocera/K...
and here are some links to pages containing info on the real kx13
http://www.kyocera-wireless.com/dorado-phone/support.htm
http://mobilewhack.com/reviews/2005/06/kyocera_kx13_ce.html
http://www.phonescoop.com/phones/phone.php?p=756
Please fix this thing and provide us with a kx13 emulator
10x
Roi
It has been a month and a half and still nothing has changed.
BREW support, please fix this thing.

The prior post indicated an issue with the KX16. I just downloaded the skin today and the skin appears to still be reporting incorrect data.
Also, a while back Dragon indicated the skin for N330 was broken. Again, downloaded it today and it still reports a different PID than is in the DDS.
Since both of these phones are pre-production, how do I know what the actual data should be? Are the DDSs correct?
The DDS for the N330 lists the PID as 2135, but the skin says 2082. Which is correct?
Are there any master lists of Carrier / Phone / PID that I can download? I have found a 'parent' 'child' list of some PIDs, but it doesn't appear to indicate Carrier relationships and Max has indicated there is a dependency there.
Thanks,

The prior post indicated an issue with the KX16. I just downloaded the skin today and the skin appears to still be reporting incorrect data.
Also, a while back Dragon indicated the skin for N330 was broken. Again, downloaded it today and it still reports a different PID than is in the DDS.
Since both of these phones are pre-production, how do I know what the actual data should be? Are the DDSs correct?
The DDS for the N330 lists the PID as 2135, but the skin says 2082. Which is correct?
Are there any master lists of Carrier / Phone / PID that I can download? I have found a 'parent' 'child' list of some PIDs, but it doesn't appear to indicate Carrier relationships and Max has indicated there is a dependency there.
Thanks,

Roi wrote:It has been a month and a half and still nothing has changed.
BREW support, please fix this thing.
I've sent a request to have the image updated.

Roi wrote:It has been a month and a half and still nothing has changed.
BREW support, please fix this thing.
I've sent a request to have the image updated.

The PID on the skin will likely be the first commercial PID. The DDS should display the most recent PID that has been reviewed by QUALCOMM.
When the BREW Device Database is made available, you will be able to see a comprehensive listing of PIDs for given devices.

The PID on the skin will likely be the first commercial PID. The DDS should display the most recent PID that has been reviewed by QUALCOMM.
When the BREW Device Database is made available, you will be able to see a comprehensive listing of PIDs for given devices.

Max,
Thanks. Quick follow up, when is the BREW Device Database going to be released? Definitely would be a handy tool.

Max,
Thanks. Quick follow up, when is the BREW Device Database going to be released? Definitely would be a handy tool.

I can't give a date offhand, but hopefully soon...

I can't give a date offhand, but hopefully soon...

Hi, in the app the cyScreen reports 133 px and it should have 132.
r1

Hi, in the app the cyScreen reports 133 px and it should have 132.
r1

This skin doesn't even open... it says that the configuration file has an error... can you fix this? please...
r1

This skin doesn't even open... it says that the configuration file has an error... can you fix this? please...
r1

A skin for LG VX-9800 with QWERTY keyboard working on the emulator ???
As for the various problems with skins, just try to edit the skin and check the memory . Though, it will be nice just to download them and use them with no modific.

A skin for LG VX-9800 with QWERTY keyboard working on the emulator ???
As for the various problems with skins, just try to edit the skin and check the memory . Though, it will be nice just to download them and use them with no modific.

editing the skins is one thing, but realise NSTL uses the skins as is.

editing the skins is one thing, but realise NSTL uses the skins as is.

ooops .. that is stupid ... I remember that the CDM-8600 had a soft button that didn't work... Or other skins that had little memory an the applications would not start and many other problems... Using them "as is" is not a good thing :(
I repeat the question :
Can the LG-VX-9800 skin be made in such way that the QWERTY keys would work on the emulator ???...

ooops .. that is stupid ... I remember that the CDM-8600 had a soft button that didn't work... Or other skins that had little memory an the applications would not start and many other problems... Using them "as is" is not a good thing :(
I repeat the question :
Can the LG-VX-9800 skin be made in such way that the QWERTY keys would work on the emulator ???...

zuma wrote:A skin for LG VX-9800 with QWERTY keyboard working on the emulator ???
.
Managed to make some keys to work by editing the skin ... A noticed that the emulator receives the event of the "A" key when I press the "A' key on the keyboard but it does not display it ... Are we getting close to use the keyboard soon ???

zuma wrote:A skin for LG VX-9800 with QWERTY keyboard working on the emulator ???
.
Managed to make some keys to work by editing the skin ... A noticed that the emulator receives the event of the "A" key when I press the "A' key on the keyboard but it does not display it ... Are we getting close to use the keyboard soon ???

Hi,
Every1 i am getting an unusual problem of emulator crash.
The problem is dat when i try to launch n emulator from VC++ it crashes and gives an error that unable to run...when i tried to debug then i found dat its giving an error of access violation...because of this i need to install whole SDK again...as i am using 2.0 version,and it takes 30-45 minutes to install this sdk...cn nybody tell me wht exactly d problem is?as my work goes on halt for this...and it happens mostly when i am dealing with KX414 emulator...
Pleez let me know if ny1 know regarding ths issue..
Thnx..

Hi,
Every1 i am getting an unusual problem of emulator crash.
The problem is dat when i try to launch n emulator from VC++ it crashes and gives an error that unable to run...when i tried to debug then i found dat its giving an error of access violation...because of this i need to install whole SDK again...as i am using 2.0 version,and it takes 30-45 minutes to install this sdk...cn nybody tell me wht exactly d problem is?as my work goes on halt for this...and it happens mostly when i am dealing with KX414 emulator...
Pleez let me know if ny1 know regarding ths issue..
Thnx..

not getting exactly wat ur problem is be more specific about it so can be helpful to answer...
deepti.p wrote:because of this i need to install whole SDK again...as i am using 2.0 version,and it takes 30-45 minutes to install this sdk...cn nybody tell me wht exactly d problem is?
so is it da case dat when u install all of a new its all fine, if so when does dat happens??

not getting exactly wat ur problem is be more specific about it so can be helpful to answer...
deepti.p wrote:because of this i need to install whole SDK again...as i am using 2.0 version,and it takes 30-45 minutes to install this sdk...cn nybody tell me wht exactly d problem is?
so is it da case dat when u install all of a new its all fine, if so when does dat happens??

Hi,
first of al thnx manju for relying...
my emulator gets crashed when i change applet directory or change to ny other emulator...and once it gives the error i cant run emulator further...so to work on my application i need to launch sdk n yes aftr dat it wrks fine...actually i checked d error
when i get dat dont send error window so its stating dat its windoes problem bt i donno d reason...n when i try to run i get this error BREW_Emulator.exe: 0xC0000005: Access Violation.
Thnx..

Hi,
first of al thnx manju for relying...
my emulator gets crashed when i change applet directory or change to ny other emulator...and once it gives the error i cant run emulator further...so to work on my application i need to launch sdk n yes aftr dat it wrks fine...actually i checked d error
when i get dat dont send error window so its stating dat its windoes problem bt i donno d reason...n when i try to run i get this error BREW_Emulator.exe: 0xC0000005: Access Violation.
Thnx..

deepti.p wrote:Hi,
first of al thnx manju for relying...
Manju & deepti
please continue this discussion in
emulator dll
http://brewforums.qualcomm.com/showthread.php?t=17330

deepti.p wrote:Hi,
first of al thnx manju for relying...
Manju & deepti
please continue this discussion in
emulator dll
http://brewforums.qualcomm.com/showthread.php?t=17330