Во-первых, есть русская пословица про «капля камень точит». Т.е. любого человека можно довести до точки, просто с кем-то это попроще, с кем-то посложнее. Если найти должный индивидуальный подход, сломать можно каждого.
Во-вторых, да, потребность остаётся. Но не забывай, что потребность редко бывает привязанной к конкретной медиа. Buddy, как мне кажется, пошутил про судомоделирование. Но есть художественные сайты, есть литературные сайты, очень просто на самом деле чуть скорректироваться и уйти в тусовку подружелюбнее. Творчество — вещь гибкая.
Ты можешь годами ходить на работу и ни один человек в офисе не будет знать тебя по-настоящему.
Про покупку машин и дач, и выплату ипотек вроде очевидно — личное вовлечение нулевое. Ну если только вместо покупки машин покупать откровенные удлинители членов!
Жениться не раскрываясь немного сложнее, конечно, но многие справляются и с этим.
А вот сделать хорошую в моём понимании дему «не раскрываясь» — невозможно. Творчество, любое, идёт от тебя, поэтому барьер негде ставить. Поэтому, да, парадоксально, но иногда хобби может запросто оказаться болезненнее реала.
Зависит от человека. Некоторые очень хрупкие, и если их не хвалить, они сразу вянут.
Лично мне было бы очень неприятно, если бы меня похвалили за что-то, похвалы, на мой взгляд, не заслужившее. Поэтому раньше я старался прямо говорить что думаю почти всегда. Сейчас я понимаю, что люди разные и стараюсь молчать, если не могу искренне похвалить. Вроде это помогает…
Чтобы отбить человеку желание заниматься демосценой, нужно делать вот что. Нужно всякий раз, когда этот человек что-то делает, говорить ему что он делает говно.
Как-то аргументировать не нужно, и даже вредно. Надёжнее всего придумывать каждый раз новую причину почему сделано говно. Демо на 128к критиковать за то, что не 48к, демо на 48к критиковать за то, что звук биперный. Критиковать TS за то, что сделано не из советских микросхем, критиковать пентагон, за то, что сделан без ULA, критиковать классику за то, что ULA антисоветская. Любой код — говнокод, любой дизайн — потыренный или невпечатляющий, любая музыка — наверняка одновременно зарелиженная и спёртая. Ну, в общем, тут можно много писать, но суть ясна и примеры всем известны.
Артём, я слегка изнасиловал твой скрипт, чтобы сделать заливку поплотнее и лучше увидеть оттенок.
Вышло вот что:
Как ты видишь, оттенки не очень хорошо совпадают. У тебя, я думаю, такая же ошибка как сделал в своё время я.
Допустим, мы смешиваем 50% одного цвета и 50% другого. Законы аддитивного цвета нам говорят: нужно сложить цветовые компоненты и разделить на 2. Вроде всё правильно? Мне кажется, что нет. Дело в том, что смешение цвета происходит на экране, а у экрана — гамма. Гамма монитора в среднем будет что-то типа 2.5. Значит нужно взять покомпонентно оба цвета, перевести их в мониторную гамму, там — смешать и разделить на два, а уже потом — взять обратно гамму. Типа
Нет, просто ты и я понимаем под «затеей» (я бы сказал, под «проектом») совершенно разные вещи.
Для тебя, как я это понимаю, совладать с новой железкой — уже проект. А мне это не кажется интересным достижением. Мне нужно сказать что-то за пределами чисто технического результата. И у меня сейчас нет совершенно ничего такого, что я бы не мог сказать на спектруме, но смог бы на GBC. Поэтому осваивать GBC кажется мне глубоко бессмысленной затеей.
Да не было никакой затеи. Прочёл что там не Z80, а что-то другое, похожее, залез и посмотрел что именно. Запомнил, было прикольно разобраться. Но это никакая не идея для проекта. Это просто общее образование.
Я не люблю такие решения из-за узкой аудитории. Мне интересно кодить чтобы другие могли посмотреть. Конечно, всегда можно записать youtube, как это делает тот же lft, но ты фактически гарантируешь, что это только на youtube и будут смотреть. А при таком раскладе возня с железом и т.д. становится слишком уж абстрактным упражнением на мой вкус.
Ну т.е., возвращаясь к деме Alone Coder для NGS — что, не прикольно? очень прикольно. Но я сразу прикидываю кол-во работающих железок реальное, вспоминаю какие проблемы всякий раз запустить, даже в эмуляторе, и понимаю, что упражнение слишком академическое.
Т.е. люди на TS-Conf ругаются, что не тру, а между прочим, куда демократичнее по железу выходит, нежели NGS.
Примеры интересных команд: мы привыкли, что ld a,(hl): ld (de),a: inc hl: inc de — слишком медленно, нужно либо делать ldi/ldd, либо, как минимум, пытаться экономить на инкрементах (всякие спрайты раскранченные чтобы ходить по ним inc h или inc l, рисование змейкой и т.д. и т.п.). А на GBC у нас есть ldi a,(hl) — за 8 тактов всего, с бесплатным инкрементом!!!
Или, мы привыкли что заливать стеком — эффективнее всего. push hl работает 11 тактов, т.е. заливает по 5.5 такта на байт. А на GBC push hl — это уже целых 16 тактов, считай что ldi (hl),a даёт тебе ту же скорость, что и стек.
Или, мы привыкли, что JR занимает меньше памяти, но работает чуть помедленнее чем JP (12 тактов против 10). Т.е. оптимизация по скорости — это почти всегда JP, оптимизация по памяти — почти всегда JR. А на GBC JR работает за те же 12 тактов, в то время как JP — целых 16!
Т.е. мораль такая: наши привычки с Z80 во-многом неприменимы более. Я могу себе представить заливку стеком на GBC, но моё ощущение сейчас такое, что опытный GBC кодер вряд ли будет делать это автоматически стеком, как мы привыкли у себя.
И ещё есть ощущение, что процессор у GBC более сбалансирован. Т.е. сам факт, что для пересылки команд поэффективнее всё же использовать команды для пересылки команд, или что локальные переходы пошустрее, он говорит о том, что кодирование не настолько через жопу, как у нас, где заливают стеком, ходят по экрану дикой комбинацией стека и ldi, и т.д. и т.п. Чисто на идеологическом уровне.
Я не согласен и всё потому, что мне интересно думать в терминах демокодинга.
Демокодинг на Z80 приучает к некотором стандартным общим образам мысли: «стеком быстрее», «перекладывать байты эффективнее, если задействовать ldi» — базовые эвристики выглядят примерно в этом духе. А на GBC команды чтения и записи байтов с автоинкрементом настолько эффективны, что всякие решения, обычно отметаемые на Z80 становятся снова актуальными. Нужно заново продумывать на уровне эвристик, даже базовые операции.
Игра работает на 32-битном микроконтроллере производства NXP с ядром ARM Cortex-M0 на частоте 48 МГц, 16КБ ОЗУ и 128КБ ПЗУ.
Вот поэтому и читерство. Почему процессор в GBC назван «недо-Z80» — неужели тоже объяснять нужно? Потому что может меньше чем #Z80 (хотя в плане оптимизации для него нужно так много переосмысливать, что лично я даже не вполне уверен, какой набор команд окажется более производительным).
Мультиколор позволит иметь произвольные цвета в каждом ряду 4х8. Т.е. пары соседних чанков всё равно оказываются одного цвета. Надеюсь, что это отвечает на твой вопрос, т.к. я без понятия что ты спрашивал :)
Во-вторых, да, потребность остаётся. Но не забывай, что потребность редко бывает привязанной к конкретной медиа. Buddy, как мне кажется, пошутил про судомоделирование. Но есть художественные сайты, есть литературные сайты, очень просто на самом деле чуть скорректироваться и уйти в тусовку подружелюбнее. Творчество — вещь гибкая.
Про покупку машин и дач, и выплату ипотек вроде очевидно — личное вовлечение нулевое. Ну если только вместо покупки машин покупать откровенные удлинители членов!
Жениться не раскрываясь немного сложнее, конечно, но многие справляются и с этим.
А вот сделать хорошую в моём понимании дему «не раскрываясь» — невозможно. Творчество, любое, идёт от тебя, поэтому барьер негде ставить. Поэтому, да, парадоксально, но иногда хобби может запросто оказаться болезненнее реала.
Лично мне было бы очень неприятно, если бы меня похвалили за что-то, похвалы, на мой взгляд, не заслужившее. Поэтому раньше я старался прямо говорить что думаю почти всегда. Сейчас я понимаю, что люди разные и стараюсь молчать, если не могу искренне похвалить. Вроде это помогает…
Как-то аргументировать не нужно, и даже вредно. Надёжнее всего придумывать каждый раз новую причину почему сделано говно. Демо на 128к критиковать за то, что не 48к, демо на 48к критиковать за то, что звук биперный. Критиковать TS за то, что сделано не из советских микросхем, критиковать пентагон, за то, что сделан без ULA, критиковать классику за то, что ULA антисоветская. Любой код — говнокод, любой дизайн — потыренный или невпечатляющий, любая музыка — наверняка одновременно зарелиженная и спёртая. Ну, в общем, тут можно много писать, но суть ясна и примеры всем известны.
Вышло вот что:
Как ты видишь, оттенки не очень хорошо совпадают. У тебя, я думаю, такая же ошибка как сделал в своё время я.
Допустим, мы смешиваем 50% одного цвета и 50% другого. Законы аддитивного цвета нам говорят: нужно сложить цветовые компоненты и разделить на 2. Вроде всё правильно? Мне кажется, что нет. Дело в том, что смешение цвета происходит на экране, а у экрана — гамма. Гамма монитора в среднем будет что-то типа 2.5. Значит нужно взять покомпонентно оба цвета, перевести их в мониторную гамму, там — смешать и разделить на два, а уже потом — взять обратно гамму. Типа
Rmix = (0.5*R1^2.5+0.5*R2^2.5)^(1/2.5)
Для тебя, как я это понимаю, совладать с новой железкой — уже проект. А мне это не кажется интересным достижением. Мне нужно сказать что-то за пределами чисто технического результата. И у меня сейчас нет совершенно ничего такого, что я бы не мог сказать на спектруме, но смог бы на GBC. Поэтому осваивать GBC кажется мне глубоко бессмысленной затеей.
Ну т.е., возвращаясь к деме Alone Coder для NGS — что, не прикольно? очень прикольно. Но я сразу прикидываю кол-во работающих железок реальное, вспоминаю какие проблемы всякий раз запустить, даже в эмуляторе, и понимаю, что упражнение слишком академическое.
Т.е. люди на TS-Conf ругаются, что не тру, а между прочим, куда демократичнее по железу выходит, нежели NGS.
Примеры интересных команд: мы привыкли, что ld a,(hl): ld (de),a: inc hl: inc de — слишком медленно, нужно либо делать ldi/ldd, либо, как минимум, пытаться экономить на инкрементах (всякие спрайты раскранченные чтобы ходить по ним inc h или inc l, рисование змейкой и т.д. и т.п.). А на GBC у нас есть ldi a,(hl) — за 8 тактов всего, с бесплатным инкрементом!!!
Или, мы привыкли что заливать стеком — эффективнее всего. push hl работает 11 тактов, т.е. заливает по 5.5 такта на байт. А на GBC push hl — это уже целых 16 тактов, считай что ldi (hl),a даёт тебе ту же скорость, что и стек.
Или, мы привыкли, что JR занимает меньше памяти, но работает чуть помедленнее чем JP (12 тактов против 10). Т.е. оптимизация по скорости — это почти всегда JP, оптимизация по памяти — почти всегда JR. А на GBC JR работает за те же 12 тактов, в то время как JP — целых 16!
Т.е. мораль такая: наши привычки с Z80 во-многом неприменимы более. Я могу себе представить заливку стеком на GBC, но моё ощущение сейчас такое, что опытный GBC кодер вряд ли будет делать это автоматически стеком, как мы привыкли у себя.
И ещё есть ощущение, что процессор у GBC более сбалансирован. Т.е. сам факт, что для пересылки команд поэффективнее всё же использовать команды для пересылки команд, или что локальные переходы пошустрее, он говорит о том, что кодирование не настолько через жопу, как у нас, где заливают стеком, ходят по экрану дикой комбинацией стека и ldi, и т.д. и т.п. Чисто на идеологическом уровне.
Демокодинг на Z80 приучает к некотором стандартным общим образам мысли: «стеком быстрее», «перекладывать байты эффективнее, если задействовать ldi» — базовые эвристики выглядят примерно в этом духе. А на GBC команды чтения и записи байтов с автоинкрементом настолько эффективны, что всякие решения, обычно отметаемые на Z80 становятся снова актуальными. Нужно заново продумывать на уровне эвристик, даже базовые операции.
Разумеется, багов процессора это всё не касается…