Jump to content

azure

Members
  • Content Count

    179
  • Joined

  • Last visited

Community Reputation

159 Excellent

1 Follower

About azure

  • Rank
    Chopper Commander

Profile Information

  • Custom Status
    Busy.
  • Gender
    Not Telling
  • Location
    Seattle, WA
  • Interests
    Classic game consoles and computers, game programming, stock market investing
  • Currently Playing
    Knight Rider (2600)
  • Playing Next
    Knight Rider II (2600)

Recent Profile Visitors

7,574 profile views
  1. Mine too. It has interesting game mechanics.
  2. Hmm. That 21 addition is fascinating. I suppose you already knew, but 21 is the only number that works for that algorithm. +20 doesn't work for 252/3 and 255/3. And +22 doesn't work for 2/3 and 5/3. From what I can make of it, it's adding two adjustments to the summation series: +21/128 and it's also folding back in the carry. I'm not sure I can figure out what adjustment the carry is having, but it seems to make it all work for the full 8-bit range.
  3. Sorry for bumping an old thread, but I think the accuracy of this divide by 3 algorithm can be improved a lot by a simple fix. As it is it produces an incorrect result for all multiples of 3 greater than 0. Just add 1 before each iteration, then the algorithm gives the correct answers up to 255/3. Only four iterations are actually necessary for 8-bit division, so there's a savings of 5 cycles. Five iterations will give accurate answers up to 1024/3 if extended into 16-bits. sta Temp ; 3 (3) ; iteration 1: a = a * 1/4 clc ; 2 (5) adc #1 ; 2 (7) ror ; 2 (9) lsr ; 2 (11) ; iteration 2: a = a * 5/16 sec ; 2 (13) adc Temp ; 3 (16) ror ; 2 (18) lsr ; 2 (20) ; iteration 3: a = a * 21/64 sec ; 2 (22) adc Temp ; 3 (25) ror ; 2 (27) lsr ; 2 (29) ; iteration 4: a = a * 85/256 sec ; 2 (31) adc Temp ; 3 (34) ror ; 2 (36) lsr ; 2 (38) ; iteration 5 is unnecessary for 8-bit division by 3 ; iteration 5: a = a * 341/1024 sec ; 2 (40) adc Temp ; 3 (43) ror ; 2 (45) lsr ; 2 (47) The assembly can be verified here: https://skilldrick.github.io/easy6502/ I've written a simple test program in C, which implements the algorithm in 16-bits. It flags all incorrect results. div3.c div3.txt.zip
  4. How can Combat not be on the list? Did it really sell less than 1 million?
  5. I've been subscribed to him for a while. There was something that popped out at me on this video. At 0:38 he asks "How many bits are used to produce one frame of gameplay on a standard Atari 2600 game?" At 1:49 he says there are 39 bits, but he's not counting the (real) background color (COLUBK) as a bit. I think it should be counted.
  6. Can you put me on the list for purple cart, Pokey Max, and YM2151?
  7. Found a bug in my bankswitching code that's been in the code since the first day (going back to 2018). It didn't surface until now, because the bankswitching routines were in the same offset location, so they worked by accident.

  8. Maybe have occasional special golden arrows with a power boost? So missing those would be extra costly. Basically like the boost arrows in Mario Kart. 😏
  9. I was thinking something. This game would work nicely in the vertical direction but with rockets instead of cars. Although limited to 6 rockets for non-flickering sprites. Instead of acceleration arrows, maybe acceleration clouds. Heh. Maybe an option for a future sequel?
  10. What if you had a little on-screen indicator in each lane that blinks on and off when you press and depress the button? The visual feedback would tell you which car is yours, because it will blink in synchronization with your button presses. It would have to be during the waiting time before the race starts. That's kind of how it works in Nintendo multi-player games where you're selecting a character. There's on-screen feedback when you press buttons. I went back and noticed you do indicate which lane you're in by changing from grey to color. It's easy to miss though if you're not paying close attention.
  11. I'm assuming you wouldn't use deceleration as part of the function. It'd be only cars where acceleration > 0.
  12. I tend to overcomplicate things, so don't let me sidetrack you. What you have sounds pretty good. After thinking about it some more, very little has to be done to shape the sound envelope when the sound is a function of the acceleration (or velocity or both). The math is already done in the car physics. It might be worth an experiment to divide the 8 cars into 2 groups and bind 4 cars to each sound channel: Top 4 cars on the left channel and bottom 4 cars on the right channel. Each channel's volume could be computed from a base minimum plus the summation of the currently accelerating cars in its group. That way all players would be interactively contributing to the sound rather than the top 2 leaders and you'd still get throbbing ups and downs.
  13. I think you'd have to play them at two different pitches and shape their sound envelopes with offset attack and decay so they contrast. When I loaded up the game I immediately thought of the sounds at Disney's Tomorrowland Speedway (better with earphones), but louder and sped up. It sounds like a back to back series rising and falling motor sounds shaped by a combination of throttling and the Doppler effect
  14. I'm curious if there will be sound effects given the 8 cars and how that'll work out. Btw, it looks really good. It reminds me of a rhythm game.
  15. It has Microsoft Office, Visual Studio C++, and a lot of educational CD-ROM games installed, so maybe it was an overlay for one of those? Possibly an obscure game.
×
×
  • Create New...