Список режимов:

• 1 - 1024 х 768
  
• 2 - 1152 х 864
  
• 3 - 1280 х 600
  
• 4 - 1280 х 720
  
• 5 - 1280 х 768
  
• 6 - 1280 х 960
  
• 7 - 1280 х 1024
  
• 8 - 1400 х 1050
  
• 9 - 1600 х 900
  
• 10 - 1600 х 1200
  
• 11 - 1856 х 1392
  
• 12 - 1920 х 1080
  
• 13 - 1920 х 1200
  
• 14 - 1920 х 1440
  
• 15 - 2048 х 1536
  

Список разрядности:

• 1 - 16
  
• 2 - 32
  

Так же есть возможность режима: окно (Играть в окне).

Последующие шаги - это разработка управляемого GUI. Суть его сводится к тому, что будут файлы диалогов, которые будут содержать настройки диалога, то есть, кнопки, редакторы, флажки, в общем элементы. Каждый элемент будет иметь свой ID. Этот ID будет использоваться в скриптах. Таким образом будет осуществляться управление.

В направлении реализации GUI были созданы:

TGUIObject - стандартный класс объектов. Содержит в себе все необходимые элементы и функции, которые много раз могут повторяться в других объектах. Этот класс является прородителем последующих объектов.

TGUIButton - класс кнопки.

Пример записи информации из кнопки:

До двоеточия идёт идентификатор типа объекта, в данном случае "BUTTON".
После двоеточия идут цифры. В этом случае:
10 - Идентификационный номер объекта, он используется в функции CallBack.
5 - Положение объекта по горизонтали (X или Left)
25 - Положение объекта по вертикали (Y или Top)
В конце, взятая в кавычки строка "Кнопка", является надписью.

Но это ещё не всё в конфигурации записи строки. Система AlloGUI загружает стандартные параметры для каждого отдельного типа объектов. Они устанавливаются как стандартные (default). Но есть возможность применить отдельные параметры для отдельного объекта.

На скрине есть надпись "УРА!!!". Она записана следующей строкой:

Эта строка имеет три секции, разделённые двоеточием. Нас интересует последняя секция. В ней указываются локальные параметры форматирования объекта.
Color - задаёт цвет текста
Size - задаёт размер текста
Font - указывает название шрифта для текста.

---
Вскоре будет выложена дополнительная информация.

Так обычно не делают. Режимы дисплея в большинстве случаев определяют используя возможности WinAPI после чего создается список доступных режимов. В таком случае проект может работать на практически любых машинах, в том числе если пользователь поменял видеокарту. Хардкодное прописывание режимов дисплея (или другого железа) это не очень хорошо.

Не одобряю однозначно.

Добавил - где кстати, частота обновления экрана? Почему только размеры и цветность?

На счёт "Окончательно" ты прав, в более продвинутых проектах делается всё динамично. Но пока это для меня гремучий лес...

З.Ы.
Я не кричу, что создаю супер-проект... Зачем. Я просто конкретно практикуюсь в этой области, создавая этот проект. В дальнейшем и эту тему я затрагиваю. А пока принцип создания окна, анимации, гуи...

А с частотой я ещё не возился...

Частота, размер окна и цветность получаетя одной и той же функцией, надо только указать что именно получать. Также можно установить минимальный порог, например цвет 16 и окно допустим 600 на 480. Делается это дело может быть за час или за два. Потом надо просто отсортировать массив по трем параметрами и у тебя будет список режимов.

Советую такое сделать если не сейчас то потом. Поскольку пользователи обычно ленивые и им лень разбираться что и как после смены компьютера или железа, к тому же человек может хотеть играть на GeForce 4 поколения например...

Через API да, будет тяжеловато и там факт потребуется сортировка.

Насчет ДХ я не в курсе, я с ГЛ работаю.

Через АПИ несложно, сортировка тоже легко делается. Не слышал чтобы ДХ использовали для этих целей, обычно получают данные через ВинАПИ о режимах дисплея, которые поддерживаются системой в данный момент времени. Окно программы для получения этих данных можно не иметь вообще,
то есть сперва получешь всю информацию, потом либо берешь данные из настроек (проверив на месте ли железо или его поменяли и т.д.), либо берешь новые данные от АПИ и задаешь параметры перед тем как создать окно, либо для смены режима, если окно уже есть.

Я же не утверждаю, что тяжело... Ты имеешь в виду захватить инфу о железе, потом предложить подходящие параметры... Да, я этот момент "зубрю", но для проекта 2D движка стратегий в не изометрии, я думаю ни к чему...

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

You decide =)

Но то, что ты мне привёл, я возьму на заметку, в принципе, через винапи узнавать инфушку, этим я не задавался...

To you plus :+)

Попрошу не закрывать тему, она актуальна, пусть даже проект заморожен.

Тех, кого интересует, что нужно для проекта, это:
1. Совмещение (TCanvas "BCB") с DX9 и OpenGL. Может показаться странно, но кое что у меня уже получилось, но медленно.
2. Поворот некой части массива из TCanvas->Pixels на нужный градус. Эта тема очень сильно сложна, так как доступ к массиву этого класса медлен. Может я, просто, не знаю некие функции с BCB API, которые решают эти задачи.
3. Алгоритм A*. Ну описания по нему у меня есть, только немного до меня не дойдёт. Всё ровно, найду более подробное описание поиска пути по этому алгоритму.

Ну и далее, я думаю, что смогу найти ответы.

Проект живёт, и я его завершу. Кстати, скоро будет год, как я им занимаюсь...

Просто не смотрится он...
Оставляет ощущение недоделки и т.д. ИМХО конечно...
Не очень приятная расцветка...
Зелёный - скучный цвет...
Лучше использовать кремовый/светло-голубой...
И полностью переделать шапку... (она просто ужасна)
Вроде всё...

Добавлено (09.11.2010, 14:57)
---------------------------------------------
Да и залезающий на узоры текст - это не красиво...

Я: О великий повелитель этой ничтожной вселенной - сокращённо ЁЖ!

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