STOS Parallax, SKOPY and the 4 bitplanes Using MISTY

[EstTeeEfEm]

OK, So I've managed to create a decent parallax scrolling background using SKOPY from the MISTY extension, only I don't know how to set-up the bit planes correctly, or which colours need to be what in order for it to work.

Could someone explain what colours need to be what and which bit-planes need to be copied in order to make this look awesome...

Thanks in advance...

P.S I've included a PRG so you can see what it COULD be

[mrdalliard]

I was going to ask about this, too. I seem to be able to move bits around without issue using skopy, as long as there's "clear space" around. The colour of what I'm moving (on a single bitplane) seems correct, but as soon as what I'm moving comes into contact with something of another colour, it seems to disappear behind what's already there. This suggests I've probably got my palette wrong. Or I've really not go the right end of the bitplanes stick.

Anyway, I know this was posted nearly two months ago, but it anyone's got any good examples of Misty using multiple bitplanes, or perhaps an "Idiots Guide To Bitplanes" (I search the forum, but many of the links appear to be out of date), then I (and I'm sure, EstTeeEfEm) would appreciate it.

M.

[exxos]

You might be better asking in the 68000 sections about bitplanes, as its not something I have ever gone into. I've not been active in STOS for 20 odd years either so that does not help much

What it sounds like though is if a graphic is "wiping" away stuff near it , then there is a problem with the screen setup, like you are drawing all the graphics on the logical screen and not drawing all graphics on the background screen then using screen swap.

