GAMELEGEND 2021-02-26 03:56 (Edited)
what is it suppose to do
99.99% of the time it just prints 0
was8bit 2021-02-26 04:57
IF the cells in your backgrounds only use PAL then CELL.A shows the PAL#...If a cell also has other things set, like PRIO FLIP then the number is a binary combination of all of these settings, as described here...
BG Data
A background is a map of 32x32 character cells. Each cell occupies two bytes:
- Character number
- Attributes:
Bit Purpose
0-2 Palette number
3 Flip X
4 Flip Y
5 Priority
6-7 Unused
was8bit 2021-02-26 04:59
For SPRITE.A it is a binary encoded number for all of the sprite settings as described in the Attributes section...
Sprite Registers
There are 64 sprites available, each occupies 4 bytes:
- X position
- Y position
- Character number
- Attributes:
Bit Purpose
0-2 Palette number
3 Flip X
4 Flip Y
5 Priority
6-7 Size:
0: 1 character (8x8 px)
1: 2x2 characters (16x16 px)
2: 3x3 characters (24x24 px)
3: 4x4 characters (32x32 px)
was8bit 2021-02-26 05:06
IF you are making a game were you are NOT storing game data in variables or arrays, but are ENTIRELY building your game data directly in the backgrounds, and your game constantly scans every single cell in your backgrounds and used this data to dricd your game, then YES, CELL.A is extremely important...
I did this here in one game....
was8bit 2021-02-26 05:09
The ONLY advantage is that it allows you to have WAY more things moving about on the screen, and you do NOT have to track ANY of the items data, settings, or anything.. ALL the info is stored in the background data...
Movement is jumpy, game response can sometimes be slugish and irratic sometimes, but it is definitely a unique approach...
was8bit 2021-02-26 05:19 (Edited)
HOWEVER, for the average game, i recomend trying to use mostly ARRAYS to control your active pieces, using SPRITES for these active pieces, and using the background mostly for decoration...
The math connecting sprites and backgrounds, especially if you use scrolling, can get tricky...
In this game...
https://lowresnx.inutilis.com/topic.php?id=1581
I experimented with using backgrounds that do NOT scroll, and also there are two levels (floors) which are always the same.. this approach GREATLY makes things easier...
... also the backgrounds have key images (when the new screen is being made) get converted into sprites... ANY special point of the screen i wanted the character to interact with became a sprite... this is because SPRITE HIT has pixel precision, but is also automatic (no math required)..
This approach DOES have a complicated way of reusing different sprite #'s and reassigning and repurposing them for different things on different screens... once i solved that issue, the rest of the game was easy :)
was8bit 2021-02-26 05:23 (Edited)
For basic games, using char#0 (empty) is a common way of allowing movement of any sprite... Timo has good math for that... using BG 1 as strictly decoration, then using BG 0 for controlling how things move (for floors and walls etc.) and putting items that get picked up, etc... should be sufficient...
In this case, CELL.A would not be needed...
... and honestly, i cant think of any common uses for SPRITE.A
was8bit 2021-02-26 05:24
IF you really want to know how to get the settings out the binary code... let me know, and i will post them :)
GAMELEGEND 2021-02-26 06:05
whoa thanks was8bit thanks a whole lot :)