Как обстоят дела с графическим интерфейсом и игровой программой по сравнению с веб-программами?

Некоторое время я разрабатывал веб-приложения и погрузился в разработку GUI и игровых приложений.

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

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

То же самое для программ с графическим интерфейсом, я полагаю, что есть "цикл приложений" некоторых видов.

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

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

Источник

3 ответа

Решение

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

Если вы сделаете шаг назад, ваши веб-приложения будут основаны на цикле - веб-сервере accept() цикл:

while(listening) {
     get a socket connection;
     handle it;
}

... но, как веб-разработчик, вы защищены от этого и пишете код, "управляемый событиями" - "когда кто-то запрашивает этот URL, делайте это".

GUI также управляются событиями, и события также где-то обнаруживаются циклом:

while(running) {
    get mouse/keyboard/whatever event
    handle it
}

Но разработчику GUI не нужно много думать о цикле. Они пишут "когда здесь происходит щелчок мышью, сделайте это".

Игры, опять то же самое. Кто-то должен написать цикл:

while(game is in progress) {
    invoke every game object's 'move one frame' method;
    poll for an input event;
}

... в то время как другой код написан в более управляемом событиями стиле: "когда объект пули совпадает с этим объектом, инициируйте событие взрыва".

Источник

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

В играх важен игровой цикл, поскольку он ориентирован на обработку экрана и состояния игры. Многие игры нуждаются в производительности в реальном времени. Благодаря современному API-интерфейсу 3D-графики большая часть обработки экрана может быть перенесена в графический процессор. Однако игровое состояние отслеживается основным циклом. Большая часть усилий команды для игры направлена ​​на то, чтобы сделать цикл очень плавным.

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

Для приложений последовательность

  1. пользователь делает X, X и связанная с ним информация (например, координаты X,Y) отправляется в UI_Controller.
  2. Пользовательский интерфейс решает, какую команду выполнить.
  3. Команда выполнена.
  4. Модель / данные изменены.
  5. Команда сообщает UI_Controller для обновления различных областей пользовательского интерфейса.
  6. UI_Controller перерисовывает пользовательский интерфейс.
  7. Команда возвращается.
  8. Приложение ожидает следующего события.

Есть несколько вариантов этого. Модель может позволить слушателям ждать изменений в данных. Когда данные слушатель выполняет и перерисовывает пользовательский интерфейс.

Источник

Что касается программирования игр, я был просто увлеченным человеком, однако я обычно так и делал:

У меня был объект, который представлял собой очень общую концепцию "сцены" в игре. Все различные основные разделы игры взяты из этого объекта Scene. Сцена действительно может быть чем угодно, в зависимости от типа игры. В любом случае, каждая более конкретная сцена, полученная из сцены, имеет процедуру для загрузки всех необходимых элементов для этой сцены.

Когда игра должна была менять сцены, указатель на активную сцену был установлен на новую сцену, которая затем загружала бы все необходимые ей объекты.

Универсальный объект Scene имел виртуальные функции, такие как Load, Draw и Logic, которые вызывались в определенное время в игровом цикле из указателя активной сцены. У каждой конкретной сцены были свои способы реализации этих методов.

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

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

Источник
Другие вопросы по тегам