jimomura@lsuc.on.ca (Jim Omura) (12/03/90)
1990/12/01
Re: the Mouse Cursor Limit Problem
As you may recall the problem was how to reset the limit
of the mouse cursor travel after resetting the screen from Medium
resolution to Low resolution.
First, it seems clear to me from the help I received that
there is still no support for absolute mouse addressing in GEM/TOS
1.4. Apparently, only relative mouse returns are processed
and the travel limits are within GEM/TOS itself. I have been
informed that it is possible to reset the limits by using a
"change cursor" command on the VDI level, and at first I thought
I'd received enough information to do this. Upon reading the
information I received, I did not have sufficient information.
I do not have the Pseudo-Op code number and the definitions for
parameters passed and returned in the various data structures.
I thought about pursuing the matter further, but decided against
it. The program which required this setting is "functional" and
I have decided not to continue cleaning up the code for publication.
Rather, I have decided to put my time into developing my original
longer term project for which this program was necessary.
My thanks to all who responded!
Re: Sprites
And now on to the next, and hopefully my last problem along
the way to producing this main project. In this case, I have almost
all the technical capabilities to finish the whole project! Almost.
However, I've run into a very unexpected problem. As you may
recall, I wrote a number of Line-A bindings for the earlier
project and they were all successful. So looking at the Line-A
calls for the drawing and undrawing a sprite, I expected no
particular problems. Indeed, when I looked a the description
in "Atari ST Internals", it looked like a particularly simple
problem.
Draw Sprite:
Entry Conditions:
A0 = pointer to sprite definition block
A2 = pointer to buffer
D0 = Hot Spot X
D1 = Hot Spot Y
The Sprite Definition Block:
Unsigned shorts:
1. X offset to hot spot
2. Y offset to hot spot
3. Format 0 = VDI, 1 = XOR
4. Backgrnd colour
5. Foregrnd colour
followed by 16 pairs of shorts making up a set of bitmaps
background, foreground, (first row)
background, foreground, (second row)
etc.
The Buffer has a different format, but it's unimportant.
Simply stated, if it's 266 bytes (or 133 shorts), then it's
big enough to hold any data expected.
The Undraw Sprite definition was even simpler. Only
the pointer to the buffer is passed in A2 according to the
book.
So, I wrote the following:
.text
.globl _sprshow
_sprshow:
; void sprshow(sprite,buffer,posx,posy)
; short *sprite;
; short *buffer;
; short posx;
; short posy;
;
; Show sprite with "hot spot" at posx/posy
; Line-A support module for Sozobon C by Jim Omura
;
;var 4 8 _sprite
;var 4 12 _buffer
;var 2 16 _posx
;var 2 18 _posy
;
link a6,#-0
;
movea.l 8(a6),a0 ; A0 = Sprite Def Block
movea.l 12(a6),a2 ; A2 = Sprite buffer
move.w 16(a6),d0 ; D0 = X
move.w 18(a6),d1 ; D1 = y
;
.dc.w $a00d ; pseudo-op
;
unlk a6
rts
.data
; *** End of SprShow ***
.text
.globl _sprhide
_sprhide:
; void sprhide(buffer)
; short *buffer;
;
; Replaces Sprite with Buffer stored by sprshow()
;
; Line-A Support module by Jim Omura
;
;var 4 8 _buffer
;
link a6,#-0
;
movea.l 8(a6),a2 ; A2 = buffer address
;
.dc.w $a00c ; pseudo-op
;
unlk a6
rts
.data
; *** End of SprHide ***
It all looks nice and simple, but it doesn't work.
I crashed with bombs on the first attempt to "sprshow()".
I don't know if the "sprhide()" works because I never
succeeded to draw the sprite in the first place, and the
undraw command only works if you have the data stored.
It doesn't make sense to me that the actual routines
would not be working in TOS 1.4, and I don't think I'm being
particularly big headed in assuming that I made no mistakes
in my coding in accordance with the information in the book.
So the book is probably wrong. That would not surprise me.
In particular, I was surprised that *no* data has been sent
through the big A-Line data structure. It's possible that this
is correct. I don't see any reason to doubt it, but then
again, it seems like the place to look.
Does anybody have any information about the sprite
routines that contradict what I have?
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
lsuc!jimomura
Byte Information eXchange: jimomura