spritesort reduces spriteflicker

Page 5/13
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By JohnHassink

Ambassador (5389)

JohnHassink's picture

21-03-2010, 20:35

@ manuel: you inspired me to check. Smile

Topografie = screen 4
Eindeloos = screen 4
De Sekte = screen 4
Tempo Typen = screen 4
Zoo = (surprisingly?) screen 5
De Grotten van Oberon = can't find the MSX2 version but I suppose screen 4
Kruiswoord & Rekenwonder = couldn't find, probably screen 4
Breaker = screen 8

...I feel like I'm forgetting some game(s)...

List on Generation MSX

By Manuel

Ascended (15527)

Manuel's picture

21-03-2010, 21:11

Well, at least I was right with Breaker Smile (It's the only one I had in my head, but apparently it's the only other one existing Smile

Kruiswoord is also in screen 4.
Grotten van Oberon MSX2 as well (intro in screen 5).
Rekenwonder also.

By JohnHassink

Ambassador (5389)

JohnHassink's picture

21-03-2010, 21:53

Ah, additional research. Nice. Smile

So Radarsoft were quite the screen 4 fans. Wink

Actually, I try to think of more screen 8 scrollers from any company, but I really can't come up with others than these two...
While both games prove it's well possible to execute.

By AuroraMSX

Paragon (1901)

AuroraMSX's picture

21-03-2010, 23:06

Wasn't Zanac-Ex in screen 8?

By JohnHassink

Ambassador (5389)

JohnHassink's picture

21-03-2010, 23:13

Zanac-Ex is screen 5, as are its Aleste follow-ups.

By hit9918

Prophet (2853)

hit9918's picture

22-03-2010, 18:30

@ARTRAG
how fast is blitter over a full frame i.e. average on screen 8? is the tile aproach needed because it is still too slow for 1/16?

My idea would be, like, the blitter does the 1/16 thing and also it does blit a vertical pixel line at the border that I fill with cpu just out 98h. This would need a blitter with destination modulo = screenwidth and source modulo = 0 (I use Amiga terminology, thats the blitter I know).

If I then got such scroll device, I would do tile considerations on top of that with cpu. CPC style.
BTW what about out 98h and messing the vdp on msx2? is it still there? are there problems while blitter is running?

However as you talked about "repetitive" things I wonder whether you are about attacking the mass of the 1/16 copy itself with a tile system. The fast ZX spectrum games must have done something like this, only scroll the parts that are not blank. And maybe they got the charset (software charset) 8 times scrolled in memory.

By PingPong

Prophet (3327)

PingPong's picture

22-03-2010, 18:51

@ARTRAG
how fast is blitter over a full frame i.e. average on screen 8? is the tile aproach needed because it is still too slow for 1/16?

My idea would be, like, the blitter does the 1/16 thing and also it does blit a vertical pixel line at the border that I fill with cpu just out 98h. This would need a blitter with destination modulo = screenwidth and source modulo = 0 (I use Amiga terminology, thats the blitter I know).

If I then got such scroll device, I would do tile considerations on top of that with cpu. CPC style.
BTW what about out 98h and messing the vdp on msx2? is it still there? are there problems while blitter is running?

However as you talked about "repetitive" things I wonder whether you are about attacking the mass of the 1/16 copy itself with a tile system. The fast ZX spectrum games must have done something like this, only scroll the parts that are not blank. And maybe they got the charset (software charset) 8 times scrolled in memory.

hti9918: to summarize:

VDP engine copy speed:
- "byte mode" 170kb/sec in active area. 20% more in vblank, 17% more in active area if you disable the sprites.
- "pixel mode" about 100000 pixels/sec.

VDP copy operations are uninfluenced by the screen mode used.
VDP fill operations are about twice times faster than copy operations.

vdp operations works on rectangular areas.

For speed, detailed info check here : http://map.grauw.nl/articles/vdp_commands_speed.php

sending data to ports 98, while the blitter is working is PERFECTLY acceptable. blitter speed is not affected by z80 outs. no corruptions occours. time ago i've done a massive test in screen 5 at 60hz while having 4 bands of 8 sprites aligned on scanline and while the vdp does a pixel copy the z80 executes a bunch of outi. no problems at all.

By hit9918

Prophet (2853)

hit9918's picture

22-03-2010, 18:59

By the way I had issues when writing to vdp color register on MSX1, is it normal that it wrecks the vdp write address pointer for out 98h?
Maybe its low byte becomes the register number?

And when I do in 98h after an out 98h, it does read the byte I did just out, i.e. one address ahead the write pointer.
But still does increment the pointer, when I write it out again, then I get the duplicate with an untouched byte in between.
Is this mechanism somehow usefull for copy?

Is Bluemsx correctly doing these things?

By hit9918

Prophet (2853)

hit9918's picture

22-03-2010, 19:25

Ah, I knew I had seen a table, but googling I could not find it any more. The funny thing is the site doesn't mention the chip. I guess it is 9938 and not 9990 Wink

256*192*50/16 -> 153k per second, that is the ballpark you are mentioning.
the competition too does snip the border and have status bar, so
240*176*50/16 -> 132k. just go down till it works, and then tease the Amiga with rainbow gfx Tongue

Well I would try, but I am busy developping a MSX1 smoothscroller. The MSX must scroll! LOL!

By PingPong

Prophet (3327)

PingPong's picture

22-03-2010, 21:35

Ah, I knew I had seen a table, but googling I could not find it any more. The funny thing is the site doesn't mention the chip. I guess it is 9938 and not 9990 Wink

256*192*50/16 -> 153k per second, that is the ballpark you are mentioning.
the competition too does snip the border and have status bar, so
240*176*50/16 -> 132k. just go down till it works, and then tease the Amiga with rainbow gfx Tongue

Well I would try, but I am busy developping a MSX1 smoothscroller. The MSX must scroll! LOL!

from the site. here the table of copies. in bytes/frame:

LMMM accuracy: 16 HMMM accuracy: 32 YMMM accuracy: 32

Spr / Lin - Speed 50/60Hz Spr / Lin - Speed 50/60Hz Spr / Lin - Speed 50/60Hz

on / 212 - 1232 / 976 on / 212 - 3552 / 2784 on / 212 - 4192 / 3168
on / 192 - 1264 / 1008 on / 192 - 3616 / 2880 on / 192 - 4384 / 3360
off / 212 - 1584 / 1312 off / 212 - 4384 / 3616 off / 212 - 5856 / 4832
off / 192 - 1584 / 1312 off / 192 - 4384 / 3684 off / 192 - 5856 / 4864
--Blank-- - 1600 / 1344 --Blank-- - 4512 / 3776 --Blank-- - 6112 / 5120

LMMM = logical (pixel) move between vram and vram
HMMM = high speed (byte) move between vram and vram
YMMM = vertical non boxed area move (bytes) between vram regions (similar to hmm but does not allow to specify width, that is always the entire screen width)

Now, for example, using a resolution of 256x192 @60hz, with sprites on, give 2880 bytes / frame for a HMMM operation, thus 170kb /sec

clear?
this is v9938/v9958
v9990 is 9 times faster.

Let we know about your work. it's interesting

Page 5/13
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10