Graphic, Sound, & Coding Tips / Tricks / Effects / Etc. Tools for development

[elmer]

It's taken me a couple of cups of coffee to get my old head around what you're describing.

Very Cool! 

It's fun to figure out how to achieve some nice effects.

I'll be interested to see the demo if you decide to put one together.

Isn't this going to have a pretty high CPU & memory cost for any large pattern? 

Do you envision using this in a game level, or is it more of a title-screen/demo-mode effect?

Could you see this technique helping you with a PCE version of Sonic?

[touko]

I'am also interested of how many CPU+RAM this effect could cost .

[Bonknuts]

All the approaches I've been looking at, are all for in game stuffs. Some might be on the extreme side - but still allowable for some type of game engine. I had the above line style one clocking in about ~55% cpu resource with a 120x192 dynamic tile window.

 By demos, I mean playable. I have shmup engine that I'll use for a few examples (forced scrolling always lends itself to nice optimizations). I need to make a platform engine to demo on.

[touko]

55% is huge,and not bad at same time !!
There are only 45% remaining for all the rest, it's short .
It's doable for a plateformer i thing, or for non intensive datas transfert games .
If you can keep most of datas in VRAM, 45% should be enought .

[Bonknuts]

So this is just theoretical, but there's a possible way to save some cycles when doing modifications to stuff stored in vram.

 So say you need to modify just the LSB or MSB of data in vram. Normally, you set the read and write positions to be the same, and do a redundant read/write in order for the process to be updated. I.e. dealing with modifying only a byte, but you have to write a word for the pointer to be updated.

 So here's something that might help out:
Normally, you would do something like LDA $0002, sta $0002 and then write new data to $0003.

 That read/write $0002 is 12 cycles (+1 penalty for each access to the port). So, is there an instruction that could read and write back to the same address without modifying the data? Yes. TRB or TSB are read-modify-write instructions. As long as Acc is zero, nothing will be modified. The instruction is 7 cycles for Absolute addressing. So, given that there should be a +1 and another +1 for the read and write back, total cycle count should be 9 cycles.

 With Acc as zero, use either X or Y to update the data for $0003. Both X and Y are flexible enough for reading in data from an array; LDX array,y or LDY array,x. And both can write to the vdc port as well.

[touko]

Eh like you said before, tom you have a winner here ;-)
Very interesting trick.

[Bonknuts]

I was specifically thinking tilemap and tile stuffs (dynamic tiles), etc - but there's something else that's interesting you can do with this.

 Say you have a sprite cell that you want to dynamically clip holes into it to show parts of the background onto if it. I.e. creating a fake priority layer to certain pixel in the BG @ position x,y on the screen. Normally, you would do this in local memory and AND a mask against all planes. AND'ing all planes creates holes in the sprite cell.

 Ok, so you have a "clean" sprite cell in vram. The object (no pun intended) is to write to a new cell in vram - the updated "look" of the cell. This bypasses having to transfer from main memory to vram after the ANDing process.

 Something like
lda table.lo,x
trb $0002
lda table.hi,x
trb $0003
inx

 VS
lda $0002
and table.lo,x
sta $0002
lda $0003
and table.hi,x
sta $0003
inx

 Both approaches keep the source and the destination cells in vram, but the first method is 30 cycles VS 36 cycles of the second one. Of course you could optimize it a bit more with some unrolling, but the difference will always come from the TRB vs lda/sta.

 Something I also thought about, but don't have an idea of what to use it for... is a TRB on $0002 followed by a TSB on $0002. I wonder if it would read back what's in the buffer (the modified byte). Probably not. But I should test just in case.

[touko]

Not bad at all,but actually is less than 30 cycles(in fact 28 in the first method)and you must count the setting of vram read pointer,it's negligible when you have to do it multiple times .

Code: [Select]

lda table.lo,x        ; 5 cycles
trb $0002            ; 7 cycles + 1
lda table.hi,x        ; 5 cycles
trb $0003            ; 7 cycles + 1
inx                      ; 2 cycles

total =                28 cycles


[Bonknuts]

There could be in fact no penalty cycles for TRB. It's unknown because the extra penalty cycle for LDA, STA,Txx, and ST0/ST1/ST2 is done inside the CPU (anything accessing $1fe000-1fe03ff) and not a wait state thing from the VDC. It's possible TRB/TSB doesn't have it, or has +1 overall, or has +1 for the read and +1 for the write. I would have to test it.

 It's weird how for example ST1 is listed 4 cycles, but since it writes to $1fe000-1fe03ff range, it has the internal +1 penalty. As far as I know, there's no difference between the 6280 and 6280a for this penalty area.

[touko]

It's weird how for example ST1 is listed 4 cycles

Yes even in official doc is listed as 4 cycles .
i don't understand japanese, but is doesn't seem that there is any penalties when accessing VRAM, unleast nothing in official doc seems to suggest that .

Are you sure that this kind of penalities are really here ??

[elmer]

Eh like you said before, tom you have a winner here ;-)
Very interesting trick.

Yep, Xanadu 2 is using the TSB/TRB trick for writing the font data ... together with self-modifying code to switch between TSB and TRB opcodes in order to set the color.

I've not looked at Xanadu 1's font code yet.

[Bonknuts]

Yep, Xanadu 2 is using the TSB/TRB trick for writing the font data ... together with self-modifying code to switch between TSB and TRB opcodes in order to set the color.

 That's awesome!

[touko]

Yep, Xanadu 2 is using the TSB/TRB trick for writing the font data ... together with self-modifying code to switch between TSB and TRB opcodes in order to set the color.

Thanks, very interesting to know .

[elmer]

Yep, Xanadu 2 is using the TSB/TRB trick for writing the font data ... together with self-modifying code to switch between TSB and TRB opcodes in order to set the color.

That's awesome!

In the case of Xanadu 2 it's more of a way to be "clever" than "fast".

They're drawing a 12x12 glyph as 3 separate passes of 4x12 pre-shifted strips ... pretty slow and ugly with a lot of changing of VRAM pointers.

Even the Xanadu 2 8x12 glyphs (that don't exist in Xanadu 1) are still drawn in 3 passes.

If you look at Xanadu 1's text on-screen ... the way that the glyph outlines overlap really suggests that they're doing the same.

Because I've not looked at it, yet, I'm not sure if they are dynamically-generating the thick-and-outlined glyphs from the ROM font data, or if they are stored in the game data.

Either way ... since they're using 4x12 strips, then I can probably hack the font system to do bi-width glyphs in the same way that I did for Team Innocent (that's plan A).

[Bonknuts]

Audio!