Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #153 > unrolled thread

Weird scaling bug - any ideas ?

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Weird scaling bug - any ideas ? Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-05 12:28 -0700
    Re: Weird scaling bug - any ideas ? Martin Wuerthner <spamtrap@mw-software.com> - 2011-04-05 21:59 +0200
      Re: Weird scaling bug - any ideas ? Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-05 17:30 -0700
        Re: Weird scaling bug - any ideas ? Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-04-06 05:23 +0200
          Re: Weird scaling bug - any ideas ? Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-06 02:23 -0700
            Re: Weird scaling bug - any ideas ? Martin <News03@avisoft.f9.co.uk> - 2011-04-06 10:53 +0100
              Re: Weird scaling bug - any ideas ? Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-06 03:59 -0700
                Re: Weird scaling bug - any ideas ? Martin Wuerthner <spamtrap@mw-software.com> - 2011-04-06 14:50 +0200
                  Re: Weird scaling bug - any ideas ? Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-06 09:31 -0700
                    Re: Weird scaling bug - any ideas ? Steve Fryatt <news@stevefryatt.org.uk> - 2011-04-06 18:19 +0100
                    Re: Weird scaling bug - any ideas ? Martin Wuerthner <spamtrap@mw-software.com> - 2011-04-07 13:14 +0200
                      Re: Weird scaling bug - any ideas ? Martin Hansen <mhh@shrewsbury.org.uk> - 2011-04-07 09:49 -0700
            Re: Weird scaling bug - any ideas ? Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-04-06 14:23 +0200
            Re: Weird scaling bug - any ideas ? Steve Fryatt <news@stevefryatt.org.uk> - 2011-04-06 18:20 +0100
    Re: Weird scaling bug - any ideas ? Gerph <gerph@gerph.org> - 2011-04-09 05:06 -0700

#153 — Weird scaling bug - any ideas ?

Dear All,
I'm trying to get to the bottom of a long standing bug in one of my
programs.
I'll describe the symptoms...
From a clean start I open an !Edit window, and type in some stuff.
I launch the program that contains the bug.
With it on the Icon bar, all is well.
I open a window containing a sprite.
The text in the !Edit window (if I refresh it by dragging a window
over it) is now half size.
On the one hand, this is trivial, on the other, it means there is
something about my
program I don't understand, and it's bound to cause other problems a
have not
unearthed yet.
For a long time I wondered if I'd not reserved enough memory for
something but I now
I suspect some sort of scaling issue.
Any ideas ?
I'm happy to experiment to try and get to the bottom of this.
Regards,
Martin.

http://www.MathMagical.co.uk
http://www.RISCOScode.com

[toc] | [next] | [standalone]

#154

In message <31efb046-01a1-4bb9-a833-d897cf321997@r14g2000vbm.googlegro 
ups.com>
          Martin Hansen <mhh@shrewsbury.org.uk> wrote:

> Dear All,
> I'm trying to get to the bottom of a long standing bug in one of my
> programs.
> I'll describe the symptoms...
> From a clean start I open an !Edit window, and type in some stuff.
> I launch the program that contains the bug.
> With it on the Icon bar, all is well.
> I open a window containing a sprite.
> The text in the !Edit window (if I refresh it by dragging a window
> over it) is now half size.
> On the one hand, this is trivial, on the other, it means there is
> something about my program I don't understand, and it's bound to cause
> other problems a have not
> unearthed yet.

That sounds like your program upsets the VDU system. Are you using any 
VDU calls in your program? How do you plot the sprite?

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#156

On Apr 5, 8:59 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
> That sounds like your program upsets the VDU system. Are you using any
> VDU calls in your program? How do you plot the sprite?
> Martin

I'm using OS_SpriteOp calls, but I think you may be right.
Following your thought, I've isolated the bug to a volume control
window
which contains a sprite 'vblue'.

In a user sprite area, usa2%, I have various sprites labled v80, v75,
v70 etc
and one called vblue whos address is stored in vblue%.
These sprites are for the various volume barlengths and the idea
is to write the sprite for the volume selected by the user into vblue
and
let RISC OS then display it in the window.

