Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,062

Juno Title

Sign in to follow this  
cd-w

1,535 views

This is just a quick update on my Juno First project. I have now created the title screen, thanks to some more amazing artwork by Nathan. I was aiming to reproduce the look of the Arcade title screen as far as possible, and I think I have managed to do a reasonable job given the limitations of the 2600 (arcade shot on the right :)):

 

blog-6563-1170931286_thumb.png

blog-6563-1170931294_thumb.png

 

The logo is 96-pixels wide and is created using the Homestar/Ruby Runner flickering trick. It is necessary to use the Phosphor option in the emulators (Game Properties->Display under Stella) or it looks like a mess. There is one small issue with this technique when using a real TV, and that is a banding effect between the columns. I think this is caused by colour bleeding, but I'm not entirely sure. This banding effect is shown (exaggerated) in the screenshot below:

 

blog-6563-1170931532_thumb.jpg

 

Anyway, even with the banding effect, I think the logo looks very nice. The binary and source for the title screen are attached at the bottom of this message. This screen will be included in my next Juno code release (hopefully sometime soon). One of the few things missing from the game now is some music for the title screen - there isn't any in the arcade game, but title music seems to be the norm for Homebrew Atari games! If anyone has any spare music that they would like to contribute, then I will be very grateful!

 

Chris

Sign in to follow this  


13 Comments


Recommended Comments

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!

Share this comment


Link to comment

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

Share this comment


Link to comment
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.

checker.gif

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

checkerr.gif

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.

Share this comment


Link to comment

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??

Share this comment


Link to comment

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:

 

s_CommunistMutantsFromSpace_4.png

Share this comment


Link to comment

[

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

Share this comment


Link to comment

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

Share this comment


Link to comment

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. :)

Share this comment


Link to comment

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.

Share this comment


Link to comment

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

 

juno-logo-gl.gif

Share this comment


Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...