Stream texture

[Shazz]

Hello there !

I'm trying to code it but a question never killed anybody (or I hope so...), is it possible to stream a texture to the GS, I mean let's say that my framebuffer = a texture (not true but basically it is as I 'just' map a texture to the screen, the GS is not involved for any 3D rendering in my case) ?

And a want to update this framebuffer in parts and not globally (in my case, per line), so is it possible to only modify a part of the existing texture present in the GS memory ?

I try to see if I can tweak the TEX0_x Register to only update a part of the GS memory...with a good choice of the base pointer and TEX_DECAL switch...

[blackdroid]

uhm yes technically you can update parts of a texture.
but sending just on line ? what are you trying to achieve ( in any case im sure you will be wasting cycles )

[Shazz]

All the details are available on my blog : www.acerockerz.free.fr/blog/

But I can symmarize in a few lines :

The goal is to "externalize" the Planar2Chunky routine from the emulator core (so running within the EE) to the VU1, basically, the core sends the source videobuffer (organized in 4 planes) & the palette to the VU1 to perform the texture generation and then send the texture to the GS to display it on the screen : target framebuffer (a 2D buffer so).

So as the whole texture won't fit into the 16Kb my idea was to stream the source videobuffer line by line to the VU1 which can update the texture (the target videobuffer) and do P2C conversion, 16 colors to 16bbp...

Why line by line is because the Atari ST can handle palette update at each HBL so I wouls send each new line updated with the associated palette.

So, if it is possible I would fit into the 16Kb but maybe problems of sync and "DMA waits" can occur...

[MrHTFord]

Shazz,

AFAIR the Atari ST can have it's palette changed as and when you want. It's just a set of registers. Yes, lots of demos did change it in the HBL interrupt, but lots of plasma demos changed it constantly.

Anyway, it's been years since I did any ST stuff, so my memory could be corrupted.

[Shazz]

Hello Mr HTFord,

Nice to see an old ST coder here ! :D

Yep you're right, the palette register is usually changed at the HBL for rasters but nothing forbid to change it more frequently, I would think that the minimum should be 16 pixels as the planes are organized to handle 16 pixels so changing the palette in the middle of a plane should provoke I think really strange things....

I'll ask if there is some cases when it occurs... some demos...

By the way, this is more a technical challenge than to improve the emulation at this level, currrently the CaSTaway emulator core manage lines and not pixels so, it would be a good start ;-)

[Shazz]

Mr HTFord,

It's possible to change 1 color every 4 pixels. Or every 8, 16 pixels starting at any 4 pixel boundary.
4 pixels seems to be the lower possible count, because it match 1 nop of the 68000.

If you want to start a little crisis of nostalgy Mr HTFord, you can follow the whole topic : go there

It seems that a 100% ST emulator should send nearly each pixel with its color at the VBL counter time :D whoooosh :D

[Shazz]

uhm yes technically you can update parts of a texture.
but sending just on line ? what are you trying to achieve ( in any case im sure you will be wasting cycles )

So I made a few tests, so it is possible to update parts of the texture using the TRXPOS Register to setup the offset of the recafter having setting with the tangular area whre the transmitted buffer will be sent...

So basically after having setting the GS buffer address/size with the BITBLTBUF register, simply set where you want to copy the texture in the area...

So it is working, that's make me think that I can now make the VU handle only small part of the texture to do P2C and then stream it to the GS...

Blackdroid, do you see a potential performance issue here (DMA waits,... ???) ?