Rainbow + Pascal

+202
в блоге Блог им. nick_ys
Продолжаю заниматься бесполезным делом рисовать пони в Паскале.

В этот раз это Рейнбоу Дэш, пока я ее рисовал, я понял что не люблю расправленные крылья =)
Что интересно, оригинал с DA я не нашел когда закончил…

Собственно, оригинал:

и Pascal


Исходный код

program Rainbowdash;
uses graph,crt;
var gd,gm:integer;
begin
gd:=0;
gm:=0;
initgraph (gd,gm,' ');
{znak}
setcolor (1);
line (330,249,335,231);
setcolor (14);
line (337,232,332,246);
setcolor (4);
line (330,249,340,232);
line (340,232,342,237);
line (342,237,344,235);
{xvost}
setcolor (11);
ellipse (275,205,95,175,80,60);
ellipse (226,203,95,175,30,30);
ellipse (228,310,99,170,25,140);
ellipse (178,273,279,350,25,70);
ellipse (178,273,279,330,39,70);
ellipse (143,291,279,350,70,100);
ellipse (155,291,260,310,75,100);
ellipse (190,200,270,300,30,190);
ellipse (189,290,275,340,60,100);
ellipse (218,340,300,20,30,50);
ellipse (220,280,285,352,55,107);
ellipse (280,289,190,280,5,25);
ellipse (310,340,99,170,30,150);
setcolor (4);
ellipse (295,338,99,160,32,150);
ellipse (236,243,285,340,30,130);
setcolor (12);
ellipse (280,338,95,160,32,150);
ellipse (221,243,320,340,30,130);
setcolor (14);
ellipse (267,337,97,160,32,160);
ellipse (209,233,285,340,30,150);
setcolor (2);
ellipse (290,215,90,170,53,60);
ellipse (199,220,284,340,32,150);
line (229,272,237,205);
setcolor (5);
ellipse (280,215,95,170,55,66);
ellipse (206,146,284,340,20,170);
{griva niz}
setcolor (11);
ellipse (425,193,270,0,10,50);
line (426,215,425,243);
ellipse (386,209,280,350,40,50);
ellipse (389,209,280,350,13,50);
ellipse (432,220,100,180,30,45);
setcolor (5);
ellipse (399,205,280,330,12,50);
ellipse (420,255,100,150,12,50);
{zadnie nogi}
setcolor (11);
ellipse (410,360,130,200,60,89);
ellipse (421,392,128,179,109,151);
ellipse (334,389,180,340,21,5);

ellipse (429,400,128,180,120,160);
ellipse (289,400,180,340,22,5);
ellipse (388,400,141,180,120,160);
ellipse (328,291,110,184,20,73);
ellipse (303,332,79,115,22,35);
{perednie nogi}
setcolor (11);
ellipse (500,291,170,260,30,115);
ellipse (460,325,160,250,20,85);
ellipse (474,402,180,340,22,5);

ellipse (439,381,110,205,30,100);
ellipse (428,410,120,185,60,140);
ellipse (390,421,180,340,22,5);
{levoe krilo}
setcolor (11);
ellipse (404,137,200,250,45,75);
ellipse (308,323,45,95,75,230);
ellipse (301,110,100,180,3,15);
ellipse (340,38,225,252,60,100);
line (322,133,330,150);
ellipse (238,244,45,81,130,130);
ellipse (255,132,80,160,5,15);
ellipse (343,36,225,252,130,130);
line (303,160,316,170);
ellipse (291,199,70,110,70,31);
ellipse (313,179,160,200,50,25);
ellipse (268,249,60,90,125,60);
ellipse (377,214,139,270,60,24);

