Comments 25
Спасибо за перевод отличной статьи!
столько мучений ради 157КБ вместо 140КБ?!
Не только ради этого. Во-первых, лишних 10% места позволили продавать игру не на трёх, а на двух дискетах. Во-вторых, подозреваю, что благодаря большей длине сектора считывание выполнялось быстрее, да и дискеты в дисководе приходилось менять реже. В-третьих, такой формат записи защищал игру от пиратства. По-моему, овчинка вполне стоит выделки.
«защита от пиратства» случайно же получилась, из-за сложности и закрытости формата.
конкретно этой игре повезло, ей хватило +10% к объёму что бы уместиться на двух дискетах. полагаю, что для других игр (а они были?), такой эффект случался довольно редко.
конкретно этой игре повезло, ей хватило +10% к объёму что бы уместиться на двух дискетах. полагаю, что для других игр (а они были?), такой эффект случался довольно редко.
В те времена лишние 10кб порой давали много чего интересного. Если хотите попробовать почувствовать себя, как разработчик софта в 70-80ых годах — возьмите самый мелкий микроконтроллер (tiny 13A например) и пишите код. В вариантах отличных от «помигать светодиодом» вы очень быстро прийдете к мнению «ардуино тут не катит», потом к «надо переписать эти стандартные библиотечные функции», а потом, когда вылезет ситуация «черт, мне не хватает всего 17 байт», то и к «а тут надо на ассемблере кусок написать, он меньше весить будет». Ну и в итоге научитесь тотальной оптимизации.
в данном конкретном случае никто не парился и взял третью дискету.
Представьте, что вы пишете 32-битное приложение (по независящим от вас причинам, например, у вас подгружается несовместимая с х64-либа), и вы не влезаете даже в 3ГБ, и у вас есть оптимизация, которая экономит 10%… Зато с OOM не падает. Или предложете переписать приложение (и все используемые несовместимые либы заодно) на х64?
Или более подходящий пример, пишете х64 приложение, а у клиента 4гига выедает и в своп все падает. А у него тысячи таких машинок, и "просто докупить еще одну плашку памяти" он не может. Тоже 10% ничего не дают?
Нужно понимать, когда — преждевременная оптимизация, а когда — бизнес-преимущество.
эхх, были времена ZX-Spectrum, TR-DOS, черезсекторное чтение дорожки за 2 оборота (вместо 16 в обычном режиме), OS с 9 секторами по 512 байт (нестандартный формат)…
и ассемблер, ассемблер, ассемблер…
и ассемблер, ассемблер, ассемблер…
Просто напомню, что на хабре был цикл статей, про создание редактора уровней НЕСовского Принца Персии.
Вроде 6502 всегда был 8-разрядным микропроцессором в те времена как и i8080 и z80
Интересно читать. Только сильно непонятен странный способ искать grep с помощью find.
6502 — это не 16-битный процессор, это 8 бит
Странное чувство, когда про процессор 6502 и ассемблер для него рассказывают как о чём-то очень древнем, а ты зарабатываешь на разработке под него в 2017 году.
Шикарно, получил большое удовольствие от увиденного и прочитанного, ротоскопирование движений, круто!
Sign up to leave a comment.
Анализ исходного кода и защиты от копирования Prince of Persia