Jump to content
IGNORED

Yet Another Scrolling Demo


Mord

Recommended Posts

Ok since I've been letting yet another side project rot away for too long and I really don't know if/when I'll get back to it, here's another little demo as I fiddle with scrolling.

 

In a nutshell the program uses plotmapfile to display full screens in 160A and the player can move about in 4 directions, going 1 full tile at a time. When you reach the edge of the screen that is connected to a different map, it will scroll that map in black and white to the new screen then flash the color back.

 

There are only two screens in this program. The screen you start in, and the screen to the left of it. Any other screen edges you can reach are "dead" and won't trigger a change. There's a "template" tmx file included that's got the embedded tiles, etc all set up for adding new screens for playing around with.

 

Additionally this demo includes collision detection between the player and the map tiles. Changing around the order of tiles in the tmx files would obviously mess around with the collision code so keep that in mind.

 

Compiling instructions in a command/dos window are listed in the bank0c.bas file.

 

As mentioned in that file feel free to use anything in the code in your own projects.

 

And yes, I suck at drawing hero sprites. :)

 

 

 

rpg7800.zip

rpg.bas.a78

rpg.bas.bin

rpg7800-fixed.zip

Edited by Mord
  • Like 10
Link to comment
Share on other sites

Hm. Admittedly I haven't tried this on mame either. I find mame/a7800 a bit finicky to use so I don't know if it erroring right now is because of the rom or because I don't know what I'm doing with it. Could someone comfortable with mame try checking it out to make sure it fails and give me the error if it does? This rom does use an extra 16k at $4000, which isn't something I normally use.

Link to comment
Share on other sites

Hm. looking at the video the tiles are still corrupting during the actual scroll - they should be showing the new screen moving onto the screen. I'll try looking into it this weekend as well as getting use to using A7800 again.

Link to comment
Share on other sites

Ok I can pretty much confirm it's a bankswitching issue that's causing the graphics corruption. It's something I spoke with Rev about in the earlier incarnation of this test a while back. Looks like the fix I was able to do for prosystem doesn't work on hardware/mame/a7800. I did a quick change over to a more standard rom type - those without 16k rom sitting at $4000 - and it worked as intended. I'll do a bit of cleanup and add an extra room of sample graphics to show the up/down scrolling then post updated roms/zips. I won't have time to post it today but should have it posted early Saturday morning before most people wake up. :)

  • Like 1
Link to comment
Share on other sites

Ok I've fixed up the code and updated the attachments in the first post. I've left the original zip there for people to see what it was originally like - no harm in it. The new version using a 128k rom structure is in rpg7800-fixed.zip.

 

The bin and a78 files are the updated fixed versions. If someone really wants to see the old versions they're in the zip file. I tested using a7800 this time so shouldn't be any issues!

 

The basis of the corrupted graphics appears to stem from trying to use a bank changing gosub out of a permanent bank. I originally tried to move the stuff that was in the permanent bank at $4000 to the top bank in the fixed version and the corrupted graphics remained.

 

I added a third room going down from the first room to test the vertical scrolling - there were two careless bugs in the vertical scrolling in the original version, so a good thing I did this test! The first was not specifying the width of the extended map in the vertical direction. I didn't bother since I was going to plot the entire width of 20 anyway. That caused it to only display the first line of graphics for the entire scroll. After that was fixed I noticed my setup in the scroll data was reversed. Placed the rooms in the wrong halves of the map for the intended scrolling direction.

  • Like 3
Link to comment
Share on other sites

  • 2 weeks later...
  • 1 year later...

Certainly possible to come up with other ways of doing it, but I doubt there's any trivial method of doing it with plotmapfiles. Using plotmap to do small scrolling on a plotmapfile will certainly result in errors in the tile's palettes.  If your map can make do with one palette it would be easier to just do the larger map and use plotmap. Horizontal scrolling at the very least becomes pretty easy that way. Vertical scrolling however would still be a lot harder going pixel by pixel unless you use the "fake scrolling" method of using black bars to cover up the errors in the bottom zone as you scroll.

 

 

Link to comment
Share on other sites

2 hours ago, Mord said:

If your map can make do with one palette it would be easier to just do the larger map and use plotmap. Horizontal scrolling at the very least becomes pretty easy that way. 

