Timo 2019-03-08 12:33 (Edited)
Example how to program scrolling with maps bigger than 32x32 cells. It makes use of the fact that BGs wrap around the edges and only copies new areas entering the screen. Enable the debug mode to see that it uses only 2% of the CPU when scrolling.
In this example only map heights up to 32 cells are supported, the copy trick is used for horizontal scrolling only. It could be extended though if required.
V1.1: Added cell collision checks. This version PEEKs into memory, but I’m planning to add built-in functions.
V1.3: Added collectable rings, uses new MCELL functions.
UxoZii 2019-03-08 14:22
Damn, I'm really mad at myself that I couldn't figure this out alone. I'll give my current project with scrolling some rest and work on something else, because that annoyed me a bit... Maybe it's because my lowres skills went downhill because of my big pause... I'll make some easier projects for now.
But still, thank you Timo for making this demo !
was8bit 2019-03-08 14:56
@UxoZii, don't feel upset... NX is built fundamentally different than original, and even though both feel similar at first, NX is actually more powerful... NX is "game cartridge" and "cell image" based... so you'll have to relearn many little things...
Just keep experimenting and have fun, I think you'll fall in love with NX once you get comfortable with it :D
UxoZii 2019-03-08 14:59
Yeah, I really want to love NX as much as the original, eventually I'll get used to it :p
Timo 2019-03-08 15:17
NX basically just works like a Game Boy and other old consoles. Even if you don't plan to program for old consoles, stuff you learn for NX is not completely wasted. It can make you look at old games with different eyes, if you know how the technical limitations were :)
Jack Sbertox 2019-03-09 10:10
Timo 2019-03-19 08:53
I will probably add commands like CELL, but accessing directly the source map instead of the current BG. This will simplify collision checks with tiles.
was8bit 2019-03-19 09:51 (Edited)
That will be great for static map games :)
I'm still trying to iron out a dynamic approach.. i think I'm having memory address issues when trying to save my map changes to memory, but I've been too tired lately to wrap my brain around it :/
my "LONG BACKGROUND TEST" shows the memory errors when scrolling... my idea is when using the map dynamically, it is used as storage for enemy characters, pickups, etc. and so changes to the map have to be saved as the portion of map goes out of view and you want the player to be able to revisit that part of the map again...
My BUGZ game limits the background to 32x32, and my Toobit game doesn't allow player to go back, only forward (or right) as any changes to the map are lost as they scroll off...
My LONG BACKGROUND TEST is designed to test the ability to make changes to the background, player can move the floaty things, and supposedly as you scroll anywhere left or right your changes to the background are supposed to be saved...
.. as you can see, all I accomplished is corrupting the memory... :/
Timo 2019-03-22 22:52 (Edited)
This is how it works with the new MCELL functions
was8bit 2019-03-27 00:27 (Edited)
@1.3... Nice update :)
DJMoffinz 2019-10-28 07:08
Where the gravity go?
was8bit 2019-10-28 12:24
... try this one ;)