5 ms·

Accompanying article is here: https://arstechnica.com/gaming/2020/03/war-stories-how-prince-of-persia-slew-the-apple-iis-memory-limitations/ https://arstechnica

Accompanying article is here: https://arstechnica.com/gaming/2020/03/war-stories-how-prince-of-persia-slew-the-apple-iis-memory-limitations/ https://arstechnica.com/gaming/2020/03/war-stories-how-princ... Which links to the transcript: https://cdn.arstechnica.net/wp-content/uploads/2020/03/prince.txt https://cdn.arstechnica.net/wp-content/uploads/2020/03/princ... And his journals from the time, which are now being published: http://jordanmechner.com/journals http://jordanmechner.com/journals

reaperducer 7y ago
Accompanying article is here It really seems to be a trend these days for new accounts to submit the YouTube videos that were embedded in previously popular HN articles as new HN articles. I've seen this several times in the last week or so.
- wyldfire 7y ago
  I heard about this video directly and didn't know there was an accompanying text article. It's reasonable to assume the submitter thought the same.
  - taeric 7y ago
    Didn't change the trend. Does ask for a different call to action. No need to be upset on people submitting auxiliary videos. Would be nice to have a feature linking the video to the article. Is there already metadata to make this discoverable?
    - AmericanChopper 7y ago
      I’d suggest that the article is the auxiliary content to the video.
      - taeric 7y ago
        I actually hate consuming video. So perhaps complimentary? :)
        AmericanChopper 7y ago
        Media preferences aside, the article is essentially a watered down commentary on the video. If I came across this while I was at work, I would also prefer to consume the article. But I think the video is where the value is in this content.
- Morizero 7y ago
  I even saw this video on /r/TheMakingOfGames/ last week
MayeulC 7y ago
TL;DW: Memory constrains prevented the inclusion of enemies in the game (due to the space taken by rotoscoped images), so he got the idea of xor-ing frame pixels together to get the outline of the main character, kind of a shadow, and made that the enemy. He also squeezed a bit more memory from an "auxiliary" memory unit to animate guards. Kind of light on details, though :)
- ChrisSD 7y ago
  If you want to delve into the details then the Apple II source code is on github: https://github.com/jmechner/Prince-of-Persia-Apple-II https://github.com/jmechner/Prince-of-Persia-Apple-II Along with technical documentation: http://jordanmechner.com/downloads/popsource.pdf http://jordanmechner.com/downloads/popsource.pdf
- jmechner 7y ago
  Hi, saw this thread and wanted to jump in. It's a good question not answered in the 20-minute ArsTechnica video: since Shadowman was born out of the necessity of being squeezed for memory on the Apple II, how was I then able to add guards, skeletons, and a Vizier? To refresh my own memory (which is more than 48K, but often foggy), I checked my journal. Part of the answer is in this entry from 11/20/1988: "...Put in footsteps, and improved the chomping jaws. But the real breakthrough this week was invisible: I moved a bunch of stuff around so the main game code can use the auxiliary language card. Basically, I've just freed up an extra 12K. That gives me some breathing room I'll sorely need if I'm going to put in all this sword fighting." And a few months later, on 2/16/89: "A lot of heavy work, most of it invisible, but which will make it much easier for me to implement the enemy guards in their flowing robes and turbans." The journal doesn't give more technical detail than that (if I'd imagined anyone would be interested in this stuff 30 years later, I'd have written more!) but the code is on github, so anyone who's motivated enough should be able to reconstruct how the final code uses the auxiliary memory. In my recollection (foggy, as warned -- it's been a while), the "auxiliary language card" was an extra 16K of RAM that Apple had squeezed into the latest generation of Apple II computers, but that was difficult to use because it wasn't contiguous with the rest of RAM. I seem to recall it shared addresses already used by the main memory, so you had to flip between which part you were using. In November '88, seeing how much Shadowman and swordfighting and Shadowman improved the game motivated me to invest the time to rewrite/strategically relocate a bunch of existing code to free up 12K that I could use to implement enemies. As for the multiple enemies, I'm pretty sure that each level contained exactly one enemy, whose shape table was packaged with the level load. The floppy disk access (very quick, thanks to Roland Gustafsson's magical 18-sector routines) when the level was loaded would swap out the previous level's enemy with the new one. That's why you'll notice that the levels containing the "special enemies" (skeleton, Jaffar, and the Fat Guard) had no normal guards in the rest of the level -- they couldn't. Hope this helps. Thanks for your interest!