All is OK until the moment I click on the icon that causes the sprite
in the window, vblue, to be updated.

Here is my procedure to put the sprite of the correct barlength into
vblue, and
hence into the display.
(All the sprite are of identical size, colour depth etc)

DEF PROCputvolume(barlength%)
LOCAL more%, partial%
scrap%!0 = WHvolume%
scrap%!4 = 140
scrap%!8 = -88
scrap%!12 = 541
scrap%!16 = -71
SYS "Wimp_UpdateWindow",0,scrap% TO more%
WHILE more%
SYS "OS_SpriteOp", 512+60, usa2%, vblue%, 0 TO , , partial%
$scof% = "v"+STR$(5*(barlength%+1)
SYS "OS_SpriteOp", 256+24, usa2%, scof% TO , , addscof%
SYS "OS_SpriteOp", 512+28, usa2%, addscof%
SYS "OS_SpriteOp", 512+60, usa2%, partial%, 0
SYS "Wimp_GetRectangle", 0, scrap% TO more%
ENDWHILE
ENDPROC

scof = sprite currently of focus
WHvolume% is Window Handle of volume window.

This does what it should, and the display updates instantly, but
is it also the source of the weird bug ?

I'm still unable to see what is going wrong.
Regards,
Martin.

[toc] | [prev] | [next] | [standalone]

#157

On 06/04/2011 02:30, Martin Hansen wrote:

> SYS "Wimp_UpdateWindow",0,scrap% TO more%
> WHILE more%
> SYS "OS_SpriteOp", 512+60, usa2%, vblue%, 0 TO , , partial%
Switch output to sprite area.
> $scof% = "v"+STR$(5*(barlength%+1)
> SYS "OS_SpriteOp", 256+24, usa2%, scof% TO , , addscof%
Get address of sprite.
> SYS "OS_SpriteOp", 512+28, usa2%, addscof%
Put sprite at graphics cursor point (presumably in the sprite area?).
> SYS "OS_SpriteOp", 512+60, usa2%, partial%, 0
512+60? What are you trying to do here?
This would indicate that you are switching the output to be directed to 
a new sprite area - one pointed to by partial% in sprite area use2%.

> SYS "Wimp_GetRectangle", 0, scrap% TO more%
Eeks!

You appear to be missing:
1. Switch output back to the display as per normal.
2. Plot the sprite into the window for the redraw op.

> ENDWHILE


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#158

On Apr 6, 4:23 am, Rick Murray <heyrickmail-use...@yahoo.co.uk> wrote:
> On 06/04/2011 02:30, Martin Hansen wrote:
>
> > SYS "Wimp_UpdateWindow",0,scrap% TO more%
> > WHILE more%
> > SYS "OS_SpriteOp", 512+60, usa2%, vblue%, 0 TO , , partial%
>
> Switch output to sprite area.> $scof% = "v"+STR$(5*(barlength%+1)
> > SYS "OS_SpriteOp", 256+24, usa2%, scof% TO , , addscof%
>
> Get address of sprite.
> SYS "OS_SpriteOp", 512+28, usa2%, addscof%
>
> Put sprite at graphics cursor point (presumably in the sprite area?).> SYS "OS_SpriteOp", 512+60, usa2%, partial%, 0
>
> 512+60? What are you trying to do here?
> This would indicate that you are switching the output to be directed to
> a new sprite area - one pointed to by partial% in sprite area use2%.
>
> > SYS "Wimp_GetRectangle", 0, scrap% TO more%
>
> Eeks!
>
> You appear to be missing:
> 1. Switch output back to the display as per normal.
> 2. Plot the sprite into the window for the redraw op.
>
> > ENDWHILE
>
> Best wishes,
>
> Rick.

Dear Rick,
Yes, I was reading the programmers reference
manual, volume 1 on each of these steps last
night (at about 3am) and thinking that this is
definitely where the problem is.
I think when I concocted this, I was just trying
things until I got something that seemed to work.
(the "engineer's" approach, I guess)

I need help to sort this out, as I just can't get
my head around the OS_SpriteOp 60 in
particular. The guide says R3 as 0 (the save area)
should be avoided if possible.

And I was wondering about what the graphics
cursor was doing.

I think I thought that I'd fooled RISC OS into
simply replotting an existing sprite vblue through
having to update an existing window and that
by my sneekily changing what vblue looked like
got the result I was after.
Now I'm not so sure what is actually going on.
Rick, why the Eeks ? Isn't that a standard way
of updating the window ?

Does anyone have some sample code I could look
at that does this sort of thing ?

Or a suggestion as to what I should change in the above ?

Regards,
Martin.

[toc] | [prev] | [next] | [standalone]

#159

I wonder if you are over-complicating the issue?

You have a sprite (a variable one, depending on the volume setting) that
you want to plot in a window. So why not decide which one you want, where
you want it, then plot it? As it is in a redraw loop, anything outside
the rectangle being re-redrawn will be ignored by the wimp - which means
that until you get the co-ords correct, you may not see anything! 

Your use of
    SpriteOp 60  TO ,r1,r2,r3,r4
MUST be followed by
    SpriteOp r1,r2,r3,r4 
to revert back to normal.

But this is only used when you want to CREATE a sprite by writing or
drawing something in to it. You already have the sprite you want to plot!

<plug>
If you are trying to write and debug a Basic program, I would strongly
recommend using !Reporter so you can see what is going on, display
variables, etc. Available from http://www.avisoft.f9.co.uk/  Without it
you are working in the dark!
</plug>

Martin

-- 
Martin Avison 
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received. 

[toc] | [prev] | [next] | [standalone]

#160

Eureeka !

I think I've sorted it.
It is to do with that OS-Sprite_Op 60 and the
save area, as Martin Avison suggests.

Adopting a minimalist approach, if I add a local variable savearea% as
follows the problem vanishes.

WHILE more%
SYS "OS_SpriteOp", 512+60, usa2%, vblue%, 0 TO , , partial% , savearea
%
$scof% = "v"+STR$(5*(barlength%+1)
SYS "OS_SpriteOp", 256+24, usa2%, scof% TO , , addscof%
SYS "OS_SpriteOp", 512+28, usa2%, addscof%
SYS "OS_SpriteOp", 512+60, usa2%, partial%, savearea%
SYS "Wimp_GetRectangle", 0, scrap% TO more%
ENDWHILE

This has sorted the problem on the Iyonix.
I'm now going to test it on various other RISC OS machines.

I'll add variables r1, r2 as Martin suggests - as I've also assumed
that
r1 = 512+60
r2 = usa2%
I thought those were reasonable assumptions, but maybe not.....

Thanks for the help guys !

[toc] | [prev] | [next] | [standalone]

#162

In message <8f897550-9fd7-4bb7-9765-5f0da2c786d4@a26g2000vbo.googlegro 
ups.com>
          Martin Hansen <mhh@shrewsbury.org.uk> wrote:

> Eureeka !

> I think I've sorted it.
> It is to do with that OS-Sprite_Op 60 and the
> save area, as Martin Avison suggests.

> Adopting a minimalist approach, if I add a local variable savearea% as
> follows the problem vanishes.

Yes, that fixes the problem that you did not pass the original 
context's save area when switching back, which meant that the original 
VDU state could not be restored.

> WHILE more%
> SYS "OS_SpriteOp", 512+60, usa2%, vblue%, 0 TO , , partial% , savearea
> %
> $scof% = "v"+STR$(5*(barlength%+1)
> SYS "OS_SpriteOp", 256+24, usa2%, scof% TO , , addscof%
> SYS "OS_SpriteOp", 512+28, usa2%, addscof%
> SYS "OS_SpriteOp", 512+60, usa2%, partial%, savearea%
> SYS "Wimp_GetRectangle", 0, scrap% TO more%
> ENDWHILE

> This has sorted the problem on the Iyonix.

Maybe, but
a) The above code is still wrong. As has been pointed out you should 
pass all three values that are returned to you by OS_SpriteOp 60 into 
your call to switch back. You are still passing your own sprite area 
pointer in the call that switches back.

b) You should not call any non-X SWIs while output is switched. You 
must check for errors and switch back if there is an error, else any 
error is likely to crash the machine.

c) It is still completely unclear what the above code is meant to 
achieve in the first place. You tell the Wimp you want to update a 
window, you go through the redraw loop, but you do not draw anything 
to the window, so why go to all the trouble? Inside your "redraw" 
loop, all you do is switch output to a sprite and plot some other 
sprite into it.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#163

On Apr 6, 1:50 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:

> > This has sorted the problem on the Iyonix.
>
> Maybe, but
> a) The above code is still wrong. As has been pointed out you should
> pass all three values that are returned to you by OS_SpriteOp 60 into
> your call to switch back. You are still passing your own sprite area
> pointer in the call that switches back.

Hi Martin,
Yes, I've done that, as I said I would.
But thanks for emphasising the importance of this.

> b) You should not call any non-X SWIs while output is switched. You
> must check for errors and switch back if there is an error, else any
> error is likely to crash the machine.

