Creative ways for name table in screen 2/3/4

Enlighted (4136)

29-11-2022, 21:28

Hello, all. the pattern approach arrangement of those modes make possible to setup the nametable in various ways.
for example, the screen 2 settings of MSXBASIC arrange nametable by filling each position with a different pattern with sequentially assigned pattern no. It does repeat three times this setting.

This arrangement, allow the pattern mode to be seen as a true bitmap mode. Forget about nametable and make gfx commands work to pattern table.
The translation from a X,Y coordinate to an address however, while not so complex is not a thing that computationally is light as it does require shifts, bit manipulation, masking etc.

Here my question: someone had done or tryed different arrangements that allows for faster address computation or other advantages that are not the usual tricks (one patter table for three regions and so one)?

!login ou Inscrivez-vous pour poster

Par Wlcracks

Hero (565)

30-11-2022, 07:19

I think the original Konami MSX1 16k/32k serie games had a different screen 2 table setup compared to MSX basic. Maybe this had a reason to calculate faster. I don't think there are a lot of options due to the limits of the registers. Maybe only 2 for screen 2 from my bad memory. MSX2 i don't know, never looked in to that.

Par theNestruo

Champion (421)

30-11-2022, 08:51

Some ZX Spectrum conversions used a vertically aligned sequential assignment (0-8-16-.. in the first row, 1-9-17-.. in the second one, 2-10-28-.. in the third one, etc.).
I think this was intended to improve the rendering of software sprites, as larger vertical strips could be rendered in the pattern table.
I think I saw this in Tour 91, by Topo Soft, maybe? I don't remember exactly.

Par PingPong

Enlighted (4136)

30-11-2022, 12:33

theNestruo wrote:

that's interesting. what would be the best layout to approach zx spectrum layout?

Par Metalion

Paragon (1625)

30-11-2022, 14:35

theNestruo wrote:

Some ZX Spectrum conversions used a vertically aligned sequential assignment (0-8-16-.. in the first row, 1-9-17-.. in the second one, 2-10-28-.. in the third one, etc.). I think this was intended to improve the rendering of software sprites, as larger vertical strips could be rendered in the pattern table.

I'm using a similar set up in a game I'm working on, but in order to speed up ram to sprite transfer.
Indeed, the vertical alignment greatly improves that kind of transfer.

The calculation downside is that, instead of doing adr=32.y+x, you have to do adr=24.x+y.
And multiplication by 32 is fastest and easiest than by 24.

Par max_iwamoto

Hero (643)

30-11-2022, 16:11

Metalion wrote:

theNestruo wrote:

Some ZX Spectrum conversions used a vertically aligned sequential assignment (0-8-16-.. in the first row, 1-9-17-.. in the second one, 2-10-28-.. in the third one, etc.). I think this was intended to improve the rendering of software sprites, as larger vertical strips could be rendered in the pattern table.

I'm using a similar set up in a game I'm working on, but in order to speed up ram to sprite transfer.
Indeed, the vertical alignment greatly improves that kind of transfer.

The calculation downside is that, instead of doing adr=32.y+x, you have to do adr=24.x+y.
And multiplication by 32 is fastest and easiest than by 24.

Wouldn't be even better to have a table of all addresses in the order you like, that will take even less time.

Par theNestruo

Champion (421)

30-11-2022, 18:38

theNestruo wrote:

I think I saw this in Tour 91, by Topo Soft, maybe? I don't remember exactly.

Screenshot for clarification:

PingPong wrote:

that's interesting. what would be the best layout to approach zx spectrum layout?

Don't know. But this approach seems to be better for rendering large software sprites in the pattern definition table, as each vertical strip maps to a contiguous memory area. That may allow several interesting optimizations.

Metalion wrote:

The calculation downside is that, instead of doing adr=32.y+x, you have to do adr=24.x+y.
And multiplication by 32 is fastest and easiest than by 24.

Well, when blitting software sprites I think that that calculation being slower is the least of the performance problems, haha. Let's just add one more LUT table ^_^

Par PingPong

Enlighted (4136)

30-11-2022, 19:56

Metalion wrote:

theNestruo wrote:

Some ZX Spectrum conversions used a vertically aligned sequential assignment (0-8-16-.. in the first row, 1-9-17-.. in the second one, 2-10-28-.. in the third one, etc.). I think this was intended to improve the rendering of software sprites, as larger vertical strips could be rendered in the pattern table.

I'm using a similar set up in a game I'm working on, but in order to speed up ram to sprite transfer.
Indeed, the vertical alignment greatly improves that kind of transfer.

The calculation downside is that, instead of doing adr=32.y+x, you have to do adr=24.x+y.
And multiplication by 32 is fastest and easiest than by 24.

24= 16+8 ;-) both are power of two if you have computed x*8 you can save in some temp reg. then double and sum the result with tmp

Par PingPong

Enlighted (4136)

01-12-2022, 18:34

screen 3 has another very strange mapping between pixels and address. i'm wondering if anyone had used some arrangement to make a more easier way to translate (x,y) coordinates to addresss in order to allow faster plotting

Par Micha

Expert (103)

01-12-2022, 20:50

I actually never realised that screen 3 had a nametable, but it has... and it is complicated...

Par bore

Master (168)

01-12-2022, 23:25

Vertically works pretty well:

If you are going to redraw everything you can just render even columns into a ram buffer and the loop for odd column can or with the even column before writing to vram. That way you only have to set the address once per frame.

If you aren't accessing it sequentially you might be able to add some gap between each column so that the address is ((x & 0x3E)<<6)+y and x & 1 says if you are looking at high/low nibble.
It might even be possible to space it out so that the column pairs are 256 byte apart.