ellipse (375,224,115,250,30,15);
line (360,210,332,190);
ellipse (333,179,150,260,10,10);
ellipse (333,179,90,160,10,9);
line (334,170,358,187);
ellipse (369,126,200,250,30,65);
ellipse (338,213,50,85,36,65);
{pravoe krilo}
setcolor (11);
ellipse (589,209,80,130,91,70);
ellipse (598,148,300,50,11,10);
ellipse (602,267,90,115,109,110);
ellipse (555,185,40,90,85,17);
ellipse (614,182,300,50,11,10);
ellipse (605,201,81,135,80,10);
ellipse (540,244,20,80,51,50);
ellipse (574,223,290,350,15,15);
ellipse (526,270,42,90,70,50);
ellipse (523,239,350,70,9,20);
ellipse (513,229,220,310,30,20);
ellipse (494,225,260,30,15,15);
ellipse (510,200,263,70,30,15);
ellipse (510,170,285,60,40,15);
{telo}
setcolor (11);
line (511,207,470,270);
ellipse (392,235,290,330,90,70);
ellipse (395,256,175,265,45,40);
ellipse (385,220,45,100,25,25);
{lico}
setcolor (11);
line (410,100,413,90);
ellipse (421,151,175,295,16,19);
line (427,169,432,164);
ellipse (423,174,280,45,13,13);
setcolor (12);
ellipse (423,174,280,28,4,13);
setcolor (11);
ellipse (457,166,230,300,52,29);
ellipse (450,135,320,360,80,110);
ellipse (420,153,240,300,6,9);
setcolor (12);
ellipse (432,183,80,220,3,3);
{yxo}
setcolor (11);
ellipse (545,115,100,150,40,70);
ellipse (518,86,295,50,30,53);
ellipse (515,84,310,13,23,33);
{griva verx}
setcolor (11);
ellipse (496,120,75,150,67,48);
ellipse (482,124,120,150,50,60);
ellipse (385,10,264,305,120,80);
ellipse (367,10,280,330,69,80);
ellipse (419,70,80,160,30,20);
ellipse (442,80,80,160,55,50);
ellipse (416,70,50,100,55,50);
ellipse (443,74,15,120,80,60);
setcolor (12);
ellipse (499,100,73,152,60,50);
setcolor (4);
ellipse (499,102,75,150,60,50);
setcolor (12);
ellipse (483,188,81,112,165,150);
setcolor (14);
ellipse (483,186,82,114,165,150);
{glaza}
setcolor (11);
ellipse (470,130,150,20,30,40);
ellipse (415,124,311,28,15,30);
ellipse (419,125,135,240,15,30);
ellipse (415,147,200,340,10,5);
setlinestyle (0,0,1);
setcolor (7);
ellipse (471,130,20,150,30,40);
line (500,119,513,119);
line (497,108,510,102);
line (488,99,500,89);
ellipse (417,124,28,124,14,27);
ellipse (419,124,134,135,15,30);
{zrachki}
setlinestyle (0,0,1);
setcolor (13);
setfillstyle (1,13);
fillellipse (460,130,15,21);
fillellipse (420,125,8,16);
setcolor (6);
setfillstyle (1,6);
fillellipse (456,130,10,15);
fillellipse (423,124,5,12);
setfillstyle (1,15);
setcolor (15);
fillellipse (459,133,3,3);
fillellipse (464,122,5,6);
fillellipse (422,129,1,2);
fillellipse (423,119,3,4);
while not keypressed do;
end.

Думаю Паскаль стал на 20% круче
Кроме «рисования» я решил попробовать себя в написаний рассказа (фанфика?).
В связи с этим возник вопрос, если выкладывать сюда, то обязятельно ли его понифицировать? Рассказ почти никак не связан с основной линией сериала.

Бонус


DA

DA

DA

DA


З.Ы. Предлагайте кого запихнуть в Паскаль следушим.Если среди бонусов обнаружены бояны (а они там точно есть), это происки Дискорда.

88 комментариев

мда, и долго ты в паскале работал?
darkeng
0
В целом часов 12+ в течении недели.
nick_ys ↑
0
Ты бы ещё в автокаде нарисовал, лол.
А так годно.

UPD: хоть я и не особо знаю паскаль, но, взглянув на исходный код, я сразу понял, что структурный подход ты не используешь. Блоки кода, рисующие отдельные части, лучше не просто обозначить комментариями, а вынести в процедуры.
lol_u_phail
+6
Ты бы ещё в автокаде нарисовал, лол.

Zayka ↑
0
А я собирался нарисовать в автокаде, там самые лучшие вектора.
darkfrei ↑
0
Автокад я к сожалению (или к счастью) не изучал… Так что рисую пока так, как удобно.
nick_ys ↑
0

Имхо

Для данной программы нет абсолютно никакого смысла выносить отдельные блоки в процедуры. По сути — вся эта программа является отдельной и законченной. Автору врят-ли понадобится взять отдельно процедуру для рисования головы. Ибо другой рисунок — уже другая голова. Незачем плодить процедуры без реальной на то необходимости.
Структурный подход, конечно, необходим, но лишь тогда, когда в нем существует реальная необходимость. Тоже касается и ООП. В программе на 10-15 строк использование ООП — это излишество, забирающее столь бесценное время.
Abaduaber ↑
+2
Разбиение на части — очень хорошая традиция, особенно если автор собирается не только поней в с помощью ЯП общего назначения, но и полезные программы для танков, пароходов и мейнфреймов.
lol_u_phail ↑
0
Я не хочу устраивать очередной глупый холивар, однако позволю себе парочку замечений.
но и полезные программы для танков, пароходов и мейнфреймов.

Тут вы правы. Создание любой серьезной программы требует такого-же серьезного подхода. Не используя ООП, или, хотя-бы, процедурный подход, программирование превратится в сущий ад.
Но, я надеюсь, вы согласны, что создавать 100500 процедур, чтобы вывести «Hello World!» — это пустая трата времени? ;)
Abaduaber ↑
+1
Сравнение с «Hello world!» некорректно. Всё-таки тут код намного сложнее.
lol_u_phail ↑
+1
Код сложнее, но все-равно линейный. Ни условий, ни циклов (задержка в конце не в счет), ни ввода, ничего.
Это один сплошной последовательный блок. Добавленные процедуры едва-ли облегчат чтение, но перегрузят код лишними определениями и идентификаторами begin-end.
Abaduaber ↑
+1
Нет, не так. Отдельные части можно скомпилировать в объектные файлы, а уже потом линковать. При разработке это намного удобнее, т. к. не нужно тратить время на перекомплицию готовых частей.
lol_u_phail ↑
0
При разработке это намного удобнее, т. к. не нужно тратить время на перекомплицию готовых частей.

