turbo Pascal 7,0, Нужны проги... Либо со списками ... Либо с графикой... Опции

[ismolnik]

\\Если блок Begin...End. там есть, то это код инициализации модуля.
Коды инициализации модулей исполняются в программе, использующей данный модуль, до того как получит управление самый первый оператор самой программы. Коды инициализации разных модулей исполняются в том порядке, как эти модули были указаны в операторе(ах) Uses.

Понял про .тпу
прошу пример для моей компиляции

[drusha]

Для какой такой Вашей компиляции?
Для тех, что выложены здесь?
Можете просто слова Program заменить на Unit, сделать раздел Interface (не знаю, может ли он быть пустой, можно попробовать, а если не получится, то поместить туда хотя бы объявления некоторых глобальных переменных), а потом поставить ключевое слово
Implementation
чтобы в этот раздел попал весь (или почти весь) исходный код программы. Вместе с Begin...End.
Потом компильнуть, и получится TPU. Ну, скажем, PRIMER.TPU
Потом пишется программа такого вида

Program Main;
Uses Primer;
Begin
End.

По идеее (надо бы проверить сей факт) в таком случае модуль будет работать как Ваша программа в исходном варианте.

[ismolnik]

Трудно, но сравнимо с Inclide в BASIС :-)

[drusha]

А какие трудности-то?
С Include в Basic ничего общего. У Паскаля есть свой Include. Вернее, директива
{$I имя_файла}
Это чисто как вставка фрагмента текста. А тпу - это МОДУЛЬ. Аналог объектника. А Бейсик (как правило) - это вааще, интерпретатор. Хотя, Visual Basic (не VBA) вроде, компилирует... А может, врёт, это тот же интерпретатор. Просто генерируется EXEшник, в котором сидит сам интерпретатор, а твоя прога (ну, может быть, в "шитом коде") помещена там в секцию данных. И получается иллюзия компиляции.

Впрочем, я люблю интерпретируемые языки. Там есть такие возможности, которые компиляторам обычно не по зубам.

А вааще, если кто хочет, у меня есть свой собственный интерпретатор языка ЛИСП (я его назвал "Топо-ЛИСП" или более кратко "Тополь") написанный на Турбо-Паскале (чисто под DOS). Весит где-то 250 Кб.

[ismolnik]

Пришли на е-мейл!
\\интерпретатор языка ЛИСП (я его назвал "Топо-ЛИСП" или более кратко "Тополь") написанный на Турбо-Паскале (чисто под DOS). Весит где-то 250 Кб.

[MaX]

Вот короч...Конкретики ...
Если кто может написать ... напишите плиз оч надо .. ( можно и на Дельфи)...



Задача №1


РИСУНОК


Вообщем...
Летает самолёт по овальной траектории (по кругу, постоянно, не очень быстро), внизу стоит пушка( пушка должна поварачиваться на заданный угол..)
Т.е. Мы должны ввести угол, пушка должна выстрелить и либо попасть в самолет, либо снаряд пролетает мимо
Выход из программы по нажатию "ESC"



Задача №2


РИСУНОК №2


Тоже самое что и в предыдущем задании, только движение корабля хаотическое...




Задача №3


Рисунок №3


Тут , надо нарисовать треугольник ( Большой)... по его сторонам должен двигаться маленький треугольник, при переходе через углы, маленький треугольник должен менять цвет ..
Выход из программы, также по нажатию "ESC"

[ismolnik]

\\Задача №1

Это лучше в граф.режиме,
но я не на столько хор знаю ГРАФИКУ.

[drusha]

Чесгря, за падло писать прогу с нуля... Когда так конкретно, то горовой такой, разумеется, нет.

Но если писать на Трубе или на Дельфе - это две большие разницы.

В Дельфе, там всё построено на компонентах. Ну, можешь заготовить много битмапов или иконок (я думаю, 32х32 для самолётика хватит за глаза), можно много, и менять их... А тому компоненту (например, Image) только соответствующие свойства менять. Это выглядит как присваивание значения каким-то полям записи. На самом деле в поняиях компонент и свойств это только синтаксически похоже выглядит. А на самом деле там для каждого свойства, которому что-то присваиваешь новое, при этом вызывается соответствующая подпрограмма "Set...", которая может делать всё что угодно, в том числе и перерисовывать что-то на экране. Чтобы картинка двигалась, надо просто присваивать новые значения свойству Position, там X и Y... А если менять ещё свойство ImageIndex у компонента, который завязан на ImageList, то можно быстро менять сами картинки, заставляя объект двигаться.

