Eliminating the stairstep/waterfall effect when using both playercolor kernels with playfield colors?

[freshbrood]

(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 by freshbrood

[+Karl G]

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.

[Andrew Davie]

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  

[+Gemintronic]

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)

[freshbrood]

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 by freshbrood

[+Karl G]

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. 

[freshbrood]

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 by freshbrood

[+Gemintronic]

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.

 

[freshbrood]

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.

[bogax]

 

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 by bogax

[freshbrood]

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.

[freshbrood]

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. 

[+Karl G]

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.  🙂 

[freshbrood]

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.

[bogax]

1 hour ago, Karl G said:

tl;dr loading player graphics from data tables is a pain, so avoid it if you can.

[freshbrood]

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 by freshbrood

[+Karl G]

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. 

[freshbrood]

Interesting. I need to start playing with the assembly tutorials. Unfortunately my pc just crashee on me. 

[bogax]

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
 

[+Karl G]

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.

[+Karl G]

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.