Moving SoftSprites over a PM

[José Pereira]

Hello to all.

 

 

I need today some answers into this:

 

 

 

Moving Soft Sprites over a PM could be simply choose the need Priority.

But (remember PeteD always saying not to think in Priorities, and rest it to the coder), but I always want to know if what I'm thinking/doing can be pratical possible and how to!...

 

 

 

I need to use PRIOR0 in all the Graphics.

 

 

 

- My SoftSprite it's PF0-Black.

- Enemy SoftSprite it's PF0-Black, PM0 and PM0Ored PF1.

 

 

Normal and everytime my SoftSprite (Black-PF0) overlaps Enemy, it will always be with PM0 colour above (Black always loose in OredOperation).

What I want to know is if I want that sometimes have Black goes in front of PM0, how to?

 

 

I see like having different shapes of PM0 according to thepossible diffrent ways of PM0 and my SoftSprite overlapping?

Or something like the Or/And Operation between SoftSprites and Backgr. graphics, but with Soft Sprite and PM?

 

 

Help please.

 

 

Thanks and greetings.

José Pereira.

[Rybags]

A softsprite is just normal playfield, it's as simple as that.

 

If you don't want PRIOR 0 colour changes due to the ORing, then you have to turn off the selected bits of the Player if overlap occurs, simple as that.

 

And that introduces it's own problems. Extra processing aside, if you have 4x stretched players, turning off 1 bit means that 4 pixels can be affected.

[José Pereira]

A softsprite is just normal playfield, it's as simple as that.

 

If you don't want PRIOR 0 colour changes due to the ORing, then you have to turn off the selected bits of the Player if overlap occurs, simple as that.

 

And that introduces it's own problems. Extra processing aside, if you have 4x stretched players, turning off 1 bit means that 4 pixels can be affected.

 

 

 

 

 

O.k. turning off the needed PMs. bits is what I want.

And in pratical, how to?

I reveal what I have in mind:

 

I sttoped LastNinja because I came into many, many new things, Screen redone, Masters Screens,... but one thing still the same from the very first time... PF0-Black: Ninja goes in front (behind it's instant...) of Enemy Clothes.

I can do all the LN(s) Screens ready to coding, only PM2&3 expanded for the Backgr. graphics.

PM0 must be for the Enemy Clothes. It's a normal size PM. with 6pixels wide maxim.

 

 

I think you understand better what I want now.

What you think of this on this particular case in LN? Possible? What difficulties you see?

 

 

Thanks.

José Pereira.

[Rybags]

Just do Last Ninja in 256 colour VBXE mode... may as well because it's probably the only way anyone will bother to do it a port attempt is made.

 

 

OK... maybe not. Possible options:

 

- keep OR-overlay PMs away from where the softsprite characters will be.

 

- give priority to ORed overlays (in front of ninja).

 

- use playfield/player combinations for ninja such that they don't interact with ORed overlays, ie PF2 won't combine with P0/P1, and P2/3 won't combine with PF0/1. Keep possible conflict areas elswehere.

Problem there is that player priority is set in stone, so Player 0 will always mask out Player 2 and 3.

Edited April 13, 2010 by Rybags

[José Pereira]

Just do Last Ninja in 256 colour VBXE mode... may as well because it's probably the only way anyone will bother to do it a port attempt is made.

 

 

OK... maybe not. Possible options:

 

- keep OR-overlay PMs away from where the softsprite characters will be.

 

- give priority to ORed overlays (in front of ninja).

 

- use playfield/player combinations for ninja such that they don't interact with ORed overlays, ie PF2 won't combine with P0/P1, and P2/3 won't combine with PF0/1. Keep possible conflict areas elswehere.

Problem there is that player priority is set in stone, so Player 0 will always mask out Player 2 and 3.

 

 

But what I want is getting LN like if it was in the Old Times.

The challenge is that.

I want to do things like what they can be on a real old Machine.

If no one code it, we still have a Slideshow. But it must be in a real/on a way to turn into a real playable Game.

 

By now, if you can, please just answer to this question, please?

 

 

Hope you understand my feelings.

 

 

Thanks.

José Pereira.

[Rybags]

Answer - if your enemy sprite has PM ORing, then you need to mask/turn off bits if he overlaps the ninja. Or just let the enemy be "on top" all the time. But that's not what you really want.

 

If you're only doing a slideshow, then none of that should be a worry anyway since you're constructing the screen by hand.

[José Pereira]

Answer - if your enemy sprite has PM ORing, then you need to mask/turn off bits if he overlaps the ninja. Or just let the enemy be "on top" all the time. But that's not what you really want.

 

If you're only doing a slideshow, then none of that should be a worry anyway since you're constructing the screen by hand.

 

 

 

Thanks Rybags.

And turning PM0 bits OFF and ON everytime Ninja/Enemy Overlap is possible/game speed in an LN Isometric Game alike?

 

 

 

 

Slideshow only if no-one pick-up the Game to Code. Sliddehow Screens but in a way to someone use them into a real Game. Even if this takes Ligh Years ahead...

 

 

 

 

 

Thanks again.

José Pereira.

[PeteD]

If I understand right you want to mask the PM (turn off bits/pixels as it goes behind the other sprite) ? In which case yes, that's what I've been talking about all along You could possibly work out how to do everything on every screen using PRIOR alone but it's so much easier to have one routine that masks everything be that PF or PM data in any situation. Processing time would be minimal impact (or at least a minimal difference to PF alone) because, let's face it, LN isn't doing a lot.

 

 

Pete

[José Pereira]

If I understand right you want to mask the PM (turn off bits/pixels as it goes behind the other sprite) ? In which case yes, that's what I've been talking about all along You could possibly work out how to do everything on every screen using PRIOR alone but it's so much easier to have one routine that masks everything be that PF or PM data in any situation. Processing time would be minimal impact (or at least a minimal difference to PF alone) because, let's face it, LN isn't doing a lot.

 

 

Pete

 

 

 

Great. I can do/continue my re-work in the way I think:

Only using PM2&3 for Background colour enhancements.

And from this I can have all the Screens using PRIOR0, the best.

 

No problem to re-start things...

 

 

Thanks and greetings.

José Pereira.