Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 18 окт 2019, 03:40

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 13 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: 13 авг 2012, 14:50 
Не в сети
Аватара пользователя

Сообщения: 967
Откуда: Днепропетровская обл.
Открыл эту тему для консультации будущего пользователя среды ZXDev, в надежде, что ещё кому-то будет интересно.

Руслан пишет:
Цитата:
Спасибо за ответ. Вы меня заинтересовали. Но мне нужно увидеть его производительность по отношению с тем же бэйсиком. Именно меня интересует лазер бэйсик. Вы сможете написать простой скрипт где по управлению клавиатуры двигается большой (100 на 100) спрайт.
Но сразу вынужден предупредить, если я заинтересуюсь, то вас замучаю вопросами (первое время). Схватываю легко, логика вроде работает. Так что учусь быстро))

Руслан, производительность скомпилированного Оберон-кода будет в десятки раз лучше, чем скорость интерпретатора бейсика (включая лазер). Просто в заданной Вами задачке производительность будет зависеть не от нескольких десятков машинных команд, написанных на Обероне, а от скорости вывода спрайта, который будет выводиться конечно же подпрограммой в машинных кодах. Ибо такую низкоуровневую задачу решать прямо на Обероне невыгодно — потеря производительности.

Навскидку есть идея как сделать всё максимально просто — опрашивать клавиатуру прямо по порту 254, а спрайт выводить лазером (будет примерно скорость лазера, ну может чуть повыше).

У меня есть наработанные библиотеки опроса клавиатуры и вывода тайлов, но явно не 100x100. К тому же, это, получается, не атрибутные спрайты, а точечные? Тогда надо искать ассемблерную подпрограмму для вывода таких спрайтов.

Я понимаю, что задача явно макет, но и тут есть доп. вопросы. Например.

    1. Что входит в управление? QAOP, Sinclair, Kempston, что-нить ещё?
    2. Как реагировать, если нажато сразу несколько клавиш?
    3. Как быть с тем, что новый спрайт будет выведен поверх старого, но часть старого спрайта при этом не будет затираться?
    4. Нужно ли делать программу универсальной и кроссплатформенной или она не планируется ни для чего, кроме Спека? (это накладывает некоторые особенности).
    5. Что делать при выходе спрайта за пределы экрана?

Если Вы хотите увидеть примерный Оберон-код, то я в любом случае начну с проектирования интерфейсов. Итак, разделим высокий и низкий уровень. В низком у нас будут.

Код: "OBERON"
  1. DEFINITION GrSpr; (* Графика *)
  2. TYPE
  3. Coords = SHORTINT;
  4. Sprite = CARDINAL;
  5. PROCEDURE PutSprite (x, y: Coords; spr: Sprite);
  6. END GrSpr.

Код: "OBERON"
  1. DEFINITION Control; (* Опрос управления *)
  2. CONST
  3. Up = {1};
  4. Down = {2};
  5. Left = {3};
  6. Right = {4};
  7. Fire = {5};
  8. TYPE
  9. CtrlKeys = SET;
  10. PROCEDURE GetCtrl (): CtrlKeys;
  11. END Control.

Код: "OBERON"
  1. DEFINITION Rsrc; (* Файл ресурсов игры *)
  2. VAR
  3. Sprite-: CARDINAL; (* Наш выводимый спрайт *)
  4. END;

Мы ещё не написали ни строчки кода реализации, но уже имеем отличное представление о том, чего мы ждём от низкоуровневого кода. Кроме того, реализация скрыта от пользователя высокоуровневых интерфейсов. И особенности платформы тоже скрыты. Появляется возможность, заменив реализацию, пересобрать программу для других платформ.

Высокий уровень.

