Largest sprites on CPC (size & number) ?

[fgbrain]

Hi everybody!!


My bro wants to know: 

Which demo has the largest 50hz-software sprite on CPC,
both in size (in bytes) and/or amount (1,2, ... 20 etc) displayed on a fully background screen OK ?

Let's count them!

[Gryzor]

Is he going to produce something bigger and better?

[norecess]

Balls in Zap't'Balls are huge, 50hz-animated with background.


Otherwise, I would have answered Xyphoes Fantasy, unfortunately it's not 50hz-animated.




Oh, sorry, I know you spoke about demos but demos are more about scrollers you know..

[redbox]

For number of sprites, I'm pretty sure that the Boules and Bits demo holds the CPC record.

[TomEtJerry]

Hi

Croco Meeting 4 intro has two big sprites ! That's right sprites technic are not the most used one in "big demos" (too time consumming I suppose).

T&J/GPA

[fgbrain]

Thanks all for replying..
It's been years that I'm not active in the scene, and my point is that there's not such information clearly on the wiki..

Croco Meeting 4 intro has two big sprites !

yes, but with no background 
So, my sprite (size) record remains http://www.cpc-power.com/cpcdemos/index.php?page=detail&num=1484   ?
I cannot believe it!!!

Balls in Zap't'Balls are huge, 50hz-animated with background.

I remember Multi-Ball part of the Facehugger Ultimate MD is similar.. http://www.cpc-power.com/cpcdemos/index.php?page=detail&num=148

For number of sprites, I'm pretty sure that the Boules and Bits demo holds the CPC record.

The Balls-record is a nice idea!

[redbox]

So, my sprite (size) record remains http://www.cpc-power.com/cpcdemos/index.php?page=detail&num=1484   ?
I cannot believe it!!!

Interesting demo, not seen this one before!  I like the Sam Cooke music too. 


I see the sprite is large... it appears that they way it's drawn means you could have used some optimisations for shifting the bytes...?  Otherwise I'm assuming you would have used a more complex drawing.  Is it running at 50hz?


Not technically a sprite, but Axelay used software to scroll the parallax backgrounds in his Sub Hunter conversion.  This appears to be the most impressive and recent demonstration of shifting serious amounts of bytes using only software techniques.

[TFM]

Now, how big is that sprite (pixel or bytes)?

[MacDeath]

no youtube video of this record holding demo then ?

[redbox]

Now, how big is that sprite (pixel or bytes)?

I calculate it to be &fe6 bytes in size.

[TFM]

I calculate it to be &fe6 bytes in size.

Ah no, it's never one quarter of the screen.

EDIT:  I looked at it more preceisely, it's close to 2000 bytes.

[redbox]

Good point - I think the screenshot I took must have been in false dimensions.

[TFM]

Good point - I think the screenshot I took must have been in false dimensions.

You should do a bigger one ;-)

[fgbrain]

If you read the text it says: 118x41 pixels - in mode 0 its 2419 bytes.
but its a shame really.. There are NO other suggestions? 


We can talk about games too, but I dont think we can find 50hz-sprites..

[Optimus]

