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.

TFM

Quote from: FatAgnus on 09:49, 13 April 11
Ssg is right.
You need 3 colours in mode2, "ink"+"black"+"transparent", so you can't simply "OR it" (if you want a USEFUL routine, of course)

But Mode 2 _HAS_ only two colors. A mask is senseless there. Look at Bollawares prods.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: arnoldemu on 09:17, 13 April 11
a fast sprite drawing challenge!
this will be fun.

Think so. Now let's define some parameters... Screen format... sprites size.... how to measure time (100 moves of the sprite?).... background or no backgound?   

Tell me what you want ... I don't care.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

andycadley

Quote from: TFM/FS on 19:17, 13 April 11

But Mode 2 _HAS_ only two colors. A mask is senseless there. Look at Bollawares prods.

That's exactly why you need a mask, two colours isn't enough.

Let's consider a very simple example, a sprite like Dizzy who is basically a big blob with eyes. If you use ink 0 as transparent and ink 1 as white there is no way you can draw him without making his eyes transparent, which is going to look exceptionally ugly as he wanders around the world. You need a seperate mask so that you can make his eyes black, his body white and the space around him transparent. It's basically essential for all but a handful of limited scenarios.

The two key cases where you could avoid masking are where the entire background is ink 0, but then you could equally well OR a Mode 0 or Mode 1 sprite, or for extremely simple sprites which are just a solid block of colour. Now that is handy for bullets, but you can use the same optimisation of just ORing onto the display in Mode 1 or 0 by just drawing your bullets entirely in ink 3 or 15 respectively.

FatAgnus

#53
Quote from: TFM/FS on 19:17, 13 April 11

But Mode 2 _HAS_ only two colors. A mask is senseless there. Look at Bollawares prods.


Sorry, you are wrong: the mask does the job.

EDIT: Oooops, Andycadley was faster and better.

TFM

Quote from: andycadley on 19:57, 13 April 11
Let's consider a very simple example, a sprite like Dizzy who is basically a big blob with eyes. If you use ink 0 as transparent and ink 1 as white there is no way you can draw him without making his eyes transparent, which is going to look exceptionally ugly as he wanders around the world.

You are absolutely right in this case.

But solid tanks and jets don't have eyes  ;D  Ok, I'm always taking space games as reference in mind. For Sprites with two colors you can do something else. Just directly draw them. Routines will be a bit more complex, but really quick.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

Quote from: FatAgnus on 20:00, 13 April 11

Sorry, you are wrong: the mask does the job.

EDIT: Oooops, Andycadley was faster and better.

No, I'm not.

Andy is right with Dizzy.

But I'm right with SpaceWars.

It depends on the final application, the way you like to use them.

Look f. e. at the FutureOS mousepointer, no mask is needed, and I guess it get's the job done. I have no better example, because I don't consider Mode 2 (at the moment) for games.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

FatAgnus

Yes, you are.
If you want to win "because I was talking about this game, not about this other", nice then.
Nice to meet yourself.



andycadley

Well except for the fact that in something like Spacewar you can just OR (probably even XOR) the sprites regardless of the mode, so it's definitely not faster in that case.

TFM

#58
Quote from: FatAgnus on 20:36, 13 April 11
Yes, you are.
If you want to win "because I was talking about this game, not about this other", nice then.
Nice to meet yourself.

You miss the point! It's not about a particular game. It's just in which way you want to use the sprites. Again look at Bollawares prods f.e. and then it may be nice to meet yourself - or whatever :-\

Quote from: andycadley on 21:00, 13 April 11
Well except for the fact that in something like Spacewar you can just OR (probably even XOR) the sprites regardless of the mode, so it's definitely not faster in that case.

If you OR them it's way faster... that brings us back to the sprite benchmark.  8)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

FatAgnus

Sorry again, but "THE POINT" is obvious here, very very obvious.

EDIT: I feel BANHAMMER over my head, so, "oh yes, you are right, thanx!". Ok?

TFM

Quote from: FatAgnus on 21:29, 13 April 11
Sorry again, but "THE POINT" is obvious here, very very obvious.