Код: "OBERON"
  1. MODULE MySprt;
  2. IMPORT GrSpr, Control, Rsrc;
  3.  
  4. PROCEDURE Main* ;
  5. VAR
  6. x, y: GrSpr.Coords; pressed: Control.CtrlKeys;
  7. BEGIN
  8. x := 10; y := 10; (* Начальные координаты спрайта *)
  9. LOOP (* Вечный цикл *)
  10. GrSpr.PutSprite(x, y, Rsrc.Sprite); (* Спрайт будет “размазываться”, край НЕ ЗАТИРАЕМ! *)
  11. pressed := Control.GetCtrl(); (* Никакой проверки за пределы экрана не предусмотрено! *)
  12. IF Control.Up IN pressed THEN y := y - 1 END; (* Есть обработка нескольких клавиш сразу *)
  13. IF Control.Down IN pressed THEN y := y + 1 END;
  14. IF Control.Left IN pressed THEN x := x - 1 END;
  15. IF Control.Right IN pressed THEN x := x + 1 END;
  16. END;
  17. END Main;
  18.  
  19. END MySprt.

Конечно этот код собрать и проверить на Спектруме я не пробовал, надо сначала решить тот список вопросов выше. И реализовать (или найти) все сущности, описанные в интерфейсах. Что уже слегка выходит за рамки программирования на Обероне. Как видите, Руслан, для машинно-зависимых и критичных по скорости работы участков кода по-прежнему ассемблер — лучшее средство.

Если у Вас есть готовый низкоуровневый код процедур на асме, могу показать как вызывать его из своих программ на Обероне. В примерах к ZXDev, правда, всё это есть, но с удовольствием отвечу на возникшие вопросы.


Последний раз редактировалось Zorko 13 авг 2012, 19:56, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 13 авг 2012, 18:38 
Не в сети

Сообщения: 5
Zorko писал(а):

    1. Что входит в управление? QAOP, Sinclair, Kempston, что-нить ещё?
    2. Как реагировать, если нажато сразу несколько клавиш?
    3. Как быть с тем, что новый спрайт будет выведен поверх старого, но часть старого спрайта при этом не будет затираться?
    4. Нужно ли делать программу универсальной и кроссплатформенной или она не планируется ни для чего, кроме Спека? (это накладывает некоторые особенности).
    5. Что делать при выходе спрайта за пределы экрана?


В управление пускай qaopm,
Ни как не реагировать, пускай работает дальше.
Пускай затирается
Только для спека (но потом может и не только)
Пускай останавливается у краев

Спрайт выводить с помощью лазер бэйсика


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 авг 2012, 12:42 
Не в сети
Аватара пользователя

Сообщения: 967
Откуда: Днепропетровская обл.
Подготовил тестовую программку, чтобы посмотреть её прямо на Спеке. Инструкция: распаковать архив MoveSpr.zip прямо в папку с установленным XDev. Некоторые уточнения.

Laser Basic не умеет выводить поточечные спрайты, поэтому я взял первый попавшийся спрайт с атрибутами из набора Sprite2B, это оказалась черепаха размером 4x2 знакомест. Эксперименты с бОльшими размерами спрайта, Руслан, оставляю на Ваше усмотрение.

Я отступил от разработанных выше интерфейсов. Отчасти чтобы сделать всё быстрее (и без промежуточных уровней-прослоек), отчасти потому что сделал подгонку под имеющуеся у меня ассемблерную подпрограмму для опроса клавиатуры.

Насчёт кроссплатформенности. Конечно лазер бейсика для других платформ нет, кроме того, не на всех устройствах есть клавиатура (например, в интернет-планшетках с сенсорным управлением), и управление QAOPM не везде применимо.

Вообще проектирование платформенно-нейтральных интерфейсов — вещь сама по себе нетривиальная, но кроссплатформенное программирование вообще имеет ряд особенностей, и здесь дело не в Обероне. Но Оберон помогает чётко провести грань между платформенно-зависимым и независимым кодом, а хорошо спроектированные интерфейсы для взаимосвязи частей программы повышают шансы на её кроссплатформенность.

По поводу размера бинарника, который бы сразу кинулись критиковать великие умы с форума zx.pk.ru. В бинарник сейчас входит ВЕСЬ набор спрайтов Sprite2B и ВСЕ процедуры из библиотек Basic и Laser Basic, и я не предпринимал никаких шагов, чтобы уменьшить бинарник. Но если этим специально заняться, то можно сократить, и, полагаю, весь код будет занимать меньше килобайта.

На закуску прикладываю демонстрационную программку Hero, которая выполняет ту же самую задачку, что задал Руслан, но для MS-DOS. Для сборки используется компилятор Oberon-M. Управление — курсорные клавиши. Выход за пределы экрана никак не проверяется.