Я уже упомянул, что если речь идет о большом серьезном проекте, то это действительно так, и тут я с вами полностью согласен :P
Но сейчас речь идет о линейном проекте на 70-80 строк. Что вы собрались в нем компилировать отдельно? Создать объектный файл с процедурой, рисующей голову, объектный файл с процедурой, рисующей ноги, а потом линковать все это вместе? Это пустая трата времени для такой небольшой программы.

Также:

В паскале процедуры не компилируются отдельно. По отдельности компилируется сразу весь модуль. Выходит, эту программу нужно было разбить не только на процедуры, но и вообще, сразу на несколько файлов? =)
Abaduaber ↑
0
Так и написание такой программы можно назвать пустой тратой времени. Ведь в ней не используются какие-либо хитрозакрученные приёмы, а просто набор последовательных функций. Так что про ненужность тут ещё стоит подумать.

Re: Также

Разбиение на несколько файлов — традиционная практика промышленного программирования. Модули легче править, компилировать, некоторые можно переписать, в том числе и на других языках, где эти модули будет легче поддерживать.
lol_u_phail ↑
-1
Да, я тоже разбиваю программы на несколько файлов. Но только тогда, когда есть, что разбивать. Такую-бы не разбивал, ибо не вижу смысла. Маленькая она. Мне лень создавать лишний файл, или писать заголовок процедуры, если без нее можно обойтись, и я буду четко понимать, что потом не будет баттхерта =) Оттого и начал спорить.
Так и написание такой программы можно назвать пустой тратой времени

Автор и не отрицает, что это не совсем продуктивное времяпрепровождение. Вместе с тем, это все-равно мило, и нравится мне. Хитрозакрученных приемов, конечно, тут нет, но зато есть наглядная демонстрация усидчивости и стараний автора =)
Я полагаю, нам следует закончить обсуждение. Ибо это даже не похоже на спор — мы с друг-другом, вроде-бы, вполне согласны, я лишь только хотел попробовать донести, что в некоторых случаях ООП и процедуры могут быть излишними. Но, сколько людей, столько и мнений, и каждый по своему прав, поэтому, думаю, нет смысла дискутировать дальше. Просто программируем, так как любим, и так, как получается, а остальное неважно =)
Abaduaber ↑
+2
А ну ок. Просто кодеров не так часто встретишь.

__

Так ты же у меня вконтактике есть.
lol_u_phail ↑
-1
Вы чего тут устроили? Функции лишние стали?
Даже в такой маленькой программе рисования нужно использовать функции для отображения отдельных частей тела. Иначе, через два месяца, если ты вдруг захочешь чуть подредактировать рисунок, в цифрах и вызовах функцию рисования ты не поймешь НИЧЕГО. В коде остались каменты, но это не самая подходящая вещь. Вместо того, чтобы зайти в main() и потом перейти в редакторе к определению функции, ты будешь скроллить по коду, пытаясь понять, где у тебя начинается рисование отдельного уха или головы.
Сейчас мне кто-нибудь скажет, что можно поиском по тексту это выполнить, но я уверяю, ты не вспомнишь точного написания комментария. Для поиска по каментам есть стандартные макросы типа TODO/FIXME/XXX/WTF и прочее. Если у тебя нет списка формализованных отметок, стиля составления комментария и его принятого формата, греп по коду может сильно затянуться.

На счет использования функций. Функции надо использоваться всегда, если у тебя повторяется кусок из более чем одной строки более чем один раз.
Liksys ↑
0
Ответ:
Хорошо, друга, в целом, вы убедили меня. Но в частности:
Функции надо использоваться всегда, если у тебя повторяется кусок из более чем одной строки более чем один раз.

Ну не совсем всегда :P Не следует перегибать палку. Например, мне нужно (не спрашивайте, зачем) запилить процедуру для программной отрисовки спрайта. И у меня есть процедура для отрисовки отдельной точки, пусть будет PSet. Но я не буду пользоваться этой процедурой. Нет. Вместо этого, я вынесу ее код в цикл отрисовки спрайта, и не буду тратить лишнего времени на вызов процедуры и передачу параметров. Выигрыш в скорости будет особенно чувствительным, если процедура PSet и внешний цикл отрисовки состоит лишь из нескольких строк. Вы и сами это понимаете.
Если говорить про ассемблер, то там подобные оптимизации еще более актуальны — вспомните хотя-бы разворот циклов, когда вместо постоянных джампов назад, тело цикла дублируется несколько раз, благодаря чему для некоторых циклов можно получить заметное ускорение. Но это частный случай, конечно.
И да, если мне нужна скорость, я с радостью пожертвую читаемостью (а активные и четкие комментарии смогут помочь быстро восстановить смысл, через время), для того, чтобы получить ее. По профессии я не программист, поэтому, вполне могу позволить себе такое. Ведь жалеть не буду. И еще никогда не жалел.
Получается, что функции нужно использовать всегда, но, как-бы, и не совсем всегда.
Я не знаю, зачем написал вам такой ответ. Наверное, чтобы вновь поспорить :P

