Wich one of these two Prince of Persia you prefer?

[José Pereira]

DELECTED

Edited October 13, 2011 by José Pereira

[Rybags]

Seperate masks are needed.

 

Or if the PM is aligned with the bitmap part, a translation table could be used (less memory but slower).

[José Pereira]

And now?

 

I see that there you have the Gfxs. and those equal ones on inverse.

 

Ones has the real colour and other called Mask are in Black, the Background register colour (00), like this:

and Mask one:

(this is sure what Karol was talking on that 'AND bit Masking')

 

Having this is what we need for the Masking, right?

Is it like this: If the Player goes behind it's Mask in VRAM does Bitmap masking over the guys?

 

 

But if the guys on C64 are hardware Sprites there are some Hardware sprites vs Gfxs. colour Registers interaction here, right?

(Hardware sprites bit-pairs vs Gfxs. colour Registers bit-pairs)

This is because I was wondering that because C64 Multicolour sprites are also in bit-pairs, the same as the Gfxs. then their interaction/Masking can be exactly ported into A8 on the 'Walls vs Soft Sprites'.

Am I thinking it right?

 

 

------------------------------------------------------------------------------------------------------------------------------------------

I never understand how you can do Masking on A8 between Gfxs. and PMs.

 

Gfxs. are bit-pairs that four bit-pairs are 1byte

On the other way PMs. are single bit and 1PM's bit=1bit-pair of Gfxs. (8bit/1byte Player are 8bit-pairs=2bytes)

 

How interact PM 1bit with the same width Gfxs. that are two bits in form of bit-pairs?

 

 

 

On a later PMs overlay would this Mask Tiles be worth/possible of use in the Gfxs. masking over PMs.

 

 

 

 

 

Help... Thanks.

Edited October 13, 2011 by José Pereira

[José Pereira]

DELECTED

Edited October 13, 2011 by José Pereira

[José Pereira]

Seperate masks are needed.

 

Or if the PM is aligned with the bitmap part, a translation table could be used (less memory but slower).

 

 