Вложения:
MoveSpr.png
MoveSpr.png [ 22.25 КБ | Просмотров: 38370 ]
Комментарий к файлу: Проект MoveSpr для ZX Spectrum
MoveSpr.zip [13.79 КБ]
Скачиваний: 1912
Комментарий к файлу: Проект Hero для MS-DOS
Hero.zip [125.53 КБ]
Скачиваний: 1926
Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 авг 2012, 18:21 
Не в сети

Сообщения: 5
Скорость впечатляет, учитывая что код простой.

Теперь скажите пожалуйста.

Сколько весит чистый код?
Блок лазер бейсика разве со спрайтами идет в комплекте и сколько он весит вообще?
Спасибо!


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 авг 2012, 18:35 
Не в сети

Сообщения: 5
Не пойму как компилировать и проверять код.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 авг 2012, 18:42 
Не в сети

Сообщения: 5
Да еще, как цеплять коды? - набор картинок например, музыку и тд? Так же как менять значение ячеек памяти?, - это поке. Если библиотеку лазер бэйсика довести до ума. А она на сколько я помню умеет Различными способами накладывать спрайты (ксор, ор) так же зеркалить спрайт, а еще что не помните?. То можно уже бутит попробовать что нить написать. Потом - автор Оберона не против что на его языке пишут, он вообще не коммерческий? И куда грузиться блок лазер бэйсика, его можно закидывать по другим адресам?


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 авг 2012, 18:50 
Не в сети
Аватара пользователя

Сообщения: 967
Откуда: Днепропетровская обл.
Ну, давайте посчитаем малость.

    Процедура опроса клавиатуры _Keyboard_Pressed = 72 байта

    Лазер бейсик (весь блок процедур) = 5025 байт (здесь можно выгадать, если выковырять именно нужные процедуры и оставить только их. Однако не просите этим заниматься меня, пожалуйста. :-) )

    Инициализация-деинициализация бейсик-уровня _Basic_Init + _Basic_Quit = 10 + 10 байт

    Установка цвета бордюра и прочее подобное — тоже немного. Байты или десятки байтов.

    Спрайт-черепашка = 4x2x9+5 байт.

    Весь модуль MoveSpr (а именно скомпилированная процедура MoveSpr_Main) занимает в машинном коде 139 байт (размер можно посмотреть в листинге MoveSpr.lst, который создаёт SDCC в процессе компиляции).

Извиняюсь, может что-нибудь немного упустил.

Наборы спрайтов Sprite2A и Sprite2B идут в поставке Laser Basic, но включать все спрайты в свой проект конечно же нет никакой необходимости, я так просто сделал на скорую руку.

Прошу не обижаться, но меня больше интересует именно Оберон-уровень и проектирование высокоуровневых интерфейсов, а не низкоуровневый кодинг на ассемблере Z80.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 14 авг 2012, 21:50 
Не в сети
Аватара пользователя

Сообщения: 967
Откуда: Днепропетровская обл.
Как мы используем двоичные данные из бейсика? Определяем свободный участок памяти по адресу N, загружаем туда машинный код (или данные) с внешнего накопителя информации (или из бейсика с помощью READ/DATA) и работаем с ними (USR N, PEEK/POKE). С точки зрения Оберона ресурсы представляют собою массивы байтовых данных, которые мы тоже можем загружать, но при их использовании распределением адресов занимается сам компилятор, и обычно париться с этим не нужно. С массивами работаем или по идентификатору (который указывает на адрес, но без явной циферки), или по индексу. Это гораздо более кроссплатформенно. Использовать POKE/PEEK и прямую адресацию в Обероне в общем-то никто не запрещает, но страдает переносимость, и понятно, что делать такое нужно только на низком уровне.

Для включения в программу ресурсов (спрайтов, шрифтов, музыки, звуков, уровней и т.п.) я обычно завожу ресурсный модуль Rsrc, в который вставляю двоичные данные, подготовленные утилитой XDev/ZXDev/Bin/Bin2c.exe, в виде инициализированных массивов. Обычно имеет смысл заводить один массив на один ресурс (чтобы не заниматься сложными расчётами адресов). Пример такого модуля, в который занесён набор спрайтов лазер бейсика Sprite2B, можно посмотреть в файле XDev/ZXDev/Lib/C/LaserSprite2B.c.