EDIT: I feel BANHAMMER over my head, so, "oh yes, you are right, thanx!". Ok?

What's your problem? Afraid of a discussion? Do you like to make a personal problem out of it?

Ok, I leave this thread now. Have fun alltogether. :P 8)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

Xyphoe

Please don't fall out guys! This could be (and was/is) an interesting topic and very useful ... even if I don't really quite understand large parts of the technical discussions!  :-*

redbox

Quote from: TFM/FS on 01:11, 14 April 11
Ok, I leave this thread now. Have fun alltogether. :P 8)


Ah, don't go - I was hoping to see that you might finally admit you were wrong for once...?


Was an interesting topic too.  :)

arnoldemu

Quote from: TFM/FS on 20:33, 13 April 11
It depends on the final application, the way you like to use them.
Yes I agree. It does depend on application.

So the way to solve this would be to define various scenarios, and then each person can implement a method that works in that scenario.

to me the ultimate timing would be to see the timing of the raster bars in the border. If we define how the timing is done, we can also then compare and find the fastest.

I think it would be a interesting way to look at how sprites can be drawn.



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

sigh

This is a fantastic idea!!

It's also very likely to create new thoughts and techniques that may not have yet been discovered.

FatAgnus

Quote from: Xyphoe on 02:06, 14 April 11
Please don't fall out guys! This could be (and was/is) an interesting topic and very useful ... even if I don't really quite understand large parts of the technical discussions!  :-*


Yes, you are right Xyphoe. You are cent per cent right.
About the "contest", as long as Executioner can be considered winner (why wasting time? :-X ), it would be very interesting to know who gets the second place.
My bet is for Syx.

andycadley

Quote from: FatAgnus on 10:45, 14 April 11
About the "contest", as long as Executioner can be considered winner (why wasting time? :-X ), it would be very interesting to know who gets the second place.

If we end up with a library of fast sprite routines that can be used, everyones a winner!  ;)

FatAgnus

#67
QuoteIf we end up with a library of fast sprite routines that can be used, everyones a winner! 

Yes, you are right too.  ;) :laugh:

SyX

Niño que sepas que te aprecio mucho y que tengo que invitarte a unas birras ó lo que prefieras, pero me vas a poner gordo con tanto halago  :laugh:

FatAgnus

#69
Quote from: SyX on 12:48, 14 April 11
Niño que sepas que te aprecio mucho y que tengo que invitarte a unas birras ó lo que prefieras, pero me vas a poner gordo con tanto halago  :laugh:


Why?
I give you THE SECOND pos, not the first one!  :laugh:
A Executioner-Grim-Rhino duel could be mythical! but, of course, they don't need to prove anything ;) 
...wait... if so, then you are fourth! Sorry about that!  ::)

SyX


sigh

Quote from: andycadley on 12:14, 14 April 11

If we end up with a library of fast sprite routines that can be used, everyones a winner!  ;)

So very true.

TFM

Quote from: redbox on 09:22, 14 April 11

Ah, don't go - I was hoping to see that you might finally admit you were wrong for once...?


Was an interesting topic too.  :)

Nice! And Thanks! So if you want to see me wrong, that's easy - just let's make the sprite benchmark contest. I already said, you can define all parameters. If I do it, then maybe some guy would call it ballenced. So all paramerters free for you to define. But seeminly nobody wants that. Give it a try, proove me wrong  ;)
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

TFM

#73
Quote from: arnoldemu on 09:27, 14 April 11
Yes I agree. It does depend on application.

So the way to solve this would be to define various scenarios, and then each person can implement a method that works in that scenario.

to me the ultimate timing would be to see the timing of the raster bars in the border. If we define how the timing is done, we can also then compare and find the fastest.

I think it would be a interesting way to look at how sprites can be drawn.

Aehm... if I get you right... then you suggest the following:
- switch border to different color
- move sprite (or just draw sprite, or??)
- switch border again to other color

Right?

Ok, can somebody define the other paramertes (size, screen format, background)?
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

sigh

A weekend start? (Not to sure how long it takes to do these things...)

Really am interested in these results!

Powered by SMFPacks Menu Editor Mod