dmbaggett · HackerTrans

قبل شهرينdiscuss

In the same era (age 7-12) I went to school on an airbase in Germany and at some point “they” (no idea who) decided I should not do normal math, but should instead spend time with the Airmen who ran the computers. They had an Interdata-something-16 minicomputer which had both punched tape and teletype I/O. I played Oregon Trail on the teletype and always died of dysintery. I once asked the wise and aged Airman (he was probably 25), “can I punch my own holes in the tape and make the computer do cool things?” To which he responded “Yes. No.”

dmbaggett

قبل شهرينdiscuss

I had “Microsoft Adventure” on the H89, which I played for a million hours and was why I dug up the original (probably not really; it’s complicated) Don Ekman Colossal Cave FORTRAN code and ported to TADS, which then led to Graham Nelson’s Inform port.

dmbaggett

قبل شهرينdiscuss

WUT, I had no idea. That’s cool!

dmbaggett

قبل شهرينdiscuss

I remember reading Byte Magazine when I was 7 and not understanding why I couldn’t plug one of those cool S-100 bus graphics cards into my Heathkit H89.

So I made space invaders out of box drawing characters.

BASIC was slow so I tried using C. (Yes, there was a minimal C compiler for the H89!) But then C was too fast and “for (i=0; i<10000; i++);” didn’t seem to slow things down like it did in BASIC so then I was stumped. “C is too fast for games!” — me

The H89 had a built-in monitor and a 5 1/4” floppy drive. Its precursor, the H8, was much like this emulated S100/Altair, with LEDs and switches as your only I/O.

dmbaggett

قبل 8 أشهرdiscuss

I don’t know how much time Andy spent building the “poor man’s VM” system, but I know it was a significant effort that underpinned the rest of the game. The packer was something I probably put a few days into in the beginning (greedy and other trivial heuristics) and then kept improving in my “spare time” over the next year or so.

The packer was the final step after a level was pre-sorted and otherwise processed. It was quite fast, so it added only a little bit of extra time to the primary work of pre-rendering every frame of the level to recover the sort order (which typically took around an hour).

I did experiment with solver algorithms but they were so obviously going to be too slow that I abandoned the idea.

dmbaggett

قبل 8 أشهرdiscuss

Thank you. Too many startups ago. :)

dmbaggett

قبل 8 أشهرdiscuss

Sort of. While it was helpful to have the delta-compressed polygon list for each part of the level in its own 64KB chunk, the minor miracle of fitting >10MB levels into 2MB of RAM (half of which was VRAM as I recall) was down to two things: 1) Andy wrote this insane dynamic layout/loader thing that optimized the CD’s bandwidth (which was of course pathetic by today’s standards, as you point out); 2) I wrote a tool that packed the chunks into pages so that we never needed too many active at any given point in the level. This is an NP-Complete problem and we didn’t have solvers back then so the tool just tried a bunch of heuristics, including a stochastic one (think early simulated annealing). The problem with the latter was that if you “got lucky” you might never achieve the required packing again after the artist changed a turtle or something…

dmbaggett

قبل 8 أشهرdiscuss

Exactly right! I had been working on a prototype for a Doom-style game in the summer of 1994 for the 3DO and built out the beginnings of the “sort polygons AOT” concept. While the idea was conceptually simple, the details were a bear. I guessed that using keyframes with the entire polygon list plus deltas would “just work out” and fit in the limited storage and computational budget of the PS1… and I was very relived when it was clear my intuition was right. (Otherwise we would have needed to redo the entire game engine.)

Another challenge was dealing with foreground objects: you have to somehow sort these into the pre-sorted background polygons. This mostly worked with bucket sorting but we had to use the gross hack of allowing each foreground object to have tunable “push-back” to fix sorting glitches. This required manual work for each level.

Finally, while precomputing the per-frame sort order for a game like Crash would be trivial now, in 1995 we had to build our own Beowulf cluster thingy and farm the level precompute out in pieces to the artists’ SGI workstations, and levels typically took an hour to process. The artists LOVED that. :)

dmbaggett

قبل 11 سنةdiscuss

He did use Allegro, but only to host his own compilers.

dmbaggett

قبل 11 سنةdiscuss

Exactly. You said it better than I. :)

dmbaggett

قبل 11 سنةdiscuss

Yes, but approximate algorithms for NP-hard problems hadn't been as thoroughly studied back then -- this was 1996, after all -- and even if I'd had the appropriate papers at hand, I probably wouldn't have invested the effort to implement anything complicated. There was just simply too much to do in too little time. The simple approximation using greedy packing did pretty well in practice; I'm sure how close that comes to optimal is well understood by now.

dmbaggett

قبل 11 سنةdiscuss

Thanks!

It's on my bucket list to write that book -- also including many humorous tales from my 10+ years at ITA Software, and anecdotes from my current startup (http://inky.com).

If I live long enough, that is. :)

dmbaggett

قبل 11 سنةdiscuss

That would have to be Andy. I'm really kind of a hack when it comes to lisp programming. :)

But yes, Andy's lisp code is certainly great -- all the more so because he also wrote the lisp compilers that compiled it. :)

comments