На Трубе надо использовать модуль Graph. Его надо инициализировать, потом установить графический режим... При этом используются BGI-драйверы (файлы с расширением BGI - например, EGAVGA.BGI, которые входят в комплект поставки Турбо-Паскаля). Они должны быть доступны твоей программе. Не помню, используется ли там переменная окружения PATH при поиске таких файлов, но для надёги BGIшники нужно помещать вместе с программой, а та должна уметь узнавать свой путь (откуда она запущена, что не обязательно есть текущая папка) и указывать BGIшник по полному пути.

Но это - ладно. Положим, графический режим установлен. Сначала отрисовываем фон, а потом рисуем спрайты (видимые объекты, которые могут двигаться). Для отрисовки каждого спрайта лучше написать свою подпрограммку, которая берёт параметры X и Y.

Можешь воспользоваться моим модулем REALGRAF. Там есть инициализация и установка граф. режима и просто ПЕРЕСЧЁТ координат. Мой модуль ничего сам не рисует (рисовать нужно всё средствами GRAPH), но для получения целочисленных пиксельных координат использовать мои функции scrx и scry. Как параметры туда даются действительные числа. Используются также собственые глобальные переменные этого модуля, означающие сдвиг и масштаб отображения (уст. через ZOOMxxx)

Для организации спрайта можно использовать функции
ImageSize(X1,Y1,X2,Y2) - размер буфера по двум углам прямоугольника
GetImage(X1,Y1,X2,Y2,буфер) - запомнить изображение в буфере, размер которого можно определить ImageSize (если размер прямоугольника не меняется, то можно один раз и навсегда узнать нужный размер и динамически выделить буфер, а можно просто взять статический буфер заведомо достаточного размера)
PutImage(X1,Y1,буфер) - восстановить изображение. Можно заметить, что тут даётся только один (левый верхний) угол, поскольку данные о размере прямоугольной области сидят в буфере.

Движение объекта делаем так (положим, ImageSize и выделение буфера уже сделано - для соответствующего спрайта)

GetImage - сохраняем прежний фон того места, где будем рисовать
DrawMySprite - своя подпрограмма (это условное имя, на самом деле своё для самолётика, пушки, снаряда, треугольничка...). Предполагается, что она принимает как параметры координаты некой точки привязки X и Y, и относительно них не вылезет за пределы нашего прямоугольничка, область которого мы сохранили.
Задержка. Тут можно заделать цикл опроса клавиатуры, мышки... Изображение должно "повисеть" на экране. Можно дать Delay или в цикле опроса клавиатуры-мышки смотреть ещё счётчик тиков таймера, ожидая когда он изменится. В DOS-приложениях эмулируется таймер, тикающий 18.2 раза в секунду. Этого достаточно чтобы создать иллюзию непрерывности движения, а 18.2 гц заведомо меньше частоты обновления экрана. Это значит, что изображение будет реально отрисовано, и граз успеет на него полюбоваться. К тому же, привязка к часам не зависит от быстродействия процессора.
PutImage на прежнем месте - то есть, восстановление фона и "стирание" спрайта

И повторяем всё по новой уже в новых координатах. Координаты и "вид" самолётика можно менять в зависимости от "фазы". Пусть, "фаза" - это у нас будет такая глобальная переменная, которая меняется при обнаружении изменения счётчика таймера. От неё зависят
- Координаты самолётика
- Вид самолётика
- Вид пушки
- координаты снаряда
- вид снаряда.

Вид - это то, от чего зависит то, как изображение рисуется. Например, у нас есть 3-мерная модель самолёта. То есть, набор некоторых 3-мерных опорных точек (представляемых как тройки действительных чисел), которые надо в некотором сочетании и порядке соединить линиями или закрашенными полигонами (треугольниками, четырёхугольниками)... Кроме того, у нас есть ориентация локальных координатных осей (9 чисел - направляющие косинусы базисных векторов). Фактически, это матрица перехода к другой стстеме координат (матрица поворота). Есть ещё одна матрица - проекции на 2-мерную плоскость - тоже матрица, но она будет вырожденная (но нам это пофиг). Положим, у нас на каждой фазе меняется ориентация самолётика. Это по сути направляющие косинусы его "локальной" системы координат, в которой представлены его опорные точки (нос, хвост, кончики крыльев...). То есть, в зависимости от ориентации (скажем, трёх углов: курс, тангаж и крен) расчитываются элементы той матрицы (т.е. направляющие косинусы). Умношив каждый 3-мерный вектор (3-мерные координаты каждой опорной точки) на эту матрицу, мы получаем эту точку в глобальной системе. Тут надо ещё почленно (по правилам векторной алгебры) прибавить координаты точки привязки - это где находится "начало" локальной системы координат самолётика. Тогда у нас получатся 3-мерные координаты оответствующих точек в некой глобальной системе координат. Потом каждый такой вектор домножается на матрицу проецирования (текущего вида).,и получаем фоктически 2-мерные точки для проекции. 2-мерные потому что наша матрица проецирования вырожденная, и координата Z тождественно обращается в 0. Её можно отбросить. Оставшиеся 2-мерные вещественные координаты для проекции. пересчитывает в пиксельные экранные координаты. Последние - уже целые (округлённые до целых пикселей) получаются в зависимости от текущего масштаба (а это тоже глобальные переменные, которые используются функцией пересчёта). Ну, в этих координатах-то и проводятся все линии, строятся и закрашиваются многоугольнички... Так, вот, рисуется спрайт по "честной" 3-мерной модели.

