UxoZii 2019-03-07 20:37
I need help, how can I make the level longer ? I'm really bad with the new "layers" and BG commands. The level is longer in memory but I can't load it, because the limit of the "BG COPY" command is 32x32 cells.
was8bit 2019-03-07 20:52
I did a background scroller with TOOBIT SAVES BITVILLE game
was8bit 2019-03-07 21:02
I use two tricks...
SUB GETMAP(DX)
Copies the next piece of background...
Also I restrict player movement to stop at 8 MOD placement so cell.c checks are easy...
was8bit 2019-03-07 21:03
You are welcome to take any of my games and remix them :)
was8bit 2019-03-07 21:06
I technically only do a real scroll for 8 pixels, then I reset the scroll , move all the cell contents left, and reload a new strip of background... the timing is important ..
was8bit 2019-03-07 21:14
Since I add everything to the background that a player may interact with, and since player may make changes to the background, I only allow one way background movement... otherwise allowing player to go left lets coins anch such reappear even though they have been picked up
Making all objects and enemies be included in the background means that once the backgound is made then the objects are automatically processed ... so it’s easy then to redesign the backgound, objects and enemy placement easily..:)
was8bit 2019-03-07 21:17 (Edited)
My idea is to make a generic game maker so that all a person had to do is design graphics and background and the game will automatically play..
My goal is you can make a Mario game... that’s my goal.. :)
It will take time...
Timo 2019-03-08 00:46 (Edited)
There is also the "official" way to scroll a big map, but I'm falling asleep and cannot explain now. My "Legend of Lowria" prototype uses it. And it's the trick they used on all the old game consoles.
was8bit 2019-03-08 01:43 (Edited)
"legend of lowria" has a background of 64x64, and the DISPLAY setting is set for double background which allows all of the background to fit into background memory of 32x32
This test game has a background of 128x32 while my Toobit game has a background of 128x16 ... neither of which can all fit into the 32x32 background memory..
So BG COPY must be used to add the remaining background from file into active background memory as needed...
When you use SCROLL you have to remember that the cell coordinates scroll too, so if you use SCROLL 0,8,0 the upper top left corner of your visible screen is no longer CELL 0,0 anymore, what is visible now in that corner is CELL 1,0 ... and if using sprites your Sprite coordinates do NOT scroll, so you must compensate...
my brain gets confused trying to do the adjustment ... so I use a different approach so the top left corner is always CELL 0,0 in my game... i use a map index to track where the BG COPY begins copying from and bump this by one every time my player gets close to the right edge....
UxoZii 2019-03-08 07:21
Ah yes I get it! Something like:
IF (scroll variable for x) MOD 8 = 0 THEN
BX=BX+1
(Scroll variable for x) = 0
END IF
BG COPY BX,BY,32,32 TO 0,0
I remember now I did something similar in the original lowres coder, when I'm back home I'll test it, thank you !
Timo 2019-03-08 08:43
The 16x16-pixel cell mode of Legend of Lowria is not the actual trick. It’s the way the background is copied. I will make a simple demo today, I should have time for it.
was8bit 2019-03-08 09:42 (Edited)
Ah, I see where you also so a lot of BG COPY as well... you are good at the advanced sort of stuff!
I have always been easily confused with the fact that the Sprite coordinates are always absolute to the visible screen where when scrolling the background the cell coordinates are always relative to the visible screen.... so I always keep the background cell coordinate absolute to the visible screen to match the sprites coordinate... keeping both coordinate systems identical...
... also in my game I use the background as memory so the changes in the background effect the game... In your game I would have to load all of the entire initial background into an array and then reload the array into the background every time I moved the background...
So, rather, in your game your background probably remains unchanged, and anything interactive would have to be programmed in seperately...
... I know I think abit oddly, but my approach depends upon a changeable background, using as an interactive memory that changes as the game progresses...
so then I would ask this question... how could one copy disk background data into active memory, edit that active memory, and copy that into the screen's background.... like we can do with characters... i am guessing that is not possible to do with backgrounds...
I.e. It would be nice to load my 128x16 background file somewhere into working ram ($A000+) where it can be edited, then copy portions of that into background memory ($9000+ or $9800+) ... but I haven't tried it as I'm even unsure if that's possible,,,
Timo 2019-03-08 12:27
You can copy the map to working RAM and use BG COPY from there, just use BG SOURCE. But there are no simple commands to get and set cells in RAM, you'll have to use PEEK/POKE.
Timo 2019-03-08 12:35
My scrolling example:
https://lowresnx.inutilis.com/topic.php?id=318
was8bit 2019-03-08 14:52
@TIMO... COOL :) I'll have to check that out :) probably will be awhile before I can play with code though but that sounds exciting, thanks again :)
desbyc 2019-03-11 06:01
I like the animation 👍
Mrlegoboy 2019-08-23 02:21
Damn this is really cool howd i miss this?
AstonBrown 2022-11-06 11:28
haha the character when hes about to jump
