Example

MCELL TESTS

0

was8bit 2019-03-27 05:12 (Edited)

.... reformatting...

Incremented player movement from 1 to 8

MCELL TESTS.nx | Open in app
2019-03-29 01:01
MCELL TESTS.nx | Open in app
2019-03-28 06:11
MCELL TESTS.nx | Open in app
2019-03-27 05:29
MCELL TESTS.nx | Open in app
2019-03-27 05:21
MCELL TESTS.nx | Open in app
2019-03-27 05:12

was8bit 2019-03-27 05:19

I will be testing creating 6 32x32 active maps, only one map at a time will be active...


Timo 2019-03-27 07:29

Give him a jetpack and put “up” on button A or B :)


was8bit 2019-03-27 12:41

Nice idea :)

But in my next test I’ll be changing him into a bug and changing the platforms into maze walls... after I figure out how I want to connect all the mazes together... that’s why I started a separate post as it will end up being different than the original idea.. I copied it to start out be because I wanted to use your scrolling system...

But, I’ll certainly add your idea to the other one for sure, it’s a good idea :)


XenonLab 2019-03-28 10:55

A new feature to move sprites on a grid? similar to the structure of a roguelike right? Very interesting.

Does the new webplayer at the start show the 0.13 release? what did I miss?


Timo 2019-03-28 11:08

The new feature are functions to access cells directly from the source data instead of BG. But it’s only to use maps bigger than 32x32 cells.


was8bit 2019-03-28 17:03 (Edited)

@xenonlab... Originally I was trying to create games using only the background (see my BUGZY BATTLE GAME) this is convenient in that i didn’t have to use arrays, I could simply have the code READ what was on the background, and so I used the background as memory to store stuff... this is easy to do if your background stays at 32x32, the size of both BG 0 and BG 1

I then tried to make a scrolling game sizes 128x16 with pickups like hearts for extra life (see my game TOOBIT SAVES BITVILLE game) so i designed the big background with its pickups already placed in it on the 128x16 editor... and in game code would use BG COPY to copy portions from file to the 32x32 screen...

everything worked great... you could touch a heart, the code would remove the heart from the screen, give you extra life, and you could continue moving to the right... originally I also allowed LEFT movement, but discovered the once removed heart would reappear as i moved backwards to places I had been... this was because the hearts were only removed from the 32x32 screen, not the actual background file... so when I used the 128x16 file with BG COPY the hearts of course are still in the background file as you can not change files from the gsme’s code, only with an editor tool... my fix for that game was to remove the ability to go left, so only going right fixed that problem..

SO, for navigating maps bigger than 32x32 that you want to be interactive, what TIMO created was a way to upload the entire map file into active memory, and reassign the BG COPY command to work with the copied map in active memory, rather than using the map file...

So them you use MCELL to read and write to indivual cells or even BG COPY to update your 32x32 screen from your map stored in active memory... so if you add or remove something from your “active map” that is now stored in active memory the change stays during your game...

On TIMO’s help file, this active memory is called WORKING RAM starting at memory address $A000

I made a test version that demonstrates how a player can move things, and they STAY moved, and also the code moves an enemy even when they scroll way off the view... (see my test BACKGROUND 128x16 MCELL TEST)

So, if your map is only 32x32, you’ll only be using your BG COPY command once, and then all changes to your BG 0 or BG 1 will remain just fine by using CELL command..

BUT, if your background is BIGGER than 32x32: AND if you want an active background that changes, any changes done with CELL are lost once you use the BG COPY command to load other portions of your map to a 32x32 BG 0 or BG 1

Only for bigger active screens can you copy the entire file to active memory with
'COPY MAP TO RAM TO ALLOW
'CHANGING CELLS
COPY ROM(3),SIZE(3) TO $A000
BG SOURCE $A000

From then on, using MCELL or MCELL.C commands directly access this stored background and not your background file..

This requires a bit more attention.. for my background 128x16 tests, XX will represent where the left edge of the view screen is on my very wide background ... this code saves everything on my BG 1 to the active memory background.. CELL.C and CELL.A reads from BG 1 and MCELL writes to my active memory

SUB MUPDATE(XX)
FOR IY=0 TO 15
FOR IX=0 TO 19
ATTR (CELL.A (IX,IY))
MCELL XX+IX,IY,CELL.C(IX,IY)
NEXT IX
NEXT IY
END SUB

To scroll left or right requires reading from active memory to BG 0, done with only this command :)
BG COPY XSCROLL,0,20,16 TO 0,0

Normally this command gets the background data from the background file... however once you have use this command..
BG SOURCE $A000
you’ve told LOWRES NX to now use active memory starting at location $A000 for background data (rather than the default background file)

To reset this back to the background file
BG SOURCE ROM(3) resets LOWRES to use the background file for the BG COPY command

In code....
ROM(3) identifies the background file..
ROM(2) identifies the character file..
ROM(1) identifies the palettes file...

At the bottom of your game code you will notice in text your files are marked as...
#1:MAIN PALETTES
#2:MAIN CHARACTERS
#3:MAIN BG
#15:MAIN SOUND

FILE #0 should remain unused so that the default NX FONT set can be automatically loaded

This leaves files #4 - #14 to be used for anything else you want... like extra backgrounds ;)

I suggest reviewing TIMO’s game MAP SCROLLING as it offers a great example of how to use the new commands for a really big background :)


Log in to reply.