new sprite record

Page 1/3
| 2 | 3

By hit9918

Prophet (2911)

hit9918's picture

28-09-2013, 16:07

check out this demo:
https://sites.google.com/site/tueftlerlabs/home/downloads/de...
from
https://sites.google.com/site/tueftlerlabs/home/downloads

description:
in a historic event, the MSX1 beats the C64 in SPRITE SCANLINE PUNCH :D :D :D

C64 sprites must be 21 lines high, in 21 lines it can show 8 sprites,
but the MSX1 demo in same area shows 20 sprites :D

The MSX still has 4 sprites per scanline, but now it has variable height sprites, means empty lines not account for scanline budget.
Beats C64 only in some genres, but it is a surprise that anyone beat it in any genre involving scanline load.

But this thing is not only about small bullets:
Stacking sprites of variable height, MSX1 practicaly got linecolor like MSX2 :D :D :D

Examples:
The faces of green beret get face color. But the hat keeps green. Normaly, the empty lines of the middle sprite would cause extra scanline load, this is a thing of the past.
Mario can have red hat, rose face, blue suit in one sprite per scanline. The second sprite per scanline makes the blackframes. Or maybe something more SNES style :D

Login or register to post comments

By flyguille

Prophet (3028)

flyguille's picture

28-09-2013, 21:23

can you post some vids, or images?

how is that it has "variable height"?, oh, you move the sprite elsewhere on scanline interrupt?

By hit9918

Prophet (2911)

hit9918's picture

28-09-2013, 21:36

Does the download not work? The demo is in the msxfiles folder of demo20130928spriteheight.zip

By hit9918

Prophet (2911)

hit9918's picture

28-09-2013, 21:58

About the tech, you got to look at the demo with the sprite rack. The bullets are 4 pixel high, but normaly their 12 empty scanlines would cause so much load that you never could display such rack.

The deal is that empty lines of sprites DO make scanline load.
But with this engine no more, because the sprite list is sorted by Y! more precisely by (Y + sprite height).

But that discovery was just the start of the journey,
flicker no more works the usual way and a scanline exact flicker detector is asked,
the engine has to jump over these hurdles.

That rack demo maybe is a bit technical, but it really can make nicer mario sprites Smile

By hit9918

Prophet (2911)

hit9918's picture

28-09-2013, 22:07

Ok, a screenshot of the demo "exploding sprite rack" Smile
Normaly one cannot show such tight rack.

By Manuel

Ascended (18255)

Manuel's picture

28-09-2013, 22:20

How does sorting the sprites on Y help exactly?

By hit9918

Prophet (2911)

hit9918's picture

28-09-2013, 22:31

Imagine every bullet has 12 empty lines hanging downwards.
But the sprites who are more down on the screen got higher priority, so they razor the useless lines!

The engine makes that always the empty lines end up as 5th sprites and the useful things get shown.
The VDP is very upset, reporting 5th sprites all day, but the rack is stable Smile

By Manuel

Ascended (18255)

Manuel's picture

29-09-2013, 09:12

heheh, nice idea Smile

By PingPong

Prophet (3793)

PingPong's picture

29-09-2013, 11:44

@hit9918: you said "spritelist is sorted by y". What is the kind of algo have you used? (Quicksort, bubble, insertion or whatever?)

By hit9918

Prophet (2911)

hit9918's picture

29-09-2013, 18:10

@PingPong, I must give a funny answer!
ysort may take exponential time, the god of gradius would send me to hell, so I had to do a hyperfast sort Big smile
So... I use bubblesort Big smile

I run only one loop of it, and another one in reverse direction, and then I blindly bail out and leave the rest to the hardware sprite multiplexer that is still under the hood!

So, the list may still be somewhat unsorted. The result is no crash. The theory says that there may be "blinking in places where is critical scanline load".

In scanlines without critical contention, sprites can be sorted completely wrong, but the TMS shows them. While C64 software multiplexer must always walk a tidy sorted list down the TV beam.

With all the flicker handeling code, the ysort actualy takes a fraction of time. Would be no showstopper to double the sort work.
But I haven't seen the need for that yet. It must be noted that one again sees the MSX doing violent sprites with Y speed fed from RANDOM number generator.
The MSX with console sprites and console gameplay Smile

p.s.
but why bubblesort, with so low numbers of elements and so primitive instruction set, bubblesort is better than other algorithms.

By flyguille

Prophet (3028)

flyguille's picture

29-09-2013, 22:36

you means that the sprite Y are not updated in H interrupt?, that it is only a technic of what sprite plane is using each one bullet in a smart way?

I don't get it., how it shows up to 16 sprites in the same scanline.

it works in real MSX or just emulators?

Page 1/3
| 2 | 3