Luke Benstead - Beginning OpenGL Game Programming, Second Edition ( ISBN10:159863528X; ISBN13:9781598635287) Course Technology PTR 2009

Там написано о принципах?

Перечитай тред.

Какашками на кидать

Щас накидают, раз просишь.

Не знаю, я эту книгу не читал. Первое, что нагуглилось.

Позовите вылдродня, он вам всё расскажет.

//каждую неделю одна и та же тема.

Мне не нужны маны по opengl, я хочу маны по построению игры. :)

Что-то ты не с той стороны подходишь к вопросу.

В смысле? А как надо? У меня есть идея, хочу понять как надо её не через жопу реализовать.

я же уже создавал точно такой же тред

Т.е вообще особо принципов нету?

Для начала почитай про game loop.

Разве что чисто технического характера. Рисовать побыстрее, данные по сети передавать покомпактнее.

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

А тогда что почитать по opengl 2d и С?

TARGET=this.thread
Какашками на $TARGET кидать

Тут все расписали уже.

В смысле openGL 2d в С.

Опять же нужен арт

Учится можно (нужно) на рогаликах.

Да хватит уже игр под линукс!!!

Да хватит уже игр под линукс!!!

Они тебя беспокоят? Хочешь об этом поговорить?

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

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

чувак, с твоими умственными способностями, да еще и на си, да еще и с opengl - не мучай себя

А что не так то?

Тут как с программированием, начать надо с хеллоувордов.
1. Сапер.
2. Тетрис.
3. Жалкое подобие марио.
Если будешь двигаться именно в этой последовательности, книжки тебе не понадобятся.

После этого можешь начать воплощать свою идею, попутно читая хорошие статейки про геймдиз. Но это все потом.

И да, дальнейшие вопросы лучше задавать где-нибудь здесь http://www.gamedev.ru

Спасибо. :)

пауза для экономии ресурсов и поддержания стабильного фпс

Вот это по-моему (и не только, но пруфов не будет) нехорошо, вместо этого нужно писать событийно-ориентированый код, чтобы ОС вызывала некую функцию только при поступлении внешних раздражителей (callback function в терминах винапи?), правда не знаю как все это реализуется в линуксах..

Таймеры у ОС неточные, всё равно надо цикл гонять. И даже если мы сами цикла не видим, значит он спрятан внутри используемого фреймворка.

делаешь бесконечный цикл, в котором последовательно:

-опрашиваются клавиатура и мышь
-обсчитывается модель ИИ
-посылаются пакеты по сети туда-сюда, если мультиплеер
-рисуется и рендерится графика
-проигрывается звук

вкратце так :)

за подробностями на gamedev.ru если оно еще живое

а есть же готовые программы для создания игр, Basic3D вроде называлась одна.

Берем cocos2d-x, проходим уроки, пытаемся написать игру.

Накидайте манов по теории создания игры

Game Coding Complete, Third Edition.
Не обращай внимание на то, что в книге используется Оффтопик32 API и DirectX. Книга достаточно годная.

sleep(x) а чему должен равняться икс?

по другому никак: или ты будешь впустую сьедать слишком много тактов, или пропустишь нужные события, все зависит от производительности системы тоже..

Да и в наш век энергопотребление не пустой звук..

http://www.gamedev.ru/projects/forum/?id=8221

sleep(x) а чему должен равняться икс?

1/(предполагаемый FPS) минус время, затраченное на отрисовку предыдущего кадра. Нужно также обработать ситуацию, когда это значение выходит отрицательным, для этого может применяться пропуск кадров или другие техники.

Можно (и нужно в качестве опции), конечно, воспользоваться vsync, но на некоторой части конфигураций это может привести к заметному лагу между вводом и его обработкой, что не прибавляет играбельности.

посылаются пакеты по сети туда-сюда, если мультиплеер

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

так _не делают_, пусть кто больше в теме программинга объяснят почему..

В последнее время стало возможным получать профит из выкидывания некоторых задач геймлупа в отдельные потоки. Но это частности.

не представлю как должно работать в общем

Что конкретно? Там представлять-то особо нечего. Тем более, если игра 2d.

стоит вникнуть в openGL

И да, смотри в сторону SDL.

Все нужные игры уже были написаны.

пшол нахоооой

чмо бля

напиши свой roguelike

Лучше пойди и напиши патч для minetest или какой нибудь плугин.
Благо там реально простой код, заодно скилл прокачаешь.

Да хоть 10 - 2000 fps, никаких проблем, многопоточность и распределённый подсчёт времени от таймера всё синхронизируют. Другой вопрос что >1000 fps не нужно, время удобно измерять в миллисекундах. Их в секунде примерно столько, сколько пикселей на экране, поэтому халявно считать: начальная координата + миллисекунды прошедшие с момента начала движения * коэффицент скорости = текущая координата объекта. Время от времени нужно делать паузы >=2 миллисекунды чтобы линукс успел посчитать другие задачи. Но если fps или производительность железа будут низкими, рисоваться будет как скриншоты.

Да и в наш век энергопотребление не пустой звук..

Тогда будет игра только для ПК, консоли, планшеты и телефоны получат «подарок».

sdltutorials.com

Спасибо всем большое, может что слеплю.. :)

Я не понял в чем я не прав? то о чем я твержу это почти стандартный подход в написании любых приложения, как минимум под винду.. а еслиб весь софт гонял бы в циклы по своему усмотрению, все бы тормозило и грелось. Я не спорю что программы в конце концов работают циклично, потому и не завершаются, но если например у вас есть окно и на нем выводится статичная картинка, стоит ли перерисовывать ее каждые 100мс, или же нужно дать ОС решить когда тебя перекрыли и пусть вызывает функцию только тогда? конечно второй подход..

Вот только под линуксом не идут.

Все нужные игры были написаны под дос :)

Я не понял в чем я не прав? то о чем я твержу это почти стандартный подход в написании любых приложения, как минимум под винду..

В идеале программа должна хорошо работать в широком диапазоне фпс. Можно работать со временем записанным нецелым числом и ничего не параллелить, дело автора, можно делать и так и так.

а еслиб весь софт гонял бы в циклы по своему усмотрению, все бы тормозило и грелось.

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

но если например у вас есть окно и на нем выводится статичная картинка, стоит ли перерисовывать ее каждые 100мс, или же нужно дать ОС решить когда тебя перекрыли и пусть вызывает функцию только тогда?

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