How To
Autotile
Benimo12 2022-07-09 10:05
How do I make a program that auto-tiles tiles in the background and tiles placed
Timo 2022-07-09 11:41
What do you mean with auto-tile?
was8bit 2022-07-09 16:02
A quick overview of backgrounds....
Basically, BG memory does not store actual graphics, just a reference# pointing to a character#... NX then renders the background images to the screen based on what image happens to be in the character memory...
By default, a chr# will fill one BG cell... however if you use CELL 1,1, then a chr# will fill, for BG 1, a 2x2 block of BG cells with the chr# being the upper left of the block
You can fill a background by using Background Editor which saves your work to file, then using BG COPY to copy it from file to the actual BG memory so it can be seen
.... alternatively, you can use code to add or change parts of either BG 1 or BG 0 (#0 being in front of BG 1) ... and remember, even though the screen shows 20x16 background cells, memory actually holds 32x32 (0-31) cells..
Also remember that commands like PRINT, NUMBER TEXT will overwrite background data... usually I use BG 1 for displaying graphics/images and reserve BG 0 for text and numbers, like scores, etc.. although you can use, say little hearts, as well, but the idea is I use BG 0 for displaying information, which will be seen above the graphics held on BG 1... also as each BG can be independently scrolled, you can scroll BG 1 graphics,without scrolling BG 0 data..
was8bit 2022-07-09 16:09
The code for basic filling in of tiles on a background is super easy...
BG 1 sets all commands to use background 1
PAL # set the color
CELL X,Y,chr# loads chr# reference from the character page to be shown on spot X,Y
... my specific code you references in my program will, after adding basic tiles, scan the entire visible portion of the background and for each cell determine what are the surrounding cells are, and based on that edit the cells to yield the nice boarder lined pieces to create the appearance of a solid shaped block..
You read a cell with C=CELL.C(X,Y)
If no fancy placements like FLIP was used, then P=CELL.A(X,Y) will read the palette value placed in that cell.. so if reading the colors of a cell is important, not using FLIP simplifies that process... if you need to use FLIP settings, it complicates reading the color setting...
was8bit 2022-07-09 16:17
"IF" the image data in the character file gets changed, the effect is that all instances of that character referenced in a background memory will be seen immediately... this is an advanced thing to do, but it is a pretty cool trick ;)
was8bit 2022-07-09 16:19 (Edited)
This example demonstrates HOW NX creates the background you see... that a background doesn't hold actual images, just a reference# to the actual images in the character file ;)
Anyone who may have a copy of the orginal LowRes app will remember that in OSlowres, each layer actually stored the pixel color# for each pixel location... images and text were always converted into individual pixels, no other information was available graphically..
With NX, each reference# to an 8x8 pixel graphic block stored in the character memory is what is stored in its background memory...
was8bit 2022-07-09 16:28
Theoretically, in NX, it IS possible to read an individual pixel inside a CHARACTER block from character memory... but as a background only stores character ref#, you cannot read the indiviual pixels that you see on the actual screen... you have to first read what character block(s) is on the screen, then you can use fancy code to figure out what the pixels are for each character... not easy to do... but possible...
was8bit 2022-07-09 16:34 (Edited)
It's best (starting out) to stick to blocks of 8x8 pixels, individual characters, and plan your game from that point of view...
Starting out, keep image tiles to BG 1, data feedback to BG 0
Starting out, just set the PAL or color for each tile if you need your code to read a tile's color
SPRITES to background tiles is a tricky thing... which we can discuss as needed ;) just remember that background tiles always fit into a fixed grid, the visible grid 20x16, and sprites go by pixel location, and each cell of the background grid is 8x8 pixels... but the REAL size of a background is 32x32 in cell size, keep that in mind as well...
was8bit 2022-07-09 16:46 (Edited)
... now in the specific program you referenced, I am also doing an additional trick... to "move" tiles, what I am doing is..
PICK UP..
1) reading BG tile info
2) determining each cell of the entire block that was touched
3) store that data
4) deleting the touched tiles from the background
5) creating sprites replicating what was visually seen before as tiles
MOVING BLOCK...
1) track the TOUCH
2) move all sprites to follow touch and retain block illiusion
DROPPING ...
1) delete all sprites
2) using data, edit background to add cells back to background as stored in data
was8bit 2022-07-09 16:50
Currently, this demo overwrites existing cells in the background if you drop a block on top of them
... in a game, I would need to add a check for such possibility, and instead of allowing a drop overtop existing cells tiles, return the block to original position, preventing a player to place a piece overtop an existing piece...
... someday I would like to make that a game ;) but as these types of games are already readily available, I kinda put that off for now unless I can think of a unique variation ;)
was8bit 2022-07-09 16:59 (Edited)
Now, IF you were interesting in using a program like mine to EDIT and SAVE the data to a background files, it is a LOT more complicated as you have to create a file editor... this adds a lot of complications if you were wanting to create a file that a command like BG COPY could use your file ...
FILE EDITOR reads and writes to file data, and it is possible to create one... but actually open up the code for Timo's character or background editor, and you will see it takes a LOT of code ... so, anyone can make and use an editor, I have, but to make one compliant with NX formats is abit complicated...
to create a file editor using a file format that YOU can personally use is really easy... kinda like an advanced form of using PERSIST data... so if you can already use PERSIST data, you can easily create a file editor that creates your own storage format :)
was8bit 2022-07-09 17:05
So, for example, in my program, I could convert it into a file editor, use my code to create and place tiles, and maybe add buttons for loading and saving the data...
The file format would be a simple array that stored ch# and pal # for a 20x16 size...
I would probably move the graphics to page 3.... to allow pages 1 and 2 for general game images, page 4 is for the font set..,.
was8bit 2022-07-09 17:06
IF this is something u would be interested in, it sounds like a fun thing I would be happy to put together ;) ... just let me know :)
was8bit 2022-07-09 17:09 (Edited)
... now, just to let you know... in Timo's graphic editor, you can already copy and paste blocks of graphics....
You would only need my program if you wanted auto highlight edging...
... otherwise, Timo's block copy/paste in his background editor is VERY useful ;)
nathanielbabiak 2022-07-11 01:58 (Edited)
A good exercise when looking at an algorithm "big picture" is:
- First, separate the algorithm into steps
- Then, identify a single step where you would benefit from a "black box" subprogram, meaning a placeholder that provides the exact inputs and outputs you need
- Write down what this algorithm would do, add as much detail as you can, and try to code it
This approach uses a "black box" subprogram, meaning you can focus on only the inputs (data you know, or can easily calculate) and the output (super-helpful data that you're not sure how to create).
Once you've listed those in's and out's, it's easier to focus on how the algorithm might work.