1. Конкретно по риалтаймам надо найти 5 минут, чтобы объявить хотя бы на ГФ тему конкурса. Остальная сдача работ — через events, это в теории должно быть настроено заранее.
Если придумать тему заранее, то больше никаких рисков с соблюдением графика не остается. Можно еще, как вариант, кому-то надежному эту тему сообщить заранее, чтобы он объявил. Тогда даже 5 минут не надо искать.
2. Отлично!
3. Если разрешить, то надо написать в правилах и объявить об этом уже сейчас, иначе по традиции половина людей не узнает, а вторая половина забудет. Спросил Вассу — ей критично, чтобы в реалтаймах не было конверсий. Мне не критично, но без конверсий в реалтаймах как-то лучше.
>По рилтаймам — по всем конкурсам предлагаю как в прошлый раз начало объявить где-то вечером 9 числа, а конец утром 10-ого.
>Получится часов 12 наверное. Много/мало?
Сугубо моё имхо — в обычных реалтаймах весь кайф в жестком ограничении по времени, часа на три. Если дать 12 часов, то это совсем другой формат конкурса, за 12 часов можно при желании успеть сделать довольно серьезную работу, особенно если делать на двоих. Правда, желающих рисовать всю ночь без сна всё равно не найдется, поэтому я сам не знаю, что и сказать.
Я бы послушал в этом вопросе остальных заинтересованных лиц. Спросил Вассу — она вообще говорит, что даже час времени был бы интереснее, то есть в сторону уменьшения двигаться. Имхо, это экстремизм был бы :)
1. График. Часто бывает проблемой его соблюдать, но в этот раз предпосылок не должно быть.
2. Приглашать надо конечно заранее, ибо во время пати времени не останется. Попробуем.
3. Моё имхо — разрешить. Судьи при оценке должны сами решить что это за работа и поставить соответствующий балл.
По рилтаймам — по всем конкурсам предлагаю как в прошлый раз начало объявить где-то вечером 9 числа, а конец утром 10-ого. Получится часов 12 наверное. Много/мало?
Реалтаймы и конкурсы интересуют, постараюсь выставить что-то достойное, но надо избавиться от проблем прошлых лет:
1. Начало реалтаймов затягивать больше, чем на 30 минут, не стоит. Реалтаймы продлевать нельзя, если есть дедлайн, он должен быть для всех единым — в этом вся суть реалтаймов. Не успел — в out of compo.
2. Нужно больше участвующих, они сами себя не пригласят. В прошлый раз на реалтаймах было ровно двое участников — это был фэйл.
3. Конверсии нужно или прямо разрешить в правилах, или недрогнувшей рукой отсеивать на преселекте. Нет стэпов и есть сомнения в работе — в out of compo.
Нет, эти все ограничения ок для zx-скрина в формате PNG/etc.
Бывают следующие случаи, когда конвертор будет бессилен:
1) мультиколор
2) экран нарисован в растровом редакторе с ошибками, т.е. ошибочно в некотрых местах не выполняются ограничения
Лёш, я сейчас пишу конвертор, есть несколько вопросов.
1. Я подразумеваю, что исходное изображение дано как BMP, PNM (PPM/PGM/PBM), XPM, LBM(IFF ILBM), PCX, GIF, PNG, TGA или TIFF. Поддержать JPG легко, но это создаст проблему в пункте 3, поэтому пока что я подразумеваю, что у нас не JPG. Это то, ради чего мне хочется много DLLлек.
2. Я подразумеваю, что изображение имеет разрешение 256х192. Иначе программа матерится.
3. Я подразумеваю, что в изображении не более 15 различных цветов, иначе программа ругается матом. Т.е. писать bmp2scr я пока что не созрел. Насколько жёсткое это ограничение? Сталкивался ли ты с изображениями, как бы спектрумовскими, но нарушающими это правило?
Та выдержат, чо нет. Вон мой автодайвер так и работает в виде bat-скрипта. Выше вон лежит. А если не будет у тебя работать оно, так Speccy Viewer есть в телефоне, да BNB конвертор на васике.
Спасибо за примеры, всё пойдёт в дело. Лёша, твои эстетические чувства выдержат, если эта утилита командной строки будет требовать для своей работы 5-10 разных .dll? Или это зависит от её работоспособности, т.е. если будет хорошо работать, можно и потерпеть, но вот если не будет — тогда точно крышка? :)
Мне нравится идея треш-запила без скролла.
А что с музыкой делать? Воровать же придется. Или музыку по-любому надо написать самому? Трэш-компо от этого только выиграло бы.
Если придумать тему заранее, то больше никаких рисков с соблюдением графика не остается. Можно еще, как вариант, кому-то надежному эту тему сообщить заранее, чтобы он объявил. Тогда даже 5 минут не надо искать.
2. Отлично!
3. Если разрешить, то надо написать в правилах и объявить об этом уже сейчас, иначе по традиции половина людей не узнает, а вторая половина забудет. Спросил Вассу — ей критично, чтобы в реалтаймах не было конверсий. Мне не критично, но без конверсий в реалтаймах как-то лучше.
>По рилтаймам — по всем конкурсам предлагаю как в прошлый раз начало объявить где-то вечером 9 числа, а конец утром 10-ого.
>Получится часов 12 наверное. Много/мало?
Сугубо моё имхо — в обычных реалтаймах весь кайф в жестком ограничении по времени, часа на три. Если дать 12 часов, то это совсем другой формат конкурса, за 12 часов можно при желании успеть сделать довольно серьезную работу, особенно если делать на двоих. Правда, желающих рисовать всю ночь без сна всё равно не найдется, поэтому я сам не знаю, что и сказать.
Я бы послушал в этом вопросе остальных заинтересованных лиц. Спросил Вассу — она вообще говорит, что даже час времени был бы интереснее, то есть в сторону уменьшения двигаться. Имхо, это экстремизм был бы :)
2. Приглашать надо конечно заранее, ибо во время пати времени не останется. Попробуем.
3. Моё имхо — разрешить. Судьи при оценке должны сами решить что это за работа и поставить соответствующий балл.
По рилтаймам — по всем конкурсам предлагаю как в прошлый раз начало объявить где-то вечером 9 числа, а конец утром 10-ого. Получится часов 12 наверное. Много/мало?
1. Начало реалтаймов затягивать больше, чем на 30 минут, не стоит. Реалтаймы продлевать нельзя, если есть дедлайн, он должен быть для всех единым — в этом вся суть реалтаймов. Не успел — в out of compo.
2. Нужно больше участвующих, они сами себя не пригласят. В прошлый раз на реалтаймах было ровно двое участников — это был фэйл.
3. Конверсии нужно или прямо разрешить в правилах, или недрогнувшей рукой отсеивать на преселекте. Нет стэпов и есть сомнения в работе — в out of compo.
Навскидку, это должно помогать в лечении глюка с вертикальными полосками, но не более того.
Бывают следующие случаи, когда конвертор будет бессилен:
1) мультиколор
2) экран нарисован в растровом редакторе с ошибками, т.е. ошибочно в некотрых местах не выполняются ограничения
1. Я подразумеваю, что исходное изображение дано как BMP, PNM (PPM/PGM/PBM), XPM, LBM(IFF ILBM), PCX, GIF, PNG, TGA или TIFF. Поддержать JPG легко, но это создаст проблему в пункте 3, поэтому пока что я подразумеваю, что у нас не JPG. Это то, ради чего мне хочется много DLLлек.
2. Я подразумеваю, что изображение имеет разрешение 256х192. Иначе программа матерится.
3. Я подразумеваю, что в изображении не более 15 различных цветов, иначе программа ругается матом. Т.е. писать bmp2scr я пока что не созрел. Насколько жёсткое это ограничение? Сталкивался ли ты с изображениями, как бы спектрумовскими, но нарушающими это правило?
А что с музыкой делать? Воровать же придется. Или музыку по-любому надо написать самому? Трэш-компо от этого только выиграло бы.