But wouldn't I just be able to scroll between 0-255, that's a very very small distance to scroll, right?

 

The visable tiles I have in ram at $2200, for the tile collision checks to work I feel like I have to scroll that memory, and fetch a little bit of new data from a bigger map for the side columns or a buffer outside the visable area or something like that?

 

Edited by Lillapojkenpåön
Link to comment
Share on other sites

1 hour ago, Lillapojkenpåön said:

But wouldn't I just be able to scroll between 0-255, that's a very very small distance to scroll, right?

 

The visable tiles I have in ram at $2200, for the tile collision checks to work I feel like I have to scroll that memory, and fetch a little bit of new data from a bigger map for the side columns or a buffer outside the visable area or something like that?

I don't know about the "very very small" description. 256 characters provide 6 screens of 160A/320A characters, which is a lot for certain game designs, and insufficient for others. (acknowledging that this is worse for other character modes.) The problem is, when you go beyond 256 characters, you start to run into rom storage issues. Beyond a width of 682 you've exhausted the ability of one 16k bank to hold your map data. Beyond a width of 2048 you've exhausted the ability of 48k's worth of address space to hold your map data. All of this storage assumes no vertical scrolling, and one level of data; If that's not true, then multiply the storage requirement by the number of vertical screens, and again by the number of levels your game has.

 

It seemed a reasonable design decision to make 256 the limit for the 7800 plotmap routines, avoiding code complexity for all game designs that can make use of maps up to 256 width.

 

To go beyond those limits, you need to use ram based tiles and roll your own method of tile map compression, screen loading, screen updates, etc. There's no one-size-fits-all generic scroll solution that can be applied to any 6502 level machine. Some scrolling games store groups of tiles as meta tiles, some use compression based on certain attributes of the level data, some may procedurally generate content, etc.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Using doublewide for your tiles also extends the size of your potential map since the same map data would cover twice the number of pixels. 

 

Another way of increasing the map size would be to "fake it" so to speak. In other words you would have 2 maps in 2 different banks that you would be able to switch between.  The second map would start with the same screen data as the end of the first map so that when you switch between the maps the player wouldn't notice anything had happened.  You would need to make sure the graphics of each bank were essentially the same except for anything unique that happens in each map - and of course make sure the unique things don't occur during or around that switch over point at the end of the first/start of the second maps.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

I just started doing something like that, I think the NES has nametable A and nametable B and when you scroll it goes A B A B A B... and you update the one that's not visable

 

 dim tilemap = $2200 ;A (visable area)

 dim tilemap2 = $23E0 ;B

 

If you can shift that data like how you scroll on 2600, then when you have shifted the entire B screen into A, you can just copy the next screen into B, maybe?

 

But if you wanted to scroll both left and right you would have to have three areas I think, A B C, would that work?

 

 

 

Does making your levels with alphachars take less space than the tiled map or same thing?

Edited by Lillapojkenpåön
Link to comment
Share on other sites

On 10/19/2020 at 8:48 AM, Lillapojkenpåön said:

I just started doing something like that, I think the NES has nametable A and nametable B and when you scroll it goes A B A B A B... and you update the one that's not visable

 

 dim tilemap = $2200 ;A (visable area)

 dim tilemap2 = $23E0 ;B

 

If you can shift that data like how you scroll on 2600, then when you have shifted the entire B screen into A, you can just copy the next screen into B, maybe?

 

But if you wanted to scroll both left and right you would have to have three areas I think, A B C, would that work?

 

 

 

Does making your levels with alphachars take less space than the tiled map or same thing?

 

Not entirely sure about the scrolling you're talking about - basically just sounds like using double buffering. When it comes to trying to scroll two Tiled maps you still end up with problems regarding the wrong palettes being used unless you're updating all the display lists for the new sizes and positions. Which is why I avoided trying to do that for the screen switching in the demo.

 

Making levels with alphachars directly in your source would use a little less space since imported Tiled maps also have an extra table created to quickly determine how the display lists need to be created if I'm reading the .asm files correctly.  You won't have that extra table with normal alphachar maps - however that means the map will also be limited to a single palette unless you create your own data structure/table/etc for determining which tiles need what palettes. At that point you're removing the space savings.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...