The Southsider

Nice! Very arcade-like.

 

(Of course, I may be a little biased. )

 

Music wise, how about some of the stuff moderntimes99 has been working on?

Good work you two. I like what you did with the colour interleave on the Juno First logo.

Looks cool, even with banding.

 

BTW: And idea why TVs show this effect?

Music wise, how about some of the stuff moderntimes99 has been working on?

 

My first thought exactly! His interpretation of the Silkworm tune is screaming for a release!

 

And that title screen looks brilliant! Seems after Lady Bug the next killer app is coming here!

Thanks for all the comments. I am happy to say that I have now spoken to Erik (modertimes99), and he has agreed to let me use his fantastic Silkworm tune for Juno First! I will incorporate this tune into the next release that I post here. Beyond this, my goal for the game is to add some actual levels, so that the game-play can be properly tested and tuned. I have reasonably high hopes for the game as it seems to be coming together nicely so far.

 

With regard to the banding issue, I'm not entirely sure why it is happening, but I have a theory. The logo is displayed by flickering between two sets of six sprites: 0X0X0X0X0X0X and X0X0X0X0X0X0, where X is a sprite and 0 is a gap. What I think is happening is that the sprites are not being entirely accurately positioned (due to colour bleeding?), so that there is a slight overlap between the edges of the sprites. This causes the colour at the edges to appear lighter (since it is being displayed on both frames), and leads to the banding effect. I could be wrong about this though ...

 

Chris

With regard to the banding issue, I'm not entirely sure why it is happening, but I have a theory. The logo is displayed by flickering between two sets of six sprites: 0X0X0X0X0X0X and X0X0X0X0X0X0, where X is a sprite and 0 is a gap. What I think is happening is that the sprites are not being entirely accurately positioned (due to colour bleeding?), so that there is a slight overlap between the edges of the sprites. This causes the colour at the edges to appear lighter (since it is being displayed on both frames), and leads to the banding effect. I could be wrong about this though ...

 

There are a number of factors at work. Perhaps a picture is worth 1,000 words.

Depending upon your monitor, this may or may not look like much. For comparison, here's the same image rotated:

What's happening is that on most monitors, the total amount of light emitted when two horizontally-adjacent pixels are lit is not exactly twice the amount of light emitted when one pixel is lit. Thus, an area where many pairs of horizontally-adjacent pairs of pixels are lit will not appear the same brightness as an area where only isolated pixels are lit, even if the total number of pixels lit is the same. In this particular demo picture, the areas inside the letters have many pairs of horizontally-adjacent pixels lit, while those outside the letters have none. One text box is a pixel-perfect inverted image of the other. You'll notice the artifacts at the edges of the letters are different, but the overall effect is unchanged.

Thanks for all the comments. I am happy to say that I have now spoken to Erik (modertimes99), and he has agreed to let me use his fantastic Silkworm tune for Juno First! I will incorporate this tune into the next release that I post here. Beyond this, my goal for the game is to add some actual levels, so that the game-play can be properly tested and tuned. I have reasonably high hopes for the game as it seems to be coming together nicely so far.

 

With regard to the banding issue, I'm not entirely sure why it is happening, but I have a theory. The logo is displayed by flickering between two sets of six sprites: 0X0X0X0X0X0X and X0X0X0X0X0X0, where X is a sprite and 0 is a gap. What I think is happening is that the sprites are not being entirely accurately positioned (due to colour bleeding?), so that there is a slight overlap between the edges of the sprites. This causes the colour at the edges to appear lighter (since it is being displayed on both frames), and leads to the banding effect. I could be wrong about this though ...

 

Chris

 

Take a look at Suicide Mission. Same issue. Whatever the cause, the TIA, the TV, or some aspect of human vision related to the flicker, I don't think it's avoidable. You just have to tolerate it.

 

Now can you make the score values a solid color??

BTW, maybe you can imply a darker shade of blue with dithering to get more of a 3D effect.

 

Also, you may be able to buy yourself enough cpu time to change colors in the score legend if you use a kernel like Commie Mutants:

 