Abaduaber ↑
0
Чушь по большей части. Дойду домой — напишу, почему.
Liksys ↑
0
Эм… А может не стоит делать за компилятор его работу?
Разворот циклов и инлайнинг функций сейчас, по-моему, уже все научились делать.
eeyupbrony ↑
0
Так вот, почему, собственно, чушь.
Это рассказ про сферические оптимизации в вакууме, которые, в своей сути, почти никогда не несут пользы. Если ты не пишешь прошивку под контроллер и не делаешь обработчик прерываний SATA-контроллера, то такие оптимизации попросту не нужны.
Перед оптимизацией неплохо бы понять, где у программы случается затык. Разворачивать частые вызовы функций — самое тупое решение, которое можно придумать.

Задачи по своему типу делятся на CPU и IO-зависимые. Причем, эти два класса практически никогда не пересекаются, но могут изменять свой тип по ходу выполнения. Например, кодирование видео — это CPU-зависимый процесс (тут я обобщаю всякие CUDA и прочие числодробилки, не важно), в нем присутствует дисковый ввод-вывод, но только для получения и сохранения данных, основные операции приходятся на процессор, который выполняет сложные математические операции. С другой стороны, сведение дорожек в контейнер AVI или MKV — это дисковая операция, поскольку процессор выполняет только системные вызовы read() и write() в промежуточный программный буфер.
Компьютерная игра является примером перетекающей задачи. При подгрузке 3D-карты в память она является IO-зависимой, но как только ты начинаешь играть — она превращается в CPU-зависимую, ибо рендеринг — процесс матаноемкий.

В компилируемых языках программирования, вызовы функций почти ничего не стоят, особенно на процессорах частотой больше килогерца :-) Оптимизацию такого рода следует производить только на CPU-зависимых задачах (и то, далеко-далеко не на всех), потому что в IO-зависимых задачах большую часть времени программа будет проводить в слипе, ожидая прерывания от устройства.
Я уже не говорю о том, что современные компиляторы сами разворачивают не только функции, но и циклы. Пример тому — GCC, G++, Intel C Compiler и прочие. В C99 и C++ нативно присутствуют inline-функции, а в чистом, классическом K&R C есть макросы.

Вернемся к вопросу жертвы читаемости. Поддержка программного кода и его разработка стоит сильно дороже, чем вычислительные ресурсы. Если твоя программа разово рисует картинку за полсекунды, то со сокращать это до 0.45 не имеет смысла. Кроме того, при разработке требований к софту и его архитектуры, нужно руководствоваться исключительно количественными требованиями во всем. Например, «операция обращения к ресурсу X должна быть произведена за 0.12 секунды максимум». И так во всем, в том числе с графическим интерфейсами. В ином случае, пытаться урвать лишний такт бессмысленно, если ты укладываешься в требования. Не нужно делать софт идеальным, нужно говорить себе: «это сделано достаточно хорошо, переходим к другой фиче».
Liksys ↑
+2
Друга, очень четко объяснили, спасибо. Интересно было почитать. Но, в общем-то, ничего нового для себя не открыл. Это очевидно.
Разумеется, я понимаю, что в случае программы, которая рисует только одно изображение, нет никакой необходимости делать подобную оптимизацию. Она нужна ровно там, где она нужна. Я, например, во время программирования под старые платформы (что есть мое хобби) вынужден пользоваться даже такими путями оптимизации. Когда мне нужно, чтобы процессор с тактовой частотой 25MHz, выдавал не менее нужного мне количества FPS в отрисовке нужной мне стандартной сцены, даже такая оптимизация (частичный отказ от дробления кода на куски, дублирование, где нужно), произведенная в критичном месте, спасает ситуацию. Я не говорю о приросте скорости в 2-3 раза, но на 20-30% вполне. И, да, разумеется, перед этим, я делаю все, что в моих силах, все, что приходит на ум, для оптимизации программы на высшем и самом эффективном (выбор оптимальных алгоритмов) уровне.

Я написал эти строки, а потом, ВНЕЗАПНО, прочитал следующий комментарий:
Эм… А может не стоит делать за компилятор его работу?

Лол. Я настолько зациклился на старых средах разработки, что совершенно забил на тот факт, что современные компиляторы при необходимости, проводят такие оптимизации сами =). Зато теперь я знаю, чем буду заниматься после того, как закончу текущий проект.

Я надеюсь, вы не думаете, что я спорю как упертый баран, только ради спора, и нежелания признавать свою неправоту. Нет. Дискутирующие со мной, lol_u_phail, а затем и вы, сказали очень разумные и правильные вещи, с которыми я не спорю. Однако, продолжая дискуссию, я уже вынужден защищать свой опыт, который был получен со временем и за практикой. Неужто опыт кривой? Не хочу в этом верить.
А вообще рад, что тут нашлись реально понимающие в этой теме ребята. С вами интересно вести беседу по этому вопросу.
Abaduaber ↑
+1
Я, например, во время программирования под старые платформы (что есть мое хобби) вынужден пользоваться даже такими путями оптимизации. Когда мне нужно, чтобы процессор с тактовой частотой 25MHz, выдавал не менее нужного мне количества FPS в отрисовке нужной мне стандартной сцены, даже такая оптимизация (частичный отказ от дробления кода на куски, дублирование, где нужно), произведенная в критичном месте, спасает ситуацию.

