Lay out problems on Z22

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Lay out problems on Z22

Morten Agerlin Petersen (MAP)
Hi

I've been using Plua 2 with pleasure on my old Palm Zire.

Now I've got a new Z22 (Palm OS Garnet v. 5.4.9) and all the screen
layouts in my programs are scrambled (I've tried both Plua 2b4 and
2b7).

A simple test program like this:

-- Write.lua
screen.clear()
io.write("text1")
io.write("text2")
gui.event()

writes the text "textext2" on the screen. Could it be some error on
font size?

I get the same output even if change the font with screen.font(xx).

:-(

Morten


Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

migueletto
Hi,

> Now I've got a new Z22 (Palm OS Garnet v. 5.4.9) and all the screen
> layouts in my programs are scrambled (I've tried both Plua 2b4 and
> 2b7).

Can you tell me what values are returned by these calls ?

1) screen.mode()
2) screen.textsize("a")
3) screen.font(0)

Regards,
Marcio.


Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

Morten Agerlin Petersen (MAP)
--- In [hidden email], "migueletto" <mmand@...> wrote:

>
> Hi,
>
> > Now I've got a new Z22 (Palm OS Garnet v. 5.4.9) and all the screen
> > layouts in my programs are scrambled (I've tried both Plua 2b4 and
> > 2b7).
>
> Can you tell me what values are returned by these calls ?
>
> 1) screen.mode()
> 2) screen.textsize("a")
> 3) screen.font(0)
>
> Regards,
> Marcio.
>

Hi thanks for your interest in my problem :-)

Strange enough screen.mode() returns 320 320 16 1 while www.palm.com
says "color screen 160x160" in the specs for Z22? That might by the
problem?

screen.textsize("a") returns 5 and 22
screen.font(0)returns 10 and 22

Regards Morten







 


Reply | Threaded
Open this post in threaded view
|

Re: Re: Lay out problems on Z22

Kevin Horton

On 16 Nov 2006, at 08:05, m_agerlin wrote:

> --- In [hidden email], "migueletto" <mmand@...> wrote:
>>
>> Hi,
>>
>>> Now I've got a new Z22 (Palm OS Garnet v. 5.4.9) and all the screen
>>> layouts in my programs are scrambled (I've tried both Plua 2b4 and
>>> 2b7).
>>
>> Can you tell me what values are returned by these calls ?
>>
>> 1) screen.mode()
>> 2) screen.textsize("a")
>> 3) screen.font(0)
>>
>> Regards,
>> Marcio.
>>
>
> Hi thanks for your interest in my problem :-)
>
> Strange enough screen.mode() returns 320 320 16 1 while www.palm.com
> says "color screen 160x160" in the specs for Z22? That might by the
> problem?
>
> screen.textsize("a") returns 5 and 22
> screen.font(0)returns 10 and 22
>
> Regards Morten
>
>
>
>
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>

Kevin Horton
Ottawa, Canada


Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

migueletto
In reply to this post by Morten Agerlin Petersen (MAP)
Hi,

> Hi thanks for your interest in my problem :-)
>
> Strange enough screen.mode() returns 320 320 16 1 while www.palm.com
> says "color screen 160x160" in the specs for Z22? That might by the
> problem?
>
> screen.textsize("a") returns 5 and 22
> screen.font(0)returns 10 and 22

I have uploaded to the Plua directory in the Files section two files:
ScreenLib.prc and ScreenTest.prc. I would like to ask owners of Zire
22 and Zire 31 to install them and run the application. It will run 9
tests and show some values. Please write them down and post the
results  here. I hope the results will help me identifying the problem.

PS: the application is really simple and should cause no problem, but
the usual words of warning apply.

Regards,
Marcio.


Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

ygfz4v902
Zire 31, OS 5.2.8, Plua 2.0b7:
The data below is displayed:
Test 1:   5    2    8
Test 2:   0    4    true
Test 3:   160    160
Test 4:   320    320
Test 5:   160    160   8   true
Test 6:   320    320   8   true
Test 7:   5    5    11
Test 8:   10    10    22
Test 9:   32907
Then I tapped the screen, and got a completely messed-up pattern (like
when you give Linux the wrong monitor specs) and the Palm locked up.
Soft reset brought it back.

--- In [hidden email], "migueletto" <mmand@...> wrote:

>
> Hi,
>
> > Hi thanks for your interest in my problem :-)
> >
> > Strange enough screen.mode() returns 320 320 16 1 while www.palm.com
> > says "color screen 160x160" in the specs for Z22? That might by the
> > problem?
> >
> > screen.textsize("a") returns 5 and 22
> > screen.font(0)returns 10 and 22
>
> I have uploaded to the Plua directory in the Files section two files:
> ScreenLib.prc and ScreenTest.prc. I would like to ask owners of Zire
> 22 and Zire 31 to install them and run the application. It will run 9
> tests and show some values. Please write them down and post the
> results  here. I hope the results will help me identifying the problem.
>
> PS: the application is really simple and should cause no problem, but
> the usual words of warning apply.
>
> Regards,
> Marcio.
>



Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

migueletto
Hi,

> Zire 31, OS 5.2.8, Plua 2.0b7:
> The data below is displayed:
> Test 1:   5    2    8
> Test 2:   0    4    true
> Test 3:   160    160
> Test 4:   320    320
> Test 5:   160    160   8   true
> Test 6:   320    320   8   true
> Test 7:   5    5    11
> Test 8:   10    10    22
> Test 9:   32907

Thanks for your report. What the numbers show is strange. Palm
specifications says Zire 31 has a resolution of 160x160 pixels and a
depth of 12bpp, or 4096 colors. PalmOS API calls say that the display
supports 320x320 (if set up in high density mode) and 16bpp, or 65536
colors, although is was set up to use 8 bits colors at the moment.

The program output (aside from the OS version in test 1) is exactly
the same for a Tungsten-C, which is 320x320 and 16bpp. So which one is
correct ???

Another test you can perform: if you set a single pixel on column 319
and another single pixel on column 318, do you actually see two
separate pixels on the right edge of the screen ?

One more thing: do you confirm that the output of screen.mode() is
"320 320 16 1" ?

> Then I tapped the screen, and got a completely messed-up pattern (like
> when you give Linux the wrong monitor specs) and the Palm locked up.
> Soft reset brought it back.

This is actually a problem with Plua 2.0b7. I hope I have fixed it now.

Regards,
Marcio.


Reply | Threaded
Open this post in threaded view
|

Re: Re: Lay out problems on Z22

David Elliott-3
Just out of curiosity, could you tell us what the tests below are testing?

  ----- Original Message -----
  From: migueletto
  To: [hidden email]
  Sent: Sunday, November 19, 2006 3:34 AM
  Subject: [plua] Re: Lay out problems on Z22


  Hi,

  > Zire 31, OS 5.2.8, Plua 2.0b7:
  > The data below is displayed:
  > Test 1: 5 2 8
  > Test 2: 0 4 true
  > Test 3: 160 160
  > Test 4: 320 320
  > Test 5: 160 160 8 true
  > Test 6: 320 320 8 true
  > Test 7: 5 5 11
  > Test 8: 10 10 22
  > Test 9: 32907

  Thanks for your report. What the numbers show is strange. Palm
  specifications says Zire 31 has a resolution of 160x160 pixels and a
  depth of 12bpp, or 4096 colors. PalmOS API calls say that the display
  supports 320x320 (if set up in high density mode) and 16bpp, or 65536
  colors, although is was set up to use 8 bits colors at the moment.

  The program output (aside from the OS version in test 1) is exactly
  the same for a Tungsten-C, which is 320x320 and 16bpp. So which one is
  correct ???

  Another test you can perform: if you set a single pixel on column 319
  and another single pixel on column 318, do you actually see two
  separate pixels on the right edge of the screen ?

  One more thing: do you confirm that the output of screen.mode() is
  "320 320 16 1" ?

  > Then I tapped the screen, and got a completely messed-up pattern (like
  > when you give Linux the wrong monitor specs) and the Palm locked up.
  > Soft reset brought it back.

  This is actually a problem with Plua 2.0b7. I hope I have fixed it now.

  Regards,
  Marcio.



   