Пусть использование языка Си для подключения ресурсов (да и асмового кода) Вас не ужасает, ничего сложного там нет. Со временем разберётесь. :-)

Насчёт включения в программу музыки. Проблем нет, просто нужно выбрать плеер, а мелодии подключить в виде ресурсов. В ZXDev Оберон-программа может работать в любом режиме прерываний (IM0/IM1, IM2 или DI). Режим задаётся в файле-конфигураторе BasicCfg.h. Для режима IM0 компилятор SDCC поддерживает специальный ключик --reserve-regs-iy, который запрещает использование регистра IY, оставляя его бейсику на откуп.

Компилировать код: F11, линковать запуском XDev/ZXDev/MoveSpr.bat
Это и много ещё другого описано в документации: XDev/ZXDev/Docu/ZXDevRus.txt

В итоге должен получиться образ диска MoveSpr.trd, который открываете в эмуляторе. Пока процесс выглядит так, далее может автоматизируем.

По лазер бейсику смотрите XDev/ZXDev/Docu/LaserBasic.txt. Есть по нему ещё документация на русском (гуглируйте). Да, всё вышеперечисленное Вами он умеет. Вот список процедур — интерфейс лазер бейсика для использования в своих программах на Обероне. Предлагаю убедиться как легко его сгенерировать автоматически (а часто для пользования функционалом модуля это единственное, что нужно знать; все механизмы реализации скрыты от конечного пользователя интерфейсом). Откройте:

File -> Open -> ZXDev/Lib/Mod/Laser.Def

Нажмите F12 (скомпилируем наш модуль подсистемой Dev, таким образом создастся символьный файл — сгенерированный интерфейс экспортов модуля). Дважды щёлкните на слове Laser и нажмите Ctrl+D. Откроется что-то такое:

