The Icon Bar: Programming: Sprites
| |
Sprites |
| |
Chris (21:43 16/6/2002)
Phlamethrower (16:05 18/6/2002)
Chris (23:15 18/6/2002)
rich (09:57 19/6/2002)
johnstlr (10:53 19/6/2002)
rich (11:23 19/6/2002)
Matthew (11:59 19/6/2002)
rich (18:59 19/6/2002)
Matthew (21:11 19/6/2002)
rich (23:16 19/6/2002)
johnstlr (13:20 19/6/2002)
Phlamethrower (14:20 19/6/2002)
Chris (23:20 19/6/2002)
Chris (13:13 22/6/2002)
davidb (10:14 24/6/2002)
rich (12:12 4/7/2002)
|
| |
|
Chris |
Message #15615, posted by Chris at 21:43, 16/6/2002 |
Member
Posts: 283
|
I'm having problems plotting sprites in windows. I created a sprite in high resolution with 16 colours (Mode 20) which I wish to place in a window. This works fine when the desktop is in the same mode as the sprite, but I want the graphics to reproduce correctly in low-resolution modes and/or with different colour depths.
The code I have at present is something like this:
SYS "OS_ReadModeVariable",-1,4 TO ,,xfactor%
SYS "OS_ReadModeVariable",-1,5 TO ,,yfactor%
block%!0=1
block%!4=1
block%!8=xfactor%
block%!12=yfactor%
SYS "OS_SpriteOp",256+52,area%,"sprite",x%,y%,0,block%,0
This seems to plot the sprite correctly at x%,y% in a 16-colour mode, whatever the resolution. In other colour-depths, however, I get the error message "Bad Colour Translation Table" (or similar). What am I doing wrong?
Grateful for any help,
Chris |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #15703, posted by Phlamethrower at 16:05, 18/6/2002, in reply to message #15615 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've had a poke around and I can't get it to work either, whether in the WIMP or not. I tried with a 256 colour sprite (since I had one handy), both with a palette (Probably an old 16 colour one), without a palette, and with a greyscale one, and it would only draw when in a 256 colour mode 
I then remembered about the WIMP using colour translation tables to draw icons in low colour modes, so I had a fidddle round - restarted the computer in supervisor mode and rmkilled the wimp. No effect 
It may be something to do with colourtrans though... I'll have another fiddle and get back to you. Otherwise it would appear to be a bug (Or something not mentioned in the RO 3 PRM's)  |
| |
[ Log in to reply ] |
| |
|
Chris |
Message #15725, posted by Chris at 23:15, 18/6/2002, in reply to message #15703 |
Member
Posts: 283
|
Thanks for this. I've been looking at how other programs plot sprites in the desktop, and it's become obvious that my posted effort is pretty far off the mark. I think I've almost cracked it now, but I don't have access to the PRMs. Could anyone give me a hand with how ColourTrans_SelectTable works (i.e., what parameters it takes and what they do)?
If I have any success, I'll pop the code up somewhere in case anyone else is interested. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #15740, posted by rich at 09:57, 19/6/2002, in reply to message #15725 |
 Dictator for life