The idea being all graphics are created on the background screen (which you don't see), so normally do the screen background images or whatever, then do the bobs or whatever ontop of it. Once its all done, you use screenswap which swaps the background image to the logical screen which you see. Then you use a clear screen such as "wipe" to clear the background screen ready to draw the next frame.

So I suspect you are drawing everything on the logic screen, then if you move a bob then it will wipe away anything in its path on the background image.

[mrdalliard]

I'm going to post this here, mainly because it explained the whole bitplanes thing better than anything else I've read so far:

http://mikro.naprvyraz.sk/docs/Coding/A ... TDEMO2.TXT

In essence, plane one is under plane two, which is under plane three then four. If you want, for example, scrolling text to roll over an image and not disappear, you need it to be on plane four, with colours 8 to 15 being set the same. Anything underneath needs (i.e. an image) to be using colours 0-7 on the first three bitplanes.

The only thing I can't get my head around is that skopy allows you to copy 1 - 4 bitplanes, but as the start X address has to be a 16-byte multiple, I don't see how you can just move bitplane 4 on its own. Ideally, I want to shift just one plane (the fourth), but with a starting address using a 6-byte offset (if my maths proves correct), so that it just shifts the bit I want.

Obviously, SKOPY was used back in the day quite successfully, so perhaps I've just missed something.

M.

[distantminds]

I'm pretty sure it's a 16 bit boundary - ie. an even address.

From hazy memory, doesn't the source data have to be the correct number of planes in the first place? So, if you want to move a single bitplane around using SKOPY 1, then you'll need to have the one plane 'screen' as a standalone piece of data.

not sure, but that's my recollection

D

The only thing I can't get my head around is that skopy allows you to copy 1 - 4 bitplanes, but as the start X address has to be a 16-byte multiple, I don't see how you can just move bitplane 4 on its own. Ideally, I want to shift just one plane (the fourth), but with a starting address using a 6-byte offset (if my maths proves correct), so that it just shifts the bit I want.

M.

[mrdalliard]

I'm glad to say I've cracked it.

I went back to Exxos's STOS resources site, where there's a single "BitCopy" archive. The document that's in the archive is a little more helpful and explains about copying a single bitplane when it's not number one (i.e moving just plane 4).

So, I wasn't far wrong that my offset needed to be 6 bytes when I needed to shift just plane 4:

skopy 1, start(source memory bank)+6,0,0,32,8,physic+6,target x,target y

The 6 byte offset on the start/end address will indicate which bitplane you want to copy. (+0 = 1, +2 = 2, +4 = 3, +6 = 4). Same goes for the destination, so if you're feeling so inclined, you can move plane 1 to plane 4 or whatever.

Glad I've got that cracked, anyway. Thanks for all your help. I've not looked at the original poster's program, but if he's still struggling over it I hope this helps!

M.

[EstTeeEfEm]

My apologies for the late reply

In essence, plane one is under plane two, which is under plane three then four. If you want, for example, scrolling text to roll over an image and not disappear, you need it to be on plane four, with colours 8 to 15 being set the same. Anything underneath needs (i.e. an image) to be using colours 0-7 on the first three bitplanes.

Yes, this allows crude transparency too ... ive seen it done but dont ask me how !

Exxos: I have read some of your STOSSER Documents too... very interesting reading

STOSSER archives are by far the most informative when dealing with STOS and its innards I wholly recommend it!
(Also on Exoss' site I believe?)

I think in general, i'll need a little more STOS knowledge and a lot more ST graphics knowledge to fully achieve what I want atm. I know its possible but time has got away from me a little... holidays, new year...

[exxos]

We all have family's , work and the rest, at least you are doing something constructive which is always a good thing

Yeah STOSSER is awesome,http://www.exxoshost.co.uk/atari/STOS_index.htm Really the information needs converting to HTML or something more easily readable as there isn't many STOS guides about. There is "The beginners guide to STOS basic" book which is awesome. http://www.exxoshost.co.uk/atari/STOSFLOPPY/index.htm After that just read the docs for "the missing link" and your pretty well armed to code in STOS then

[mrdalliard]

I think in general, i'll need a little more STOS knowledge and a lot more ST graphics knowledge to fully achieve what I want atm. I know its possible but time has got away from me a little... holidays, new year...

I know the feeling. I had a few days over Christmas to make a dent in my reject, but now it's back to the usual routine of family, work, etc... and I've not got so much time now. Still, I've made some progress and have got a couple of demos nearly completed. My project is to get an entire MegaDemo done by the end of the year. It won't set the world alight, but it's gloriously oldskool and I'll get to finish a project I started 25 years ago. Hopefully will post some screens in the next week or so to give you an idea.

EstTeeEfEm - Best of luck with your project too.

M.

[exxos]

I wrote a MEGA demo 20 years ago, never released it. I know I saw it some years ago and thought hell this is awesome, but at the time I was coding it, it was the "same old same old - nothing new" type thing so kinda lost interest in it.

All my STOS stuff is backed up on my PC, its just finding the stuff thats the problem and time to sort though it all. So I wouldn't worry about "end of the year" to get stuff finished, I'm spanning decade's at the moment Hopefully I can get my stuff sorted out. Don't forget anything you guys do can go on my site to help others in the future.

[mrdalliard]

Well, this isn't quite finished, but you get the idea for this screen - four demos, one in each corner of the screen (barrel scroller, starfield, VU bars, scrolltext). Got to finalise the colours, improve the presentation a bit, change the scrolltext font and add rasters. That's the intention, anyway!



I know it doesn't break any new ground, but it makes me happy.

M.

[exxos]

New STOS stuff is always welcome There hasn't been any STOS coding for some years. I thought I was the last of the die-hard fans

[mrdalliard]

I thought I was the last of the die-hard fans

Oh no, I've always loved it. Speed wasn't it's forté, but it was good for getting stuff together quite quickly. The community of extensions was what filled in the gaps. I always think it's a shame there isn't a comparable development environment nowadays.

(This isn't a deliberately inflammatory comment, I've just not found something small and portable since STOS that I've enjoyed so much).

M.

[EstTeeEfEm]

There was talk of a cross-editor/compiler but I'm not sure what happened to it, i dont think all the extensions were incorporated, check the threads and the info thread in partic.

[Mikefulton]

I'm going to post this here, mainly because it explained the whole bitplanes thing better than anything else I've read so far:

http://mikro.naprvyraz.sk/docs/Coding/A ... TDEMO2.TXT

In essence, plane one is under plane two, which is under plane three then four. If you want, for example, scrolling text to roll over an image and not disappear, you need it to be on plane four, with colours 8 to 15 being set the same. Anything underneath needs (i.e. an image) to be using colours 0-7 on the first three bitplanes.

The only thing I can't get my head around is that skopy allows you to copy 1 - 4 bitplanes, but as the start X address has to be a 16-byte multiple, I don't see how you can just move bitplane 4 on its own. Ideally, I want to shift just one plane (the fourth), but with a starting address using a 6-byte offset (if my maths proves correct), so that it just shifts the bit I want.

Obviously, SKOPY was used back in the day quite successfully, so perhaps I've just missed something.

M.

This "plane one is under plane two" ect. thing doesn't accurately describe the hardware. It's just this guy describing this trick he's figured out, and it's probably going to be kinda misleading to anybody who doesn't have a good understanding of how bitplanes work in the first place.

Bitplanes are commonly misunderstood. But they're really not that difficult once you have the necessary "A HA!" moment.

Assuming 4 bitplanes like ST low-rez mode, each 16 pixels worth of screen memory is laid out like this:

{16 bits for bitplane 0} {16 bits for bitplane 1} {16 bits for bitplane 2} {16 bits for bitplane 3}

That's one 16-bit word per bitplane, 8 bytes of data overall, and it represents 16 pixels worth of data. If we were in a 2-plane mode like ST medium rez, we would have bitplanes 0 and 1, but not 2 and 3. Likewise, a 256-color mode like on the TT030 has 4 additional bitplanes for a total of eight.

To get the individual pixel values, you grab a bit from each word and shift them into the result. After you've done this with each bit plane, you have the resulting pixel value. For example, if you wanted to extract each of the pixel values out of the bitplanes, you would do something like this:

Code: Select all

int pixelvalues[16];
int numplanes = 4;
short *screenmemory; // presume this is set elsewhere

for( int pixel = 0; pixel < 16; pixel++ )
{
    int result;

    for( int currentBitPlane = 0; currentBitPlane  < numplanes; i++ )
    {
        // Grab a bit from the current bitplane
        int bit = screenmemory[currentplane] & ( 1 << (15-pixel) );

        result <<= 1;    // Shift everything left 1 bit
        result |= bit;    // bitwise OR in the bit we just grabbed
    }

    pixelvalues[ pixel ] = result;
}

The way this shifts in the bits is why the video chip in the ST is known as the video shifter.