EricBall's Tech Projects

Those animation look pretty cool already. The running one looks odd though, like some animation frame is missing in the middle.

 

BTW: I just had a first look at your complete kernel code. IMO it looks very easy to remove those JSR/RTS. Two loops with loading from a table should do the job and would be even faster than what you have now. So you just would have to double that LINESUB code.

Hi there!

 

Uihjah! Guess it shows that I'm generally ignoring anything sounding like "hardware" discussion. So a High Score cart was released for the 2600?

 

Greetings,

Manuel

Uihjah! Guess it shows that I'm generally ignoring anything sounding like "hardware" discussion. So a High Score cart was released for the 2600?

Whoops, that's me confusing the 2600 & 7800.

Those animation look pretty cool already. The running one looks odd though, like some animation frame is missing in the middle.

 

BTW: I just had a first look at your complete kernel code. IMO it looks very easy to remove those JSR/RTS. Two loops with loading from a table should do the job and would be even faster than what you have now. So you just would have to double that LINESUB code.

The code is only half the work, the other half is redoing the level bitmaps.

Does look very nice - It is very hard to play this without being able to dig, though!

Hi there!

 

Uihjah! Guess it shows that I'm generally ignoring anything sounding like "hardware" discussion. So a High Score cart was released for the 2600?

Whoops, that's me confusing the 2600 & 7800.

 

But there was talk about something like that, no? IIRC 2-3 years ago, Paul Slocum asked me if I were to update Star Fire for something like that... ... if I'm not mixing it up with something else...

 

That's the problem with homebrew hardware, no matter what the plan is, 95% of it never sees the light of day... that's why I generally don't care until it shows up in the AA store...

 

Greetings,

Manuel

But there was talk about something like that, no? IIRC 2-3 years ago, Paul Slocum asked me if I were to update Star Fire for something like that... ... if I'm not mixing it up with something else...

Maybe you remember that: AtariVox

But there was talk about something like that, no? IIRC 2-3 years ago, Paul Slocum asked me if I were to update Star Fire for something like that... ... if I'm not mixing it up with something else...

Maybe you remember that: AtariVox

 

If you use the AtariVox then it will conflict with the "joy2ser autoload fob".

 

Maybe you could have it elegantly fail in either instance (fob or atarivox).

This looks really good with the sprites. However, there seems to be a bit of a glitch when the player is falling. The sprite alternates slowly between the two frames shown below, though this could be deliberate?

 

 

Chris

Hi there!

 

Maybe you remember that: AtariVox

 

Sure I remember that, but it was definitely something different. I don't find any trace of it now though...

 

More like some vaporware stuff from "Junie's Creations" or ... what was his name again... CupCactus? Something like that...

 

Greetings,

Manuel

This looks really good with the sprites.  However, there seems to be a bit of a glitch when the player is falling.  The sprite alternates slowly between the two frames shown below, though this could be deliberate?

Good eyes. Actually, what you're observing is a side effect of the repositioning line between the rows of 8 lines. I don't bother changing the sprite I'm not repositioning, so it duplicates the last line of the top row. Similar stuff happens to the climbing sprite although it's less obvious. I tried having the falling sprite move but it looked silly.

 

You can see the same effect when two running sprites are on the same row. One sprite will touch the ground while the other doesn't (because that sprite is being repositioned).

Good eyes.  Actually, what you're observing is a side effect of the repositioning line between the rows of 8 lines.  I don't bother changing the sprite I'm not repositioning, so it duplicates the last line of the top row.

Maybe with the updated kernel you will be able to fix that.

 

You can see the same effect when two running sprites are on the same row.  One sprite will touch the ground while the other doesn't (because that sprite is being repositioned).

I don't understand. AFAIK repositioning happens after the bottom line, no?

 

BTW: I noticed the player sprite flickers too. Is that intentional?

I don't understand. AFAIK repositioning happens after the bottom line, no?

 

BTW: I noticed the player sprite flickers too. Is that intentional?

How to best explain this... Hmm... Let's start at the beginning of the kernel. The first two lines of the kernel position the two player sprites. (Player sprites in TIA terms, not game terms. They may be player or enemy.) The next 8 lines copy the playfield and player sprites from the virtual bitmaps in SC ROM to the playfield registers. Now the fun begins.

 

The next line first clears GRP1 and PF0-2 (since I won't have the time during the repositioning to create the asymetrical playfield), then repositions player 1. Meanwhile onscreen we have a black line between the two rows of the playfield, but player 0 doesn't change from the previous line.

 

Then we're back into the 8 lines of copying the playfield & player sprites. The next line then repositions player 0. Then back to 8 lines of copy; rinse & repeat.

 

So each sprite is really 16 lines high from the kernel perspective, but they alternate which one is being positioned, so it kinda looks like two rows of a brick wall standing on end. Now, if a sprite isn't needed, it's repositioned to the left edge of the screen so it doesn't cause problems (and so the blit routine doesn't need to clean up the previous frame).

 

This gives the kernel the ability to display two (non falling/climbing) sprites on the same line without flicker and more than two sprites onscreen without flicker (assuming they aren't on the same line). But if there are more than two sprites on the same line (or two falling/climbing sprites) then there is a semi-intelligent flicker routine built into the code to determine which sprite gets drawn every frame.

 

<edit>Oh, I just realized your question was - is the player supposed to flicker just like the enemies. The answer to that question is yes. All sprites are equal.

Nice game so far. The animations really do bring it to life!

 

As far as the memory card goes did you homebrewers know/remember this?

 

Memory Card

 

A while back he was handing them out to seed development. I have one and will use it in the future. If anyone wants to borrow it in the meantime, let me know.

 

It's compatible with the AtariVox.

 

Oh, and why are you considering going to reflected? I'm guessing you will still be asymmetrical but using the reflected mode has some advantages in your kernel?

 

- David Galloway -

Oh, and why are you considering going to reflected? I'm guessing you will still be asymmetrical but using the reflected mode has some advantages in your kernel?

You could save some cycles by using a mirrored playfield. Then you would avoid any writes to PF0 and the AND. So you would have 7 reads and writes (=49 cycles) instead of 7 reads, 9 writes, AND and NOP (59 cycles).

I originally went with non-reflected because I wasn't certain that I could avoid a glitch in midscreen. But Thomas assures me it's possible, and even provided the code in comment #42(!) in Time, it is precious.