Comments 17
Вопрос по пункту «Почему SDL?»: а почему не HGE? Это уже готовый движок, а так же он еще проще и быстрее в освоении, после чего можно опускать гору кода и приступать сразу ко второй части. И просьба автору убрать код под кат. Спасибо.
+1
SDL портирован под Android/iOS, и он не умер 5 лет назад :)
+3
А можно вас попросить поподробнее об этом написать? А еще бы круче статейку
-12
HGE часто рекомендуют как С++ 2D Engine для начинающих на форумах по геймдеву. Для статьи смысла особого нет, так как он хорошо документирован, есть демки и собственный форум. Основан на DirectX 9, поэтому только под винду. Но нет шейдеров. Встроенный звук на bass.dll не подходит для коммерческих проектов из-за лицензии. А так прост и красиво сделан. Больше подробностей смотрите на оффициальном сайте.
+1
Еще есть SFML, чуть приятнее чем SDL.
0
а чем приятнее? В чем отличия идут?
0
Говорят, что SDL более стабилен на других платформах. Но у SFML приятный и простой ООП код. Каких-то радикальных отличий, кажется, нет. Т.е. если для себя поиграться, то я бы выбрал SFML, если на production, то SDL.
0
Раньше пробовал написать простое графическое приложение VC++ с очень плохим примером, который порекоммендовал один знакомый «специалист». Пример работал, но сложность этого примера не позволяла совершенствоваться дальше и интерс сразу был похоронен в горе рутинного обязателъного кода.
Эту статью открыл чисто из любопытства и поразила именно простота кода. Куда уж проще.
Эту статью открыл чисто из любопытства и поразила именно простота кода. Куда уж проще.
0
Такое же есть в примерах DirectX11 от Microsoft, увидел интересную фичу — долго разбираешь кучу классов и полуиндусский код. Насколько помню — никогда не хватало силы воли разбирать всю ненужную фигню, которую потом все равно никак не запихаешь в проект тупо из-за отсутствия расширяемости
P.S. Нифига себе, земляк из одного города 0_о
P.S. Нифига себе, земляк из одного города 0_о
0
18 March 2008 — последний релиз HGE 1.81
11 August 2013 — SDL 2.0.0
SDL поддерживается Valve, и на нем сделано множество прекрасных современных игр, например любимая FTL или Mark of Ninja. И да, это скорее библиотека а не фреймворк или движок, который абсолютно ничего не навязывает а только дает средства для кросс платформенного импорта текстур, обработки управления, создания графических контекстов и т.п. Лично мне больше нравится SFML, но SDL очень достойный выбор
11 August 2013 — SDL 2.0.0
SDL поддерживается Valve, и на нем сделано множество прекрасных современных игр, например любимая FTL или Mark of Ninja. И да, это скорее библиотека а не фреймворк или движок, который абсолютно ничего не навязывает а только дает средства для кросс платформенного импорта текстур, обработки управления, создания графических контекстов и т.п. Лично мне больше нравится SFML, но SDL очень достойный выбор
+1
необходимо использовать многобайтную кодировку символов
шел 2013 год…
+7
Статья должна называться «Смотрите, я про SDL узнал». На туториал не тянет в первую очередь по качеству.
Вы видимо SDL1.2 используете? Очень рекомендую посмотреть в сторону SDL2. Аппаратное ускорение графики и переработанный интерфейс больше подходят для игр.
Прям вредный совет какой-то. SDL кроссплатформенна, поэтому и код не должен быть зависим от винды. Если бы вы использовали исключительно виндовые вещи, тогда всё понятно, но у вас один main (MessageBox не в счёт). Создайте консольное приложение и main будет стандартным, а лучше использовать SDL_Main для SDL1.2. И консолька не время разработки будет полезна. В SDL2 main надо писать обычный сишный. Макросы всё правильно разберут на каждой платформе.
Вы видимо SDL1.2 используете? Очень рекомендую посмотреть в сторону SDL2. Аппаратное ускорение графики и переработанный интерфейс больше подходят для игр.
#include <Windows.h>
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int)
{
return 0;
}
Прям вредный совет какой-то. SDL кроссплатформенна, поэтому и код не должен быть зависим от винды. Если бы вы использовали исключительно виндовые вещи, тогда всё понятно, но у вас один main (MessageBox не в счёт). Создайте консольное приложение и main будет стандартным, а лучше использовать SDL_Main для SDL1.2. И консолька не время разработки будет полезна. В SDL2 main надо писать обычный сишный. Макросы всё правильно разберут на каждой платформе.
+10
Полностью поддерживаю, ужасная статья про одну из лучших библиотек! Мне вообще интересно, что сам автор думает про его цикл обработки событий? ))) А вообще думаю что на текущий момент SDL2 лучшая многоплатформенная библиотека, и нужно начать было с того так ее собрать, под разные платформы, разными компиляторами, как потом ее подключать, статически, динамически и т.д. И потом можно было бы сделать целый цикл отличных статей. А так это ужас.
+1
*некропост*
Спасибо, покажите ваш цикл обработки событий. На мой взгляд, у меня все логично в классе Input
Спасибо, покажите ваш цикл обработки событий. На мой взгляд, у меня все логично в классе Input
-1
Читаем документацию про SDL_PollEvent — и там видим — что данная функция забирает событие из очереди, и в зависимости от того, есть ли в очереди еще события возвращает 1 или 0. Поэтому цикл:
«Проглотит» все события а самое последнее останется скопировано в «evt», что показывает полное непонимание как работать с событиями вообще.
А должно быть на псевдокоде как-то так:
while(SDL_PollEvent(&evt));
«Проглотит» все события а самое последнее останется скопировано в «evt», что показывает полное непонимание как работать с событиями вообще.
А должно быть на псевдокоде как-то так:
while(SDL_PollEvent(&evt))
{
switch(InputEventType(evt))
{
case INPUT:
ProcessInputHandler(evt);
break;
case ...
default:
DefaultEventHandler(evt);
}
}
+1
Я бы порекомендовал вам изменить содержимое метода Execute:
— внутри метода инициализировать вспомогательные объекты — я бы инициализацию вынес либо в отдельный метод (e.x. Init);
— зачем вам возвращаемый тип int? Если для функции main, то у вас внутри никаких проверок нет на NULL (или исключения). И потому вы всегда возвращаете 0;
— тоже самое касательно delete. Либо в деструктор, либо куда-нибудь ещё.
— внутри метода инициализировать вспомогательные объекты — я бы инициализацию вынес либо в отдельный метод (e.x. Init);
— зачем вам возвращаемый тип int? Если для функции main, то у вас внутри никаких проверок нет на NULL (или исключения). И потому вы всегда возвращаете 0;
— тоже самое касательно delete. Либо в деструктор, либо куда-нибудь ещё.
+1
Sign up to leave a comment.
Пишем игры на C++, Часть 1/3 — Написание мини-фреймворка