Приемлемо, согласен. Смотря по ситуации и по требованиям. Но, если это был не асм, то сишным макросам уже лет 30 и стоило их использовать для читаемости ;-) Опять же, упростит модификацию и поддержку в дальшейшем. Ся без препроцессора — большая редкость. Думаю, ты в курсе, как он работает. Это просто копипаст кода в нужные места. То же самое, что и разворот функций, только автоматически.

PS: обратил внимание, что с момента, когда я пост написал, меня раз пять минусанули и плюсанули :-)
Liksys ↑
+1
меня раз пять минусанули и плюсанули :-)

Держите шестой. Это будет плюс :P
Я всегда понимал, что пропуская C, я поступаю не совсем разумно. Да, изучая C на первом курсе универа, еще до того, как вылетел из него, у меня не было проблем. Знания ассемблера, и базовые представления о том, как компиляторы генерируют код, и как это вертится на нижнем уровне, спасают ситуацию, и дают возможность учить почти любой язык. Однако, с сями у меня так и не сложилось. Не знаю, что стало причиной. Я знаю его на базовом уровне, и иногда решаю на нем простенькие задачки студентам первых курсов, но в своих разработках никогда не использую, и отчего-то, не желаю изучать глубже.
Мне намного ближе паскаль. Да, в общем случае, код, генерируемый компиляторами паскаля проигрывает сишному. Я компенсирую это, запиливая все самые критичные к скорости процедуры на ассемблере. Вроде, получается неплохо. Там, где нужна скорость, работает ассемблер, в остальных местах, где она не критична, все написано на паскале. Вот, как-то так и живу)
Abaduaber ↑
+1
Позволю себе опять встрять :)
Тут не пять раз плюсанули или минусанули, тут просто глюки какие-то с сайтом: даже свеженаписанные комменты пропадают и появляются в течение пары-тройки минут.
eeyupbrony ↑
+1
Liksys прав. Заканчивайте это :)
Jedi_Knight ↑
+1
с помощью ЯП общего назначения рисовать, но и писать полезные программы

fxd
lol_u_phail ↑
0
Я положу и этот код в свою копилочку. У вас получается бесподобно, спасибо =)
Abaduaber
0
Мда уж, жесть, и почему людям порой так нравится себя истязать?

Кул.
AzureVortex
+2
Почему истязать то?=) Меня просто радует когда я вижу конечный результат!
nick_ys ↑
+2
WHAT? WHAT!? WHAT!
О ВЕЛИКАЯ ЛАПША! ЭТО БОЖЕСТВЕННО! РАМИНЬ!
BlindEyeColonel
0
Паскаль
Liksys
+3
Нас вообще бэйсик учить заставляют.Мозг изучающий си и привыкший к ооп(яве), яростно протестует.
Solexid ↑
+1
У меня в школе был только бейсик, тоже что-то рисовал.

А теперь Си — ванлав, даже несмотря на недостатки.
lol_u_phail ↑
0
бэйсик учить заставляют

заставляют

Убей их всех
Liksys ↑
+1
Если не знаешь ничего — учи бейсик, мозг упорядочишь. Потом и нормальные языки учить можно будет.
darkfrei ↑
0
Вспомнил как на нём 2 года занимался. Даже 2 игрушки сделал. Вобще Весело графикой на нём заниматся было, но теперь для этого дела Компас.
JoshuaGraham
0
А у вас где-нибудь остались эти игры? Очень интересно посмотреть на ваши результаты. Я сам предпочитаю не новые и эффективные средства разработки, а именно старый Turbo Pascal + встроенный ассемблер. Олдфажеская душа находится в гармонии во время кодинга в этой революционной для своего времени среде разработки =)
Abaduaber ↑
0
Да остались, на дискетках где то. Мне вод интересно то что было на Турбопаскале старом, запустица на новых версиях?
JoshuaGraham ↑
0
Последняя версия Turbo Pascal вышла еще в 1993 году. Далее Borland окончательно перешла на Object Pascal и в частности на его реализацию в Delphi. Программа, написанная для Turbo Pascal, не скомпилируется на Delphi или Pascal ABC без серьезных (подчас критичных) переработок. Хотя, многое тут зависит еще и от объема программы, а также функций DOS, которы е она использует
Если Turbo Pascal работает некорректно под новым железом, его можно всегда запустить через DosBox (http://dosbox.com) и уже через эмулятор DosBox все нормально побежит.
Abaduaber ↑
0
На pascalABC нет, там часть операторов переименовали и граф модуль инициализируется по другому, дальше я него не углублялся
Rainbow_dragon ↑
+1
DosBox тебе в помощь :)
Jedi_Knight ↑
+1
Omgosh, не-на-ви-жу Паскаль и Делфи
По моему у меня даже сохранился многооконный мультизадачный векторный граф редактор, который писали на нем;)

Афтор жжешь, давай анимацию Hardcore!!!
Rainbow_dragon
+2
Анимацию? Нет я конечно подумаю… Но пока даже представлять не хочу =)
Кстати по моему вопросу никто не отписался, ни по одному… Жаль очень хочется узнать =)
nick_ys ↑
0
Кстати по моему вопросу никто не отписался, ни по одному

