Chained vs. un-chained SCBs

[+bhall408]

9 minutes ago, 42bs said:

Take the source and add some debug output in susie.cpp

Of course

 

I really should have just asked if that theory was plausible (and thus worth pursuing)... My gut says yes...

[42bs]

17 minutes ago, bhall408 said:

Of course

 

I really should have just asked if that theory was plausible (and thus worth pursuing)... My gut says yes...

Yes. At least I would do. Static objects that just vanish (thus setting the SKIP flag in the SCB). Makes a lot sense.

[+bhall408]

Ms. Pac-Man has 200+ objects per screen (if you count dots as objects).

 

I thought earlier I recall it being said that 130 or so was OK (presumably for 60fps)

 

Would 250 or so be reasonable (on actual hardware) for 30fps or 20fps? (and given that the majority of them are single pixel)

 

...and at some point I'll see if I can get an max chained object count for Ms. Pac Man and report back

 

[Cyprian]

19 hours ago, 42bs said:

Don't judge a 30 year old machine by today's possibilities.

 

 

I'm far from judging Lynx, I just see a different between two 34 year old solutions - amiga's one and Atari's one.

For a "clean" mode the first one reaches 1.79MB/s and the second one 4MB/s - thanks to using all available memory slots.

 

We don't know yet how internally Lynx's blitter works, but we know it can shows much much more sprites in one VBL than amiga and ST gathered together.
 

 

 

[42bs]

1 hour ago, Cyprian_K said:

 

I'm far from judging Lynx, I just see a different between two 34 year old solutions - amiga's one and Atari's one.

For a "clean" mode the first one reaches 1.79MB/s and the second one 4MB/s - thanks to using all available memory slots.

 

We don't know yet how internally Lynx's blitter works, but we know it can shows much much more sprites in one VBL than amiga and ST gathered together.
 

 

 

The latest sprite record on the ST is 268 4 color sprites. Let's see if Suzy can beat this.

 

 

Ah and this one (unchained):

 

https://demozoo.org/productions/180262/

Edited July 11, 2019 by 42bs

[Cyprian]

3 hours ago, 42bs said:

The latest sprite record on the ST is 268 4 color sprites. Let's see if Suzy can beat this.

 

https://demozoo.org/productions/180262/

 

yep, Leonard did a great job, but this is a software record for 16x16 two bitplane (4 colors) sprites.

In case of hardware blitter's sprites, Lynx is still ahead of both machines:

- STE: 21 sprites 32x32 16 colors with background clearing:

 

- STE: 17 sprites 32x32 16 colors with restoring background:

- A500: 13 sprites 32x32 16 colors with restoring background

 

- A500 with FastRam: 21 sprites 32x32 16 colors with restoring background

 

[snes2600]

On 7/7/2019 at 10:09 AM, 42bs said:

I made a small test drawing the Phobyx logo wobbling with a sinus (like demo0006) once with a chain of 102 SCBs (w/o size and palette reloading) and as 102 separate sprites (flipped, but this is only the drawing order).

