Multi color sprites
Turbo-Randy
I'm planning to make a game with a bean (see alt.binaries.emulators.misc
(PLAATJE VAN BOON))
But there is a problem. This bean is made out of 3 sprites (one single
colored and two multi colored)
1. black outline + pupils + mouth
2. Green hat + green body
3. white eye part + shoes
Since I only can color a sprite line by line (and not by pixel) I can not
create a single sprite (on an MSX 2)
Can I merge these 3 sprites into one (with an MSX2) or is there a more
advanced method for the MSX 2 or Turbo-R to make a multi color sprite like
this.
I ask this becouse if I move the 3 sprites, they move very choppy and it
looks horrable.
Thanks.
Turbo-Randy
Eric Boon
>Okay... here is the problem.
>I'm planning to make a game with a bean
<insert obvious remark/joke/whatever here ;-)>
>(see alt.binaries.emulators.misc (PLAATJE VAN BOON))
(Sorry, my newsserver says: no group "alt.binaries.emulators.misc")
>But there is a problem. This bean is made out of 3 sprites (one single
>colored and two multi colored)
>1. black outline + pupils + mouth
>2. Green hat + green body
>3. white eye part + shoes
>
>Since I only can color a sprite line by line (and not by pixel) I can not
>create a single sprite (on an MSX 2)
>
>Can I merge these 3 sprites into one (with an MSX2) or is there a more
>advanced method for the MSX 2 or Turbo-R to make a multi color sprite like
>this.
>
>I ask this becouse if I move the 3 sprites, they move very choppy and it
>looks horrable.
AFAIK, the way you do it is the only way, if you insist on using sprites.
And, yes, BASIC ts too slow to do that properly. You could improve the
speed by using a ML routine to position/move the sprites...
Another method would be using a bitmap on a non-visible videopage
instead of sprites - you can then disable sprites in the VDP
completely, which speeds up the VDP speed, too.
Let's assume your game plays on page 0, then you can have bitmaps for
your bean in different positions in page 1. You then save the background
from page 0 somewhere on page 1, copy the correct bean in place on page 0.
Parts of the bitmap which should not be copied should have color 0
(transparent).
If the bean moves,you copy back the original background, save the background
for the new position and copy the bean onto it.
' bean is at BX, BY. Should move DX, DY pixels
' bean bitmap is on (0,0) page 1, size 16x16
' (0,196)-(15,211), page 1 is used as background store
COPY(0,196),1 - (BX,BY),0 ' restore old background
BX=BX+DX: BY=BY+DY ' move bean
COPY(BX,BY),0 TO (0,196),1 ' save new background
COPY(0,0)-(15,15),1 TO (100,100),0, TPSET' put bean
Works in all MSX2 screen modes. But becomes more difficult when you
will be using more than one 'sprite' and you have to check for collision
etc...
HTH,
Eric
--
Ceci, ce n'est pas une .signature
B. Wijnen
> >But there is a problem. This bean is made out of 3 sprites (one single
> >colored and two multi colored)
> >1. black outline + pupils + mouth
> >2. Green hat + green body
> >3. white eye part + shoes
> >
> >Since I only can color a sprite line by line (and not by pixel) I can not
> >create a single sprite (on an MSX 2)
> >
> >Can I merge these 3 sprites into one (with an MSX2) or is there a more
> >advanced method for the MSX 2 or Turbo-R to make a multi color sprite like
> >this.
> >
> >I ask this becouse if I move the 3 sprites, they move very choppy and it
> >looks horrable.
>
> AFAIK, the way you do it is the only way, if you insist on using sprites.
> And, yes, BASIC ts too slow to do that properly. You could improve the
> speed by using a ML routine to position/move the sprites...
There is an other method. The MSX2 VDP (and I think also MSX1) supports
overlappin sprites to have a different colour. If you set a bit in the
sprite attribute table (some bit in the high nibble in the colour byte),
this line will not check for collisions, but if it collides, the colour of
this line and the line it is colliding with are ORed and the result is the
printed colour. So to get 3 colours on one row, you make one sprite with
all the green and black bits set to 1, and an other sprite with the black
and blue bits set to one (or whatever colours you want). Then you set your
palette so, that (colournumber of green) OR (colournumber of blue) =
(colournumber of black). At least one of the sprites must have its
or-on-overlap-bit set.
To get rid of the choppyness, you should make sure you only move the
sprites together, while the vertical blanking is active is a very suitable
moment. This is when the interrupt is generated, so if you write a little
ML program to do this for you, it should be fine. You could try vpoke,
which is probably faster than put sprite, but I think it will still be too
slow.
> Another method would be using a bitmap on a non-visible videopage
> instead of sprites - you can then disable sprites in the VDP
> completely, which speeds up the VDP speed, too.
Indeed. And you don't have the limited-sprites-on-one-row problem then.
It is much slower, however. So if it can be done with sprites, it is
advisable.
<snip about how to use copy to emulate hardware sprites in software>
> Works in all MSX2 screen modes.
No, this method does not work in screen 4, because it is a character mode.
(Often, using this does speed up your program enormously, see space manbow
as an example for that. But you have colour spills and all...)
> But becomes more difficult when you
> will be using more than one 'sprite' and you have to check for collision
> etc...
A good colliion check like the hardware does is very hard. Software
sprites are mostly not checking the collision of the sprite, but merely
the bounding box (which results in hitting walls that you actually didn't
hit). The reason for this is that it is a complicated calculation. In
BASIC you definitely don't want to do it.
Good luck with the game,
Greetings,
shevek.
---
/** mastermind. input 4 numbers 0-5. output <right>.<in the right place> **/
main(){int c[4] ,x=3 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44> x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16 >i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
Turbo-Randy
sprites.
With platform games there are often more than 4 sprites on one horizontal
line. So if I make a character out of 2 sprites (one less then it is now)
there is no place for another character like an enemy sprite and other
sprites like bullets (or a fart in this case)
SO I have to test the copy command. I hope that will do anything good. Damn,
how the hell works assembly ??? :) Beginner and advanced books about
assembly are very welcome. (mail me if you want to sell some books. Only
Nederland)
Are there any good assembly programs around the Wereld Wijde Web ?
There is another question. How do I program music that play's constantly ?
Houdoei,
Turbo-Randy
John van Poelgeest
Turbo-Randy <sp...@cybermail.net> schreef in berichtnieuws
8t7c1o$rvm$1...@azure.nl.gxn.net...
Eric Boon
><snip about how to use copy to emulate hardware sprites in software>
>
>> Works in all MSX2 screen modes.
>
>No, this method does not work in screen 4, because it is a character mode.
Eh yes. You're right, of course. I dunno why, but I usually start
counting the MSX2 modes at screen 5, but I stop counting at 3 for the
MSX1 modes ;-)
Eric Boon
>Are there any good assembly programs around the Wereld Wijde Web ?
There are a lot: both for MSX and PC... Another option would be
using an MSX BASIC compiler, like MCBC....
>There is another question. How do I program music that play's constantly ?
The easiest way:
1. Use a music program (MoonBlaster, SCC Blaffer, PSG Tracker, whatever)
to write the music
2. Load the replayer & music.
3. Start playing and have fun
The hard way, in BASIC and for PSG (for example) - define your music
in a set of PLAY commands which each play a piece of the music,
approximately
equal in playing length (e.g. 2 measures) and use ON INTERVAL:
10 ' example of BGM in BASIC
20 ON INTERVAL=50 GOSUB 100
30 INTERVAL ON ' play music
40 Print "Music playing..."
50 IF INKEY$="" GOTO 50
60 INTERVAL OFF: END
90 ' ------ da tunez -------
100 P=(P+1) MOD 4 ' 4 lines of music
110 ON P+1 GOTO 120,140,160, 180
120 PLAY "o3C4 o4E4 o2G4 o4E4", "o4 r4 G4 r4 G4", "o5 r4 C4 r4 C4 r4"
130 PLAY "o3C4 o4E4 o2G4 G#4", "o4 r4 G4 r4 G4", "o5 r4 C4 r4 C4 r4":
RETURN
140 PLAY "o2A4 o4E4 o2E4 o4E4", "o4 r4 A4 r4 A4", "o5 r4 C4 r4 C4 r4"
150 PLAY "o2A4 o4E4 o2E4 o4E4", "o4 r4 A4 r4 A4", "o5 r4 C4 r4 C4 r4":
RETURN
160 PLAY "o2F4 o4F4 o2C4 o4F4", "o4 r4 A4 r4 A4", "o5 r4 C4 r4 C4 r4"
170 PLAY "o2F4 o4F4 o2C4 F4", "o4 r4 A4 r4 A4", "o5 r4 C4 r4 C4 r4":
RETURN
180 PLAY "o2G4 o4F4 o3C4 o4F4", "o4 r4 B4 r4 B4", "o5 r4 D4 r4 D4 r4"
190 PLAY "o2G4 o4F4 o2A4 B4", "o4 r4 B4 r4 B4", "o5 r4 D4 r4 D4 r4":
RETURN
ON INTERVAL=x GOSUB y calls the subroutine at y every x/50th seconds, so
in the example above, line 100 gets called every second. With INTERVAL
ON/OFF
you can switch this mechanism on and off. Try leaving out the INTERVAL OFF
in line 60. IIRC, the music continues playing even after the program
stopped!
Disclaimer I: I typed the code above straight into my newsreader, did NOT
check
for any syntax error, as I have no means of testing this right now!
Disclaimer II: I can not guarantee that the music played is of any quality
:-P
Enrico Barbisan
and also for sprites in screen 0.
Enrico
http://space.tin.it/computer/enribarb
Eric Boon
Enrico Barbisan:
>I have an assembler routine for 2 colour sprite for MSX1
>and also for sprites in screen 0.
Sprites in Screen 0? I don't believe you! ;-)
Could you post the source?
Or mail it or make it available through your website?
>http://space.tin.it/computer/enribarb
Couldn't find it there...
Eric
--
[This sig was intentionally left blank]
Hans Guijt
>>I have an assembler routine for 2 colour sprite for MSX1
This might involve placing two sprites on top of each other ;-)
>>and also for sprites in screen 0.
>Sprites in Screen 0? I don't believe you! ;-)
You could emulate it by allocating 4 characters (say, 251..254), and OR'ing
the 'sprite' pattern and the characters behind it into them. Then you would
have to replace the four affected characters with those characters. Making a
mouse cursor for screen 0 in this manner should be possible, but it would be a
lot of work.
The principle is exactly the same as the normal text cursor, except with more
characters so that the 'sprite' can move over character boundaries.
Hans Guijt
Eric Boon
>Eric Boon (Eric...@ICT.nl) wrote:
>>>I have an assembler routine for 2 colour sprite for MSX1
>
>This might involve placing two sprites on top of each other ;-)
Probably - it's the most obvious way to do it :-)
>>>and also for sprites in screen 0.
>
>>Sprites in Screen 0? I don't believe you! ;-)
>
>You could emulate it by allocating 4 characters (say, 251..254), and OR'ing
>the 'sprite' pattern and the characters behind it into them.
Ok, ok, ok. I *know* that trick. But that's not a real sprite :-)
I would have liked to see *real* sprites in SCREEN 0!
Manuel Bilderbeek
> Eric Boon (Eric...@ICT.nl) wrote:
> >>and also for sprites in screen 0.
>
> >Sprites in Screen 0? I don't believe you! ;-)
>
> You could emulate it by allocating 4 characters (say, 251..254), and OR'ing
> the 'sprite' pattern and the characters behind it into them. Then you would
> have to replace the four affected characters with those characters. Making a
> mouse cursor for screen 0 in this manner should be possible, but it would be a
> lot of work.
>
> The principle is exactly the same as the normal text cursor, except with more
> characters so that the 'sprite' can move over character boundaries.
This newsgroup discussion brings me to a point:
WHY didn't any program for MSX used 2 cursors? I mean, a textcursor and a
mouse cursor. That can be so convenient! Placing the text cursor with the
mouse, selecting text with the mouse cursor...
TED e.g. could have used this very nicely. Also Moonblaster or any
other editor. I think this is really a missed chance. A mouse can be a
helpful tool, especially for beginners.
NOte, that this cursor doesn't need to be different than just a block-text
cursor. No fancy shit.
Grtjs, Manuel
PS: MSX 4 EVER! (Questions? The Ultimate MSX FAQ: http://www.faq.msxnet.org/)
PPS: Visit my home page at http://bilderbeek.cjb.net/
tuneman
>WHY didn't any program for MSX used 2 cursors? I mean, a textcursor and a
>mouse cursor. That can be so convenient! Placing the text cursor with the
>mouse, selecting text with the mouse cursor...
A mouse wasn't really standard on MSX, almost nobody had one.
But it would have been handy of course.