Mode 3

[redbox]

BTW: I'm not goint to present too quick here.

Hahahahahahahahahahahahahahahaha!

[arnoldemu]

Hmm. In this case I see not a real difference from DI.

Try using the stack pointer and push/pop with DI and then with this code
They are different.

[MaV]

Hahahahahahahahahahahahahahahaha!

Now really, was this necessary? He's probably up to his ears in work and can hardly raise his eye-lids when posting here, much less code a nice piece of assembly code in that state.

Give him the benefit of the doubt and let's wait until he comes up with something.

MaV

[FatAgnus]

Now really, was this necessary? He's probably up to his ears in work and can hardly raise his eye-lids when posting here, much less code a nice piece of assembly code in that state.

Give him the benefit of the doubt and let's wait until he comes up with something.

MaV

I can't believe it (again)... I agree, TFM could be right. let's wait, free time is not always so easy to obtain!
But he is wrong, THE MASK ALWAYS DO THE JOB! 

[redbox]

Now really, was this necessary? He's probably up to his ears in work and can hardly raise his eye-lids when posting here, much less code a nice piece of assembly code in that state.
Give him the benefit of the doubt and let's wait until he comes up with something.

I think you miss the point of my laughter; TFM was the one who said MODE 2 was fastest and he would prove it.


And now he's already making excuses before even posting anything.


I find this funny.  Very funny.   

[MaV]

I think you miss the point of my laughter; TFM was the one who said MODE 2 was fastest and he would prove it.

And now he's already making excuses before even posting anything.

I find this funny.  Very funny.   

Ok. Of course, it doesn't look too good, if he claims mode 2 sprites are faster, and can't show results in time.

But still, maybe he's just got a lot of work to do right now.

MaV

[Optimus]

Something irrelevant but very very funny and wow. The blue background from Axelay's example creates a great optical illusion. It's like diagonal smooth shade from darker blue to brighter blue. Me, trying to find where the colour changes, but it's all the same tile. Wow! (I know I must be sounding crazy

[Axelay]

I had at look at this in winape. So when you say that "Narrowing the screen has saved only 2 scan lines (down to 60) but it would be multiplied by the number of sprites you have in a game, so it all adds up.", 
Does this mean that that the more sprites you have in the game, the more scanlines that you save in comparison to mode 1 and mode 0?

Sorry, perhaps I should have said it too, but andycadley was exactly right, the sprite routine I am using is exactly the same speed, regardless of mode, and only the sprite data and mask bytes change.

But otherwise, yes.  This is a single sprite, so if you had 8 sprites, rather than being 2 scan lines faster than my previous example, it will be 16 (in any mode!).  Not enough for an extra sprite, but easily enough for some other required processing, such as movement, animation or collision.

tbh, I dont think any mode would be faster than another, because the fastest way of dealing with screen data is to ignore resolution and deal with it at the byte level rather than the bit level.  Not so practical with backgrounds though, you'd end up with a nasty, irregular looking ink 0 coloured border around the sprites.  Beyond that, I think any variation that could give a speed benefit in any particular mode almost certainly comes with some form of limitation, but it's balancing them out that is the fun part of software sprite code imo 

[TFM]

Hahahahahahahahahahahahahahahaha!

What's the problem? May some of us have a real live, and currently I'm working with 135 single living cells, and I have to process them every 75 minutes. I can put them to 8 degrees for not longer than 9 hours (during every night). I have to do this for at least 20 more days. So sorry, if I take resarch more important than my hobby.

[EgoTrip]

What's the problem? May some of us have a real live, and currently I'm working with 135 single living cells, and I have to process them every 75 minutes. I can put them to 8 degrees for not longer than 9 hours (during every night). I have to do this for at least 20 more days. So sorry, if I take resarch more important than my hobby.

What sort of cells? Whats the research for?

[sigh]

Sorry, perhaps I should have said it too, but andycadley was exactly right, the sprite routine I am using is exactly the same speed, regardless of mode, and only the sprite data and mask bytes change.

But otherwise, yes.  This is a single sprite, so if you had 8 sprites, rather than being 2 scan lines faster than my previous example, it will be 16 (in any mode!).  Not enough for an extra sprite, but easily enough for some other required processing, such as movement, animation or collision.

tbh, I dont think any mode would be faster than another, because the fastest way of dealing with screen data is to ignore resolution and deal with it at the byte level rather than the bit level.  Not so practical with backgrounds though, you'd end up with a nasty, irregular looking ink 0 coloured border around the sprites.  Beyond that, I think any variation that could give a speed benefit in any particular mode almost certainly comes with some form of limitation, but it's balancing them out that is the fun part of software sprite code imo 

Hmmm. There seems to be less reason for using mode 2 for games apart from utilising the 640 width.

[redbox]