Ах-да. Точно.
По поводу того, что рисовать — у меня особенных фаворитов нет. Увидеть на паскале буду рад любую поняшку. Хотя… Умм. Попробуйте Октавию =)
Что касается вашего рассказа: по идее, на Табун стоит выкладывать все-же что-то имеющее отношение к поняшам. Но смотрите: если у вас рассказ почти готов, и вы хотите им поделиться, то, я думаю, уже не стоит перелопачивать все заново, запихивая пони то там, то тут. Красиво врят-ли выйдет, разумнее будет написать новый рассказ. Можете попробовать выложить вместе с рассказом и несколько картинок, посвященных поняшам — так рассказ, не посвященный вселенной MLP могут принять более позитивно (правда, есть вероятность, что за картинками проигнорируют сам рассказ).
Abaduaber
0
Рассказ еще не закончен, мне просто нужно постороннее мнение (и возможно вычитка).
Рассказ имеет отсылки к MLP но лучше всего они будут заметны в понифицированной версий.
Скажем так герои сериала «реинкарнировались» (ну и слово) в другом времени, ролях и обстоятельствах.
nick_ys ↑
0
В программировании я ноль. Дэш выглядит вроде нормально, но из-за адового изображения, лучше не видеть ее такой во сне:).

Плюс за извращение :)
Keep
+1
Вообще тема!
Кто хочет заняться: надо скачать pascalABC.net, заменить uses graph на uses graphabc, убрать initgraph, будет то же самое но в windows-окошке.
Ещё можно сконвертировать в SVG, или вызовы CANVAS в HTML5, сейчас займусь этим…
Jedi_Knight ↑
+1
Поддерживаю идею с конвертацией в SVG.
lol_u_phail ↑
0
Уже делаю в Canvas :)
Jedi_Knight ↑
0
Вы для меня — лунные пони
Keep ↑
0
А ты для меня человек, который не умеет гуглить.
lol_u_phail ↑
0
не пытается. Смысла нет.
Keep ↑
0
Вот так вот люди и пользуются устаревшим. Смысла-то нет что-то менять!
lol_u_phail ↑
0
Кроме «рисования» я решил попробовать себя в написаний рассказа (фанфика?).

Чтобы не нарушать традицию, фанфик надо писать на брейнфаке.
Sid
+1
nick_ys ↑
0
Да. Я могу помочь вам в этом. Давайте попробуем?
С вас фанфик, с меня готовая программа на брейнфаке, которая будет выводить фанфик :P
Abaduaber ↑
0
Ну сначала нужно посмотреть насколько он будет достоин этого =)
nick_ys ↑
0
Ничего не нужно смотреть, отправьте мне фанфик, и мы продолжим ваши славные традиции. Опубликуете фанфик, и программу на брейнфаке вместе — в лучших традициях будет =)
Abaduaber ↑
0
после этого даже ассемблер кажется простым и дружелюбным
Dozorniy ↑
0
Только HQ9++ и Piet, только хардкор!
Neon ↑
0
бОНУС С ТвайлаДэш)
а так
cool2050
0
ТОЛЬКО ASCII-АРТ ТОЛЬКО ХАРДКОР!!!
Le_Raux
+1
Только и только так =)
Abaduaber ↑
+6
HTML5 Rainbow Dash


Исходник js-файла