I don't but again thanks for pointing this out.

> c) It is still completely unclear what the above code is meant to
> achieve in the first place. You tell the Wimp you want to update a
> window, you go through the redraw loop, but you do not draw anything
> to the window, so why go to all the trouble? Inside your "redraw"
> loop, all you do is switch output to a sprite and plot some other
> sprite into it.

I think you are assuming that all of the sprite is visible, but in my
case
it may be partially covered by another window, which is why it's in a
redraw loop. Perhaps this is unnecessary - it's a couple of years
since
I wrote this. I recall trying several things that didn't work before
settling
on this. Once I'd got something that worked well (apparently) there
was no motivation to keep experimenting. It was only a really
obscure effect that I noticed by chance with the !Edit file that got
me curious about what was going on.

I'm still very pleased it's now sorted, though.
See you at Wakefield.
Regards,
Martin.

[toc] | [prev] | [next] | [standalone]

#165

On 6 Apr, Martin Hansen wrote in message
    <345c300b-5fa0-46f5-8d64-09f5afc09874@s33g2000vbb.googlegroups.com>:

> On Apr 6, 1:50 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:
>
> > b) You should not call any non-X SWIs while output is switched. You must
> > check for errors and switch back if there is an error, else any error is
> > likely to crash the machine.
> 
> I don't but again thanks for pointing this out.

