Timo 2019-08-20 18:38
I'm trying to simplify commands and functions which use bit-wise attributes. Here my current idea:
I'll remove the syntax with brackets and make the one with several optional parameters standard:
SPRITE.A n,[pal],[fx],[fy],[pri],[s]
ATTR [pal],[fx],[fy],[pri]
DISPLAY [s],[b0],[b1],[c0],[c1]
LFO.A v,[w],[r],[e],[t]
I would try to keep most of the existing programs working by ignoring brackets in the attribute commands.
Now the getter functions still have the binary format, this doesn't fit. A very simple solution is removing them, probably they aren't used anyway. If you really want to do advanced stuff, you could still use PEEK and POKE. So let's remove:
=SPRITE.A
=CELL.A
=DISPLAY
With CELL.A removed, the =CELL.C(x,y) function could be renamed simply to =CELL(x,y).
I would also remove the current idea of the binary mask of the ATTR command. It was used to overwrite only some specific attributes (not all) using the CELL command. But this requires understanding the binary attribute format and is complicate to understand. The main reason for this feature was changing the palette of existing cells on the screen, mostly for button highlights. So I think specific commands for this could be enough, for example:
CELL x,y PALETTE p
BG FILL x,y TO x,y PALETTE p
"PALETTE" is quite long, I could make "PAL" a keyword, but then it wouldn't be available as a variable name anymore.
I would make the character parameter of the normal CELL command non-optional to simplify it:
CELL x,y,c
Any better ideas? Would you miss getter functions for attributes?
moechofe 2019-08-20 21:46
Can you explain the reason of removing the optional c parameter for the CELL command? I think i’m using it.
I approve everything else. :p
Mrlegoboy 2019-08-20 23:13
ok i guess I'll just have to rewrite all of my code then? always felt like an idiot not remembering if it was palette or pallet so i like that. i really hate the way ATTR works, i like the idea of using 1 command to change a cell attribute.
was8bit 2019-08-21 03:35 (Edited)
Oh, I actually use a CELL.A a lot.... when using the screen as memory, when moving a character from one cell to another, you not only need its character# but also its palette# so you can delete it from one cell and reput it into another cell...
Timo 2019-08-21 06:24 (Edited)
@Was8bit, good point, that’s an issue.
@moechofe, for what exactly do you use CELL without the character parameter? What attribute do you change? (--> I don't want to remove the c parameter, I want to make it mandatory)
To all, what reason do you have to change cell attributes without changing a cell’s character?
Only for palettes or others, too?
was8bit 2019-08-21 10:18
I know flipping can be used for animation, and I've done that when I was only animating my player ... but for multiple animations it makes the code more consistent to use the same math to process the animation so I use 2+cells in that case
Timo 2019-08-21 19:13
I will rethink character attributes again then.
moechofe 2019-08-23 12:17
What about this:
ATTR [pal],[fx],[fy],[pri],[s]
ATTR a[,m]
Timo 2019-08-24 11:04
So, I’m thinking now about this approach:
Binary access to the character attributes will stay using the existing ATTR and SPRITE.A commands. Their syntax for separate flags will be deprecated (but kept for compatibility).
There will be new commands for replacing the non-binary ATTR:
PAL n
FLIP n
PRIO n
Both CELL and SPRITE will get new commands and getter functions for each attribute:
SPRITE.P
SPRITE.F
SPRITE.PR
SPRITE.S
You could set and get each attribute separately.
I’m unhappy though that palette and priority both start with P, buy that’s just cosmetic :/
And there would be:
BG FILL x,y TO x,y PAL n
BG FILL x,y TO x,y FLIP n
...
I think it’s ok to merge flip x and y to one value 0-3.
was8bit 2019-08-24 15:27
Sounds exciting :)
moechofe 2019-08-24 21:26
Sounds good to me
Timo 2019-09-06 19:22 (Edited)
Almost final ideas: https://twitter.com/timo_inutilis/status/1170039682996080642
was8bit 2019-09-07 04:23
Your examples on twitter look great :)