//Rainbow Dash pascal graphics, © nick_ys , http://tabun.everypony.ru/blog/17441.html , 10.04.2012
function drawDash()
{

setcolor (1);
line (330,249,335,231);
setcolor (14);
line (337,232,332,246);
setcolor (4);
line (330,249,340,232);
line (340,232,342,237);
line (342,237,344,235);
//{xvost}
setcolor (11);
ellipse (275,205,95,175,80,60);
ellipse (226,203,95,175,30,30);
ellipse (228,310,99,170,25,140);
ellipse (178,273,279,350,25,70);
ellipse (178,273,279,330,39,70);
ellipse (143,291,279,350,70,100);
ellipse (155,291,260,310,75,100);
ellipse (190,200,270,300,30,190);
ellipse (189,290,275,340,60,100);
ellipse (218,340,300,20,30,50);
ellipse (220,280,285,352,55,107);
ellipse (280,289,190,280,5,25);
ellipse (310,340,99,170,30,150);
setcolor (4);
ellipse (295,338,99,160,32,150);
ellipse (236,243,285,340,30,130);
setcolor (12);
ellipse (280,338,95,160,32,150);
ellipse (221,243,320,340,30,130);
setcolor (14);
ellipse (267,337,97,160,32,160);
ellipse (209,233,285,340,30,150);
setcolor (2);
ellipse (290,215,90,170,53,60);
ellipse (199,220,284,340,32,150);
line (229,272,237,205);
setcolor (5);
ellipse (280,215,95,170,55,66);
ellipse (206,146,284,340,20,170);
//{griva niz}
setcolor (11);
ellipse (425,193,270,0,10,50);
line (426,215,425,243);
ellipse (386,209,280,350,40,50);
ellipse (389,209,280,350,13,50);
ellipse (432,220,100,180,30,45);
setcolor (5);
ellipse (399,205,280,330,12,50);
ellipse (420,255,100,150,12,50);
//{zadnie nogi}
setcolor (11);
ellipse (410,360,130,200,60,89);
ellipse (421,392,128,179,109,151);
ellipse (334,389,180,340,21,5);

ellipse (429,400,128,180,120,160);
ellipse (289,400,180,340,22,5);
ellipse (388,400,141,180,120,160);
ellipse (328,291,110,184,20,73);
ellipse (303,332,79,115,22,35);
//{perednie nogi}
setcolor (11);
ellipse (500,291,170,260,30,115);
ellipse (460,325,160,250,20,85);
ellipse (474,402,180,340,22,5);

ellipse (439,381,110,205,30,100);
ellipse (428,410,120,185,60,140);
ellipse (390,421,180,340,22,5);
//{levoe krilo}
setcolor (11);
ellipse (404,137,200,250,45,75);
ellipse (308,323,45,95,75,230);
ellipse (301,110,100,180,3,15);
ellipse (340,38,225,252,60,100);
line (322,133,330,150);
ellipse (238,244,45,81,130,130);
ellipse (255,132,80,160,5,15);
ellipse (343,36,225,252,130,130);
line (303,160,316,170);
ellipse (291,199,70,110,70,31);
ellipse (313,179,160,200,50,25);
ellipse (268,249,60,90,125,60);
ellipse (377,214,139,270,60,24);

ellipse (375,224,115,250,30,15);
line (360,210,332,190);
ellipse (333,179,150,260,10,10);
ellipse (333,179,90,160,10,9);
line (334,170,358,187);
ellipse (369,126,200,250,30,65);
ellipse (338,213,50,85,36,65);
//{pravoe krilo}
setcolor (11);
ellipse (589,209,80,130,91,70);
ellipse (598,148,300,50,11,10);
ellipse (602,267,90,115,109,110);
ellipse (555,185,40,90,85,17);
ellipse (614,182,300,50,11,10);
ellipse (605,201,81,135,80,10);
ellipse (540,244,20,80,51,50);
ellipse (574,223,290,350,15,15);
ellipse (526,270,42,90,70,50);
ellipse (523,239,350,70,9,20);
ellipse (513,229,220,310,30,20);
ellipse (494,225,260,30,15,15);
ellipse (510,200,263,70,30,15);
ellipse (510,170,285,60,40,15);
//{telo}
setcolor (11);
line (511,207,470,270);
ellipse (392,235,290,330,90,70);
ellipse (395,256,175,265,45,40);
ellipse (385,220,45,100,25,25);
//{lico}
setcolor (11);
line (410,100,413,90);
ellipse (421,151,175,295,16,19);
line (427,169,432,164);
ellipse (423,174,280,45,13,13);
setcolor (12);
ellipse (423,174,280,28,4,13);
setcolor (11);
ellipse (457,166,230,300,52,29);
ellipse (450,135,320,360,80,110);
ellipse (420,153,240,300,6,9);
setcolor (12);
ellipse (432,183,80,220,3,3);
//{yxo}
setcolor (11);
ellipse (545,115,100,150,40,70);
ellipse (518,86,295,50,30,53);
ellipse (515,84,310,13,23,33);
//{griva verx}
setcolor (11);
ellipse (496,120,75,150,67,48);
ellipse (482,124,120,150,50,60);
ellipse (385,10,264,305,120,80);
ellipse (367,10,280,330,69,80);
ellipse (419,70,80,160,30,20);
ellipse (442,80,80,160,55,50);
ellipse (416,70,50,100,55,50);
ellipse (443,74,15,120,80,60);
setcolor (12);
ellipse (499,100,73,152,60,50);
setcolor (4);
ellipse (499,102,75,150,60,50);
setcolor (12);
ellipse (483,188,81,112,165,150);
setcolor (14);
ellipse (483,186,82,114,165,150);
//{glaza}
setcolor (11);
ellipse (470,130,150,20,30,40);
ellipse (415,124,311,28,15,30);
ellipse (419,125,135,240,15,30);
ellipse (415,147,200,340,10,5);
setlinestyle (0,0,1);
setcolor (7);
ellipse (471,130,20,150,30,40);
line (500,119,513,119);
line (497,108,510,102);
line (488,99,500,89);
ellipse (417,124,28,124,14,27);
ellipse (419,124,134,135,15,30);
//{zrachki}
setlinestyle (0,0,1);
setcolor (13);
setfillstyle (1,13);
fillellipse (460,130,15,21);
fillellipse (420,125,8,16);
setcolor (6);
setfillstyle (1,6);
fillellipse (456,130,10,15);
fillellipse (423,124,5,12);
setfillstyle (1,15);
setcolor (15);
fillellipse (459,133,3,3);
fillellipse (464,122,5,6);
fillellipse (422,129,1,2);
fillellipse (423,119,3,4);
}

//Pascal HTML5 emulator by Jedi_Knight

var canvas = null;
var ctx = null;

window.onload = function () {
	canvas = document.getElementById("screen");
	ctx = canvas.getContext("2d");
	
	canvas.width = 640;
	canvas.style.width = '1024px';
	canvas.height = 480;
	canvas.style.height = '768px';

	drawDash();
};

//var colors = ["black", "blue", "green", "cyan", "red", "magenta", "brown", "lightgray", 
//"darkgray", "lightblue", "lightgreen", "lightcyan", "lightred", "lightmagenta", "yellow", "white"];