Your example was calling non-X forms of OS_SpriteOp: you can't do that.

> > c) It is still completely unclear what the above code is meant to
> > achieve in the first place. You tell the Wimp you want to update a
> > window, you go through the redraw loop, but you do not draw anything to
> > the window, so why go to all the trouble? Inside your "redraw" loop, all
> > you do is switch output to a sprite and plot some other sprite into it.
> 
> I think you are assuming that all of the sprite is visible, but in my case
> it may be partially covered by another window, which is why it's in a
> redraw loop. Perhaps this is unnecessary - it's a couple of years since I
> wrote this.

It sounds hideously over complex.

If I've understood correctly, you've got an icon containing the sprite
"vblue" in your window and you need to change the actual sprite that this
refers to on demand and refresh it.  THere's no need for a redraw loop and
Wimp_UpdateWindow.

Assuming it's just a sprite icon (ie. not text and sprite[1]), then create
your icon:

  sprnamelen% = 12
  DIM sprname% sprnamelen%
  $sprname% = "v00" : REM Start with sprite "v00".
  sprarea% = -1 : REM Wimp area; set to your own if required.
  
  b%!0 = WHvolume%
  b%!4 = x0%
  b%!8 = y0%
  b%!12 = x1%
  b%!16 = y1%
  b%!20 = &1700011A : REM Flags: set as required (these may be wrong).
  b%!24 = sprname%
  b%!28 = sprarea%
  b%!32 = sprnamelen%
  SYS "Wimp_CreateIcon",,b% TO volume_icon%

Then you can set and update the window whenever you need to (in this case to
use sprite "v70" -- obviously you would make the actual string change as
required):

  $sprname% = "v70"
  b%!0 = WHvolume%
  b%!4 = volume_icon%
  b%!8 = 0
  b%!12 = 0
  SYS "Wimp_SetIconState",,b%

