ThinkC [Study Group A - GameDevTrack] - Time Measurements

[Mu0n]

It's been a long, long, long game hobby of mine to be able to program a new 68k, black and white game that runs smooth on real hardware. I know that C is my only reasonable modern chance to get there, with some dips into assembly inline blocks for some memory block movement that has to occur for video RAM.
I'm envious of Gruz (of Classic Mac Gaming, aka insanelygruz) who has found the impetus to get FlappyMac to the finish line https://gruz.itch.io/flappymac and would like one day, to add my stone to the pile.

(an example of the basics of platform gaming made in THINK C I did over 15 years ago)

Which is why, after talking it through with @eric , who isn't particularly interested in game dev but keenly interested in app/tool dev, came to an understanding with me so that I can spearhead an offshoot track for game development. Here are my goals with it:

-All pre-PPC, 100% pure 68k.
-As old as you want it to be, all the way down to a Mac 128 if need be. There's still documentation out there to make this happen!
-Continue to focus using THINK C as a nice middle point that can reach old and new in the 68k era.
-Practice timing methods to get through the barrier of dealing with screen refreshes every 60th of second (every 'Tick').
-Practice pipelines to get well dithered artwork from modern machines to this
-Create a music engine to use the square wave, the four-tone synth or the freeform wave synth of the mac

I get that I might go alone in these threads for a bit and that's alright. It'll be kept as a beaten path for others to follow at any time, that's the beauty of Tinker Different as a forums.

I get that the barrier of entry's height will be solely dependant on documentation, on APIs and other resources out there, which are dwindling due to digital erosion. Let's fight that off!

Ingemar Ragnemalm's Sprite Animation Toolkit is a good starting point (one used by gruz for his stuff) to do the heavy graphics lifting and it has to be understood that it's System 7+ only. http://www.lysator.liu.se/~ingemar/sat.html

Meanwhile, I had the beginnings of a System 6- focused on game programming back in 2004-2006 and it has some code snippets that can be used to load up graphics and deal with the basics (crude music engine too). https://mu0n.github.io/ForayInto68k/index.html


GOAL FOR THE FIRST WORKSHOP: Become a Time Lord

a) Deal with timing with Ticks (pre System 7) and Time Management routines (post System 7). The effect of using a long-winded thing every vertical blanking (smooth) vs doing it randomly (flickering).

b) you may want to use the small ANSI template in THINK C to easily get text output for your timing results



OVERVIEW OF NEXT WORKSHOPS:

• do various animation techniques with scrolling and TIME THEM OUT to compare things scientifically
• sound production. Divide peeps into Sys6- Sound Driver and peeps into Sys7 Sound Manager. Start with freeform waves. then dive into square wave synth. do a part 2 with 4-tone synth. goal, program a polyphonic tune
• keystroke input that drives a bitmap around and do a brain dead simple platformer with 1 platform and a hole and manage a game loop and let the character fall. bonus points if you have a bitmap state machine to deal with sprite animation
• ???
• Profit

 

[Crutch]

Cool stuff.

I have two 68K games coded up in THINK C that are 90%+ done, hoping to finally get the time and motivation to get them to a Public Beta stage, maybe coinciding with this effort.

The Sound Manager isn’t a System 7 thing btw. It goes back to the Mac SE and Mac II ROMs circa 1987. For anything post-Plus, unless you just want to start from scratch, the answer is almost always “just play a snd resource asynchronously.” (You can put your square wave polyphony in a snd resource if you want to.) If you want to get fancier, by the mid-‘90s there were Mac APIs to play MOD files, saving tons of space at the expense of processor time. Of course if you want to run on an ‘84-‘86 machine you do need the Sound Driver.

If you are using an emulator, beware that microsecond timing with the _Microseconds trap (System 7) appears to be suspect under Mini vMac. I have a bug report pending on that.

 

[Jason Heiser]

I’ve been slowly winding my way to the point of making something fun and interesting for early Macs. I share some of the same goals you do: fast, flicker-free animation and synchronized audio. The challenge I’ve given myself: do it in assembly for maximal optimization. I want to move as many of the bits myself that I can.

So far I have written a handful of routines for the following:

• Install a VBLTask with the Vertical Retrace Manager for doing work between ticks.
• Initialize the alternate screen buffer and toggle it on/off with the sixth bit in vBase+vBufA
• Read a SND resource and shove the first 370 waveform bytes into the audio buffer.
• Various primitive routines for crudely filling/emptying the video and audio buffers.

Getting these things to work has been challenging, but also very rewarding. Still, they are not impressive to anyone but me!

Next I’m planning to come up with a priority-based sound queue and mixer. When there’s a VBL interrupt, the two sounds with the highest priorities will be mixed and fed into the audio buffer. Naturally, every last byte in the buffer will be full so there is no dreaded popping. I am heeding Eric Zocher’s lessons when he made Airborne!

I’m looking forward to hearing the results, and learning what its CPU expense will be. Sound work can really chew up a lot of cycles on 68000 Macs. The built-in routine for four-voice synthesis devours half the processor, thwarting any chance at quality animation. It’s really only good for accompanying a static image, like Apache Strike does with its title screen.