var colors = ["#000000", "#0000AA", "#00AA00", "#00AAAA", "#AA0000", "#AA00AA", "#AA5500", "#AAAAAA", 
"#555555", "#5555FF", "#55FF55", "#55FFFF", "#FF5555", "#FF55FF", "#FFFF55", "#FFFFFF"];

function setcolor(colorIndex)
{
	ctx.strokeStyle = colors[colorIndex];
}

function line(x1, y1, x2, y2)
{
	ctx.beginPath();
	ctx.moveTo(x1, y1);
	ctx.lineTo(x2, y2);
	ctx.stroke();
	ctx.closePath();
}

function setlinestyle(p, t, width)
{
	ctx.lineWidth = width;
}

function setfillstyle(t, colorIndex)
{
	ctx.fillStyle = colors[colorIndex];
}

function ellipse(x, y, st, end, xrad, yrad)
{
	ctx.save();
	ctx.translate(x, y);
	ctx.scale(xrad, -yrad);
	ctx.beginPath();
	ctx.arc(0, 0, 1, st *Math.PI/180.0, end * Math.PI/180.0, false);	
	ctx.restore();
	ctx.stroke();
}

function fillellipse(x, y, xrad, yrad)
{
  ctx.save();
  ctx.translate(x, y);
  ctx.scale(xrad, yrad);
  ctx.beginPath();
  ctx.arc(0, 0, 1, 0, Math.PI*2, true);
  ctx.fill();
  ctx.closePath();
  ctx.restore();
}


Jedi_Knight
+3
Вау) Неплохо так получилось. Спасибо вам за работу. Линии гламурные такие, смазанные слегка =)
Abaduaber ↑
0
Да, теперь паскаль не нужен, чтобы поиграть с этим кодом. Достаточно скачать себе страницу и открыть в блокноте js-ку.

Можно считать что в векторе рисуется. Сглаживанием занимается браузер.
Jedi_Knight ↑
0
Да, у меня линие совсем не смазанные, но перетекают волной.
darkfrei ↑
0
HTML5 не знаю, но он жутко напоминает С++
Twilight ↑
0
Это ж кошерный javascript! Его, в отличие от C++, учат не годы а за месяц.

И вообще, если уж рисовать кодом, то с использованием кривых Безье =)
Jedi_Knight ↑
0
Эм. так и должно быть? dl.dropbox.com/u/7197329/MLP.FiM/dash.png
Inerf ↑
+2
О ГОСПОДИ! Это в каком браузере?

UPD. Понял. Оперная Дэши.
Jedi_Knight ↑
0
Opera 11.62 (
Inerf ↑
0
11.62 — все в порядке.
Stendarr ↑
0
Да эта пикча на 20% круче исходной!
eeyupbrony ↑
+2
Ох, вот это мега-круто! Куда там Ван Гогу до этого, вот он, труъ авангардъ!
Decadent ↑
+1
Очень круто!
Sid ↑
0
А это нормально что каждая кривая волной светится?
darkfrei ↑
0
ой быдлокод :) хотя по другому вроде никак, но рисовать в паскале, это вообще жесть
Twilight
0
Вы не расслабляйтесь, возможно, скоро еще и фанфик на брейнфаке подоспеет =)
Abaduaber ↑
+1
Код отличный, паскаль рулит! Запили еще музончик beep(440,1000);
Inerf
+2
Шедеврально!))
Подскажи, как можно вставить этот код в паскаль не переписывая его?))
PbICb
0
Копируйте все в буфер, открывайте блокнот, и вставляйте в него. Файл > сохранить как. В диалоговом меню ниже выбирайте «Все файлы», имя файла запишите, например, «1.pas». Также, разумно сохранить этот файл в директорию с паскалем. Затем, полученный файл можно открыть через паскаль и работать с ним далее.
Abaduaber ↑
0
А ты хорошо в паскале разбираешься? Мне тут помощь нужна сильно
MinusPony
0
Ещё на 20% круче и анимированней!
Поменялся код прорисовки, а то что на паскале было — осталось в неприкосновенности.

Jedi_Knight
+3
Превосходно получилось, большое вам спасибо. Интересно, как классно сумели допилить первоночальный рисунок автора.
У меня 6 FPS. Так и задумано? ;)
Abaduaber ↑
0
Да, написано криво, я ещё не оптимизировал этот ужас.
Jedi_Knight ↑
0
63 фпс, полёт нормальный.
Гугл Хром последний из стабильных.
darkfrei ↑
0
Да я себе другой браузер поставил, чтоб на это посмотреть! P.S. 44fps :P
Inerf ↑
+1
Пока не сделаю обыкновенные 60 — свой первый пост создавать не буду :)
Jedi_Knight ↑
+1
Таки я создал свой первый пост по этой теме.
Jedi_Knight
0
Ошибочка вышла: эта ссылка ведет именно на этот пост, а не на ваш.
Abaduaber ↑
0
FIXED.
Jedi_Knight ↑
+1
спасибо, ради прикола перепишу под андройд и ios :) эх времени бы свободного по больше…
ЗЫ: устроили тут понябр
adasiko
0
Зачем? Моя html5 версия отлично там работает
Да, я уже сделал нативное приложение через XDK directCanvas, но никакого прироста производительности от этого нет. Только если совсем нативное писать.
Jedi_Knight ↑
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.
Скрыто Показать