SW Sprites in screen2

صفحة 4/5
1 | 2 | 3 | | 5

بواسطة PingPong

Prophet (4093)

صورة PingPong

10-07-2011, 21:22


Can the z80 do the same, without being totally bound to gfx? I think the blitter in this situation can help a lot.

The z80 potential: two pixel in one outi, 9 cycles per pixel on screen 5! blitter was 44 cycles per pixel...

Example 32x32 pixel core:

loop:
5	exx
288	16x outi for 32 pixels
5	exx
12	add hl,de ;offset to next line in vram
14	out (c),l
14	out (c),h  ;h got setwrite bit already set. well what about screen 5, me MSX1 coder.
14	djnz loop ;line counter
--
352 cycles

the vdp can do a box transfer, you simply set the box width and height then do a bunch of outi.
Save 16xaddress setup operations
Of course, in this situation, you cannot have the blitter running, because the box transfer is already a kind of blitter command.

anyway you showed me only the ram-vram blit part.
there is a lot more, like restoring shadow RAM.

this does count.

And a pixel TPSET is not really a kind of something fast with z80 to emulate. you need nibble masking......

بواسطة Paulbrk

Hero (611)

صورة Paulbrk

10-07-2011, 21:39

on this games, the background is black, but the hard and Soft sprites goes on the background tiles too.

Look in this video:
http://www.youtube.com/watch?v=XkKM0hFQuks

On minute 1:58, the red dust is making a color clash.
On minute 2:06, the ghost is making a color clash.
On minute 3:31, the helicopter missile has 3 colors.

This soft sprites can move not only on black background, can be on platforms tiles too.

I recomend you to play Goody and see how it is. The speed is very cool.

بواسطة hit9918

Prophet (2927)

صورة hit9918

10-07-2011, 21:45


anyway you showed me only the ram-vram blit part.
there is a lot more, like restoring shadow RAM.

10.5 cycles per pixel when the blitter does copy back shadow RAM.


And a pixel TPSET is not really a kind of something fast with z80 to emulate. you need nibble masking......

I thought of that high speed square to be always plain byte copy,
i.e. need stuff 2x rotated in RAM, and corner stuff handled different.

But what game do you actually have in mind?
About the Blade Lords video my thoughts are: use sprites.

If the player is a BOB, got 2 16 color sprites per scanline,
and if you take the burden to craft sprites with 3 colors per scanline,
then you got 4 sprites per scanline.

The sceletons and green things look like 3 color sprites.

بواسطة hit9918

Prophet (2927)

صورة hit9918

10-07-2011, 22:21


http://www.youtube.com/watch?v=XkKM0hFQuks
On minute 2:06, the ghost is making a color clash.

Yes, tricky arrangements in there. But I would like to see the ghost go thru the bar with the many blue shades ;)

The most important part is that the game does not take the ZX route, where all tiles must have a black background color.

Also, as MSX overlap is per line and not per 8x8 block, the problem can turn out less dramatic.

بواسطة PingPong

Prophet (4093)

صورة PingPong

10-07-2011, 22:29

@Hit9918:
I'm thinking about a sort of generalized way to convert zx speccy games on msx. two objectives:
if the game can be really improved on msx1: handle the max with sw sprites .
if only on msx2: (no scrolling) handle the sw sprites with vdp operations like in 3D isometric games (KnightLore MSX2)

بواسطة hit9918

Prophet (2927)

صورة hit9918

10-07-2011, 23:38

@PingPong:

I think the answer is that the z80 doing monochrome is faster than the blitter.

There are so many ways to doing things that one can't give a general answer,
one would have to look at a ZX game and then discuss how it would be best done on MSX.

Look at this one: http://www.youtube.com/watch?v=e6FJxFtZ63k . Look at 2:48, the ZX likes fat BOBs.

Now, if instead of a direct port you rewrite this to MSX2.
Then with player and bullets going 60fps because of hardware sprites,
the thing might end up with better gameplay even when the blitter BOB is halve the framerate.

On the other hand, the thing is 8 tiles wide,
that means MSX2 can do it as hardware sprite in 3 colors per scanline.

MSX1 could still do it with monochrome hardware sprites, and the non-direct port would be smoothscrolling in 16 colors with charset ;)

بواسطة Paulbrk

Hero (611)

صورة Paulbrk

11-07-2011, 09:18

Yes!!! Xenon on MSX2 can be like 16 bits, I will like to see it some day Hannibal

بواسطة Paulbrk

Hero (611)

صورة Paulbrk

11-07-2011, 12:59

This games are not in MSX1 or MSX2, I sugest you to take a look.

This games are 3D, can run very well on a normal MSX, but on acelerated z80 or Turbor can be more playable.

Carrier Command:
http://www.youtube.com/watch?v=ZfBHu97Yqt0

Total Eclipse 1 & 2, Castle Master 1 & 2(this video only shows Castle Master, but Total Eclipse runs with the same engine):
http://www.youtube.com/watch?v=CyFK6xqjms4

All this games has a 16 bit versions, on a MSX2 or Turbor can be much better, maybe a fix on an speccy conversion to fill the poligons with screen5 colors?

بواسطة Paulbrk

Hero (611)

صورة Paulbrk

11-07-2011, 18:13

Some of you are going to make a ZX game conversion?

بواسطة PingPong

Prophet (4093)

صورة PingPong

11-07-2011, 19:42

@hit9918, Paulbrk:
the problem is that i need to find a general solution for a little number of games, that allow a easy port from ZX.
converting sw sprites to hw ones, often require a massive number of changes, and very often you cannot remove the sw sprite part. so you end up with two routines, hw & sw, increasing the amount of memory.
a better solution is to replace the z80 sw sprites approach with a vdp handling.
on zx, there is a backbuffer that via LDIR is always copied to the effective VRAM.
On msx2 one can avoid this by doing page flipping.
write on page 0
set as visible page 0
write on page 1
set as visible page 1

instead of ZX approach
write on backbuffer
LDIR to VRAM
write on backbuffer
LDIR to VRAM

etc.

i think this could compensate the slowness

صفحة 4/5
1 | 2 | 3 | | 5