What's the problem? May some of us have a real live, and currently I'm working with 135 single living cells, and I have to process them every 75 minutes. I can put them to 8 degrees for not longer than 9 hours (during every night). I have to do this for at least 20 more days. So sorry, if I take resarch more important than my hobby.

That's not what I said, and I have already explained this.

I laughed because you are already making excuses before posting any of your code.  This is funny.

I hope you do find some time because I'm really looking forward to you proving to everyone that Mode 2 has the fastest sprites.

[TFM]

What sort of cells? Whats the research for?

Saccharomyces cerevisiae, Aging research.

[TFM]

That's not what I said, and I have already explained this.

I laughed because you are already making excuses before posting any of your code.  This is funny.

I hope you do find some time because I'm really looking forward to you proving to everyone that Mode 2 has the fastest sprites.

Redbox, I'm not that stupid. And I made no excuse. btw. whats about 50 scanlines? Just be patient.

And BTW you said making these kinds of sprites is so easy. Now where are your routines? Can you only offend others (in a sophisticated way) or can you provide more than words?

[MaV]

Guys, please calm down.

Nothing was meant the way it was written down. Remember that this is written media which does not transmit facial expression and demeanor.


@TFM: So you're raising yeast? I knew a bavarian can't stand to be without his beloved beer.

MaV

[redbox]

And BTW you said making these kinds of sprites is so easy. Now where are your routines?

No point, everything I explained is available on the wiki and these forums - fast sprites are nothing new, hence me saying they are "easy".

However, making Mode 2 sprites the fastest would be new, and I look forward to your code.

[sigh]

Any more examples and tests to be shown on the mode 2?

[AMSDOS]

Appologies for Dragging this Big Topic back onto the Spotlight. I thought it would be worth mentioning that I found an article about this ACU January 86 page 44 & 45 and it comes with a program with a series of RSXs:


http://www.cpcwiki.eu/index.php/File:AmstradComputerUser14-0186_page_0044.jpg
http://www.cpcwiki.eu/index.php/File:AmstradComputerUser14-0186_page_0045.jpg



You can check out the article though the interesting thing this article mentions is that games like Tankbusters (yeah I know bizarre coincidence I mentioned it the other day), use this particular mode for drawing and erasing is done on the back screen and then flipped to the visible screen when it's done. Looks like I should be considering this for my little scroller? 

[ralferoo]

I still don't think there's any great advantage of using mode 3, as you simulate the same effect easily with palette switches. The only time you might want to do this is if you're swapping colour palettes line to line and don't want to change all 16 colours.

To achieve the same back and foreground effect, you just need to arrange the palette so the unused bits are ignored - and the way you achieve that is by replicating that colour for each unused bit. So for instance, for 2 4-colour mode 0 screens, you might have pens 0-3 for screen 1 and pens 0,4,8,12 for screen 2. To display screen 1, you set the palette to A0,A1,A2,A3,A0,A1,A2,A3,A0,A1,A2,A3,A0,A1,A2,A3 and to display screen 2, you set the palette to B0,B0,B0,B0,B1,B1,B1,B1,B2,B2,B2,B2,B3,B3,B3,B3. You could obviously vary this, so you could use four 2-colour mode 0 screens and flip between them.

[AMSDOS]

I still don't think there's any great advantage of using mode 3, as you simulate the same effect easily with palette switches. The only time you might want to do this is if you're swapping colour palettes line to line and don't want to change all 16 colours.

To achieve the same back and foreground effect, you just need to arrange the palette so the unused bits are ignored - and the way you achieve that is by replicating that colour for each unused bit. So for instance, for 2 4-colour mode 0 screens, you might have pens 0-3 for screen 1 and pens 0,4,8,12 for screen 2. To display screen 1, you set the palette to A0,A1,A2,A3,A0,A1,A2,A3,A0,A1,A2,A3,A0,A1,A2,A3 and to display screen 2, you set the palette to B0,B0,B0,B0,B1,B1,B1,B1,B2,B2,B2,B2,B3,B3,B3,B3. You could obviously vary this, so you could use four 2-colour mode 0 screens and flip between them.

Yeah I was having a play around with the program which was in ACU, though when that program demonstrates the change from the back screen to the front screen and visa-versa, the process is really slow. I'm not entirely convinced games like Tankbusters is using this to simulate the movement of things like the shapes or tanks unless there's a fast technique of switching the screens over, though I don't see how given Kev's example was running at the same rate as the program in ACU.


Though your right in that palette switches could be used to simulate the same effect and would seem to be seen to produce a fast result.

[Animalgril987]

Use faster LD instructions where possible - LD (HL),C is faster then LD (HL),&40 etc
4) ANDing the byte and ORing it with what you want is a quick way to mask
5) Use SET and RES to go up and down screen lines

Surely point 5 is out, as SET and RES each use an extra byte (&BC)?