На самом деле, в игрушках делают проще. Там есть много-много заранее заготовленных картинок. Ими даже можно заполнить буфера, и быстро отображать их с помощью PutImage. Например, можно заготовить 36-72 картинки для изображения самолётика или пушки, повёрнутого на разные углы с шагом 10 или 5 градусов.

Ах, да, счётчик таймера можно получить как значение переменной с абсолютной привязкой к памяти (по абсолютному адресу)

Var TimeCount:LongInt Absolute $0040:$006C;

Можно так же сделать себе указатель

Var TimeCountPtr: ^Longint;
LastTimeCount:LongInt;
...
Label again, out;
Begin
TimeCountPtr:=MK_FP($40,$6c);
Инициализируем графический режим, рисуем рамки, фон...
...

again:
Нарисовать все спрайты Если спрайты перекрываются, то сначала рисуется более дальний план, потом - более ближний. Перед отрисовкой каждого спрайта сохраняется некая область экрана в соответствующем буфере. Эта область может быть с запасом. Важно, чтобы спрайт за её пределы не вылезал.

LastTimeCount:=TimeCountPtr^;
While LastTimeCount=TimeCountPtr^ Do
Begin
Опрос, есть ли чего в очереди ввода клавы, мышки,
Если есть, то получить и обработать.
If Key=Esc Then
GoTo out;
Может быть, по результатам обработки изменить глобальные переменные
End;
Погасить спрайты в порядке, обратном их рисованию. Гашение спрайта получается путём восстановления изображения (фона), предварительно сохранённого перед отрисовкой спрайта.
Измнить фазу
GoTo again;
Out:
Выходим из графического режима, прощаемся...
...
End.


Счётчик таймера - это переменная размером 4 байта (LongInt), размещённая по абсолютному адресу 40:6C (Hex) или 0:46C (Hex) - там ROM-BIOS держит счётчик таймера. Под виндами каждое DOS-окно работает в эмулированной среде (в своём виртуальном адресном пространстве), и в этой области (0040:006С) виртуальных адресов (которые она неспособно отличить от физических) эта фигня тоже эмулируется.

Присваивать этой переменной ничего не надо. Её можно смотреть и сравнивать со значением, ранее полученным от неё же. Она сама будет увеличиваться по аппаратному прерыванию от таймера. Это забота BIOS/DOS или Windows, которая их эмулирует.

Сообщение отредактировал drusha - Dec 14 2006, 21:16

[ismolnik]

\\На Трубе надо использовать модуль Graph. Его надо инициализировать, потом установить графический режим... При этом используются BGI-драйверы (файлы с расширением BGI - например, EGAVGA.BGI, которые входят в комплект поставки Турбо-Паскаля). Они должны быть доступны твоей программе. Не помню, используется ли там переменная окружения PATH при поиске таких файлов, но для надёги BGIшники нужно помещать вместе с программой, а та должна уметь узнавать свой путь (откуда она запущена, что не обязательно есть текущая папка) и указывать BGIшник по полному пути.

Подобное я говорил на поинте,
но Ты сказал лучше.

[drusha]

Про инициализацию графического режима можно выдрать подпрогрпмму initrg из исходного текста моего модуля realgraf, который приведён в этом топике выше. Там
- Определение оборудования
- Попытка найти BGIшник в текущей папке
- Если нет, то Попытка найти BGIшник в папке где сама программа
- Если нет, то запрос пользователю на ввод пути расположения BGIшников. До тех пор пока не введёт правильно.
- Инициализация модуля Graph
- Установка графического режима - наилучшего для этого оборудования (например, EGA 640x350x16 или VGA 640x480x16)

[ismolnik]

VGA 640x480x16
как на Мобильнике,
но на нём экран меньше 21"

[drusha]

