Войти
ПроектыФорумУтилиты

Движок 'Сухарь Ванильный' (3 стр)

Страницы: 1 2 3 4 562 Следующая »
#30
1:47, 15 ноя. 2012

Viaceslav(C)
Есть предложения лучше?


#31
2:02, 15 ноя. 2012

CStalker
> Есть предложения лучше?
Таймер использовать запретили? :)

#32
2:20, 15 ноя. 2012

Viaceslav(C)
А зачем таймер? Организуется бесконечный цикл, количество прошедшего времени получается через GetTickCount(), с помощью Sleep() снижается нагрузка на проц. Просто и надежно. Разрешения в 16 миллисекунд вполне хватает для реализации игровой логики в большинстве игр.

#33
2:32, 15 ноя. 2012

cNoNim
> это все конечно весело и хорошо, тока я отказался от такого подхода, потому что
> он ну ни чем не будет отличаться от варианта с таймером
> а суть варианта в том что бы засекать время с начала кадра и засыпать на время
> оставшееся до нужной нам частоты
> и проблема как бы в том что в ручную ты делаешь практически то же самое, но ОС
> это будет делать оптимальней
имхо это не то место, где надо выжимать оптимальность
твой вариант тоже вполне жизнеспособен

> + ты наверняка пока не проверяешь поступление
> сообщений в очередь, а почему бы этого не делать? ведь получается они
> накапливаются, и после того как ты выходишь из цикла приходится тратить
> процессорное время на их обработку, хотя можно было тоже самое сделать в то
> время пока процесс спал
у меня сама игра в одном потоке, а окно с очередью - в другом
причем очередь для окна обрабатываю не я - это за меня делает сторонняя гуишная библиотечка

#34
2:36, 15 ноя. 2012

ASD
> Клевое название !!
Сухарь, потому что софтовый. А ванильный, потому что такой тёплый и ламповый! :)

cNoNim
> MsgWaitForMultipleObjects
> преимущество этой функции над Sleep только одно, она позволяет обрабатывать
> сообщения по их поступлению а не ждать пока закончится Sleep
> а точность у таймеров и sleep примерно одинаковая
Ага, это уже интереснее. Проверю на практике, спасибо.

Mikle
> Sleep(1) выполняется 16.666 мс
Вероятно, это касается и функции, про которую выше.

-------------

Значит, пока думаю сделать так:
а) TimeBeginPeriod() не использовать. Так как лучше надёжность и предсказуемость.
б) Вызывать Sleep(x), только если x больше 16 милисекунд.
в) На всякий случай ополовинивать x (ожидание в милисекундах). На тот случай, если Sleep(x) вернёт управление позже, чем я просил.

Ну, и в итоге принцип освобождения времени процессора такой:
__0) проверяю в цикле по таймеру, пришло ли время для одной из функций пользователя. (Для начала, сделаю три таких функции со своими частотами вызова)
__1) когда пришло, вызываю функцию пользователя.
__2) смотрю по таймеру, сколько времени (х) после её выполнения осталось до следующего вызова ближайшей функции из трёх.
__3) Вызываю Sleep(x/2), после чего иду на шаг (0)

Как думаете, достаточно стабильно? Какие минусы у такого подхода? Я пока вижу один минус: процессор будет освобождаться не полностью. Так как не Sleep(x), а Sleep(x/2). Процессор будет сильнее загружен, чем мог бы быть. Но одновременно и плюс: не будет подёргиваний из за того, что Sleep вернул управление позже.

-------------

Viaceslav(C)
Не тупи, обсуждаем про освобождение процессорного времени. :)

soflot
> скажи, а ты движок переписываешь просто ради удовольствия, или ты на нём игры
> собираешься делать?
Ну, дык! На прошлом своём движке я несколько игр написал. Конечно же, новый пишу для них тоже.

> И может быть тебе стоит более чётко сформулировать какие конфигурации машин ты
> собираешься поддерживать?
И прошлый двиг, и этот - будут поддерживать всё, начиная с i486. Дело в том, что всё зависит от разрешения и от использования движка. Вполне можно на нём написать игру в классическом для 486 разрешении 320*200(240), и эта игра будет там летать.

Sasha7b9
> Блин, у тебя такие игры крутые вышли, что даже неловко такие вопросы слышать.
> Откуда неровному движению возникнуть?
Тем не менее, на тестах неровное движение возникало. Вероятно, от погрешности Sleep'а, который возвращал управление не вовремя.
Тут многое зависит от ОС, кстати.

