-
Content Count
6,681 -
Joined
-
Last visited
-
Days Won
10
Blog Comments posted by RevEng
-
-
Stellar work!
I'd love to see the hero get more than 2 frames in his walk cycle. I know that's how Berzerk did it, but Frantic looks so nice that the minimal walk cycle looks out of place.
-
well done! The low pass filter as you described allowed the converter to find the lower fundamental.
The result is more accurate from a lower end point of view, but less interesting in texture... I think the original sample will be an interesting test for the next iteration.
I've attached the low-pass results to the bottom of the first post.
-
Nice Eric - I guess there really is nothing new under the sun!

I think with the addition of the other TIA waveforms the accuracy might be raised a bit... the trick is the FFT comparison code. Gonna have to think about that one for a bit.
RT - The nice part will be the ability to bypass the whole note conversion, and go directly to TIA values.
-
Hmmm, It looks like it isn't a cut-off issue.
I ran that same sample through Audacity's spectrum analysis, and it agrees more or less with the results from my app is outputting. But the original sounds like it has a much lower fundamental frequency.
I guess there's some phase interactions in the original sample that make it sound lower in pitch than it actually is, or maybe there's something else that's throwing both my and Audacity's analysis.

-
I'm no expert, but I'm pretty sure the lower-end frequency cutoff in an FFT is a function of the window size... A 1/60th second window can detect down to 120Hz, after which it's looking at partial waves, which will be interpreted as other frequencies.
I tried increasing the window size to 1/30th of a second, but the larger window smeared the dynamics in the resulting sound.
If I could get the lower frequencies in the FFT, there's no doubt TIA could play them back - plenty of frequencies to pick from in the lower end.
-
I understand the desire to add constraints... the added challenge makes the task more interesting, and I wouldn't be programming for the 2600 if I wanted to take the easiest route to creating games.
But any self-imposed challenges need to take a backseat to the game being fun, and when a coder decides his own constraints need to apply to others then he's lost touch with reality.
-
2
-
-
I don't agree on the stupid part at all, and laziness can be a positive trait for someone who writes code!
It's a concept I first read about in "Programming Pearls", my absolute favorite book on coding; laziness stops you from rushing in and coding the first idea that pops into your head, and forces you to rethink how you can write something in six lines of code instead of a few hundred.
Or to give another example, it forces you to write an easier-to-understand platformer kernel because the thought of deciphering a bunch of complex code is tiring.
The trick is overcoming the laziness when it's really time to code!

-
1
-
-
Wow, that's a heck of an update. Lots of amazing new stuff in there - just when we thought it couldn't get better!
The stack based DPC ram is interesting, and I think the first post I made on AA was a request for C style comments in bB.


WIPs of days gone by - part 2
in dragging through the retro streets at dawn
A blog by RevEng
Posted
Nice that you were able to fit it in much less than 4k!
Did you spread out the coverage of each table byte to a few pixels?
I went with a 60x60 table IIRC, which served both axies. (There's a gravity-free zone at the left and right side of the screen.)
I considered using 2 smaller tables, one with broad coverage for farther away from the sun where changes are less dramatic, and another for closer to the sun where more precision is needed, but since it was a proto I went with the simplest approach.