Если найдёшь (или сам напишешь) BGIшник под ту графическую карту (3D-ускоритель), которая у тебя, то - ради бога. Но в комплекте поставки Turbo Pascal 7.0 круче VGA nтолько (не помню, но вроде бы) IBM-8514 (или это называлось XGA) - это 104х768 256 цвеов... Но не RAMDAC, а Planed - режим с 8 битовыми плоскостями (в обычных режимах EGA/VGA 4 битовые плоскости, потому всего 16 цветов). Но на тот момент это было круто. Хотя, бывали уже виделкарточки ещё круче (скажем, Cirrus Logic делал SVGA c 1 мегабайтом, которая держала 1024х768х256, 800х600х65536 (High Color) и 640х480х16млн (True Color) - и это на шине ISA! А на VLB (только под 486) они делали до 2 Мб, и тогда можно установить 1024х768х65536 (High Color) и 640х480 и 800х600 True Color (к тому же, частоту развёртки @75 Гц). К этим видеокарточкам прилагалась дискута с дровами под Windows 3.1 (3.11), AutoCAD, P-CAD, WordSTAR и другие популярные программы... Но BGIшников там не было. Приходилось довольствоваться тем, что все эти видеокарточки поддерживают стандартные возможности VGA.

[aler]

сли найдёшь (или сам напишешь) BGIшник под ту графическую карту (3D-ускоритель), которая у тебя, то - ради бога. Но в комплекте поставки Turbo Pascal 7.0 круче VGA nтолько (не помню, но вроде бы) IBM-8514 (или это называлось XGA) - это 104х768 256 цвеов... Но не RAMDAC, а Planed - режим с 8 битовыми плоскостями (в обычных режимах EGA/VGA 4 битовые плоскости, потому всего 16 цветов).

Существует BGI-драйвер для VESA, т.е. на почти любой видеокарте режимы 800x600,1024x768,1280x1024 с 256color,highcolor,truecolor если видеокарта поддерживает эти режимы

[drusha]

Можбыть и так. Не пробовал. Но тады иногда бывает нужен VESA-драйвер (не во все Video-BIOSы он заделан)... А, вот, про highcolor и truecolor в стандарте VESA я не слыхал (может, правда, не очень внимательно слушал)... Что я конкретно где-то видел ограничивалось 1024х768х256 (ну, может, 1280х1024), а про частоту экранной развёртки - ни слова. Но, может, у меня был не самый полный и не самый новый источник инфы про VESA.

Кстати, я не утверждал, что BGIшника под VESA нет в природе. Его нет в комплекте поставки TP 7.0. А в ту пору, когда я занимался Турбо-Паскалем, инета у меня не было.

Как бы то ни было, в данной задаче заморачиваться с этим - без мазы.

Сообщение отредактировал drusha - Dec 18 2006, 18:11

[aler]

1) Во всех известных современных (с 1995 года наверно) видеокартах VESA-BIOS есть
2) Режимы до 1280x1024xTrueColor в VESA жестко стандартизированы, но и более высокие режимы там тоже можно вкдючить, хотя дольше разбираться надо, но тоже стандартно.
3) Частоту развертки VESA вроде бы не может менять

[drusha]

C 1995 Турбо-Паскаль и BGI вообще не актуален

[aler]

Разные мнения бывают
Имхо наиболее нормальный из компилируемых языков высокого уровня

[drusha]

Ну, Паскаль как язык - можбыть. Только в нормальной версии, 32-битной, без идиотских ограничений на 64 Кб... А ещё в Трубе меня бесило ограничение на длину строк 255 буковок. В Дельфи их уже нет.

Я о том, что с появлением Windows-95 (к NT 3.51 в ту пору не у всех техника была готова, тогда, в основном, были 486-е, а Пень - роскошь, хотя утверждалось, что 486DX4-100 бьёт Pentium-75, а DX5-133 - 90-й, и идёт наравне с 100-м пентиумом)... Ну, короче, DOS перестал быть вообще актуальным. Если программу начинаешь писать сейчас, то к сдаче она будет готова где-нибудь через несколько месяцев - через год (ну, там, документация, тестирование, расчёты на реальных данных, опытная эксплуатация...), ещё года 2-3 она, положим, проживёт... Ну, короче, имеет смысл писать под те программные и аппаратные средства, которые БУДУТ года через 2-3. Например, сейчас имеет смысл подумать про 64 разряда. Или хотя бы писать на тех средствах, которые обеспечат обратную совместимость, и позволят при минимальных переделках перейти к 64 разрядам. Это - сегодня.
А тогда... Тогда уже любая програма под DOS была уже мертворожденной. Ну, я понимаю, изучать численные методы и алгоритмы, работу со списками (сортировка. поиск и т.п.) и всё такое теоретическое-академическое, безотносительное к пользовательскому интерфейсу. Это можно изучать хоть под DOS, хоть под UNIX, хоть под VAX/VMS... Консольный интерфейс, наверное, тоже ещё поживёт... Но делать ГРАФИКУ под DOS на мёртвом интерфейсе - это я считаю высшей степенью маразма.

[MaX]

Спасибо за внимание .. вроде сдали ...