poll:outrun for msx2

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

By zPasi

Champion (438)

zPasi's picture

16-07-2019, 16:10

Grauw wrote:

For turns use the V9958 horizontal scroll.

Better not. Not everyone has MSX2+.

Or use that, and the adjust register as a fallback for MSX2.

By ARTRAG

Enlighted (6234)

ARTRAG's picture

16-07-2019, 19:28

https://youtu.be/jSS08co8zvA
IIRC this is a sample of what you can do with line split of the pattern table.
The sole issue is that the code is synchronization to the line rate

By Grauw

Ascended (8377)

Grauw's picture

16-07-2019, 20:32

@ARTRAG Which section of the IO demo are you referring to? The 3D plane Overflow describes here splits the colour table (r#3) rather than the pattern table (r#4). I suggest to split the name table (r#2).

@zPasi Adjust is not an option since it needs to scroll more than 16 pixels per line.

But with the second approach I described you won’t need horizontal scroll anymore so it’ll work on MSX2, and you only need to set one VDP register per line so the split will be tight:

Grauw wrote:

In screen 4, have 8 name tables. Then on the bottom third of the screen (race track), set up a series of splits which for each line selects the name table corresponding to the line number modulo 8. Now you can address the screen as if it had a 64x32 name table with 8x1 patterns. Updating the bottom third of the screen takes 2048 writes, or 36864 cycles with OUTI (61.7% CPU @ 60 fps).

Those splits spanning 64 lines will take 14592 cycles (24.4% CPU @ 60 fps). Together with writes that’s 86.1% CPU. Adding overhead, maths, gameplay and music, it seems pretty tight… Would be cool if it’d work out though! Luckily there’s the half-res (8x2) option, or reducing the height to less than 64 lines, as escape measures to lower the CPU cost.

p.s. I wonder if this technique of 8x1 or 8x2 patterns could be useful for some other type of effect?

By ARTRAG

Enlighted (6234)

ARTRAG's picture

16-07-2019, 20:58

Grauw wrote:

@ARTRAG Which section of the IO demo are you referring to? The 3D plane Overflow describes here splits the colour table (r#3) rather than the pattern table (r#4). I suggest to split the name table (r#2).

@zPasi Adjust is not an option since it needs to scroll more than 16 pixels per line.

But with the second approach I described you won’t need horizontal scroll anymore so it’ll work on MSX2, and you only need to set one VDP register per line so the split will be tight:

Grauw wrote:

In screen 4, have 8 name tables. Then on the bottom third of the screen (race track), set up a series of splits which for each line selects the name table corresponding to the line number modulo 8. Now you can address the screen as if it had a 64x32 name table with 8x1 patterns. Updating the bottom third of the screen takes 2048 writes, or 36864 cycles with OUTI (61.7% CPU @ 60 fps).

Those splits spanning 64 lines will take 14592 cycles (24.4% CPU @ 60 fps). Together with writes that’s 86.1% CPU. Adding overhead, maths, gameplay and music, it seems pretty tight… Would be cool if it’d work out though! Luckily there’s the half-res (8x2) option, or reducing the height to less than 64 lines, as escape measures to lower the CPU cost.

p.s. I wonder if this technique of 8x1 or 8x2 patterns could be useful for some other type of effect?

I miss the sense of this proposal, why this should be better than defining 2K of data in the color table or in the pattern table in the 3rd bank ?

By Grauw

Ascended (8377)

Grauw's picture

16-07-2019, 22:22

ARTRAG wrote:

I miss the sense of this proposal, why this should be better than defining 2K of data in the color table or in the pattern table in the 3rd bank ?

The basic premise is a curving road on the bottom third of the screen (64 lines) with sprites usable (rules out vertical scroll) on V9938 (rules out horizontal scroll). No scroll means the VRAM must be updated by the CPU or VDP commands. The target framerate is 60 fps for the most impressive smoothness.

Quickly considering screen 5 first, updating a 64×256 screen area (8K) by CPU or VDP commands (~3K/frame) is not feasible at 60 fps. So that’s out, and we turn to the lighter pattern modes.

Now considering screen 4, the first idea is to update the 2K pattern table and 2K colour table directly, with the name table filled with 0..255. However updating 4K is still too much for the CPU at 60 fps. Only updating the pattern table (2K) means you limit the screen to two colours.

Additionally the layout of the pattern and colour tables is inconvenient, it’s not contiguously bitmapping the screen by line, so updating one line can not be done by 32 straight OUTIs. You need to interleave 8 lines for each pattern and I don’t think that can be done quickly or conveniently.

In my proposal you can populate a line with just 32 contiguous writes, 2K total, in full colour, at 60 fps. You can even define the patterns such that they have some texture.

By the way, I just re-watched the Vespertino trailer… it says 25 fps in-game. Ooowh Smile.

By Grauw

Ascended (8377)

Grauw's picture

16-07-2019, 23:39

Since we’re only using the bottom 256x64 area of the screen: offset the screen with r#23 so that the fourth quarter of the name table is scrolled into the bottom of the screen, and then you can select any of the four different pattern and colour table parts by changing bits 0-1 of r#4 and bits 5-6 of r#3.

A little memory saving trick to fit up to 32 pattern and colour tables in VRAM, maybe useful for some animation (road markings?) or scenic changes with no CPU overhead. (No sprites on line 216 though.)

Edit: Though you could also just use r#23 to cycle through the four parts of the name tables, while using them for quadruple buffering as well, without relying on the mirroring of r#3 and r#4. Also easier to avoid line 216 then (just don’t use the fourth quarter). Seems better actually.

By Metalion

Paladin (1005)

Metalion's picture

17-07-2019, 20:32

There are some very good ideas here ...
Is there someone willing to take the challenge ?
Smile

By Metalion

Paladin (1005)

Metalion's picture

19-07-2019, 10:57

Grauw wrote:

Those splits spanning 64 lines will take 14592 cycles (24.4% CPU @ 60 fps). Together with writes that’s 86.1% CPU

IMHO, it would be even tighter than that. A frame at 60Hz is indeed 59659 cycles, but you have got to substract the ISR service, which is around 6800 cycles on a MSX2. Therefore, you have 52859 cycles available. And the split spanning 64 lines, with writes, would take 97.3% CPU @ 60 fps (or 79.4% CPU @ 50 fps).

By PingPong

Prophet (3435)

PingPong's picture

19-07-2019, 11:26

Metalion wrote:
Grauw wrote:

Those splits spanning 64 lines will take 14592 cycles (24.4% CPU @ 60 fps). Together with writes that’s 86.1% CPU

IMHO, it would be even tighter than that. A frame at 60Hz is indeed 59659 cycles, but you have got to substract the ISR service, which is around 6800 cycles on a MSX2. Therefore, you have 52859 cycles available. And the split spanning 64 lines, with writes, would take 97.3% CPU @ 60 fps (or 79.4% CPU @ 50 fps).

That's what i said. It's easy to do bunch of math and tell "is possible". Different is a complete solution.

By PingPong

Prophet (3435)

PingPong's picture

19-07-2019, 11:30

Instead i think would be more useful to investigate how those kind of games worked on onther tile based system, like the C64. Because the 6502 @ 1Mhz is not a so moster of processing power i think one could see.
Obviously, if there are some specific features (like hw scrolling & screen split) not available on msx (2) things can became harder.....

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