(See https://github.com/42Bastian/lynx_hacking/tree/master/chained_scbs).

 

Chained is always quicker and on a Lynx II it can be drawn in a single frame at 60Hz.

But not on Handy.

 

Just wanted to share this.

Out of curious, how do I compile that to a Handy lynx image for testing?

[42bs]

13 minutes ago, snes2600 said:

Out of curious, how do I compile that to a Handy lynx image for testing?

You do not have to. Handy can read the .o files.

[snes2600]

Using the Ms. Pac-Man speedup Handy fix (1/1 sprite r/w), I get 60 fps. Stepped each frame to be sure; looks butter smooth.

[Songbird]

On 7/10/2019 at 10:40 AM, karri said:

Guys. What a pity you tell me this now. I could have written On Duty with linked sprites but now I am too far in the project for changing the design. I already used the RAM for other things and there is no way to change this any more.

Does it matter for linked vs. separate for RAM layout? As I recall, all SCBs need to be located in Lynx RAM anyway.

[42bs]

There is no other RAM. But linking  SCBs might save some RAM because you do not have to repeat parts of it.

But actually it is more a speed thing. 

[+karri]

If you have 70 tiles on the screen there is a big difference if you have 70 sprite structs in memory or one.

[Nop90]

In Nutmeg  I used three sprites structures to handle background, tiles am font.

 

This limits  the performance obviously. During the last week of the competition I could reorganize the code and found memory for a 50 sprites chain, but using it the FPS speed decreased.

 

Don't know why, maybe a mistake by me or maybe the two large starting sprites to draw the scrolling bg.

 

Not having time to debug it I had to revert to the first solution.

 

I should try to do it again to understand what happened

[enthusi]

Chained is naturally much faster for more sprites. In Lacim I started with 100 sprites chained but rewrite that whole part later on. You can also generate those chains on the fly in real time with code generators

In Assembloids things like the score are chained.

[+karri]

Have you found some optimum for linked sprites in Lacim?

"Asking for a friend "

[LordKraken]

Quote

 I could have written On Duty with linked sprites 

Just out of curiosity, you're not using linked sprite at all? Or do I misunderstand something?

I had the feeling that for tile-based game, linked sprite was  the only viable solution in term of performance.

[42bs]

My (unproven) impression is, that you gain from linked SCBs if you can limit reloading.
What I have not yet tested is, if Suzy also benefits from sorting the sprites from top left to bottom right. You _have_ to do it for objects in the Jaguar.

[LordKraken]

ok I guess by reloading you mean using the "skip" flag on the SCB that does not need to be drawn?

[42bs]

16 minutes ago, LordKraken said:

ok I guess by reloading you mean using the "skip" flag on the SCB that does not need to be drawn?

No, I mean, you can tell if size, tilt, skew and palette should be loaded from each SCB. So if all sprites are of the same size, no need to reload it.

But if chaining pays off is really a case to case decision. No general rule.

For example the sprite-record demo: You need to set for each sprite the new x,y values. So what is quicker: Setting it for all sprites in a loop and then draw the chain once? Or draw each sprite separately.

But this is more a less an academic question I guess.

[enthusi]

I would bet very high that it is faster to set x,y and draw as chain

[LordKraken]

Ah ok yeah I dont call that "reload" in my head  

but in typical tile-based game, like my bombercats for instance, SCBs have fixed position, same palette, so the only thing that gets update sometime is the data. So I'm 100% sure that in this case, linked sprites are way faster  (well I hope ^^)

Edited September 17, 2019 by LordKraken

[enthusi]

Actually I think it bombercats you might get away faster by only redrawing 'dirty' tiles one by one

But if you dont need any more speed, a fixed matrix might be more convenient indeed.

Edited September 17, 2019 by enthusi

[Fadest]

Many years ago, when we were learning to code on Lynx (well, still in learning process in fact :D), Anata wrote a small Mario like level with scrolling and 1 character you could control, but it was really slow.

I spent some time studying chaining and I rewrote his engine with use of chained sprite instead of drawing sprite by sprite. The new version was really smooth and playable.

But unfortunately, as fas as I know, he did not pusue his effort, and I'm pretty sure I have lost the source codes.

But after this, I always tried to make use of chained sprites.

[+karri]

Ok guys, I confess. On Duty does not use linked sprites at all. I draw them one by one. Actually when some tile is animated I draw that tile twice.

 

When I now look back I SHOULD have used linked sprites. I lost precious smoothness in the character moves because of lack of processing power. The problem is that On Duty use up all memory - literally. In some levels I even replace the entire content with new stuff from the cart. The downside is that enemies and data will spawn in any parts of the game that was re-loaded. The only level that suffers from it is the underground factory. If I now try to add linked sprites I must cut a third away from all my maps.

 

[LordKraken]

1 hour ago, enthusi said:

Actually I think it bombercats you might get away faster by only redrawing 'dirty' tiles one by one

But if you dont need any more speed, a fixed matrix might be more convenient indeed.

I though about it. And on paper that is optimal... if only the game was not so dynamic...

When you start having big explosions all over the place, marking the sprites to redraw might take more time than redrawing all of them at once.

but I might test it if i can think of a simple solution.