I have, for example, P0 that is (11111111) and a Pillar it's (01,01,00,00) but next one has (11,11,00,11) and wouldn't Mask PM. (exactly like those two Pillars: the foreground and the background ones.

P0 would only be seen where's Gfxs. bit-pair it's (00) on the first and in all bit-pairs on the second.

 

 

The first for sure use that Black Inverse in VRAM for the Masking? The other would be the real looking bit-pairs?.

But I have a 16bit (8 bit-pairs) of gfxs. that are the same width an 8bit single bit(like in Hi-Resoution) PM. byte

Still can't see how

[José Pereira]

I begin to see:

A bit pair it's 11 but if it's those Black colour (the Mask ones), the (00) ones would 'destroy' the soft sprite bit-pair on that place:

 

gfx. (10,00,10,10)

soft sprite (11,11,11,11)

~(soft sprite would only be seen in 00)~

The result of this must be (10,11,10,10)

 

Normal Bitmap Masking with soft sprite over Gfxs. you would have:

Gfxs.----------------: (10,00,10,10)

AND

Inverse soft sprite: (00,00,00,00)

____________________________

Result in------------ (00,00,00,00)

OR

S.sprite real shape(11,11,11,11)

____________________________

Result in------------ (11,11,11,11)

 

 

But here you need to Mask the soft sprite, then it would be:

Gfxs. Mask shape- (00,11,00,00)

AND

S.Sprite real shape(11,11,11,11)

____________________________

Result in------------ (00,11,00,00)

OR

Gfx. real shape---- (10,00,10,10)

____________________________

Result in this------- (10,11,10,10)

 

 

Exactly what we want, the soft sprite (11) is only seen on the (00) of the Gfxs.

[Heaven/TQA]

And now?

 

I see that there you have the Gfxs. and those equal ones on inverse.

 

Ones has the real colour and other called Mask are in Black, the Background register colour (00), like this:

and Mask one:

(this is sure what Karol was talking on that 'AND bit Masking')

 

Having this is what we need for the Masking, right?

Is it like this: If the Player goes behind it's Mask in VRAM does Bitmap masking over the guys?

 

 

But if the guys on C64 are hardware Sprites there are some Hardware sprites vs Gfxs. colour Registers interaction here, right?

(Hardware sprites bit-pairs vs Gfxs. colour Registers bit-pairs)

This is because I was wondering that because C64 Multicolour sprites are also in bit-pairs, the same as the Gfxs. then their interaction/Masking can be exactly ported into A8 on the 'Walls vs Soft Sprites'.

Am I thinking it right?

 

 

------------------------------------------------------------------------------------------------------------------------------------------

I never understand how you can do Masking on A8 between Gfxs. and PMs.

 

Gfxs. are bit-pairs that four bit-pairs are 1byte

On the other way PMs. are single bit and 1PM's bit=1bit-pair of Gfxs. (8bit/1byte Player are 8bit-pairs=2bytes)

 

How interact PM 1bit with the same width Gfxs. that are two bits in form of bit-pairs?

 

 

 

On a later PMs overlay would this Mask Tiles be worth/possible of use in the Gfxs. masking over PMs.

 

 

 

 

 

Help... Thanks.

 

 

actually do the bit masking via AND which I have described... I guess that from quickly looking at that if you AND the MASK (the right pic) with PM gfx or the hardware sprite data that it is cut off where the pixels are black...

[potatohead]

What needs to be done is masks appropriate for each kind of graphics.

 

Four color graphics require two bits per pixel. Masks then are %00111100, for example in binary. That bit pattern could be used to mask IN the two middle pixels of a byte, if the "AND" operation is being used. PM graphics are one bit per pixel.

 

If the graphics to be masked were, say 4 pixels wide, the PM graphics would be somewhere in the byte used to communicate pixel data. Let's say those 4 pixels are in the LOWER part of the PM byte, and let's say the PM is lined up with the background 4 color pixels just right, so they are right on top of one another.

 

The masks then would be:

 

%00111100 - for the 4 color graphics

%00000110 - for the 2 color graphics. (that's assuming the same pixels would be hidden.

 

Another case might be the inverse, %00001001 for the PM, so that the background would be known to show through, for example. Plug that in above to see how the background pixels would be passed through in the middle.

 

%00111100 -- Make sure background pixels in middle of byte show on screen, others set to background color.

%00001001 -- Hide middle PM pixels, letting background pixels show through.

 

 

The bit operations are key to understanding this. AND, OR, NOT, XOR. For now, I'll just focus on AND and OR.

 

We use AND to pass through some of the pixel data, ignoring some other pixel data. This works because of how AND works. When both the source and mask are 1, the result will be a 1, otherwise the result is 0.

 

%11010101

%01111000 (AND)

---------------------

%01010000

 

Another way to think of AND is you use it when you want to make sure specific DIGITS, or BITS are ZERO.

 

Or is used in a similar way, but it's used when you want to make sure specific DIGITS or BITS are ONE.

 

%11010101

%01111000 (OR)

---------------------

%11111101

 

With OR, if either bit of the source or mask is a ONE, then the result will be ONE.

 

AND typically is used to take things away from the graphics data, leaving room to drop unique things into the gap produced by AND. OR is used to combine graphics data.

 

I'll let others expand on that with XOR, and other use cases, but maybe that helps you some Jose'

 

(Dude, you need to start programming. Seriously, just do it. You have so many great ideas and a clear passion for this. Do it. LOTS of people will help you where they have skill and time. Trust me on that.)

Edited October 13, 2011 by potatohead

[Heaven/TQA]

and Jose is a fast learner... he seems to be talented to work in games biz I have to admit... honestly.

[Heaven/TQA]

Jose... you can simulate "masking" in Photoshop & co... but I leave that to the GFX guys here... ask STE f.e.

[potatohead]

Totally agreed Heaven. If nothing else, he can learn a lot of FUN stuff. Hell, that's why many people do it. I enjoy this stuff immensely, and it's all hobby, fun 'n games for when I get time to explore.

[Heaven/TQA]

Jose... http://babek.info/libertybasicfiles/lbnews/nl143/sprite.htm

[José Pereira]

Karol I think I get it...

 

You have to create an exactly copy of the Gfxs for the 1bit PMs.

You would create a 'pseudo' Mask Gfxs in the 1bit form.

Like this:

 

Gfxs.: (11,10,00,11)(10,00,11,01)

~(PMs would only be seen in 00)~

Then you would create an inverse Gfx. where the gfxs. are in 1bit form

 

That one would be in Mask form: (0,0,1,0)(0,1,0,0)

Now you simply do the Bitmap Masking between this PM Mask and the real PM shape

the result would be the PM turning into only (00100100)

(exactly like in the above Gfxs. Bitmap Masking)

 

 

It's cycle cost but doable.

You just have two Mask shapes of the Gfxs:

-> One in Bit-pair for the PFs. Bitmap Masking

-> A second in 1bit form for the PMs. Masking

 

Cycles would be in 'normal way' something like 21cycles each

(2Bitmap Masking operation x 21cycles = 42cycles)

Is it something like this?

Edited October 13, 2011 by José Pereira

[Heaven/TQA]

yup. but don't we need only one mask? as it does not matter if you are using bitmap sprite plus overlay?

[Heaven/TQA]

ok... for the gates... 2 masks...

[José Pereira]

Jose... http://babek.info/li...l143/sprite.htm

 

Was that or something similar that learn about the 'Inverse'/put in those Black and learn about AND/OR/EOR but it was more than a Year ago and that time I didn't see anywhere the PMs vs PFs Bitmap Masking. It's an A8 only kind of thing...

Thanks.

 

 

But create two Mask shapes of the Gfx is the solution..

On the second, you copy the Gfxs Bit-pair Mask to an exactly copy of the bit-pair but in 1bit:

-> Each bit-pair (01,10,11) would be 0 on the 'Gfxs to Mask PMs shape'.

-> Bit-Pair (00) would be 1 on the 'Gfxs to Mask PMs shape'

Edited October 13, 2011 by José Pereira

[José Pereira]

Seperate masks are needed.

 

Or if the PM is aligned with the bitmap part, a translation table could be used (less memory but slower).

 

 

All this time and some posts later I finally get into the Rybags answer.

And without going anywhere... I really like to use my Head (and a lots of papers and pens also... by the way the one near me doesn't write more )

:grin:

Edited October 13, 2011 by José Pereira

[José Pereira]

Mrsid those Black Mask Tiles of the gfxs are what?

Bit-pairs of the Gfxs. or bit-pairs of the sprites?

 

On the C64 the guys are Hardware sprites only and then they would 'normal PRIOR' go always over Gfxs. bit-pairs.

If on the same scanlines you have Mask and no mask of sprites you can't use PRIOR, right?

This is saying that those Mask bytes aren't useful in hardware masking unless they are Mask bytes of the Hardware sprites...

But then, why they are in Dark Gray colour (Dark Gray colour is one of the Gfxs. bit-pairs)

If it is Gfxs. bit-pairs what they do in sprites if, for example, the next Gfxs. byte would have Dark Gray colour bit-pair and the sprite will go above it...

 

Now, related to this but for all A8 coders here:

Another thing that are making me thinking is that an hardware sprite is an Hardware sprite. In A8, for example, an A8 Player it's 8pixels wide and it doesn't need the outside bits like in the soft sprites shifting.

If I create a 1bit Mask copy of the Pillar (that, for example it's 10pixels wide) I would need 17 different walls frames for a single 8pixels Player according to the constant moving/approaching, Masking, moving/left Pillar untill the Player 8pixels are totally out of the Pillar.

This is because there are no shifting on the PMs. They are 1Player=8pixels.

You have to Mask 8bits of Player with 8bits of Gfxs. and the movement of the Player untill it left out a Pillar, for example would need 17different Masks, something like this:

 

 

Or can we just 'erase' one pixel eachtime one Player pixel goes under the Mask Gfxs.?

Edited October 13, 2011 by José Pereira

[mrsid]

I think you don't understand. The mask bitmaps are not drawn on screen, they are drawn in an invisible bitmap that is used to mask out pixels from the hardware sprite data dynamically.

[José Pereira]

I think you don't understand. The mask bitmaps are not drawn on screen, they are drawn in an invisible bitmap that is used to mask out pixels from the hardware sprite data dynamically.

 

Yes, I understand that point... you put them in what you call VRAM.

O.k. I see. I was in an A8 'type of' thinking... Of course you on C64 can directly Mask the sprites as they are also bit-pair.

You can have one Mask and the same Mask can be used like it is for a Hardware sprite or for a soft sprite. you just Load it and Mask with other bytes, are they soft/Gfxs. bits or hardware sprites bits.

 

 

But then, how you handle if the hardware sprite (like it is 12pixels wide on C64 Multicolour) and it's moving 1Hi-resolution pixel at a time untill all the frame is outside the Mask Gfx.?

(On C64 it is even more steps as C64 can move the sprites in 1:1 ratio over Gfxs. even if the Gfxs. are in 2:1 ratio)

Edited October 13, 2011 by José Pereira

[José Pereira]

Hi guys.

Now that I learn so many new things and I think we all know that we can Mask soft sprites and PMs by software and that we also think the best way to go it's Bitmap Mode GR.15 that we can port directly the Gfxs. (and I also get almost direct port the STE86 sprites shapes into A8) and probably all the screen build (probably also the Gfxs vs Sprites Mask routine) and if we get the authorization from all the C64 people involved on their PoP conversion, I have to say that about the PMs. I finally see a good use them in overlays of the soft sprites.

The other Level screen would be more or less the same as the one I posted.

(all colours and the three different Enemys, Skeleton, Bottles and some secrets ... are now in perfect conditions)

For the other Level with the Yellowish Palace looking it could be like this:

(There's no clashes (there isn't PF3...), guys going over Flames, this Enemy would be this colour on the other screens (there are three type/3colour Enemys: Vizier, Guard and Fat Guard)

 

If I get time probably I'll start some things that are really needed to any coder who may want to start coding this ...

Edited October 14, 2011 by José Pereira

[Goochman]

After reading the blog and seeing the videos Id really like to play this on the 8bit Atari. If not Ill prob load it up on the Apple IIe I got.

Edited October 14, 2011 by Goochman

[Rybags]

I'm thinking here that it might just be a whole lot easier to use PMGs in 4-colour player mode with Playfield having priority over everything.

 

Then, no masking should be needed on PMGs. Less overall colours would be available but there'd be significant time and memory savings.

[José Pereira]

I'm thinking here that it might just be a whole lot easier to use PMGs in 4-colour player mode with Playfield having priority over everything.

 

Then, no masking should be needed on PMGs. Less overall colours would be available but there'd be significant time and memory savings.

 

yes, but to get this good looking Gfxs. there are at least one Gfx. that will Mask PMs&Soft sprites that has the Background Register in it's bytes, the Pillars:

At a first saw it seems difficult not to use the Black there and more, all the other walls Rocks have the Black 'bordering' pixels:

Edited October 14, 2011 by José Pereira

[José Pereira]

Another thing that I waste some time just to see how many bytes of Data would be all the Gfxs. bytes.

Here are all the real Gfxs. but if we had the Mask ones it seems, more or less an A8 screen full of Gfxs., like:

40bytes wide x 240 scanlines = 9600bytes.

Lets count then with 8Kb->9Kb of Gfxs. Data for each Level:

Edited October 14, 2011 by José Pereira