Версия для печати темы
Нажмите сюда для просмотра этой темы в обычном формате
Форум «Всё о Паскале» _ Голосования _ Графика на ассемблере
Автор: Dark 12.03.2004 11:26
Один раз Gluk и AlaRic мне дали шанс постить свою обучалку по ассемблеру, я его не оправдал, хочу продолжить (или начать по другому) ее ВЫ ЗА ИЛИ ПРОТИВ????
Автор: AlaRic 12.03.2004 15:38
-Поступила команда "Графика на асме".
-Выполнить команду.
-Есть выполнить команду!!
Автор: Dark 13.03.2004 9:44
Ок, тады буду продолжать - начинать 
Автор: AlaRic 13.03.2004 12:37
Модерировать раздел асмы будешь?
Автор: Dark 15.03.2004 3:36
}{м, а глюк на что )))
хотя могу
Автор: AlaRic 15.03.2004 16:30
Сказано-сделано, за работу!
Автор: Rider 15.03.2004 21:42
А чем графика на асме сильнее графике на том же Паскале?
Автор: Shadow 17.03.2004 0:40
Гм если в PAS делать вставки ASM то вприципе ничем а если делать
на чистом PAS то многие возможности не доступтны
напрмер пресловутая VESA 24 bit цветом
Автор: Dark 17.03.2004 7:56
Ну вот работа
Опять работа :D
Начинаю...
Автор: GLuk 18.03.2004 1:13
напрмер пресловутая VESA 24 bit цветом
Hi Shadow!
Чушь, на паскале можно реализовать поддержку всех режимов VESA, юзая только встроенные средства. Чуть медленнее конечно будет, но на современных машинах это не принципиально.
Недоступны лишь некоторые привилегированные команды проца (и другие после 286).
Автор: Shadow 19.03.2004 0:18
Чушь, на паскале можно реализовать поддержку всех режимов VESA, юзая только встроенные средства. Чуть медленнее конечно будет, но на современных машинах это не принципиально.
Недоступны лишь некоторые привилегированные команды проца (и другие после 286).
БРРР не удобно
Автор: Shadow 19.03.2004 0:22
все лучше использовать ASM вставки или OBJ инклуды
-=-=-
кстати как реaлизовать 24 bit цвет ведь PAS незнает EAX EBX и.т.д. 32 регистры не удобно о
-=-=
не 32 ух разрядный компилятор 
Автор: Dark 19.03.2004 6:49
ну, они доступны =) но не напрямую, я в качестве теста использовал расширитель регистра - префикс db66h
=) где то вроде даже пост есть...
Автор: Shadow 19.03.2004 18:19
криво как-то
Автор: SKVOZNJAK 19.03.2004 19:44
А не проще ли тут использовать 32 битный паскаль?
Автор: Shadow 19.03.2004 20:32
Мы вроде начали обсуждать PASCAL - обыкновенный-=-=-=
да есть TMT или GNU PASCAL - не поню как он завется да он поддерживает
32 регистры
Автор: GLuk 20.03.2004 0:28
Обсудилово изначально шло по поводу реализации графики встроенными средствами паскаля (исключая асм-вставки и inline-макросы, ну и ессесно внешние подпрограммы). Само собой реализовать что-то юзая средства P386 иной раз легче, но не стоит дезинформировать камрадов по типу - это сделать нельзя!
Автор: Dark 20.03.2004 11:02
И что кривово ))) разве что вероятность ошибок повышаеться, и хрен поймешь где они....
Автор: Romtek 20.07.2004 14:45
ИМХО, на асме нет смысла графику кодить, много заморочек и суть спрятана в дебрях здоровенского кода.
Лучше на Паскале!
Автор: NetAnton 20.07.2004 17:09
поправлю - в дебрях здоровенского ИСХОДНОГО кода.. а скомпиленный - дык он как дюймовочка по сравнению с Паскалем...
Автор: BlackShadow 20.07.2004 17:17
Общепризнано и научнообоснованно, что основная потеря времени при работе программы идёт при визуализации и обмене информацией с внешними носителями. Скорость винта програмно не увеличить (не говоря уж о флопике). Значит оптимизируя работу программы, надо делать упор на визуализацию.
romtek, декомпиль такую прогу:
Uses Graph,CRT;
Const
r:Integer=DETECT;
Var
m:Integer;
Begin
InitGraph('',r,m);
Rect(100,100,200,200);
ReadKey;
RestoreCRTMode
End.
Вот тут ты хорошо прочувствуешься фразой "дебри кода"
Автор: Romtek 27.11.2005 19:02
Znayu, chto dekompilirovannyj kod budet dalyok ot sovershenstva, no e'to plata za skorost' razrabotki. A skol'ko vremeni nuzhno pisat' takuyu programmu na assemblere? A kak naschyot lyogkosti primeneniya debaggera v kode na Paskale?
Автор: FreeMan 29.11.2005 0:53
СтОит всего раз сесть и убить несколько дней на создание процедур рисования базовых фигур. А потом просто использовать связку copy-paste