MSX VS Spectrum 3D graphics.

Enlighted (6935)

28-02-2014, 19:35

Just a side note: my "player" has all tiles precomputed and stored in ROM and/or in VRAM
The sole useful thing I see for a 3d polygonal game is that my technique allows double buffering in screen 2 on a plain msx1
I see no other gain apart avoiding frame tearing.
Add that colors are shared among middle and lower banks, so you cannot draw freely color images.
As you know the 512 tiles share 256 color definitions taken from the upper bank.
Willing to go for a 3d game (not me), I would suggest monochrome filled polygons on msx1 (using a window of 256x128 and the special hybrid mode you know) and wireframe graphic on msx2.

Having said that, the zx spectrum version would be in any case faster (maybe of few % points, but faster). I wouldn't see real room for improvements in an msx1 version of 3d polygonal games from the zx.
In the end, but this is also my taste, I see no real point in a port that would have the very same graphic and about the same speed of few frames per second (or less).

By hit9918

Prophet (2932)

28-02-2014, 19:41

@ARTRAG,
I thought of the blank parts of a polygon getting rendered only in the nametable.
These parts go fast and they save charset.
With 50% blanks, the whole thing could go in normal fullscreen screen 2.

Like you draw a very low res polygon where every dot is a char of 8x8 pixels.
But the corners need allocation of new chars and then draw bitmap style within there.
That needs quite some algorithm.

Another issue is to deal colorbleed.
Like two polygons touching each other makes 2 colors, is ok.
But first one polygon was drawn over sky color, then comes the other polygon.
Need to kick out the sky color.
What just was called "sky" color could also be color of another polygon that already was drawn there. such things.

By ARTRAG

Enlighted (6935)

28-02-2014, 19:52

Well, your proposal works perfectly for monochrome filled graphic and double buffered screen 2.
Not sure how easy would be make it work and how big would be the gain, if any, when you deal with far objects or small details (i.e. when a large part of the picture is composed by different 8x8 tiles).
Maybe Freescape games on zx spectrum already have this kind of optimization as their graphic looks generally very simple.

By PingPong

Enlighted (4137)

28-02-2014, 19:54

in this kind of game the speed is only influenced by the cpu time needed to calculate 3d Graphics, not by the time needed to physically plot the gfx on screen that's because speccy vs msx make not so much difference.

Try with other kind of games, where you have a heavy VRAM update (like 2d games from speccy) and you will see that msx speed is somewhat less. However, in most of situations speed is enough. the vdp bottleneck is always seen more exagerated as it is.

By hit9918

Prophet (2932)

28-02-2014, 20:04

It's hard to estimate the border draw when one not knows yet.
Maybe a color cube demo goes faster than ZX mono.
When most of the screen is just nametable draw.

Well and if those games are trick optimized and still crawl that much.
Then maybe most time is spent in 3D.

Like, the MSX does copy mono fullscreen in 20fps.
When something does 1fps, what is that, like 20 times overdraw.
Or maybe rather all the matrix multiply.

By PingPong

Enlighted (4137)

28-02-2014, 20:15

ARTRAG wrote:

Having said that, the zx spectrum version would be in any case faster (maybe of few % points, but faster).

One thing that is always not considered is how much the z80 is slowed down from the ULA circuitry.
Plus the msx z80 is also suffering from the M1 wait state.

So what is the REAL CPU speed? how much the ULA work does slow down the z80 on speccy? on msx we estimate about a 15-20% of slow down because of the M1

By Daemos

Prophet (2065)

28-02-2014, 23:39

Quote:

So what is the REAL CPU speed? how much the ULA work does slow down the z80 on speccy? on msx we estimate about a 15-20% of slow down because of the M1

From what I see in real life I would say that the numbers are pretty correct. We also forget about the fact that we need to handle interrupts which take time as well. SFX, SCC, FM all of these things need to be on the interrupthandler. Unless you choose not to handle anything on the interrupt. Skip sfx, music and no linesplits will give a certain speed gain in that aspect.

There is another aproach I read about however. Lets say you like to use speeded up CPU's like R800. You could do alot of code execution inbetween the out's. So a lot of optimization comes into play as well.

By sd_snatcher

Prophet (3659)

01-03-2014, 00:57

Another important factor to mention is that on those converted games, the MSX will be emulating the ZX-Spectrum video all the time. In real time and while loading each frame to the VDP, the CPU has to:

1) Convert the bitmap format from linear to tiled
2) Expand the tile color information to 8x, since the MSX has 1 color per line and the ZX-Spectrum has 1 color per 8x8 pixels.

By hit9918

Prophet (2932)

01-03-2014, 06:11

And the actual problem is that the MSX is not coded yet!

The ZX topics always sound like MSX is bad.
The cause is "I want EXACTLY that game on another mchine".
Well shall we try that the other direction?

Ok, I just snipped many lines of tekknobabble, it was the article "how C64 cannot port... Athletic Land"
The ZX immedeately went off the radar.
And on NES 16x16 pixel tiles, no penguin adventure.

Trying to port an MSX game, wanting SAME game, will end in tears.
The MSX with the extreme 9918 with BRILLIANT port IO.
Ok, 9918 fan is done, now lets continue with how to make ZX game.

By hit9918

Prophet (2932)

01-03-2014, 06:57

It was long time not clear, but the big problem is not port IO, but doublebuffering.
No two screens fit into vram.
All the years, there has been nooo shouts of "help, I cant do the colorgame because of framerate".
Instead there was no colorgame at all.
Dreaming of ZX games enhanced with sprites, the sprites wobble versus the software sprites.

And now the idea:

You need timed code starting from vblank interrupt.
You copy as much of the new buffer till the beam hits same location as your copy work.
At that point you flip to "the sprite attribute table that belongs to the old buffer".
As the beam continues, it will show the old buffer.
And the hardware sprites will be in same position as in the old buffer.

There will still be tearing, but the problem of "hardware sprites wobble versus software sprites" is gone.
It will be like the monochrome ZX ports.

for nice copy to screen 2 one would arrange nametable in vertical columns.
but this time is wanted the stantard screen 2 layout because of the way the copy progresses versus the beam.
the RAM buffer is linear.