SpiceWare's Blog

I'm not entirely willing to give up on Project Retro yet. Not until I get a firm "no". Of course, without a firm "yes" there's no point in continuing with it either.

I hope TG paid you for the effort you did put in, even if they decided to axe the project.

I hope the "bus-stuffing bankswitch format" has residual benefits for batari BASIC. I could see making an Ultima type game if batari could be motivated to explore large bank switching formats (and incorporate support into bB)

 

UPDATE: I LOVE the Adventure-esque sound effect in cat food

No money changed hands. I'm free to do what I want with my code.

 

 

 

It might show up in bB, though it'll be quite some time before we know. I plan to wrap up Frantic first, then there's just a little bit more left to do on Chun-Li. After that I'll start to work on the new format.

 

The sound effect as written is for my advanced driver, which I haven't ported to bB.

sfxDF:
.byte 0, D3, D3+1, D3+2, D3+3 ; collect item

sfxCV:
.byte 0, $6f, $6f, $6f, $6f ; collect item
sfxCOLLECT = *-sfxCV-1

 

 

 

There hasn't been much response to the simple driver, so I don't know if I'll take the time to port the advanced version or not. It's simple to convert the above for the simple driver though:

 

sfxF:
.byte 0, 0,0,0, 1,1,1, 2,2,2, 3,3,3 ; collect item
sfxCV:
.byte 0, $6f,$6f,$6f, $6f,$6f,$6f, $6f,$6f,$6f, $6f,$6f,$6f ; collect item
sfxCOLLECT = *-sfxCV-1

 

In that you can see the benefit of the advanced driver, especially when you factor in that your sfxF/sfxDF and sfxCV tables are limited to just 256 bytes each. sfxDF = Duration & Frequency table.

I added some NTSC/PAL/SECAM screenshots.

Awesome Darrell - glad to see Cat Food not going to waste.

 

Also, very cool sound driver!

 

I may hit you up with questions as you work on the digital samples for Frantic, as I have also resumed work on Frenzy.

Bob

I can't speak for the other bB enthusiasts but I've been satisfied with my ability to generate sound effects. Although it is tremendously gracious of you to even consider porting libraries to bB.

 

I've been trying to figure out a good way to implement 4 way scrolling and the ability to load in playfield data as needed. batari made an example that I modified to run on newer bB builds here:

http://atariage.com/...ll-examplegame/

 

Sadly, manipulating level data is non-sensical. I don't really understand his code.

 

I guess what I'm saying is, if you ever get to thinking about bB again I'd appreciate any help you could offer simplifying 4 way scrolling (and loading in playfield data)

Thanks PacManPlus! Sure thing, though I'm doing the prep work on the ARM so I'm not sure how well it'll translate to the 6502.

 

 

Atari playfield scrolling is complicated due to the way the TIA draws the playfield. If you look at the bits in the byte as 76543210, some parts are displayed as 76543210 while other parts display as 01234567. The other complex part is you're shifting individual bits around, and if you don't have a grasp of binary (testing the state of individual bits, shifting bits from one byte to another, etc) it'll be hard to follow. This might help you follow what's going on.

 

I think the best approach for playfield scrolling in bB would be to utilize DPC+ and have functions written in ARM code with special bB commands that would call it for you. Setting that up would take a lot more work than I care to tackle as I'd need to have a really good understanding of how bB is doing everything, and I don't.

OK, I finally found some time to test your program on my SECAM VCS. I can't attach pictures here, but it seems that red is a bit tricky to get on SECAM. In the title screen the exclamation point after "Timmy" and the word "RED" turn out to be a light gray, whereas the word "START" is red when it's not selected. In all levels the platforms where red is mixed with something else it also ends up as gray, while the 'R' blocks and the ladders / chutes really are red. All other colours seem to be as intended, as far as I can tell. I hope this helps.

Thanks! That is odd about the red - I was expecting the striped areas to end up a different color but figured anything that was solid red over multiple scanlines would come out OK.

Any relation to South Park Timmy? I mean the one in the wheelchair?

 

 

How about writing a few mini-kernels to avoid the color bleed on to the rope? I never liked that in Jungle Hunt, so one day I fixed it. Turns out it was a real simple fix as the ball wasn't being used. I don't know why they didn't do that in the first place. I realize you are using the ball and playfield here, but a small kernel to do a midline color change shouldn't be too bad.

 

 

Jeff

 

 

Edit: I just followed the link and found out who Timmy was.

Timmy's a monkey, hence the banana requirement.

 

There's a bunch of mini-kernels due to sprite repositioning, which can occur on any scan line.

 

The ropes and slides look a bit different on a real Atari vs Stella as I round-robin the ball and both missiles. Stella's screen grab only shows 2 frames worth of the blending caused by the round-robining.

Added a fixed version of Timmy! for the Harmony Encore.

 

 

dd skip=3 count=29 if=timmy_20130613.bin of=t29k.bin bs=1024

cat DPC+20121020.arm t29k.bin > timmy_20130613_encore.bin 

In Timmy! if you switch the left difficulty to A you'll see 4 debugging sprites appear at the top.

 

The left 3 show the platforms & ladders detected around around Timmy.  What's overlapping Timmy is white, what's around Timmy is red.

 

The 4th shows the detected ropes/slides. What overlaps with Timmy is blue, the bottom white line shows what was detected - 1 pixel = rope,  4 pixels = slide.

 

The detection occurs in function UpdateTimmyPF_RS().  The results are used to determine if Timmy is on a ladder and cane move up, standing on a platform or falling, climbing a rope, going down a slide, etc.