Superchip Issues? Top Row Fix & 6 Lives.

[KevKelley]

I was playing around with various options and I was trying a program with these settings:

 set romsize 32kSC
 set kernel_options pfcolors no_blank_lines 

I had noticed that there was the normal issue with a different color bar appearing at the top of the screen and the color at the bottom being a little off so I tried the recommended fixes of either defining COLUPF or placing pfcolors: in the main loop.  I had also added lines to the playfield at the top or bottom.  While I was able to get the bottom line kind of fixed by changing pfres to 22 instead of 23, the color bar was still on top.

 

I had noticed that the color at the top is the background color and had wondered if this was a result of the kernel option combinations.

 

I had also was playing around with trying to add 6lives and a statusbar but it didn't seem to appear.  I had essentially copied what worked in a couple different program I had done with the only main difference being the Superchip so I had wondered if this was a conflict with Superchip.

 

Or am I missing something and having a series of brain farts? I attached the pic showing the screen.

 

*I thought I attached the .bas but attached the .bin. I'll upload it later when I have my computer.

 

 

LAWNBOY_2021_9_19.bas

Edited September 19, 2021 by KevKelley

[+Karl G]

Okay; I took a crack at it.

 

For the minikernel, there were a few problems. First, you tried to include it with "include". For multibank games, it needs to be included with "inline" in the last bank. I also had to comment out your minikernel code, as you can't have duplicate labels (the actual minikernel starts with the same label). Finally, you can't use pfscore bars and the 6lives minikernel together as they use some of the same variables, so I commented out those as well.

 

Unfortunately, I don't know of a good fix for the background color showing through at the top of the screen - this is caused by the playfield starting after PF0 is displayed, so it gets that odd shape. You may need to simply not use PF0 to avoid this, unfortunately.

 

I also copied the 6lives_statusbar.asm file to the same directory, and edited it to set the background color to black at the beginning of the minikernel.

 

LAWNBOY_2021_9_19_2.bas

 

 

[KevKelley]

Ah. I originally started with the pfscore bars before I had thought about the 6lives. And when I first put it in the program I did "inline" instead of "include" but I might have had other changes that had initially caused it not to compile. I kind of just left them in until I figured it out... But I guess I would have been going around in circles.

 

As for the bar up top, I had played with PF0 on or off. I was really curious as to why it got on but having it off is not a big deal. It was more of a curiosity. 

 

Thank you so much! I tried to play around with this on my lunch break but I kept getting interrupted to focus but I was ready to erase the code and start over.

[+Karl G]

43 minutes ago, KevKelley said:

Thank you so much! I tried to play around with this on my lunch break but I kept getting interrupted to focus but I was ready to erase the code and start over.

No problem, and I definitely know that feeling! I just realized that I forgot to attack the customized minikernel:

 

6lives_statusbar.asm

[KevKelley]

The big thing for me is to learn. I really do appreciate the help and explanations. I am have found that staring at this code and playing around with stuff helps with my anxieties. Nothing like a good puzzle.

[KevKelley]

So I'm curious. Is the PF0 issue related to using pfcolors, since that bar is the background color? 

And is it possible to just "turn off" that line or would that play a role in the timing of everything below? 

[+Karl G]

5 hours ago, KevKelley said:

So I'm curious. Is the PF0 issue related to using pfcolors, since that bar is the background color? 

And is it possible to just "turn off" that line or would that play a role in the timing of everything below? 

It's not really related to pfcolors at all. It has to with the fact that PF0 keeps a constant value, and it is drawn before the "regular" playfield is drawn. If you remove the PF0 definition, you still see the background color at the top, but it doesn't look uneven:

 

[KevKelley]

So one thing I did notice is that the sprites go above the PF0 parts on the sides but behind the brown bar on the top. I had thought the behaviors of these two spots would then be the same. 

[+Karl G]

26 minutes ago, KevKelley said:

So one thing I did notice is that the sprites go above the PF0 parts on the sides but behind the brown bar on the top. I had thought the behaviors of these two spots would then be the same. 

That doesn't seem to happen when I tried it? It cuts off at the same part going up regardless of where the sprite is horizontally.

 

I also wondered about trying your idea in reverse: use background for the unbowed lawn, and do the sky and grass stripes with background colors, then use the single-colored playfield for the mowed grass. So the playfield would start up empty and fill with pixels instead of the other way around. I haven't experimented with it, but this might end up looking nicer.

[KevKelley]

I meant on the sides the sprites are above. I had thought that when the border is in place the sprites travel behind it and are hidden.

 

And as for using the background, I was actually curious about flipping them.

 

Originally I was going to using it the current way and when certain rows were cleared I was going to change the playfield color for that row so that the ball can be randomly generated on that line to be used as a certain thing, whether bonus or obstacle. I wouldn't do this for every row, for I would have to make a pfcolors for every combination but it shouldn't take up too much space. If I use the background and draw the playfield then the ball would be pretty much useless unless I find a purpose for it in the sky. Or so I think... 

[+Karl G]

2 hours ago, KevKelley said:

I meant on the sides the sprites are above. I had thought that when the border is in place the sprites travel behind it and are hidden.

So, you thought that when you don't have PF0 set that the sprites should hide behind the background? Nothing can hide behind the background.

 

2 hours ago, KevKelley said:

If I use the background and draw the playfield then the ball would be pretty much useless unless I find a purpose for it in the sky. Or so I think...

Well, you could also display it on the edges, assuming you don't use PF0 for the entire margin.

[KevKelley]

I was looking at my other programs I think I had CTRLPF set differently so that the sprites moved behind the playfield. Maybe that is what I was thinking of. 

[KevKelley]

On 9/20/2021 at 10:15 PM, Karl G said:

So, you thought that when you don't have PF0 set that the sprites should hide behind the background? Nothing can hide behind the background.

 

Well, you could also display it on the edges, assuming you don't use PF0 for the entire margin.

So after playing around with this some more, I had noticed that with the customized minikernel the lives were not positioned to the left so they would overlap with the statusbar...

 

But that made me play around with formatting of the game a bit.  When I eliminated that minikernel the bar on the top extended across the width of the entire screen.  So instead of doing a pf0=%11110000 and making a thick border around the entire to meet the colored bar screen I went with a pf0=%11100000 making a thin border around the screen.

 

I think when compared to how I originally had it set up this kind of makes for a cleaner look.  I love the trial and error in making a design work and I thought it was really interesting to see how the mini kernel worked.  I started to play around with the assembly just for fun to see what happens when I tweak certain things.  Brought me back to middle school playing around with basic files and making funky graphical glitches and crazy physics happen.

 

I still have the COLUPF in the main loop to keep the bar color.

Edited September 28, 2021 by KevKelley

[KevKelley]

So I was playing around with this some more and I found the fix to the color bar.

 

While the original settings were this:

set kernel_options  pfcolors no_blank_lines

 I had played around with this:

set kernel_options  pfcolors no_blank_lines background 

I completely forgot about the color issue so I was changing some color values and it seemed that when I defined pfcolors that would color the playfield (or in the second code excerpt the background). Then I would have this:

 COLUPF=$F8
 COLUBK = $A6

COLUPF would color the background while COLUBK would color the little strip at the top. The image is with background set. the all blue is without background.  I was too lazy to change the pfcolors values.