CStalker
> Разрешения в 16 миллисекунд вполне хватает для реализации игровой логики в
> большинстве игр.
Беда в том, что не на каждой ОС и железе выполняются эти 16 мс. Как я уже говорил, мои тесты вот такое показали. А я хочу надёжности. Никому же не будет приятно, когда будет релиз игры, от 5% игроков получить сообщения в духе: у меня подёргивания в графике.

#35
2:43, 15 ноя. 2012

sb3d
у тебя есть привязка к фпс?

#36
2:46, 15 ноя. 2012

CStalker
> у тебя есть привязка к фпс?
Те три функции пользователя, про которые речь в пункте __0), они вызываются каждая со своим фпс. И эту частоту пользователь может устанавливать и менять сам. К примеру, свою лёгкую физику пользователь сможет вызывать 100 раз в секунду, а тяжёлое обновление экрана 24 раза в секунду.

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

#37
2:49, 15 ноя. 2012

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

#38
2:56, 15 ноя. 2012

CStalker
Пользователь движка сможет это всё реализовать и так.

а) Он может установить частоту вызова функции сам. Хоть 500 фпс.
б) Он имеет доступ к таймеру, движок (теперь) предоставляет это.
в) Он (теперь) всегда сам вызывает функцию обновления экрана\окна.

Поэтому пользователь сможет удобно рассчитывать игру 500 раз в секунду, и _сам_ с нужной частотой вызывать перерисовку экрана.

Кстати, интересный момент. Всего этого не было в прошлом движке. То есть перерисовку экрана движок вызывал сам. Что выливалось в неудобство управления. Например, при долгой загрузке файла пользователь не мог перерисовать прогрессбар, просто вызвав функцию вывода картинки на экран. Из за этого можно наблюдать, как грузится мой последний проект, и как генерируется карта: без обновления экрана, без прогресс бара.

Так что уже лучше, чем было.

#39
4:19, 15 ноя. 2012

sb3d
> Недавно я уже объяснял, почему софтрендер. Серьёзных причин две:
> а) Невозможность контролировать вывод картинки попиксельно. Например,
> масштабирование спрайта при выводе через ускоритель мне не подконтрольно.
> б) Отсутствие гарантированного стандарта рассчёта изображения. Сейчас, считая в
> софте, я уверен, что x86 стандарт будет соблюдаться бит в бит. А при
> использовании шейдеров и ускорителя я буду вынужден приспосабливаться к неясным
> и плохосовместимым стандартам шейдеров, разным версиям видеокарт, разным
> производителям, разным версиям драйверов.
тред не читал, но это высказывание неверно. растеризация полностью попиксельно документирована как для гл так и для дх, с точностью до направления округления координат пикселя при растеризации и метода расчёта коэффициентов билинейной фильтрации на границах текстуры. различные результате на различном железе можно получить, лишь используя что-то вендор-спесифик, либо используя что-то не по назначению, либо используя что-то неверно.

#40
5:26, 15 ноя. 2012

Suslik
Очевидно, что здесь тот случай, когда просто лень учить что-то новое и сам себя пытаешься убедить, что это новое тебе не нужно. Со стороны это выглядит довольно забавно, особенно на фоне незнания ленящимся предмета.

#41
6:37, 15 ноя. 2012

Suslik, петрушка, конечно, я в деталях не знаю растеризацию. Документирована ли она. Но есть простая проверка этому.

Запуская игры 2002 года, можно увидеть, что многие из них под современной системой не работают, или работают неверно. Это факт, который я наблюдал сам неоднократно. Из этого можно сделать предположение о том, как будут работать сегодняшние игры на ускорителе через десять лет. На тех компьютерах, системах и драйверах.

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

Добавил.
петрушка
> когда просто лень учить что-то новое
Лень очень полезна, на самом деле. Она не позволяет заниматься ерундой.

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

В этом случае у него не будет время на сам продукт. На авторские игры. Поэтому я не сторонник постоянного изучения всех новых фишек. Тем более, если они пока столь сырые, что за десять лет легко теряют совместимость.

-------------

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

#42
6:44, 15 ноя. 2012

sb3d
> Запуская игры 2002 года, можно увидеть, что многие из них под современной системой не работают, или работают неверно.
лолшто. проблемы того времени связаны в основном с direct draw, который уже сто лет как мёртв. вся графика, построенная на древних directx вроде 5.1 и ogl как работала, так прекрасно и работает.

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

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

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

#43
6:48, 15 ноя. 2012

Suslik
Ты хороший спец, приятный собеседник и просто отличный человек. Но право слово. Зачем этот спор? Движок софтовый.

#44
6:51, 15 ноя. 2012

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

Страницы: 1 2 3 4 562 Следующая »
ПроектыФорумУтилиты

Тема в архиве.