search

nesbox / TIC-80

TIC-80 is a fantasy computer for making, playing and sharing tiny games.
https://tic80.com
MIT License
5.03k stars 488 forks source link

clip() state should be in RAM #1508

Closed ddelemeny closed 3 years ago

ddelemeny commented 3 years ago

Actually it should probably be in VRAM, but memory is scarce up there. Anyway, it seems odd that this state cannot be peek'd/poke'd.

Use case: One can quite easily implement true-coordinates sprite drawing function using clip/spr, but this discards and overwrites any existing clip state.

nesbox commented 3 years ago

yes, we have only 3 free bytes in VRAM :)

nesbox commented 3 years ago

I moved the BLIT SEGMENT near the BORDER and got 4 free bytes for the CLIP data a54f4b1. VRAM looks now

>help vram
+-----------------------------------+
|          16KB VRAM LAYOUT         |
+-------+-------------------+-------+
| ADDR  | INFO              | BYTES |
+-------+-------------------+-------+
| 00000 | SCREEN            | 16320 |
| 03FC0 | PALETTE           | 48    |
| 03FF0 | PALETTE MAP       | 8     |
| 03FF8 | BORDER / BLIT SEG | 1     | <<<
| 03FF9 | SCREEN OFFSET     | 2     |
| 03FFB | MOUSE CURSOR      | 1     |
| 03FFC | CLIP              | 4     | <<<
+-------+-------------------+-------+
joshgoebel commented 3 years ago

😮 And now we have 0 free VRAM.

Oh wowsers...

joshgoebel commented 3 years ago

From chat:

Will this affect compatibility with previous games that use Blit Segment on TIC-80 0.80.1344 and 0.90.1723?

@nesbox

nesbox commented 3 years ago

Yes, it will affect if you used blit segment in 0.80 and 0.90, but here I'm ready to put up with it, almost nobody uses it. Also, I think, we have to release the dev version (0.91) asap to prevent using the old address.

joshgoebel commented 3 years ago

Oh ok. :-) If you're fine with it in this case, that's good. :-)

nesbox commented 2 years ago

I removed CLIP data from the VRAM here a6b4b7e, a lot of complaints from users. Sorry.

joshgoebel commented 2 years ago

Why, because it also broke border color?

nesbox commented 2 years ago

Yes, also a lot of carts uses poke(0x03FF8, color) instead poke4(2*0x03FF8, color) and this changes the blit segment. So, as usual, we can't change the spec to not break compatibility.

joshgoebel commented 2 years ago

I would suggest that in the future we simply not reserve half bytes or make some default "Bad behavior" if they are written to, to insure they are truly reserved... so the memory map which now says that the high nibble of border is "reserved" is probably technically incorrect as we'll never be able to use it without breaking all the cartridges which poke the whole byte.

nesbox commented 2 years ago

Agreed, I changed the wiki.