freshbrood Posted January 30, 2021 Share Posted January 30, 2021 (edited) (STANDARD KERNEL - NOT DPC+) When using both playercolor kernels with the playfield colors kernel, RT's Batari page says there is a known issue with a stairstep/rolling lines effect on the left side of the screen. Is there any workaround to this? Some bit of code to be inserted however sloppy that could eliminate this? I am not trying to learn how to write another kernel right now. Also; Can any of those kernels run in VBLANK? Would it help? Edited January 30, 2021 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Karl G Posted January 30, 2021 Share Posted January 30, 2021 I can't see the section of the manual that you are referring to. In your demo, the playfield lines become uneven only when the players are moving, which seems odd. I don't see any color corruption on any of the lines, however. Give me a link to the relevant part of the manual, and I'll try to understand the issue. I'm sure smarter people have already looked at this, but I can at least give it a look. The fact that it varies based on player sprite movement makes me wonder if it's not the issue that is described in the manual, however. 1 1 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 30, 2021 Share Posted January 30, 2021 12 hours ago, freshbrood said: Also; Can any of those kernels run in VBLANK? Would it help? The "kernel" is the code that draws the screen, and the VBLANK (=vertical blank) is effectively a part of that. More to the point, feeding a signal to a TV involves setting up stuff, the vertical blank, the visible screen, the oversan. The kernel is what handles all of that. You can generally put extra code in the vertical blank, and in the overscan, but there is usually has very little "room" (=available cycles) for adding anything during the screen draw itself. In other words, the question doesn't make a lot of sense to me -- you can't put the code that draws the screen in the area where the screen isn't being drawn 2 1 Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 30, 2021 Share Posted January 30, 2021 The advantages and disadvantages of canned graphic kernels are locked in. When we batari BASIC users set kernel_options it chooses one particular graphic kernel to use. Since CPU time is at a premium one graphic kernel may have better X at the expense of worse Y. In this case the "stairstep/rolling lines effect" was a calculated tradeoff. Kind of like games with that HMOVE bar (see Ms. Pac Man) 2 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 30, 2021 Author Share Posted January 30, 2021 (edited) 3 hours ago, Karl G said: I can't see the section of the manual that you are referring to. In your demo, the playfield lines become uneven only when the players are moving, which seems odd. I don't see any color corruption on any of the lines, however. Give me a link to the relevant part of the manual, and I'll try to understand the issue. I'm sure smarter people have already looked at this, but I can at least give it a look. The fact that it varies based on player sprite movement makes me wonder if it's not the issue that is described in the manual, however. Warning: If you don't use no_blank_lines with background, timing issues will cause a stairstep effect (the rows will not be perfectly straight). https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html It's just after kernel options. 2 multi colored sprites are non negotiable. I'd like to at least have either a multicolored playfield or background if possible. I think it looks ok with blank lines as long as they are geometric brick shapes and there is no waterfall effect. I'm also open to any options you think might add some visual variety. If I have to do a solid playfield and solid background it's not the worst look I guess. Edited January 30, 2021 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Karl G Posted January 30, 2021 Share Posted January 30, 2021 But are you using the background option? It's not obvious from your game demo, at least. Also, it doesn't make sense to me that the rows would have problems just on one walking frame. If you send me your latest source, I can attempt to figure out what is happening. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 30, 2021 Author Share Posted January 30, 2021 (edited) I wish I knew how to write kernels. Even if there was a way to start drawing the top row of playfield blocks only half as wide, starting lower on the screen if that saved time. (The green "health" bars. That would look better anyway.) And in turn use less sets of colors for the scanlines that it doesn't draw. Also, if the 12th row of playfield blocks can't even be shown, why does the tia still waste cycles attempting to draw it? I realized that it's still there and can be displayed if you scroll the playfiled up 3 or 4? times. Then you get 12 rows with the top and bottom rows being half as thin. I don't know how to do it myself but I think I have a rudimentary understanding of the concept and that seems like a missed exploit. Edited January 30, 2021 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Gemintronic Posted January 30, 2021 Share Posted January 30, 2021 33 minutes ago, freshbrood said: I wish I knew how to write kernels. Even if there was a way to start drawing the top row of playfield blocks only half as wide, starting lower on the screen if that saved time. (The green "health" bars. That would look better anyway.) And in turn use less sets of colors for the scanlines that it doesn't draw. Also, if the 12th row of playfield blocks can't even be shown, why does the tia still waste cycles attempting to draw it? I realized that it's still there and can be displayed if you scroll the playfiled up 3 or 4? times. Then you get 12 rows with the top and bottom rows being half as thin. I don't know how to do it myself but I think I have a rudimentary understanding of the concept and that seems like a missed exploit. The best way to test that theory is to try and make your own graphic kernel. Tons of resources here. I think Andrew Davies sessions might be a good starting point for your topics question. https://www.randomterrain.com/atari-2600-memories.html#assembly_language UPDATE: I guess what I'm saying here is that if you want to second guess batari who made the kernel then follow his footsteps. Get to know why he left that gotcha as is. My hunch is that he knew this effect was possible but the CPU time taken to fix it would mean something else had to go. Kind of like how the multi sprite kernel has no collision detection for virtual sprites. Implementing soft collision would probably not leave much time for batari BASIC programmers to put in their own game logic. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 30, 2021 Author Share Posted January 30, 2021 I hope my question didn't come off as rude or condescending towards batari's incredible work! -not my intent at all! I certainly do not know better. It was a sincere question based on my extremely limited understanding and I literally have no idea what goes into writing kernels or the first thing about assembly. Quote Link to comment Share on other sites More sharing options...
bogax Posted January 30, 2021 Share Posted January 30, 2021 (edited) 1 hour ago, freshbrood said: if the 12th row of playfield blocks can't even be shown, why does the tia still waste cycles attempting to draw it? That's kinda like asking "why does this clock keep ticking when I'm not looking at the time" That's pretty much all the TIA does The 12th row is for scrolling I assume Here's 12 rows (well, more actually) Edited January 30, 2021 by bogax 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 30, 2021 Author Share Posted January 30, 2021 That's a very cool scrolling falling sky demo. I've also noticed that if I try to manipulate too many pf blocks at once it does weird graphical things like flashing blocks in the wrong places. Quote Link to comment Share on other sites More sharing options...
freshbrood Posted February 1, 2021 Author Share Posted February 1, 2021 Hey just as an update to this issue, Karl G helped implement a very elegant solution that fixes the waterfall effect using the background/pfcolors kernels by plugging a tiny bit of assembly to direct the page to stay in the 256 page boundary. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 1, 2021 Share Posted February 1, 2021 1 hour ago, freshbrood said: Hey just as an update to this issue, Karl G helped implement a very elegant solution that fixes the waterfall effect using the background/pfcolors kernels by plugging a tiny bit of assembly to direct the page to stay in the 256 page boundary. If you don't mind me giving a little more detail here ... the issue wasn't the "stairstep" issue as described in the bB manual, as the "background" kernel option isn't even used in this game. This game loads player sprites from data manually so as to not have to define two identical sprites for each of the players. The problem with this method is that if any of the data tables used for sprite graphics crosses a page boundary, it throws off the cycle count for the display kernel when displaying that particular sprite, causing display corruption. Adding directives to align the data solved this particular issue. tl;dr loading player graphics from data tables is a pain, so avoid it if you can. ? 2 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted February 1, 2021 Author Share Posted February 1, 2021 Thanks. Yeah it's been a pain but thanks to your assistance I was able to literally double the amount of colors and sprite frames for nearly half the memory. It's an incredibly efficient engine I think for the amount of content and functionality included. Quote Link to comment Share on other sites More sharing options...
bogax Posted February 1, 2021 Share Posted February 1, 2021 1 hour ago, Karl G said: tl;dr loading player graphics from data tables is a pain, so avoid it if you can. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted February 2, 2021 Author Share Posted February 2, 2021 (edited) 6 hours ago, Karl G said: If you don't mind me giving a little more detail here ... the issue wasn't the "stairstep" issue as described in the bB manual, as the "background" kernel option isn't even used in this game. This game loads player sprites from data manually so as to not have to define two identical sprites for each of the players. The problem with this method is that if any of the data tables used for sprite graphics crosses a page boundary, it throws off the cycle count for the display kernel when displaying that particular sprite, causing display corruption. Adding directives to align the data solved this particular issue. tl;dr loading player graphics from data tables is a pain, so avoid it if you can. ? Just an fyi, RT's Batari Basic page lists the waterfall effect as an issue when using the background color kernel without the no lines kernel, and from what I understand the pf kernel just pushes the background colors to the pf. That's why I assumed it was the pfcolors kernel. Separate issue maybe? Edited February 2, 2021 by freshbrood Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 2, 2021 Share Posted February 2, 2021 10 hours ago, freshbrood said: Just an fyi, RT's Batari Basic page lists the waterfall effect as an issue when using the background color kernel without the no lines kernel, and from what I understand the pf kernel just pushes the background colors to the pf. That's why I assumed it was the pfcolors kernel. Separate issue maybe? Yes, it is a separate issue , And does not apply to the pfcolors Kernel option. The background and Playfield are controlled by separate registers. I did not make any changes to the kernel at all. The issue happens because player graphic data was being loaded from a table that spanned a page boundary. 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted February 2, 2021 Author Share Posted February 2, 2021 Interesting. I need to start playing with the assembly tutorials. Unfortunately my pc just crashee on me. Quote Link to comment Share on other sites More sharing options...
bogax Posted February 3, 2021 Share Posted February 3, 2021 If like Karl G you find tables and indexes and sprite timing and addition and subtraction and stuff painful, assembly will be pure agony Best stick with writing out multiple copies of your sprite data and strings of redundant if then spaghetti going "is this it? is this it?" Any way you don't need any assembly for your sprite tables tl;dr "loading player graphics from data tables is a pain, so avoid it if you can." is an exceptionally silly sentiment Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 3, 2021 Share Posted February 3, 2021 5 hours ago, bogax said: If like Karl G you find tables and indexes and sprite timing and addition and subtraction and stuff painful, assembly will be pure agony Best stick with writing out multiple copies of your sprite data and strings of redundant if then spaghetti going "is this it? is this it?" Any way you don't need any assembly for your sprite tables tl;dr "loading player graphics from data tables is a pain, so avoid it if you can." is an exceptionally silly sentiment Perhaps I came across as dismissive of this technique with my flip statement, and if so, I apologize. I don't think it was silly, however. Delving into the internals of bB gives the programmer more options and flexibility at the cost of increased code complexity and a steeper learning curve. Loading sprite data from tables requires knowing to out the data in the same bank as the display kernel, making sure the data doesn't cross page boundaries, and updating bB internal pointers. For some projects, it makes sense to go through all of this extra trouble/learning, but I wouldn't want to recommend it generally unless there's a good reason to do so. Quote Link to comment Share on other sites More sharing options...
+Karl G Posted February 3, 2021 Share Posted February 3, 2021 Also, in case it's useful, here's the "assembly" I had freshbrood add to the beginning of each data table. Technically it's not code or assembly, but an assembler directive that bB doesn't directly support. It checks to see if that particular table crosses a page boundary, and if it does, it places the table at the beginning of the next page to avoid having the table cross a page boundary, this avoiding display problems like freshbrood experienced.: asm if >. != >[.+table_name] align 256 endif end Add this to the start of each table containing sprite data, changing table_name to the actual table name of your data. 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.