[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

migueletto
Hi,

> Just out of curiosity, could you tell us what the tests below are
testing?

They test the return values of various screen related PalmOS API
functions, like WinGetDisplayExtent(),
WinScreenMode(winScreenModeGet),
WinScreenMode(winScreenModeGetSupportedDepths), FntCharsWidth(),
FntCharWidth() and FntCharHeight(), both in standard density mode and
high density mode (if supported).

Regards,
Marcio.


Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

rob cranfill
In reply to this post by migueletto
I have a Z22 (Plua 2.0b7, Palm OS Garnet 5.4.9) and got the following:

Test 1 5 4 9
Test 2 0 5 true
Test 3 160 160
Test 4 320 320
Test 5 160 160 16 true
Test 6 320 320 16 true
Test 7 5 5 511
Test 8 5 10 22
Test 9 32907

(Although there is something a little wrong with output even from that
program and it actually looks like this:

Test 15 4 9
Test 20 5 true
Test 3160 160
Test 4320 320
Test 5160 160 16 true
Test 6320 320 16 true
Test 75 5 511
Test 85 10 22
Test 932907

But I'm guessing there should be a space after the first numbers.
)

Thanks for your efforts!

   - rob



--- In [hidden email], "migueletto" <mmand@...> wrote:

>
> I have uploaded to the Plua directory in the Files section two files:
> ScreenLib.prc and ScreenTest.prc. I would like to ask owners of Zire
> 22 and Zire 31 to install them and run the application. It will run 9
> tests and show some values. Please write them down and post the
> results  here. I hope the results will help me identifying the problem.
>
> PS: the application is really simple and should cause no problem, but
> the usual words of warning apply.
>
> Regards,
> Marcio.
>



Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

ygfz4v902
In reply to this post by migueletto
I ran this program:

-- fill.lua
screen.moveto(0, 50)
print('mode = ' .. screen.mode())
screen.set(318, 50)
screen.set(319, 50)
screen.moveto(0, 75) -- I guess screen.set() moves the cursor
print('(317, 50) = ' .. screen.get(317, 50))
print('(318, 50) = ' .. screen.get(318, 50))
print('(319, 50) = ' .. screen.get(319, 50))
gui.event()

And the output is:
320 320 16 1
(317, 50) = 16777215
(318, 50) = 0
(319, 50) = 0
<b>I only see one black pixel, and it is one pixel from the right edge
of the screen.</b>
[of course, 16777215 = 0xFFFFFF = rgb(255, 255, 255) = white]

--- In [hidden email], "migueletto" <mmand@...> wrote:

>
> Hi,
>
> > Zire 31, OS 5.2.8, Plua 2.0b7:
> > The data below is displayed:
> > Test 1:   5    2    8
> > Test 2:   0    4    true
> > Test 3:   160    160
> > Test 4:   320    320
> > Test 5:   160    160   8   true
> > Test 6:   320    320   8   true
> > Test 7:   5    5    11
> > Test 8:   10    10    22
> > Test 9:   32907
>
> Thanks for your report. What the numbers show is strange. Palm
> specifications says Zire 31 has a resolution of 160x160 pixels and a
> depth of 12bpp, or 4096 colors. PalmOS API calls say that the display
> supports 320x320 (if set up in high density mode) and 16bpp, or 65536
> colors, although is was set up to use 8 bits colors at the moment.
>
> The program output (aside from the OS version in test 1) is exactly
> the same for a Tungsten-C, which is 320x320 and 16bpp. So which one is
> correct ???
>
> Another test you can perform: if you set a single pixel on column 319
> and another single pixel on column 318, do you actually see two
> separate pixels on the right edge of the screen ?
>
> One more thing: do you confirm that the output of screen.mode() is
> "320 320 16 1" ?
>
> > Then I tapped the screen, and got a completely messed-up pattern (like
> > when you give Linux the wrong monitor specs) and the Palm locked up.
> > Soft reset brought it back.
>
> This is actually a problem with Plua 2.0b7. I hope I have fixed it now.
>
> Regards,
> Marcio.
>



Reply | Threaded
Open this post in threaded view
|

Re: Re: Lay out problems on Z22

David Elliott-3
In reply to this post by migueletto
I was really looking for a line-by-line rundown of the calls. I guess I should have been more specific. It's not really that important, though it does sound like there is some potential for other applications to break. I've seen a few video drivers that report capabilities wrong, and they require workarounds.

  ----- Original Message -----
  From: migueletto
  To: [hidden email]
  Sent: Sunday, November 19, 2006 9:25 AM
  Subject: [plua] Re: Lay out problems on Z22


  Hi,

  > Just out of curiosity, could you tell us what the tests below are
  testing?

  They test the return values of various screen related PalmOS API
  functions, like WinGetDisplayExtent(),
  WinScreenMode(winScreenModeGet),
  WinScreenMode(winScreenModeGetSupportedDepths), FntCharsWidth(),
  FntCharWidth() and FntCharHeight(), both in standard density mode and
  high density mode (if supported).

  Regards,
  Marcio.



   

[Non-text portions of this message have been removed]

Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

migueletto
In reply to this post by ygfz4v902
Hi,

> -- fill.lua
> screen.moveto(0, 50)
> print('mode = ' .. screen.mode())
> screen.set(318, 50)
> screen.set(319, 50)
> screen.moveto(0, 75) -- I guess screen.set() moves the cursor
> print('(317, 50) = ' .. screen.get(317, 50))
> print('(318, 50) = ' .. screen.get(318, 50))
> print('(319, 50) = ' .. screen.get(319, 50))
> gui.event()
>
> And the output is:
> 320 320 16 1
> (317, 50) = 16777215
> (318, 50) = 0
> (319, 50) = 0
> I only see one black pixel, and it is one pixel from the right edge
> of the screen.

So it seems that the device allows you to address 320x320 pixel
coordinates, although it has only 160x160 real pixels (it must map
four pixel coordinates into one real pixel internally). Since PalmOS
says that the display supports 320x320, it is a bit confusing for
applications to know exactly what is going on (Tungsten-C also
advertises support for 160x160 and 320x320 modes, but in the latter
all pixels are real).

This may be that reason screen.fill() is failing, because painting one
pixel actually paints four neighboring pixels and Plua thinks the
painting area has reached the border.

Regards,
Marcio.


Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

Morten Agerlin Petersen (MAP)
In reply to this post by rob cranfill
I get exactly the same output on my Z22

Regards Morten


--- In [hidden email], "rob cranfill" <robcranfill@...> wrote:
>
> I have a Z22 (Plua 2.0b7, Palm OS Garnet 5.4.9) and got the
following:

>
> Test 1 5 4 9
> Test 2 0 5 true
> Test 3 160 160
> Test 4 320 320
> Test 5 160 160 16 true
> Test 6 320 320 16 true
> Test 7 5 5 511
> Test 8 5 10 22
> Test 9 32907
>
> (Although there is something a little wrong with output even from
that

> program and it actually looks like this:
>
> Test 15 4 9
> Test 20 5 true
> Test 3160 160
> Test 4320 320
> Test 5160 160 16 true
> Test 6320 320 16 true
> Test 75 5 511
> Test 85 10 22
> Test 932907
>
> But I'm guessing there should be a space after the first numbers.
> )
>
> Thanks for your efforts!
>
>    - rob
>
>
>
> --- In [hidden email], "migueletto" <mmand@> wrote:
>
> >
> > I have uploaded to the Plua directory in the Files section two
files:
> > ScreenLib.prc and ScreenTest.prc. I would like to ask owners of
Zire
> > 22 and Zire 31 to install them and run the application. It will
run 9
> > tests and show some values. Please write them down and post the
> > results  here. I hope the results will help me identifying the
problem.
> >
> > PS: the application is really simple and should cause no
problem, but
> > the usual words of warning apply.
> >
> > Regards,
> > Marcio.
> >
>



Reply | Threaded
Open this post in threaded view
|

Re: Lay out problems on Z22

bjpitre
In reply to this post by migueletto
--- In [hidden email], "migueletto" <mmand@...> wrote:

>
> Hi,
>
> > -- fill.lua
> > screen.moveto(0, 50)
> > print('mode = ' .. screen.mode())
> > screen.set(318, 50)
> > screen.set(319, 50)
> > screen.moveto(0, 75) -- I guess screen.set() moves the cursor
> > print('(317, 50) = ' .. screen.get(317, 50))
> > print('(318, 50) = ' .. screen.get(318, 50))
> > print('(319, 50) = ' .. screen.get(319, 50))
> > gui.event()
> >
> > And the output is:
> > 320 320 16 1
> > (317, 50) = 16777215
> > (318, 50) = 0
> > (319, 50) = 0
> > I only see one black pixel, and it is one pixel from the right
edge

> > of the screen.
>
> So it seems that the device allows you to address 320x320 pixel
> coordinates, although it has only 160x160 real pixels (it must map
> four pixel coordinates into one real pixel internally). Since PalmOS
> says that the display supports 320x320, it is a bit confusing for
> applications to know exactly what is going on (Tungsten-C also
> advertises support for 160x160 and 320x320 modes, but in the latter
> all pixels are real).
>
> This may be that reason screen.fill() is failing, because painting
one
> pixel actually paints four neighboring pixels and Plua thinks the
> painting area has reached the border.
>
> Regards,
> Marcio.
>

Marcio,

Nice theory. What's odd is that the screen.set() sets just one pixel
and not four like the screen.fill(). Using the screen.get and
screen.set, I imagine that someone could write a very slow 'fill'
function to do screen.fill's job.

Thanks,
--
Bill