Strange Wood
Модератор: Jolly Roger
-
- Сообщения: 59
- Зарегистрирован: 11 мар 2007, 13:21
- Откуда: Беларусь, Минск
- Контактная информация:
Заценил только что.
1) Скрол действительно странный. Лучше сделать, к примеру, постоянное центрирование.
2) Рисуй сначала в буффер, а потом отрисовывай его на форме. Тогда не будет этого мигания экрана.
3) Тайлы хороши только тогда, когда они нормально сделаны. Так что лучше основательно подумать, прежде чем делать графику. Как по мне, ASCII будет лучше смотреться (хотя это тебе решать).
1) Скрол действительно странный. Лучше сделать, к примеру, постоянное центрирование.
2) Рисуй сначала в буффер, а потом отрисовывай его на форме. Тогда не будет этого мигания экрана.
3) Тайлы хороши только тогда, когда они нормально сделаны. Так что лучше основательно подумать, прежде чем делать графику. Как по мне, ASCII будет лучше смотреться (хотя это тебе решать).
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Иногда случается так, что при перемещении по вертикали врубается горизонтальный скроллинг, и наоборот.
А при перегенерации уровня скроллинг вообще не врубается. По крайней мере, в подземелье.
И если ты не используешь собственный генератор (делфовский конгруэнтный мультипликативный, надо заметить, рулит не всегда), то поставь randomize; В противном случае, напиши свой randomize и вставь.
А при перегенерации уровня скроллинг вообще не врубается. По крайней мере, в подземелье.
И если ты не используешь собственный генератор (делфовский конгруэнтный мультипликативный, надо заметить, рулит не всегда), то поставь randomize; В противном случае, напиши свой randomize и вставь.
Dump the screen? [y/n]
Отвечаю по порядку
2) настройка клавиш управления предусмотрена, но интерфейс для нее пока не реализован
2) Двойная буферизация планируется после перехода на SDL. Собственно, этот переход я уже начал, но для этого надо довольно серьезно переработать главный модуль игры.
3) Ну да, художник из меня от слова "худо" . Буду брать готовые тайлы. К слову, кто-нибудь может посоветовать тайлы 24х24? На RLTiles только 32х32.
Вот, этот топик уже начал приносить реальные результаты, для чего я его вообще затеял. Спасибо!
1) На моем ноутбуке, где ведется разработка, нет нумпада;А я бы предложил юзать нумпад, стрелки и цифры.
2) настройка клавиш управления предусмотрена, но интерфейс для нее пока не реализован
1) Скролл уже частично доработан. Насчет центрирования буду думать.1) Скрол действительно странный. Лучше сделать, к примеру, постоянное центрирование.
2) Рисуй сначала в буффер, а потом отрисовывай его на форме. Тогда не будет этого мигания экрана.
3) Тайлы хороши только тогда, когда они нормально сделаны. Так что лучше основательно подумать, прежде чем делать графику. Как по мне, ASCII будет лучше смотреться (хотя это тебе решать).
2) Двойная буферизация планируется после перехода на SDL. Собственно, этот переход я уже начал, но для этого надо довольно серьезно переработать главный модуль игры.
3) Ну да, художник из меня от слова "худо" . Буду брать готовые тайлы. К слову, кто-нибудь может посоветовать тайлы 24х24? На RLTiles только 32х32.
Сорри, я про него забыл совершенно. Спасибо!поставь randomize
Вероятно, из-за того, что герой оказывается в толще камня. Генератор подземелья был сделан просто в качестве упражнения. Пока я еще не решил, будет ли он оставлен в дальнейшем.А при перегенерации уровня скроллинг вообще не врубается. По крайней мере, в подземелье
Вот, этот топик уже начал приносить реальные результаты, для чего я его вообще затеял. Спасибо!
Первая заповедь фотолюбителя: Проявил себя - закрепи!
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Меняй. Генератор хреновый, прости, конечно, за откровенность. Поковыряйся в сырцах основных проектов — найдёшь для себя много интересных мыслей. Я тоже выкладывал пару генераторов с исходниками, как раз для Дельфы. В любом случае, одним единственным генератором ты всё равно не отделаешься.Dmiry писал(а): 2) Двойная буферизация планируется после перехода на SDL. Собственно, этот переход я уже начал, но для этого надо довольно серьезно переработать главный модуль игры.[/qoute]
Не уверен, что SDL — оптимальный вариант. Если не планируешь кроссплатформенности (а судя по языку разработки ты её не планируешь), то оптимально будет DirectX, конкретно под Direct 3D. Понятно, что никакого 3D у тебя и близко не намечается, но гарантий, что Мелкософт не вырежет давно уже не поддерживаемый DirectDraw в ближайшей версии нет.
Dmiry писал(а): 3) Ну да, художник из меня от слова "худо" . Буду брать готовые тайлы. К слову, кто-нибудь может посоветовать тайлы 24х24? На RLTiles только 32х32.[/qoute]
Adobe Photoshop. Batch в случае большого числа файлов и банальный Image Size в случае одного файла. В идеале — состроить глазки девушке с ближайшего худграфа, потому что лично мне стандартные тайлы уже потихоньку набивают оскомину — лучше уж ASCII.
Dmiry писал(а): Вероятно, из-за того, что герой оказывается в толще камня. Генератор подземелья был сделан просто в качестве упражнения. Пока я еще не решил, будет ли он оставлен в дальнейшем.
Dump the screen? [y/n]
- Alchemist
- Мастер
- Сообщения: 203
- Зарегистрирован: 13 дек 2006, 09:15
- Откуда: Нижний Тагил, Иваново
- Контактная информация:
Максим, SDL - оптимальный вариант. И Delphi - здесь не помеха, т.к. этот проект потом с элементарными доработками, а то и без них, можно будет скомпилить на FreePascal. Я думаю ни у кого не возникнет сомнений, что проект, перенесенный на FP сразу станет не намного менее кроссовым, чем на C++. И еще - твое мнение о DirectX устарело, почитай технические статьи про Висту: были упоминания от Microsoft, что они через несколько лет намерены сами отказаться от DirectX. У них уже появились какие-то наработки нового поколения, причем, что интересно - усиливаются связи с их стороны с OpenGL. Разумеется это не означает, что они в один момент прекратят поддержку DirectX, но в дальнейшем он будет заменен новой технологией.Максим Кич писал(а):Dmiry писал(а): 2) Двойная буферизация планируется после перехода на SDL. Собственно, этот переход я уже начал, но для этого надо довольно серьезно переработать главный модуль игры.[/qoute]
Не уверен, что SDL — оптимальный вариант. Если не планируешь кроссплатформенности (а судя по языку разработки ты её не планируешь), то оптимально будет DirectX, конкретно под Direct 3D. Понятно, что никакого 3D у тебя и близко не намечается, но гарантий, что Мелкософт не вырежет давно уже не поддерживаемый DirectDraw в ближайшей версии нет.
- Максим Кич
- Администратор
- Сообщения: 1642
- Зарегистрирован: 03 дек 2006, 20:17
- Откуда: Витебск, Беларусь
- Контактная информация:
Блин... Отстал от жизни Значит, пора и мне на SDL перебираться.Alchemist писал(а): Максим, SDL - оптимальный вариант. И Delphi - здесь не помеха, т.к. этот проект потом с элементарными доработками, а то и без них, можно будет скомпилить на FreePascal. Я думаю ни у кого не возникнет сомнений, что проект, перенесенный на FP сразу станет не намного менее кроссовым, чем на C++. И еще - твое мнение о DirectX устарело, почитай технические статьи про Висту: были упоминания от Microsoft, что они через несколько лет намерены сами отказаться от DirectX. У них уже появились какие-то наработки нового поколения, причем, что интересно - усиливаются связи с их стороны с OpenGL. Разумеется это не означает, что они в один момент прекратят поддержку DirectX, но в дальнейшем он будет заменен новой технологией.
Dump the screen? [y/n]
- Alchemist
- Мастер
- Сообщения: 203
- Зарегистрирован: 13 дек 2006, 09:15
- Откуда: Нижний Тагил, Иваново
- Контактная информация:
У себя я уже сделал первичный порт игры на SDL. Кривой, признаюсь, довольно сильно (знания пока не хватает), но кое-как работает. А со временем собираюсь все больше усиливать поддержку и, возможно, перейду с концами на эту библиотеку, т.к. самому поддерживать кроссплатформенную поддержку графики и прочего довольно тяжело, элементарно времени на выяснение деталей и отладку не хватает. Разве что звук наверное все-же оставлю на fmod'е. Базовая разработка и компиляция под винду делается на Delphi, а все остальное - на FreePascal и Kylix (но этот устарел уже безвозвратно).Максим Кич писал(а):Блин... Отстал от жизни Значит, пора и мне на SDL перебираться.
Хм... У меня тоже не получилось. Тогда придется подождать небольшое время, пока доделаю переход на новую граф библиотеку. Надеюсь, в начале следующей недели уже будет работоспособная версия.BreakMT писал(а):Почему то не могу скачать твою демку...
Первая заповедь фотолюбителя: Проявил себя - закрепи!
26.06.07
Думаю, как лучше сделать просмотр инвентаря. По логике, это прерогатива паинтера. То есть вызываем метод Painter.DrawInventory. После этого надо опять опросить клавиатуру на предмет следующего действия - либо просмотр инвентаря с листанием предметов, либо закрытие, либо выбор предмета для выполнения какого-либо действия (бросание, использование, надевание, и т.д.).
Наверное, пока сделаю отдельным окном. Или панелью.
Проверил работу установщика атрибутов для предмета (тип повреждения, способ использования) - работает. Надо еще проверить, работает ли сброс бита атрибута и получение его значения.
Решил все-таки переходить на SDL. А то имеющийся вид предметов навевает уныние.
27.06.07
Надо переделать скроллинг. Общее правило - прокрутка выполняется только в требуемом направлении. Сейчас при необходимости прокрутки герой просто центрируется. Вроде сделал получше, но мне все равно не нравится. Посмотрим еще. Надо посмотреть, как прокрутка работает в других рогаликах.
Другая нужная переделка - вынести всю инициализацию и финализацию графики в отдельные методы паинтера. Кроме того, надо оформить методы начала новой игры и завершения текущей.
Делаю SDL. Основные вещи переделал, программа запускается. Но обнаружил, что SDL создает свое собственное отдельное окно. И что теперь делать с главным окном? Придется сразу разбираться, как обрабатывать сообщения от клавиатуры (хотел оставить на попозже). Для образца возьму KySoko - проект в исходниках на C++. Реализует Сокобан, что мне в принципе полностью подходит - пошаговость, тайловая, управление с клавиатуры.
Пришел к следующему: убираю из программы модуль Main, содержащий главную форму. Вместо него делаю модуль Game, в котором будет собрана вся функциональность игры. В файле проекта оставляю только инициализацию графики, и вывод игрового меню. Думаю меню сделать в стиле IVAN. При выборе пункта "Новая игра" или "Загрузить" вызывается соответствующий метод в модуле Game.
Думаю, как лучше сделать просмотр инвентаря. По логике, это прерогатива паинтера. То есть вызываем метод Painter.DrawInventory. После этого надо опять опросить клавиатуру на предмет следующего действия - либо просмотр инвентаря с листанием предметов, либо закрытие, либо выбор предмета для выполнения какого-либо действия (бросание, использование, надевание, и т.д.).
Наверное, пока сделаю отдельным окном. Или панелью.
Проверил работу установщика атрибутов для предмета (тип повреждения, способ использования) - работает. Надо еще проверить, работает ли сброс бита атрибута и получение его значения.
Решил все-таки переходить на SDL. А то имеющийся вид предметов навевает уныние.
27.06.07
Надо переделать скроллинг. Общее правило - прокрутка выполняется только в требуемом направлении. Сейчас при необходимости прокрутки герой просто центрируется. Вроде сделал получше, но мне все равно не нравится. Посмотрим еще. Надо посмотреть, как прокрутка работает в других рогаликах.
Другая нужная переделка - вынести всю инициализацию и финализацию графики в отдельные методы паинтера. Кроме того, надо оформить методы начала новой игры и завершения текущей.
Делаю SDL. Основные вещи переделал, программа запускается. Но обнаружил, что SDL создает свое собственное отдельное окно. И что теперь делать с главным окном? Придется сразу разбираться, как обрабатывать сообщения от клавиатуры (хотел оставить на попозже). Для образца возьму KySoko - проект в исходниках на C++. Реализует Сокобан, что мне в принципе полностью подходит - пошаговость, тайловая, управление с клавиатуры.
Пришел к следующему: убираю из программы модуль Main, содержащий главную форму. Вместо него делаю модуль Game, в котором будет собрана вся функциональность игры. В файле проекта оставляю только инициализацию графики, и вывод игрового меню. Думаю меню сделать в стиле IVAN. При выборе пункта "Новая игра" или "Загрузить" вызывается соответствующий метод в модуле Game.
Первая заповедь фотолюбителя: Проявил себя - закрепи!
9.07.07
Слегка повис. Решил в качестве первоочередной задачи при переходе на SDL реализовать вывод карты. Обработку клавиатуры сделаю позже. Сейчас - переписать инициализацию, обеспечить вывод карты.
После первой попытки переделать не заработало. Сейчас сделаю отдельный проект, посмотрю, как надо выводить картинку. Есть подозрение, что не отрабатывает загрузка изображений из файла.
Исправил. Загрузка отрабатывала, некорректно выполнялся вывод глифа на поверхность для отрисовки.
Дальше надо сделать меню. Озадачился - как выполняется вывод текста средствами SDL? Судя по ресурсам IVAN - каждая буква как картинка. Хочу что-нибудь более простое. Если не найду - придется делать так же. На первое время решил использовать готовые картинки для меню.
Пока делал меню, обнаружил, что перемешан код, отвечающий за инициализацию игры: загрузку ресурсов, переход в граф.режим и т.д. Думаю, как лучше все это структурировать. По идее, инициализацию графики надо полностью вынести в паинтер. Лучше всего проводить инит вместе с инитом паинтера. Загрузка ресурсов выполняется в том месте, где эти ресурсы необходимы. Т.е. глифы - опять таки в паинтере, определения клавиш управления - в главном цикле игры (или нет?).
10.07.07
Сегодня буду делать обработку клавиатуры средствами SDL. Главное меню оставлю на попозже. Фактически надо реализовать главный игровой цикл, в котором опрашивается клавиатура, нажатая клавиша переводится во внутреннее представление, и выполняется соответствующее действие.
16.07.07
Так и застрял на обработке клавиатуры. Думаю, надо ли выносить обработку клавиатуры в отдельный класс (или как вариант, в модуль низкоуровневой работы - экран, клавиатура).
Для меню подготовил картинки для обычного элемента меню и выделенного элемента. Теперь надо прописать код загрузки этих изображений. Сделаю двумерный массив 4х2. Первая координата - номер пункта меню, вторая - состояние пункта (обычный/выделенный).
Перенес инициализацию паинтера в тело основной программы. При создании класса паинтера теперь инициализируется SDL, загружаются необходимые изображения и выполняется прочая подготовка.
Решил меню немного отложить, сначала добьемся перемещения героя по карте.
Слегка повис. Решил в качестве первоочередной задачи при переходе на SDL реализовать вывод карты. Обработку клавиатуры сделаю позже. Сейчас - переписать инициализацию, обеспечить вывод карты.
После первой попытки переделать не заработало. Сейчас сделаю отдельный проект, посмотрю, как надо выводить картинку. Есть подозрение, что не отрабатывает загрузка изображений из файла.
Исправил. Загрузка отрабатывала, некорректно выполнялся вывод глифа на поверхность для отрисовки.
Дальше надо сделать меню. Озадачился - как выполняется вывод текста средствами SDL? Судя по ресурсам IVAN - каждая буква как картинка. Хочу что-нибудь более простое. Если не найду - придется делать так же. На первое время решил использовать готовые картинки для меню.
Пока делал меню, обнаружил, что перемешан код, отвечающий за инициализацию игры: загрузку ресурсов, переход в граф.режим и т.д. Думаю, как лучше все это структурировать. По идее, инициализацию графики надо полностью вынести в паинтер. Лучше всего проводить инит вместе с инитом паинтера. Загрузка ресурсов выполняется в том месте, где эти ресурсы необходимы. Т.е. глифы - опять таки в паинтере, определения клавиш управления - в главном цикле игры (или нет?).
10.07.07
Сегодня буду делать обработку клавиатуры средствами SDL. Главное меню оставлю на попозже. Фактически надо реализовать главный игровой цикл, в котором опрашивается клавиатура, нажатая клавиша переводится во внутреннее представление, и выполняется соответствующее действие.
16.07.07
Так и застрял на обработке клавиатуры. Думаю, надо ли выносить обработку клавиатуры в отдельный класс (или как вариант, в модуль низкоуровневой работы - экран, клавиатура).
Для меню подготовил картинки для обычного элемента меню и выделенного элемента. Теперь надо прописать код загрузки этих изображений. Сделаю двумерный массив 4х2. Первая координата - номер пункта меню, вторая - состояние пункта (обычный/выделенный).
Перенес инициализацию паинтера в тело основной программы. При создании класса паинтера теперь инициализируется SDL, загружаются необходимые изображения и выполняется прочая подготовка.
Решил меню немного отложить, сначала добьемся перемещения героя по карте.
Первая заповедь фотолюбителя: Проявил себя - закрепи!
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 45 гостей