Posts: 6828
|
I'm interested!
RISCOS Ltd. could do worse than to post a copy of the HTML PRM on their site to kickstart programming projects. |
| |
[ Log in to reply ] |
| |
|
Lee Johnston |
Message #15748, posted by johnstlr at 10:53, 19/6/2002, in reply to message #15740 |
Member
Posts: 193
|
I'm interested!
RISCOS Ltd. could do worse than to post a copy of the HTML PRM on their site to kickstart programming projects. They could but it might annoy the hell out of the people who paid for it and it would remove one source of income to actually help pay for the PRMs to be produced. 30quid isn't really that much to pay - look at how much a subscription to the MSDN costs (although admittedly that is freely available on line now). Free PRMs would be nice (and although I've paid for them it wouldn't bother me) but lets keep a bit of realism.
Having said that have people looked in the stronghelp manuals? You want to OS manual from
http://sudden.recoil.org/stronghelp/#manuals
although I don't know if the particular call mentioned is covered. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #15757, posted by rich at 11:23, 19/6/2002, in reply to message #15748 |
Dictator for life
Posts: 6828
|
The StrongHelp stuff is really useful *if* it covers what you want - there's no info on *fx138 (OK, OS_Byte 138 then) which is in the PRM. Neither has helped me poke keyboard shortcuts directly at a specific program however (hint, hint  .
I have a dead tree copy of the PRM as well as two CD copies and a full set of StrongHelp manuals (I even maintained one for a while - the filetypes one), so the suggestion isn't coming from a position of not wanting to stump up the cash. However, I think enough money has been milked from the PRMs over the years to bite the bullet and let more people have access to them for the sake of the programming community (like, making sure there is one). And you can always charge for updates, which is how many companies make their revenue these days. Acorn used to have their AppNotes after all, but charged for the paper PRMs. |
| |
[ Log in to reply ] |
| |
|
Matthew Somerville |
Message #15764, posted by Matthew at 11:59, 19/6/2002, in reply to message #15757 |
Posts: 520
|
The StrongHelp stuff is really useful *if* it covers what you want - there's no info on *fx138 (OK, OS_Byte 138 then) which is in the PRM. What's this, then? http://www.acornsearch.com/cgi/sh-cgi?manual=OS&page=os_byte138
Can't help you with your problem, though.  |
| |
[ Log in to reply ] |
| |
|
Lee Johnston |
Message #15769, posted by johnstlr at 13:20, 19/6/2002, in reply to message #15757 |
Member
Posts: 193
|
I have a dead tree copy of the PRM as well as two CD copies and a full set of StrongHelp manuals (I even maintained one for a while - the filetypes one), so the suggestion isn't coming from a position of not wanting to stump up the cash. I wasn't aiming my comments at you
However, I think enough money has been milked from the PRMs over the years to bite the bullet and let more people have access to them for the sake of the programming community (like, making sure there is one). And you can always charge for updates, which is how many companies make their revenue these days. Acorn used to have their AppNotes after all, but charged for the paper PRMs.
The charging for updates idea isn't bad but at which point do you make an update freely available? I don't expect an answer to this BTW
I'm not against it - I used the StrongHelp manuals for years before buying the PRMs CD (much more convenient than the paper copies) I'm just giving reasons as to why it might not happen. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #15772, posted by Phlamethrower at 14:20, 19/6/2002, in reply to message #15725 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Thanks for this. I've been looking at how other programs plot sprites in the desktop, and it's become obvious that my posted effort is pretty far off the mark. I think I've almost cracked it now, but I don't have access to the PRMs. Could anyone give me a hand with how ColourTrans_SelectTable works (i.e., what parameters it takes and what they do)?
If I have any success, I'll pop the code up somewhere in case anyone else is interested. Back to the matter at hand... Yes you do need to use ColourTrans_SelectTable:
R0 = Source mode, or -1 for current, or pointer to sprite area
R1 = Source palette pointer, or -1 for current, or (if r0 >= 256) pointer to sprite name/area (as specified by R5)
R2 = Destination mode, or -1 for current
R3 = Destination palette pointer, or -1 for current, or 0 for mode default
R4 = Pointer to buffer (or 0 to return size)
R5 = Flags (Used if r0>256):
bit 0 set > R1=pointer to sprite, else R1=pointer to sprite name
bit 1 set > use current palette if sprite has none, else use default
bit 2 set > use R6 and R7 to specify transfer function
bits 24-31 give format of table:
0 > return pixel translation table
1 > return physical palette table
R6 = Pointer to workspace for transfer function (If r0 >= 256 and bit 2 of R5 set)
R7 = Pointer to transfer function (If r0 >= 256 and bit 2 of R5 set)
So what you'll probably be needing is:
SYS "ColourTrans_SelectTable",spritearea,spritename$,-1,-1,buffer,2,0,0
And then you pass buffer as R7 of the OS_SpriteOp.
AFAIK the buffer takes up 1 byte per colour of the sprite, so a 256 byte one should be OK for anything rather than calling with R4=0 all the time to get the buffer size. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #15838, posted by rich at 18:59, 19/6/2002, in reply to message #15764 |
Dictator for life
Posts: 6828
|
The StrongHelp stuff is really useful *if* it covers what you want - there's no info on *fx138 (OK, OS_Byte 138 then) which is in the PRM. What's this, then? http://www.acornsearch.com/cgi/sh-cgi?manual=OS&page=os_byte138
Can't help you with your problem, though.
Just a wild guess, but it looks like a webpage?
StrongHelp on my machine just lists OS_Byte 138 as "Insert char into buffer" with no link to further info However, I'm just using it as an example as I've been using it successfully for years, and I don't think it'll do what I need for this particular project. (still hinting... ) |
| |
[ Log in to reply ] |
| |
|
Matthew Somerville |
Message #15844, posted by Matthew at 21:11, 19/6/2002, in reply to message #15838 |
Posts: 520
|
What's this, then? http://www.acornsearch.com/cgi/sh-cgi?manual=OS&page=os_byte138
Can't help you with your problem, though. Just a wild guess, but it looks like a webpage?
It's AcornSearch's StrongHelp-to-webpage convertor.
StrongHelp on my machine just lists OS_Byte 138 as "Insert char into buffer" with no link to further info Here, the "Insert char into buffer" links to a whole new page. I'd download the latest versions of the Stronghelp files. http://sudden.recoil.org/ |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #15845, posted by rich at 23:16, 19/6/2002, in reply to message #15844 |
Dictator for life
Posts: 6828
|
Ooh, ta.
I've figured out how to throw a character at a specific window/task, it's a Wimp message in the same format as poll (received) message 8. Now I can control my MP3 player without having to fake mouse clicks
Now about this sprite plotting code... |
| |
[ Log in to reply ] |
| |
|
Chris |
Message #15846, posted by Chris at 23:20, 19/6/2002, in reply to message #15772 |
Member
Posts: 283
|
Back to the matter at hand...
Thanks - that's really helpful. I'll try and get everything working over the weekend, and then post the results. |
| |
[ Log in to reply ] |
| |
|
Chris |
Message #15989, posted by Chris at 13:13, 22/6/2002, in reply to message #15772 |
Member
Posts: 283
|
OK, just after I spent a bit of time getting things to work with ColourTrans, I found a much easier way which sorts out the scaling at the same time. As long as you're running under the Wimp (which is probably the most likely explanation for making the sprite routines mode-independent), the following seems to work:
DIM scale% 16,colours% 16
SYS "Wimp_ReadPixTrans",256,area%,name$,,,,scale%,colours%
SYS "OS_SpriteOp",256+52,area%,name$,x%,y%,0,scale%,colours%
Annoyingly simple, in the end. On my system, I'm limited to old-style Sprites, so I have no idea if this works for new style 256-colour and high-colour Sprites. If anyone has a snazzy new machine I'd be interested to know. |
| |
[ Log in to reply ] |
| |
|
David Boddie |
Message #15997, posted by davidb at 10:14, 24/6/2002, in reply to message #15989 |
Member
Posts: 147
|
DIM scale% 16,colours% 16
SYS "Wimp_ReadPixTrans",256,area%,name$,,,,scale%,colours%
SYS "OS_SpriteOp",256+52,area%,name$,x%,y%,0,scale%,colours%
Annoyingly simple, in the end. On my system, I'm limited to old-style Sprites, so I have no idea if this works for new style 256-colour and high-colour Sprites. If anyone has a snazzy new machine I'd be interested to know. If it doesn't, then you may find it useful to take a look at the rendering code I wrote for my Python desktop library:
http://www-solar.mcs.st-and.ac.uk/~davidb/Software/Python/GUI/
The relevant lines are in the Sprite class (especially in the render method) and cope with various combinations of source and destination formats. I'd be equally interested to know whether my code renders obscure types of sprite correctly. |
| |
[ Log in to reply ] |
| |
|
Richard Goodwin |
Message #16307, posted by rich at 12:12, 4/7/2002, in reply to message #15989 |
Dictator for life
Posts: 6828
|
DIM scale% 16,colours% 16
SYS "Wimp_ReadPixTrans",256,area%,name$,,,,scale%,colours%
SYS "OS_SpriteOp",256+52,area%,name$,x%,y%,0,scale%,colours% Just hacked this code into FadeBack and /then/ read that it doesn't work for 256 colour sprites, so I'm getting a lovely kaledescope effect
...
Did some more work, and hand-displaying the sprite doesn't seem to give any better display than just putting the sprite into an icon and letting the WIMP do it itself. It looks like SpriteOp 56 can use ECFs, so I presume that'll do dithering, but I can't see how the internal rectangle and matrix stuff should be defined from a (albeit brief) look at the RPMs. Gah, everyone buy viewfinders so I don't have to display 256 colour sprites in anything less than glorious technicolour
________
 Cheers,
Rich.
|
| |
[ Log in to reply ] |
| |
|
The Icon Bar: Programming: Sprites |
