Mord Posted May 14, 2019 Share Posted May 14, 2019 (edited) 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 May 18, 2019 by Mord 10 Quote Link to comment Share on other sites More sharing options...
R_Leo_1 Posted May 14, 2019 Share Posted May 14, 2019 This is great, love the NES style graphics on this one. Would love to see an RPG on 7800 1 Quote Link to comment Share on other sites More sharing options...
+SmittyB Posted May 14, 2019 Share Posted May 14, 2019 Looks good, I'd certainly play a full game looking like that. I do like how the colour flashes back in after scrolling, not sure if it would get annoying after a while but it certainly looks good. 1 Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted May 15, 2019 Share Posted May 15, 2019 Hmm ... didn't work for me on Cuttle Cart 2 using real hardware Quote Link to comment Share on other sites More sharing options...
Mord Posted May 15, 2019 Author Share Posted May 15, 2019 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. Quote Link to comment Share on other sites More sharing options...
Trebor Posted May 15, 2019 Share Posted May 15, 2019 Runs perfectly fine under A7800: https://www.youtube.com/watch?v=M1I0HfLJn1o 5 Quote Link to comment Share on other sites More sharing options...
DracIsBack Posted May 15, 2019 Share Posted May 15, 2019 Damn - that looks so very, very slick! 1 Quote Link to comment Share on other sites More sharing options...
Mord Posted May 16, 2019 Author Share Posted May 16, 2019 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. Quote Link to comment Share on other sites More sharing options...
Mord Posted May 17, 2019 Author Share Posted May 17, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
Mord Posted May 18, 2019 Author Share Posted May 18, 2019 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. 3 Quote Link to comment Share on other sites More sharing options...
SlidellMan Posted May 18, 2019 Share Posted May 18, 2019 So far, what you have is solid. If you need more pixel artists, I know a few on Newgrounds. Quote Link to comment Share on other sites More sharing options...
Mord Posted May 27, 2019 Author Share Posted May 27, 2019 Not sure if I'll ever get an actual game made out of this, although I'm still picking at it here and there. The purpose of releasing the code is in case it helps anyone else trying to do similar things. 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted October 17, 2020 Share Posted October 17, 2020 Is this just one way of doing it? Could I use the same technique but scroll one pixel a frame and with colors? At first I thought I could make a big level in tiled and just use x and y variables in the plotmap command to scroll around, but that wouldn't be able to scroll very far would it, if it even works. Quote Link to comment Share on other sites More sharing options...
Mord Posted October 18, 2020 Author Share Posted October 18, 2020 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. Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted October 18, 2020 Share Posted October 18, 2020 (edited) 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 October 18, 2020 by Lillapojkenpåön Quote Link to comment Share on other sites More sharing options...
RevEng Posted October 18, 2020 Share Posted October 18, 2020 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. 1 1 Quote Link to comment Share on other sites More sharing options...
Mord Posted October 18, 2020 Author Share Posted October 18, 2020 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. 1 1 Quote Link to comment Share on other sites More sharing options...
Lillapojkenpåön Posted October 19, 2020 Share Posted October 19, 2020 (edited) 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 October 19, 2020 by Lillapojkenpåön Quote Link to comment Share on other sites More sharing options...
Mord Posted October 22, 2020 Author Share Posted October 22, 2020 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.