There's no need to have the "vblue" sprite at all, or copy any sprite into
any other: just update the icon's indirected data and get the Wimp to
refresh it.  You don't need the redraw loop either.

(In Usenet tradition, the above is all untested, and written away from a
machine that can run BBC BASIC.  It's also a while since I've written Wimp
stuff in BASIC, so there may be some C-isms creeping in.)


1. If you need text+sprite, then the same principle applies.  The difference
is that you rewrite the validation string on the fly, remembering to include
the leading "S".

> I recall trying several things that didn't work before settling on this.
> Once I'd got something that worked well (apparently) there was no
> motivation to keep experimenting.

Eww...

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                              Saturday 16 April 2011
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#166

In message <345c300b-5fa0-46f5-8d64-09f5afc09874@s33g2000vbb.googlegro 
ups.com>
          Martin Hansen <mhh@shrewsbury.org.uk> wrote:

> On Apr 6, 1:50 pm, Martin Wuerthner <spamt...@mw-software.com> wrote:

>> c) It is still completely unclear what the above code is meant to
>> achieve in the first place. You tell the Wimp you want to update a
>> window, you go through the redraw loop, but you do not draw anything
>> to the window, so why go to all the trouble? Inside your "redraw"
>> loop, all you do is switch output to a sprite and plot some other
>> sprite into it.

> I think you are assuming that all of the sprite is visible

No, that would be a very unreasonable assumption in a Wimp program.

> but in my case it may be partially covered by another window, which is
> why it's in a redraw loop.

That would be correct if you plotted anything to the screen in your 
redraw loop, but you don't. You just plot into a sprite, so doing that 
inside the loop only makes everything slower and more complicated.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#168

Dear All,
Thanks again for all the replies.
I'll try and catch folks at Wakefield for a chat about this.
Regards,
Martin.

[toc] | [prev] | [next] | [standalone]

#161

On 06/04/2011 11:23, Martin Hansen wrote:

> Rick, why the Eeks ? Isn't that a standard way
> of updating the window ?

It has been a while since I've coded anything to draw windows under RISC 
OS, so excuse me if this is a numpty question (my memory is a little 
hazy after so long)...

...but how does the previous code sample even work? At which point is 
something plotted to the window? Is it some sort of auto-redraw sprite, 
or does the Wimp override the SpriteOp 60 and intercept?


Martin - one suggestion... Wimp_SpriteOp (PRM book 3, p201).

:-)



Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#164

On 6 Apr, Martin Hansen wrote in message
    <123615df-90b2-4419-b59a-9e9e87301bfe@m7g2000vbq.googlegroups.com>:

> I think when I concocted this, I was just trying things until I got
> something that seemed to work. (the "engineer's" approach, I guess)

I don't think so... :-(

-- 
Steve Fryatt - Leeds, England             Wakefield Acorn & RISC OS Show
                                              Saturday 16 April 2011
http://www.stevefryatt.org.uk/           http://www.wakefieldshow.org.uk/

[toc] | [prev] | [next] | [standalone]

#177

On Apr 5, 8:28 pm, Martin Hansen <m...@shrewsbury.org.uk> wrote:
> Dear All,
> I'm trying to get to the bottom of a long standing bug in one of my
> programs.
> I'll describe the symptoms...
> From a clean start I open an !Edit window, and type in some stuff.
> I launch the program that contains the bug.
> With it on the Icon bar, all is well.
> I open a window containing a sprite.
> The text in the !Edit window (if I refresh it by dragging a window
> over it) is now half size.

This sounds to me like you've performed sprite redirection and have
incorrectly restored the sprite save area. When restoring after sprite
redirection all 3 returned registers (R1-R3) must be used. If you
incorrectly specify R3 you'll find that certain context is not
restored properly, such as the VDU state for the character height.
Alternatively if you pass the system save area (1) or no save area (0)
as your context then any operations will corrupt the existing context
when you restore.

Consult the PRMs for the description of the 'save area' and
OS_SpriteOp 60, 61, 62.

--
Gerph.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web