reaperducer 7y ago

Accompanying article is here It really seems to be a trend these days for new accounts to submit the YouTube videos that were embedded in previously popular HN articles as new HN articles. I've seen this several times in the last week or so.

wyldfire 7y ago
I heard about this video directly and didn't know there was an accompanying text article. It's reasonable to assume the submitter thought the same.
- taeric 7y ago
  Didn't change the trend. Does ask for a different call to action. No need to be upset on people submitting auxiliary videos. Would be nice to have a feature linking the video to the article. Is there already metadata to make this discoverable?
  - AmericanChopper 7y ago
    I’d suggest that the article is the auxiliary content to the video.
    - taeric 7y ago
      I actually hate consuming video. So perhaps complimentary? :)
      - AmericanChopper 7y ago
        Media preferences aside, the article is essentially a watered down commentary on the video. If I came across this while I was at work, I would also prefer to consume the article. But I think the video is where the value is in this content.
Morizero 7y ago
I even saw this video on /r/TheMakingOfGames/ last week

MayeulC 7y ago

TL;DW: Memory constrains prevented the inclusion of enemies in the game (due to the space taken by rotoscoped images), so he got the idea of xor-ing frame pixels together to get the outline of the main character, kind of a shadow, and made that the enemy. He also squeezed a bit more memory from an "auxiliary" memory unit to animate guards. Kind of light on details, though :)

ChrisSD 7y ago
If you want to delve into the details then the Apple II source code is on github: https://github.com/jmechner/Prince-of-Persia-Apple-II https://github.com/jmechner/Prince-of-Persia-Apple-II Along with technical documentation: http://jordanmechner.com/downloads/popsource.pdf http://jordanmechner.com/downloads/popsource.pdf
jmechner 7y ago
Hi, saw this thread and wanted to jump in. It's a good question not answered in the 20-minute ArsTechnica video: since Shadowman was born out of the necessity of being squeezed for memory on the Apple II, how was I then able to add guards, skeletons, and a Vizier? To refresh my own memory (which is more than 48K, but often foggy), I checked my journal. Part of the answer is in this entry from 11/20/1988: "...Put in footsteps, and improved the chomping jaws. But the real breakthrough this week was invisible: I moved a bunch of stuff around so the main game code can use the auxiliary language card. Basically, I've just freed up an extra 12K. That gives me some breathing room I'll sorely need if I'm going to put in all this sword fighting." And a few months later, on 2/16/89: "A lot of heavy work, most of it invisible, but which will make it much easier for me to implement the enemy guards in their flowing robes and turbans." The journal doesn't give more technical detail than that (if I'd imagined anyone would be interested in this stuff 30 years later, I'd have written more!) but the code is on github, so anyone who's motivated enough should be able to reconstruct how the final code uses the auxiliary memory. In my recollection (foggy, as warned -- it's been a while), the "auxiliary language card" was an extra 16K of RAM that Apple had squeezed into the latest generation of Apple II computers, but that was difficult to use because it wasn't contiguous with the rest of RAM. I seem to recall it shared addresses already used by the main memory, so you had to flip between which part you were using. In November '88, seeing how much Shadowman and swordfighting and Shadowman improved the game motivated me to invest the time to rewrite/strategically relocate a bunch of existing code to free up 12K that I could use to implement enemies. As for the multiple enemies, I'm pretty sure that each level contained exactly one enemy, whose shape table was packaged with the level load. The floppy disk access (very quick, thanks to Roland Gustafsson's magical 18-sector routines) when the level was loaded would swap out the previous level's enemy with the new one. That's why you'll notice that the levels containing the "special enemies" (skeleton, Jaffar, and the Fat Guard) had no normal guards in the rest of the level -- they couldn't. Hope this helps. Thanks for your interest!