SpiceWare's Blog

Very cool!

Was wore out from coding all day yesterday, so last night I only posted a brief blog entry containing the screenshot, ROM, source and stand alone program.

 

This morning I decided it needed something more

That logo is awesome!

 

 

It would be even better if at power-on you make the logo expand out to its full size from a single line. I mean start by drawing the middle line only, and pull the top and bottom out from there. The "D" in particular would look sinister as it would appear to be a lengthening spike as it comes to a point. You could also animate the green (station?) in the middle to rotate around and such after the logo is at full size.

 

While the logo is forming play some sinister, scary music. The example that immediately popped in my head was from here. Note that they grow the logo from bottom to top, but I think it would look better starting in the middle and then growing up and down at the same rate. But maybe certain letters should take longer. The "d" would look great if it was the last to stop moving (so that your eyes are fixed on the spike). I think effects like these add a lot of "life" to a titlescreen. I love seeing stuff move around on a title screen.

That could work, the image is in RAM so it could easily be manipulated. I'm not set up for DPC+ music. I don't think in-game music will happen, but I should be able to modify the menu routines to support it. One concern is bank 5, which holds all the 6507 code, only has 139 bytes free - all those reposition kernels take up a lot of space. I could possibly make bank 4 also hold 6507 code, but I suspect a change like this will be done towards the end of the project as I don't yet know how much space the ARM code will use.

 

It'll be a week or more before my next Frantic or Draconian update. I'm keeping my Sundays code-free to help stave off burn out. Tomorrow I plan to return to work on Stella and won't work on anything else until after my Cartridge RAM addition is finished and has been submitted to stephena.

Quote, "There is a minor issue with the technique - due to the way TIA generates the video signal there are vertical lines in the image."

Such a perfectionist. Relax!

It is not a minor problem. It is just the way it is. There will always be someone who will point out the smallest flaw, but everyone else will see the overall beauty.

 

Someone pointed out my tune in DK should end on the key of F.

Great feedback, much appreciated, but it DOES end on F. The TIA's F is very sharp, and coming off the previous note which is very flat, the brain can tell something is off.

It'll be a week or more before my next Frantic or Draconian update. I'm keeping my Sundays code-free to help stave off burn out. Tomorrow I plan to return to work on Stella and won't work on anything else until after my Cartridge RAM addition is finished and has been submitted to stephena.

One change I've been craving for (with Stella, with DPC+) is to not see a value in the debugger disassembly listing when LDA #Immediate is being used.

 

I would rather see LDA #$XX because you don't know what the value is going to be, and it becomes annoying trying to figure out if something is going to branch or not when you forget that.

Such a perfectionist. Relax!

Just wanted to point it out, and why it occurs, before somebody unfamiliar with the system brought it up. I bet somebody will bring it up when I post the Homebrew topic, I'll try to remember not to mention it there to see if that happens

 

One change I've been craving for (with Stella, with DPC+) is to not see a value in the debugger disassembly listing when LDA #Immediate is being used.

 

I would rather see LDA #$XX...

I see how that could be useful. It should probably be aware of the state of FastFetch mode as well, and only show the #$XX if FastFetch is turned on. I've got too many projects on my plate though, so I don't plan to add another one at this time. Frantic's been delayed enough as it is, and then along came Draconian

Added some screenshots with Stella's Debug Color mode turned on to help you see how the 96 pixel image is created.

The lines in any 96 pixel display at sprite boundaries are due to the fact that chroma/luma aren't perfect square waves, taking differing amounts of time to ramp up and down, and doing so in an analog fashion.

 

Some people lessen the lines by forgoing flickerblinds and doing a solid 6 sprites in a row on the left in even frames, and another solid 6 sprites in a row on the right in odd frames. That just leaves just a single darker line down the middle.

 

The bB titlescreen 96-wide minikernel uses flickerblinds and does the same. Personally I agree with the others that it's no big deal.

 

(and beautiful title!)

I can wrap my head around how you make that titlescreen, except how can you have 6 missile0 and 6 missile1?

Never mind. Just forgot you get 2 sets of triple missiles.

The part about PF1 masking... is that due to the "every other line" player1? (Debug colors doesn't show PF0 PF1 PF2 or SCORE colors differentiation -- it's all playfield.)

I've added some screenshots and a new ROM to show how it looks if PF1 isn't updated (technically PF1 is updated, I just changed the value so it's always the same).

 

Ideally, what we want to do with the players(0, 1) and missiles(m, n) is this:

0m0m0m1n1n1n
m0m0m0n1n1n1
0m0m0m1n1n1n
m0m0m0n1n1n1
...

To do that we need to shift players right by 8 pixels at the same time as we shift missiles left by 8 pixels.

 

That's not possible as the normal HMOVE can move 8 right but only 7 left. The early HMOVE can only move left(though up to 15 pixels).

 

So instead I move everything right 8 pixels using a normal HMOVE, then everything left 8 pixels using the early HMOVE.

 m0m0m0n1n1n1
m0m0m0n1n1n1
 m0m0m0n1n1n1
m0m0m0n1n1n1
...

The problem with that pattern is the background (b) color shows up on the right:

 m0m0m0n1n1n1
m0m0m0n1n1n1b
 m0m0m0n1n1n1
m0m0m0n1n1n1b
...

To hide the background color I use the playfield(p) in conjunction with SCORE mode. On that line the missile that's all the way to the left is masking the part of playfield that doesn't need to be masked, but everything's black so it doesn't matter.

 m0m0m0n1n1n1
m0m0m0n1n1n1p
 m0m0m0n1n1n1
m0m0m0n1n1n1p
...

Using VSYNC works as well, though there's that "noticeable when brightness is up" issue. Plus due to timing a couple pixels end up behind VSYNC, leaving you with only 94 pixels visible.

That's actually kind of cool (the screenshot without the PF1 update). It looks like there's a spotlight illuminating the letter N from below. Could be useful someday.

Thanks for explaining this in detail! VERY interesting stuff!!