Mikes360 Posted February 6, 2014 Author Share Posted February 6, 2014 I have not tested the above code, but something like it should work (and I believe that's how I did the scrolling in my demo). The idea is you don't have to reverse the bytes, you can just reverse the rox instruction. This is a nice idea but I assume all the PF data would need to be stored in RAM constantly? When a single line takes up 5 bytes you wouldn't be able to keep a very detailed PF in RAM. That's why I was looking at loading the data from ROM and displaying it first pass. Then if a user moves left one I would load the data from from ROM into a buffer and shift it all along one bit; then two, three. until I reach 8 then I would shift the all the addresses left (GFX address for PF2 now goes to PF1). And restart the shifting process. This however seems very expensive to do and I get the feeling shifting each PF line up to 7 bits across each time as well as loading the data in the first place is just too inefficient. Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted February 6, 2014 Share Posted February 6, 2014 Not all the PF data, you can have as much in ROM as you wish. Only the data you wish to display has to be in RAM. Using the same 5 byte buffer and changing it's contents every new PF line would probably take too much kernel time, though you could try it out. I'm guessing there would have to be a couple of blank lines every time you wanted to change the PF. As I said before, you can recoup some RAM by using the lower nybble of the PF0 buffers. As you have seen, horizontal scrolling takes a lot of resources. If it didn't you'd see a lot more games that did it. Quote Link to comment Share on other sites More sharing options...
SeaGtGruff Posted February 6, 2014 Share Posted February 6, 2014 How large of a playfield are you wanting to scroll-- how many PF pixels wide, and how many PF pixels tall? Quote Link to comment Share on other sites More sharing options...
Mikes360 Posted February 6, 2014 Author Share Posted February 6, 2014 Looking at Super cobra in more detail it looks like they had a 10 pixel tall by 40 pixel wide PF. This would have needed 50 bytes of RAM that is actually fairly reasonable I guess. I may push mine to a 15 or maybe 18 pixel high PF to get a better resolution. Thanks for your advice Wickeycolumbus I will look at implementing it this way and abandon my attempt to use a small buffer and modify it mid Kernel. Quote Link to comment Share on other sites More sharing options...
Mikes360 Posted February 7, 2014 Author Share Posted February 7, 2014 (edited) ror PF2RightBuffer,X rol PF1RightBuffer,X ror PF0RightBuffer,X lda PF0RightBuffer,X and #%000010000 beq CarryNotSet sec .byte $24 ; opcode for BIT zeropage instruction. has no effect on carry flag, effectively skips next byte CarryNotSet clc ror PF2LeftBuffer,X rol PF1LeftBuffer,X ror PF0LeftBuffer,X Just wanted to confirm this method works great there is just a small typo in the 'and' operation it has an extra '0' that's all. Thanks again Edited February 7, 2014 by Mikes360 Quote Link to comment Share on other sites More sharing options...
Wickeycolumbus Posted February 7, 2014 Share Posted February 7, 2014 Glad to see that you got it working. And it's good you caught that error, you understand the code. Scrolling right should be a similar routine, but there will be issues with updating the PF0 buffers. If you need some guidance on how to do so let me know and I can help. It would be beneficial for you to experiment first though. 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.