Код: "OBERON"
  1. DEFINITION Laser;
  2.  
  3. PROCEDURE ASLV (col, row, len, hgt: BYTE);
  4. PROCEDURE ASRV (col, row, len, hgt: BYTE);
  5. PROCEDURE ATDV (col, row, len, hgt: BYTE);
  6. PROCEDURE ATOF;
  7. PROCEDURE ATON;
  8. PROCEDURE ATUV (col, row, len, hgt: BYTE);
  9. PROCEDURE AWLV (col, row, len, hgt: BYTE);
  10. PROCEDURE AWRV (col, row, len, hgt: BYTE);
  11. PROCEDURE CLSM (spN: BYTE);
  12. PROCEDURE CLSV (col, row, len, hgt: BYTE);
  13. PROCEDURE GMAT (col, row, spD, spS: BYTE);
  14. PROCEDURE GMBL (col, row, spD, spS: BYTE);
  15. PROCEDURE GMND (col, row, spD, spS: BYTE);
  16. PROCEDURE GMOR (col, row, spD, spS: BYTE);
  17. PROCEDURE GMXR (col, row, spD, spS: BYTE);
  18. PROCEDURE GTBL (col, row, spN: BYTE);
  19. PROCEDURE GTND (col, row, spN: BYTE);
  20. PROCEDURE GTOR (col, row, spN: BYTE);
  21. PROCEDURE GTXR (col, row, spN: BYTE);
  22. PROCEDURE INVM (spN: BYTE);
  23. PROCEDURE INVV (col, row, len, hgt: BYTE);
  24. PROCEDURE Init;
  25. PROCEDURE MARV (col, row, len, hgt: BYTE);
  26. PROCEDURE MIRV (col, row, len, hgt: BYTE);
  27. PROCEDURE PMAT (col, row, spD, spS: BYTE);
  28. PROCEDURE PMBL (col, row, spD, spS: BYTE);
  29. PROCEDURE PMND (col, row, spD, spS: BYTE);
  30. PROCEDURE PMOR (col, row, spD, spS: BYTE);
  31. PROCEDURE PMXR (col, row, spD, spS: BYTE);
  32. PROCEDURE PTBL (col, row, spN: BYTE);
  33. PROCEDURE PTND (col, row, spN: BYTE);
  34. PROCEDURE PTOR (col, row, spN: BYTE);
  35. PROCEDURE PTXR (col, row, spN: BYTE);
  36. PROCEDURE PWBL (col, row, spN, spCol, spRow, len, hgt: BYTE);
  37. PROCEDURE PWND (col, row, spN, spCol, spRow, len, hgt: BYTE);
  38. PROCEDURE PWOR (col, row, spN, spCol, spRow, len, hgt: BYTE);
  39. PROCEDURE PWXR (col, row, spN, spCol, spRow, len, hgt: BYTE);
  40. PROCEDURE SCRM (spN, npx: BYTE);
  41. PROCEDURE SCRV (col, row, len, hgt, npx: BYTE);
  42. PROCEDURE SETV (col, row, len, hgt: BYTE);
  43. PROCEDURE SL1M (spN: BYTE);
  44. PROCEDURE SL1V (col, row, len, hgt: BYTE);
  45. PROCEDURE SL4M (spN: BYTE);
  46. PROCEDURE SL4V (col, row, len, hgt: BYTE);
  47. PROCEDURE SL8M (spN: BYTE);
  48. PROCEDURE SL8V (col, row, len, hgt: BYTE);
  49. PROCEDURE SR1M (spN: BYTE);
  50. PROCEDURE SR1V (col, row, len, hgt: BYTE);
  51. PROCEDURE SR4M (spN: BYTE);
  52. PROCEDURE SR4V (col, row, len, hgt: BYTE);
  53. PROCEDURE SR8M (spN: BYTE);
  54. PROCEDURE SR8V (col, row, len, hgt: BYTE);
  55. PROCEDURE WCRM (spN, npx: BYTE);
  56. PROCEDURE WCRV (col, row, len, hgt, npx: BYTE);
  57. PROCEDURE WL1M (spN: BYTE);
  58. PROCEDURE WL1V (col, row, len, hgt: BYTE);
  59. PROCEDURE WL4M (spN: BYTE);
  60. PROCEDURE WL4V (col, row, len, hgt: BYTE);
  61. PROCEDURE WL8M (spN: BYTE);
  62. PROCEDURE WL8V (col, row, len, hgt: BYTE);
  63. PROCEDURE WR1M (spN: BYTE);
  64. PROCEDURE WR1V (col, row, len, hgt: BYTE);
  65. PROCEDURE WR4M (spN: BYTE);
  66. PROCEDURE WR4V (col, row, len, hgt: BYTE);
  67. PROCEDURE WR8M (spN: BYTE);
  68. PROCEDURE WR8V (col, row, len, hgt: BYTE);
  69.  
  70. END Laser.

Вручную вычислять адрес, по которому грузится лазер бейсик, не нужно, — это компилятор делает автоматически. Всё, что Вам нужно для его использования, — знать имена процедур и правильно указать их параметры. Правильность последних контролирует компилятор.

Автор Оберона Никлаус Вирт совершенно не против, что пользуются его языком. Он его для этого и разрабатывал. Если говорить о коммерческом аспекте, то надо смотреть на конкретную реализацию транслятора или системы. Есть и коммерческие, но гораздо больше свободных. Среду XDev/ZXDev можно использовать для разработки и реализации программ под любой удобной для Вас лицензией.


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 16 авг 2012, 13:01 
Не в сети
Аватара пользователя

Сообщения: 967
Откуда: Днепропетровская обл.
Руслан писал(а):
Скорость впечатляет, учитывая что код простой.

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

Здесь, Руслан, лежит объяснение, почему люди так любят сложные, непонятные и запутанные языки программирования, отвергая простые. Своеобразная кастовость. Вспомните католическую церковь, которая предпочитает молитвы на мёртвой и непонятной для 99,9% людей латыни. Недалеко от них ушли и медики. Ещё бы. Им такая обособленность даёт свысока почувствовать своё превосходство и элитность. И что для мэйнстрим-программистов мы с вами, которые напишут на Обероне программы, которые поймёт любой начинающий спектрумист?

