News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_redbox

Mode 3

Started by redbox, 15:00, 06 March 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

redbox

Quote from: TFM/FS on 17:41, 18 April 11
BTW: I'm not goint to present too quick here.


Hahahahahahahahahahahahahahahaha!


arnoldemu

Quote from: TFM/FS on 18:58, 20 April 11

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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

MaV

Quote from: redbox on 08:56, 21 April 11

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
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

FatAgnus

Quote from: MaV on 10:06, 21 April 11
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!  :laugh: :laugh: :laugh:

redbox

Quote from: MaV on 10:06, 21 April 11
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

Quote from: redbox on 12:03, 21 April 11
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
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

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

Quote from: sigh on 08:51, 21 April 11
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

Quote from: redbox on 08:56, 21 April 11

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.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

EgoTrip

Quote from: TFM/FS on 06:11, 22 April 11

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

Quote from: Axelay on 03:02, 22 April 11


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

Quote from: TFM/FS on 06:11, 22 April 11
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

Quote from: EgoTrip on 11:44, 22 April 11

What sort of cells? Whats the research for?

Saccharomyces cerevisiae, Aging research.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: redbox on 16:36, 22 April 11
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?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

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
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

redbox

Quote from: TFM/FS on 17:37, 22 April 11
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?  :-[
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

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

Quote from: ralferoo on 14:45, 27 December 12
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.
* Using the old Amstrad Languages :D * And create my own ;)
* Incorporating the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Animalgril987

Quote from: redbox on 14:43, 18 April 11Use 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)?

Powered by SMFPacks Menu Editor Mod