[

<1000 words removed for brevity>

 

Depending upon your monitor, this may or may not look like much. For comparison, here's the same image rotated:

 

What's happening is that on most monitors, the total amount of light emitted when two horizontally-adjacent pixels are lit is not exactly twice the amount of light emitted when one pixel is lit. Thus, an area where many pairs of horizontally-adjacent pairs of pixels are lit will not appear the same brightness as an area where only isolated pixels are lit, even if the total number of pixels lit is the same. In this particular demo picture, the areas inside the letters have many pairs of horizontally-adjacent pixels lit, while those outside the letters have none. One text box is a pixel-perfect inverted image of the other. You'll notice the artifacts at the edges of the letters are different, but the overall effect is unchanged.

 

Here is some data to report:

I have a dual monitor display with LCD on left and CRT on right. On the LCD, the effective luminance of the inside and outside of the letters is quite similar but on the CRT the luminance is significantly higher on the inside of the letters.

Now can you make the score values a solid color??

 

I would like to make the score a solid colour, but I can't see how to do it without self modifying code. The current code has only one spare cycle. If anyone can see how to optimise this to provide an extra five mid-loop cycles (for lda #col; sta COLUP0), then I will be very grateful:

 

SpriteLoop
	ldy LINE		; [62] + 3
	lda (CPTR),Y	; [65] + 5
	sta COLUP0	   ; [70] + 3
	sta COLUP1	   ; [73] + 3	
	lda (PTR0),Y	; [0] + 5
	sta GRP0		; [5] + 3	   > 54
	lda Dot,Y		  ; [8] + 4
	sta GRP1		; [12] + 3	  < 42
	sta.w GRP0	   ; [15] + 4	  < 44	
	lax (PTR1),Y	; [19] + 5
	lda (PTR2),Y	; [24] + 5
	sta TEMP		; [29] + 3
	lda (PTR3),Y	; [32] + 5
	tay			; [37] + 2
	lda TEMP		; [39] + 3
	stx GRP1		; [42] + 3	  > 44 < 47
	sta GRP0		; [45] + 3	  > 46 < 50
	sty GRP1		; [48] + 3	  > 49 < 52
	sta GRP0		; [51] + 3	  > 52 < 55
	dec LINE		; [54] + 5
	bpl SpriteLoop		 ; [59] + 2/3

 

Chris

One thing you could do is reverse the sprites and use the PF for the color; that would eliminate one color store.

 

Also, it seems like there should be a faster way to display the dots - use the missiles maybe? Or lose the dots completely

 

EDIT: Additional idea: the first six lines of text all have a zero in the final position: hardcode that zero in and have a separate loop for the final row (with "???").

 

That would give you at least five cycles in both cases.

SpriteLoop; insert 11 cycles somewhere below
	lda (CPTR),Y
	sta COLUP0
	sta COLUP1
	lda (PTR0),Y
	sta GRP0
	lda Dot,Y
	sta GRP1
	sta GRP0
	lax (PTR2),Y
	txs
	lax (PTR1),Y
	lda (PTR3),Y
	stx GRP1
	tsx
	stx GRP0
	sty GRP1
	sta GRP0
	dey
	bpl SpriteLoop

The code above isn't quite correct but the basic idea is to use the stack pointer as an extra register while preserving Y. The timing is wrong, esp. since there are 11 cycles (by my count) that need to be put in somewhere, and I think that the 11 cycles can't be contiguous.

 

The limitation to the above is the tsx will, at best, cause one of the writes to miss one of the digits by one pixel, so you need to make the score digits 7 pixels or less.

With regard to the banding issue, I'm not entirely sure why it is happening, but I have a theory. The logo is displayed by flickering between two sets of six sprites: 0X0X0X0X0X0X and X0X0X0X0X0X0, where X is a sprite and 0 is a gap. What I think is happening is that the sprites are not being entirely accurately positioned (due to colour bleeding?), so that there is a slight overlap between the edges of the sprites. This causes the colour at the edges to appear lighter (since it is being displayed on both frames), and leads to the banding effect. I could be wrong about this though ...

I think that's basically what it is (and perhaps this was already explained, but I just now got it).

 

I just saw this happening in Stella. But I had to be in full-screen, OpenGL mode, with the phosphor effect turned off to see it. I took a screenshot of one frame, and it shows what (I think) is going on.

 

On each frame, you're drawing every other "chunk" of the logo, so the beam is turning on and off as it's moving across the screen. As it's doing this, it doesn't leave a perfectly squared-off edge at the beginning and end of each "chunk". On a TV, it's going to be slightly rounded (and therefore dimmer) at each end of those lines, since electron beams don't make square dots (also, the beam is probably not going to be at full intensity immediately, and will tail off slightly at the end). As the beam turns on and off, it's just a little bit darker at each end, than it is when it's drawing the rest of each line. So you're seeing the net effect of that beam turning on and off every other frame.

 

I didn't quite get this until I looked at the screenshot. The OpenGL filter happens to mimic this effect, since it's scaling up the lines, and shows that kind of rounding-off at each end of each line.

 

Combine two such frames together, and you end up with those dark bands.

 

(Sorry for the huge pic... but it's only 19 k, and I can't use "add attachment" in comments.)