Почему так много ругают винду и хвалят линукс? Думаете, он сильно лучше? Да вовсе нет. Объяснение — всё та же кастовость, элитность. “Мы линухойды — элита айти, а не какие-то там виндузятники попсовые”.

Вот вам хорошее объяснение малой популярности Оберонов. Обероны — это угроза, что мы с Вами, не особо напрягаясь, будем делать то, на что у мэйнстрим-работников ушли годы изучения сложных и запутанных технологий. Но это касается только языка, а не библиотек или сред разработки, — с этим у Оберонов пока не шибко хорошо.

Несколько слов про скорость работы программы. Оберон-уровень даёт хорошо прочувствовать алгоритм и меры по его оптимизации. И здесь в нашем макете можно выделить 3 направления, в которых можно улучшить скорость работы.

    1. Процедура вывода спрайта Laser.PTBL выводит спрайт по его номеру. Внутри она переводит номер спрайта в его адрес, а это дополнительные накладные расходы. Можно ли на Обероне передать в процедуру вывода спрайтов не номер, а адрес? Конечно. Для этого модуль Rsrc будет экспортировать адрес спрайта (спрятанный под понятным именем массива ресурса), а процедура его принимать. Саму PTBL для этого конечно придётся модифицировать.

    Плюс сама процедура PTBL была написана очень давно, а с тех пор придуманы техники более скоростного вывода спрайтов.

    2. Процедура опроса клавиатуры Keyboard.Pressed, как видите, вызывается аж целых 4 раза (кстати, в спроектированном мною выше интерфейсе этот недостаток устранён). Конечно же так делать нету никакой необходимости. Вызванный единожды опросчик клавиатуры может вернуть сразу набор бит, где каждый соответствует нажатию своей клавиши, а обрабатывать мы их будем, проверяя значение переменной, что гораздо быстрее.

    3. Идея этой оптимизации состоит в том, что проверять координаты на выход за пределы экрана нужно не всякий раз все сразу, а только в тех местах программы, где они реально изменялись. Код будет выглядеть где-то так:
Код: "OBERON"
  1. LOOP (* Вечный цикл *)
  2. L.PTBL(x, y, 1); (* Выводим на экран спрайт с номером 1 *)
  3. (* Есть обработка кнопок, нажатых вместе *)
  4. IF Key.Pressed(Key.Up) THEN
  5. y := y - 1; IF y < 0 THEN y := 0 END;
  6. END;
  7. IF Key.Pressed(Key.Down) THEN
  8. y := y + 1; IF y > MaxY THEN y := MaxY END;
  9. END;
  10. IF Key.Pressed(Key.Left) THEN
  11. x := x - 1; IF x < 0 THEN x := 0 END;
  12. END;
  13. IF Key.Pressed(Key.Right) THEN
  14. x := x + 1; IF x > MaxX THEN x := MaxX END;
  15. END;
  16. END;

Наконец, перерисовывать неподвижный спрайт, если его координаты не изменились, не нужно — пустая трата времени процессора. Но это уже ладно, в любом случае код условный. Просто оцените перспективы по оптимизации будущей игры, если оптимизация конечно понадобится. Мне в “Дураке” пришлось много где вставлять задержки времени, иначе играть невозможно.

Пишите об успехах в освоении технологии ZXDev и продвижении разработки Вашей игры, Руслан. Удачи!


Вернуться к началу
 Профиль  
Ответить с цитатой  
СообщениеДобавлено: 16 авг 2012, 18:57 
Не в сети

Сообщения: 5
Честно говоря, меня не привлекают языки где нужно ломать голову. Я лично предпочитаю вкладывать усилия в разработку игры (сюжет, графика). С нынешним проектом я должен скоро закончить. Потом попробую что нибудь на обероне.
Но хотелось бы все таки вас о кое чем попросить. У вас есть знакомые кодеры - может вы сможете попросить кого нибудь написать скрипт по выводу спрайта с маской на ассеблере. Желательно так - копировать часть экрана куда накладывается спрайт - маска - спрайт - наложение скопированной части экрана , как то так. Дело в том что у лб эти пять кб ну не к чему. И те процедуры что есть то же. Да еще наверняка он медленный. Спасибо


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 13 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Тех.поддержка phpBB