I remember the cpc meeting 50 demo. I like the converted graphics in the background and the big sprite is nice idea. Though, it's obvious that all pixels are filling the rectangle block so you don't have to OR with the background, only to replace a rectangle area of the previous background (which is even either a horizontal line or vertical bytes because the sprite doesn't move in a faster or more arbitrary way (sinus or something)).


Now, since I first joined the scene (in 1999) I have heard rumours about a very very big sprite in a demo that doesn't fully work anymore.
http://www.pouet.net/prod.php?which=27791
It runs for a while but then the disk is corrupted and nobody seems to have the good original anymore. So, I haven't ever seen this big sprite part and can't imagine how big it could be.

[TFM]

If you read the text it says: 118x41 pixels - in mode 0 its 2419 bytes.
but its a shame really.. There are NO other suggestions? 


We can talk about games too, but I dont think we can find 50hz-sprites..

Well, it look smaller than 41 lines, more like 36 lines, but it doesn't matter.

Games are different! They must work properly in many circumstances. So look at Game Over (1 or 2?) and at that two player space game where these two guys (at the same time) were in space fighting very big space ships... was it Forgotten worlds? I forgot!

In a demo in contrast it's way more easy, because you have very defined circumstances. But where is the gain in big sprites if they are not used for something? Just to show that they exist? Well take a calculator and see how big they can be    For games on the other had big sprites are very cool - and 50 fps or not doesn't matter. 

[fgbrain]

@optimus
Well, about the chain demo-part by EGS, you're right. I don't think anyone has a proper version of this demo 
But still, I don't expect anything better than what we see at ZaptBalls game.

But where is the gain in big sprites if they are not used for something? Just to show that they exist?

You have a point here, but then what's the purpose of demomaking afterall?

I think that if we optimize routines we can see better games as well..

[TFM]

You have a point here, but then what's the purpose of demomaking afterall?

Sure, right! Had a bit more games in background. It's wonderful to see demos, but I always think how it would be working in a game. Sure a lot of effects are just great and not ment to be shown in games :-)

I think that if we optimize routines we can see better games as well..

Absolutely :-)))

[Axelay]

Found myself wondering how well the sub hunter scroll code would work on a single big 'sprite' at 50hz, so here's a rough little example I put together of it.


The sprite is quite limited in what it can display, it couldnt be a full bitmap, just a simple rectangular word.  The background is just a repeated test tile, but it could be any bitmap image, so the sprite isnt relying on background repetition.  There are 50 scan lines unused, which I'd judge enough to add an arkos tune and a simple writer comparable to that used in the Chaos 50 demo.  The dimension of the sprite is 119x59 pixels.


But no, I can't see it being particularly useful in a game outside of the odd special case! 

[Devilmarkus]

Thats looking cool!
Would be nice to see the ASM sources...

[TFM]

Have you seen PUSH? Just imagine about 3K of them 

[fgbrain]

@axelay
Well done, nice try!! 
Your routine is more capable than mine of this old Chaos 50 demo.

Still, having read the intro text of Vectrix Part (Chain demo)...
I just wonder about what EGS claims about sprites 'with a size of a fullscreen' are possible ?
and HOW if answer is yes? (or perhaps not on 50hz..)

[Gryzor]

Found myself wondering how well the sub hunter scroll code would work on a single big 'sprite' at 50hz, so here's a rough little example I put together of it.

Heh, really nice!! Is there a reason why the bouncing sprite doesn't reach th edges of the screen?

[TFM]

@axelay
Well done, nice try!! 
Your routine is more capable than mine of this old Chaos 50 demo.

Still, having read the intro text of Vectrix Part (Chain demo)...
I just wonder about what EGS claims about sprites 'with a size of a fullscreen' are possible ?
and HOW if answer is yes? (or perhaps not on 50hz..)

Well, think about it. Small sprites are easy to do, because they need few cpu time, right?

Very big sprites let's say a sprite that uses 90% of the V-RAM are also very easy to do, for the same reasons. Got it?

[Axelay]

Thats looking cool!
Would be nice to see the ASM sources...

Attached.  Bear in mind it was a bit of a quick hack job just to try out using the stack pointer, so makes "excessive" use of index registers and isnt commented, except for the bits of code I took from my previous masked sprite example a few months ago.

Still, having read the intro text of Vectrix Part (Chain demo)...
I just wonder about what EGS claims about sprites 'with a size of a fullscreen' are possible ?
and HOW if answer is yes? (or perhaps not on 50hz..)

If it was meant to be a "hardware" sprite, surely it's some combination of screen splits?

Heh, really nice!! Is there a reason why the bouncing sprite doesn't reach th edges of the screen?

I thought it'd look better that way?     Well OK then, the "sprite" is actually larger than it appears.  There's an extra byte either side and two above and below it that, rather than have sprite data drawn to, copies the background screen from a 'refresh buffer'.  That way it (innefficiently) covers it's tracks and looks like something that is passing over a background image without destroying it.  Thinking about it, it would not have been hard to fudge it to make it hit the edges either.