Game engine ramblings

Nov 9 2024 12:42 AM

rpg game engine design ideas

While I love hardware programming, I am not the brightest hardware programmer. But hopefully this project will give me some insights into what's needed to become a better one.
The overview of the game engine is broken into systems or modules or whatever you want to call them, in order of timing priority

	audio system    (very fast)
	draw system	    (fast & memory intensive)
	keyboard sys    (handled by interrupt)
	game logic system   (slow)

Some ideas about the audio system.

It's not too difficult to replicate an "analog" voltage with a digital pin. We have a (presumably) GPIO-esque pin on the 89 that can be driven by the CPU.
So, we can probably bring the pin up between 0-3.3 or maybe 0-5V, I really have to check. If we hook it to the CPU directly, assuming that we can drive
the pin as quickly as I can command the CPU, we can get a crazy accurate analog voltage, although we probably need a low pass filter, though its not a requirement.

Here's the crudest technical overview of the audio to the extent I've thought about it.

The TI-89 HW4 has a few oscillators on board. One of the oscillators (OSC2?) drives a programmable timer (PRG).
The PRG can pull an interrupt down about every 1/8000th of a second, i.e: 8kHz. So... we can interrupt execution
for audio 8000 times in a second. I got these numbers from some handwavy benchmarks I wrote and a stopwatch.
Just some preliminary thoughts though:

We very well know that CD audio is 44.1kHz. OK, we avoid that, we are bit-banging ... CD audio wouldn't even be worth it
when the actual voltage output is very noisy (since we have to depend on the IO circuit's internal capacitance and resistance
to smooth it out in the first place, and it probably won't do a good job). But still, 8kHz mono audio is telephone quality,
if that one line in the Advanced Properties menu of rundll32.exe audio.msfzwcz (whatever it is i can't remember)
has anything to say about it.

Now, an 8-bit signed WAV file has a bunch of small tiny dots sandwiched between a range of [-127, 127]. And there's a new dot every 1/44100th of
a second. Again, I know little about how audio works except for some simple stuff. The problem immediately lies in negative amplitudes. This
is when the voice coil vibrates inwards or something special like that. There's no immediate way I can think of to generate a negative voltage from
a PWM signal that's capped between [0, 3.3V] (or 5V, still haven't checked). We need a diode or something, maybe. But I've seen audio achieved without
this, so I wonder how that works.

Just looking at PCM data for a few moments, there is a special relationship I can see between pulse-width graphs and the integral of the
wavedata graph. Doesn't it seem like a Riemann sum might help us in some way here? It's not quite ideal, but, well,
I think this is actually me figuring out what is already known as Delta-Sigma DAC....

Pulse density modulation seems much better an idea than interpreting pulsecode modulation and then playing it back via bitbanging.

In fact, this entire ordeal of bit-banging wavdata is really just a matter of accuracy.
A) We just need to drive a pin fast enough.
Driving a pin fast means we can have more control over the accuracy of the desired "analog" voltage.
Spamming a pin with 1s and 0s and throwing that into an RC low pass filter will give us a waveform that looks a little
jagged and curvy, because the circuit has to take time to smooth everything out. Even without thinking of the LPF,
intuitively, to drive voltage output error to 0, we need more subdivisions of the integral which forms the curve we desire.

Really ranting here.... How can I put this....

We wish to drive a pin to a certain voltage. We want to do it as fast as possible. The best way to do that is to think like Riemann did.
We take our pin, and we spam it between low/0 and high/5 as fast as we can. Now, the duty cycle (ratio of on and off) controls the output voltage.
Well, also the number of samples controls our output voltage. By number of samples, I mean that we can have an avg. voltage of 1V by 0V for 12 seconds
and 5V for 3 seconds for 0+...+0+5+5+5/15 = 1V. This... sucks. The average voltage is correct but over a massive time period. We want the average
voltage correct down to a very small magnitude (every 1/44100th of a second should be a guarantee of that voltage). This is just calculus.

I will write down a formal methodology that makes more sense than this lunatic rambling later...
I will probably consult the help of a professor too....

Feel free to send an email with any input (look at the top left of the page and add d0t cmu d0t edu to the end)
            

Bunny

Apr 21 2024 6:19PM

Published again

Apr 16 2024 1:15PM

Republished the website. Should be updated again. I've also noticed that contrib.andrew.cmu.edu seems to host the unpublished versions of the page. That's kinda weird, so I think I'll make sure I do my work-in-progress stuff outside of the www/ folder.

Navbar + Leetcode solutions added

Apr 15 2024 10:55PM EDT

I added a navigation bar and Leetcode solutions. Working on other stuff, stay tuned.

Website is created

Apr 1 2024 2:29AM EDT, edited Apr 16 2024 1:13PM

Thanks for stopping by. I've decided to host this website on Andrew servers because it was free (and simple enough!). With that, I also need to make a very simple website because of the 4GB bandwidth limitation. I'm sure I'll never reach it, but despite once being a "modern" web developer^*, I strongly believe in frugal websites. I've had some SSL issues setting up this website too, but if you're seeing this, it's probably working fine.

* — I did develop web apps professionally (not much anymore). They look a lot cleaner than this, but they sometimes transfer megabytes of data before caching!