Loved the video, and loved Prince of Persia growing up. It might have been my first PC game, back on our old 286. I'm saying might be, because we also had Monkey Island and Alley Cat!
Now that I'm older, I really appreciate the relentlessness of the vision. "I'm just gonna do rotoscoping! I'm gonna film my karate teacher and my brother!". I have to say it's really rare these days in the tech industry to see this kind of insane vision. It's even more rare to see someone pull off a cohesive product out of it.
I wish the interviewer had asked for more elaboration on the techniques used. It went really quickly from:"I ran out every single byte of memory with this Prince guy, how do I create an antagonist? I know, palette shifting!" to "then I added sword fighting, and enemy guards". Still, really love to hear these tales of optimization.
And he did it on an Apple 2. Those machines were good programming workstations, in the day, fast storage, lots of tools, and so forth, but high resolution graphics were hard to do fast.
And it is not even palette shifting. The Apple has absolute colors. He literally made another draw routine that performed the XOR operation.
For a modern day example of similar dedication, check this out:
Python scripts create in line assembly for the ray caster, PLASMA byte code interpreter, big world, animations, and excellent use of the 6 colors and artifact art.
A game this big would have been epic in the day. The team has been grinding away at it for some years now.
It will end up being an exemplary example of an RPG, and on the Apple, that kind of game is in the sweet spot.
What Jordan did was not really considered possible. PoP amazed many people!
The big complication was 7 pixels per byte. Artifact colors work on even "bit boundaries" aligned with the colorburst.
On pretty much every other computer, the same bit patterns resulted in the dame artifact colors, but the Apple had even and odd byte patterns, because the repeat took two bytes, not one like other machines.
On the other hand, having that high bit shift the pixel clock a little meant 6 colors, plus black and white.
Because of how artifacting works, that is actually enough to do anything. Until the PC and some machines like the color computer 3, artifact colors were limited. Red blue, kinds of things.
The secondary complication was the screen addressing, which cost a table lookup. Had it been linear, overall draw speed would have been a bit faster.
Right, within every even/odd group of seven pixels, the even/odd colors for each of those pixels were reversed. With the high bit switching between different sets of colors. And on top of that the vertical scan line interleaving.
So many levels of owch! And punching through all that with an 8 bit 6502. It's really hard to appreciate how fucking hard any Apple ][ game that uses hires graphics had to work just to put a dot on the screen.
Even more amazing were the text/hires graphics adventure engines that stippled together different colors to get a wider palette. It was so hard for the poor 6502, that part of the visceral pleasure of the game was just sitting there watching it draw each scene.
And all the visible text (IN UPPER CASE OF COURSE) must fit in the characteristic four lines at the bottom. Since it drew the scene so slowly, there was enough time to read the text before it scrolled off the top. Talk about making lemonade out of lemons, due to technical limitations!
Hi-Res Adventure #4: Ulysses and the Golden Fleece for the Apple II
Not to mention that the HGR screen was also interleaved, rather than linear. Also, if you factor in DHGR, you remove the half-pixel shift, but instead you operate like you do in 80 column text mode, with the even columns of 7 pixels being in the normal high-res memory map, and the odd columns being in the auxiliary 80-column memory, on top of the normal HGR interleaving. Certainly a lot to wrap your head around as compared to other video subsystems.
When your only registers are a 8 bits X, Y, and A, the hires screen memory was practically encrypted!
It felt so fucking amazing to finally have a computer with a normal 1 pixel : 1 byte memory mapped display.
But before that, I played around with the Sun CG1 graphics board (on a Sun 2: I mmap'ed /dev/cgone0, but maybe it was actually a cgtwo card, not sure), which was kinda but not really memory mapped.
It had 8 bit color mapped pixels, and it had an implicit read position and write position, such that you could address a row and column of pixels at a time, one pair for reading and one for writing ("rop mode memory").
When you accessed a column of the row block of memory, that set which column you could address in the other column block of memory. When you accessed a row of the the column block of memory, that set which row you could address in the other row block of memory!
As it turned out, that just happened to be useful for drawing lines and filling trapazons and performing raster operations, but it made random access quite inefficient, and was a huge pain in the ass for anything else.
(Although nowhere near as painful as Apple ][ graphics, but a lot more expensive!)
I think the early X10 and X11 servers actually supported it (SunView [SunTools at the time] certainly did), but it was really really slow.
I learned later than John Gilmore had written weird union structs the .h file to describe the memory mapped registers, when he was at Sun in its early days:
Here's some Forth and 68K code I wrote to play around with that card (notice how register offsets gr_x_select / gr_y_select, 68k code xsel / ysel, and Forth words lineaddr / coladdr work together -- yes Forth can mmap device registers, and that is RPN 68k assembly code, with opcodes at the end of the line!):
Did it use double hires graphics? That was even harder to do correctly. Half the graphics memory was in the first 64K of memory ($2000-$4000) and the other half was stored in the second bank switched 64K of memory.
It's possible that Mechner did go into further detail and it was cut for this video. Keep an eye on this channel; recent videos in this series (Rand Miller and Lorne Lanning) had the full un-cut interviews posted, which go on for hours and are well worth it if you're into this stuff.
Now that I'm older, I really appreciate the relentlessness of the vision. "I'm just gonna do rotoscoping! I'm gonna film my karate teacher and my brother!". I have to say it's really rare these days in the tech industry to see this kind of insane vision. It's even more rare to see someone pull off a cohesive product out of it.
I wish the interviewer had asked for more elaboration on the techniques used. It went really quickly from:"I ran out every single byte of memory with this Prince guy, how do I create an antagonist? I know, palette shifting!" to "then I added sword fighting, and enemy guards". Still, really love to hear these tales of optimization.