Так нет альтернативы. Я же их написал не от того, что просто пришло в голову, а от того, что не мог Dreamer писать музыку на PT3, только ASM. Сколько не турбируй плеер, ничего не получится. Вот и пришлось сделать свой формат mason'а, который изначально был простым компилятором на ПиЦи, на входе были любые модули PTх или ASM, а на выходе уже мой формат. Это он уже потом перерос в редактор. потому, что появились запросы о специфической музыке и универсальности типа 2хАУ. Ну а про ассемблер я вообще молчу, тут без него у меня стопор начался ещё в 2000 году. Никогда не забуду этот «ад» со сборкой демок. Теперь один ассемблер всё собирает и выдаёт конечный пакованный файл.
Тут то же есть куча этапов. У меня очень жестокий подход к написанию проекта. Я ставлю в рамки только тогда, когда понимаю, что без определённого инструмента не обойтись, например мой Mason, от которого я беру незаменимые возможности. Но если нет ограничений, я стараюсь идти по пути максимального удобства для творчества. Например ты график, и рисуешь в фотошопе, мы договариваемся что результат твоей работы это PSD, а метод передачи графики в конечный результат это BMP. Далее только моя проблема как это попадёт в код. И вот тут начинается разветвление, например путь который я вообще не признаю, где на промежутке между тобой и мной запускается утилита, в которой нажимается какая-то кнопочка(предварительно нужно 20 бегунков накрутить), потом получается какой-то файл, который в итоге загружается мной и с ним что-то делается, как правило не удобный формат и не оптимальный результат. Мне же всегда нужен под каждый случай свой формат. Поэтому я практически никогда не пользуюсь стандартной утилитой, просто на выходе будет то, что мне не подойдёт. Например у меня палитра из 128 значений, где нужно каждый 0ой и 15ый цвет оставить свободным, так устроена графика на гранях куба в SYNCHRе. Где эта утилита которая мне такое сделает? Её просто нет. Поэтому путь только писать свою, и эту утилита будет брать твой файл BMP, и запускаться каждый раз при компиляции демки, где нет участия человека, только жёсткий автомат с идеальным результатом для данного эффекта.
1. График нарисовал в удобном редакторе, или поправил один секретный пиксель.
2. Музыкант написал музыку не задаваясь вопросом сколько это будет занимать.
3. Клацнул на ентер.
4. Смотришь уже конечный запакованный результат, готовый к отправке, с лоадером, пакером, шмакером, кодером и другими супер-пупер вещами.
Главное нет вот этого промежуточного вызова утилиты и настроек. Так, что утилиты то же бывают разные.
Ооо… Досбокс вообще не рассматривается как что-то для ловли багов. Вот тут собственно и проблема. Если писать под дос, то нужно выбирать между массой, которые будут смотреть результат на реале и теми, кто будет всё это пускать под эмулятором. Я бы сказал так, что если ориентироваться под эмулем, то это путь серьёзных ограничений. Из моей практики на пентиуме с частотой 466mHz, делается практически всё фреймово.
А разве можно как-то по-другому написать демо?
Альтернатива только запилятор. Если не запилятор, то все вот эти бесконечные конверторы и генераторы данных.
Лёша, да, я знаю, что ты такой же. Твой подход я увидел сразу при первом знакомстве. Просто очень приятно встречать людей, которые готовы отдать кучу времени, что бы написать десяток конвертеров ради того, что бы результат был на пять с плюсом.
Robus , спокойствие, только спокойствие! Не перевелись ещё психи на земле русской!
У меня больше половины времени — это именно такие дела, бесконечные конверторы, генераторы графики, генераторы кода, компрессоры самопальные, и т.д. и т.п.
Писать под себя всякие тулзы приходится по одной простой причине — часто готовые проги не удовлетворяют запросам, да и возможностей для данной конкретной задачи не хватает. Например, в случае с ldi нельзя было просто посчитать все на месте (вообще-то можно, но… немного медленно :), поэтому пришлось писать различные генерилки текстур\табличек, батники для пакетной сборки, зато и самому интересно, и результат радует.
Да и blash писалась по принципу «делаем прод и по пути делаем побочный стафф, который потом обязательно пригодится» :)
Артём, я ведь правильно понимаю, всё это 2015 год, не 2000 а современность? Любо-дорого посмотреть на всё это. Я думал, что один такой вот остался, и пишу на всё какие-то конвертеры, компиляторы, кранчеры, линкеры, вожусь с ХМками. Я уже на столько привык к критике, -«что вон все на виндовсе10 сидят, а ты всё под старьё пишешь», в итоге просто перестал рассказывать кому либо про путь, по которому шёл, что бы получить конечный результат.
Согласен со всем. 2 или 3 часа — не сильно критичная разница, оба формата имеют плюсы и минусы.
Правда, на 53с можно и побольше времени дать чисто из соображений удобства, там никто 12 часов подряд рисовать не будет.
— суть рилтаймовости — что работа выполняется во время конкурса.
— для того чтобы она выполнялась во время конкурса — надо задавать узкую тему и объявлять её перед началом рилтайма.
— длительность рилтайма ни откуда не следует, он может быть хоть 1 минуту, хоть сутки.
— короткий рилтайм (30-60 минут) не дает возможности собраться с мыслями большинству участников, при 5-6 работах будем иметь например 1 хорошую.
— длинный рилтайм (3 часа и более) увеличивает количество работ, но становится более скучным для тех, кто быстро рисует.
— 12-часовой рилтайм — для некоторых это практически эквивалент времени на рисование копии обычного фуллскрина. работы можно получить очень хорошие, но и довольно тяжело в таком режиме рисовать 12 часов подряд.
Я бы рекомендовал 2 часа на рилтайм. За это время те, кто долго думает сумеют что-то придумать. А те, кто быстро рисуют успеют навести необходимый лоск, но не успеют заскучать. Некий компромисс между совсем уж черновыми скетчами и серьезными работами.
1. График нарисовал в удобном редакторе, или поправил один секретный пиксель.
2. Музыкант написал музыку не задаваясь вопросом сколько это будет занимать.
3. Клацнул на ентер.
4. Смотришь уже конечный запакованный результат, готовый к отправке, с лоадером, пакером, шмакером, кодером и другими супер-пупер вещами.
Главное нет вот этого промежуточного вызова утилиты и настроек. Так, что утилиты то же бывают разные.
Альтернатива только запилятор. Если не запилятор, то все вот эти бесконечные конверторы и генераторы данных.
Супер!
У меня больше половины времени — это именно такие дела, бесконечные конверторы, генераторы графики, генераторы кода, компрессоры самопальные, и т.д. и т.п.
Да и blash писалась по принципу «делаем прод и по пути делаем побочный стафф, который потом обязательно пригодится» :)
Правда, на 53с можно и побольше времени дать чисто из соображений удобства, там никто 12 часов подряд рисовать не будет.
— для того чтобы она выполнялась во время конкурса — надо задавать узкую тему и объявлять её перед началом рилтайма.
— длительность рилтайма ни откуда не следует, он может быть хоть 1 минуту, хоть сутки.
— короткий рилтайм (30-60 минут) не дает возможности собраться с мыслями большинству участников, при 5-6 работах будем иметь например 1 хорошую.
— длинный рилтайм (3 часа и более) увеличивает количество работ, но становится более скучным для тех, кто быстро рисует.
— 12-часовой рилтайм — для некоторых это практически эквивалент времени на рисование копии обычного фуллскрина. работы можно получить очень хорошие, но и довольно тяжело в таком режиме рисовать 12 часов подряд.
Я бы рекомендовал 2 часа на рилтайм. За это время те, кто долго думает сумеют что-то придумать. А те, кто быстро рисуют успеют навести необходимый лоск, но не успеют заскучать. Некий компромисс между совсем уж черновыми скетчами и серьезными работами.