Airat1995: Precach\Preload каждый реализует сам в конкретном движке со своими хитростями, нет универсального способа или особых финтов в opengl на тот счет. В целом как я и выше писал, либо грузите все необходимое заранее до геймплея, либо грузите все в реальном времени и изобретаете велосипеды чтобы это было незаметно либо комбинируете оба способа.
По поводу мипмапов https://www.khronos.org/registry/OpenGL-Refpages/g...
Без LOD смысла нет, но лоды обязательно надо делать.
Airat1995: TBO если проще говорить это линейный буфер с не совсем известными данными(внутри может быть 1D\2D\3D\Cube и т.д.), никаких мипмапов или фильтраций нет, только хардкор. Мипмапы автоматически не генерируются, на этот счет от версии к версии opengl было и есть куча разных методов для генерации оных.
С IO надо исходить из задачи. Раньше когда видеопамяти и озу было не так много то часто хитрили и на лету грузили и выгружали ресурсы. Сейчас эта проблема остро не стоит, памяти везде много и она очень быстрая. Исключением может быть игра с бесшовным миром и огромным числом текстур. Если исключить такие миры то текстуры грузят не в реальном времени на лету а вначале при загрузке уровня загружают абсолютно все что понадобится для уровня(обычно называют прекэшем), по времени это опять же становится не критичным т.к. пока грузятся ресурсы игроку обычно показывают экран загрузки с нескучными картинками.
Намного больше времени,как правило, уходит на разработку алгоритма грамотного прекэша. Решают или в лоб путем статичного списка прекэша который точно не меняется на протяжении игры(текстура героя\оружия... в общем все то что на протяжении всей игры не меняется и будет почти на каждом уровне) и данимаческий список(текстуры присущие конкретному уровню, составляется обычно отдельной утилитой которая делает файлик со списком всех текстур на уровне). Динамический список при каждой смене\загрузки уровня сначала вычищается а потом на его место грузится новый. Такой подход в движке сорса и вообще почти в каждом.
Бывает что идут немного интереснее и эти списки составлют динамически на лету и также динамически асинхронно по этому списку все грузят и выгружают. Чтобы сделать этот процесс незаметным идут хитрым путем. Делают свой "велосипед" формат текстур в котором запекают мипмапы, располагают их в начале файла самый мелкий а в конце самые большие т.е. текстура в оригинальном разрешении. При необходиомсти загрузки асинхронно быстро грузится начало текстуры и сразу накладывается на объект(он получается мыльный) и по мере загрузки файла подменяют мипмапу на более качественную. Такой подход тоже много где используется, живой пример был и остается двиг UE3. В нем на компьюерах с малым количеством памяти\медленной памятью или медленным хардом можно наблюдать в реальном времени за этой загрузкой. Карта грузится очень быстро, затем включается рендер мира и все мыльное мыльное и в течении секунд на глазах все обрастает деталями, стоит поднять новое оружие как оно несколько секунд мыльное и вдруг резко становится красивым. У этого подхода к плюсам можно отнести более быструю загрузку, возможность делать огромные и бесшовные миры, возможность загружать огромные текстуры но все это прекрасно и красиво на очень мощных ПК или на более слабых с условием что игра не шибко динамичная а размеренно плавно медленная.
Дмитрий Чередниченко: Я же говорю как вариант можешь раскладывать по принципу как я выше описал. Проблема больших чисел в том что каждый ЯП, каждая функция в фремворки или собственная, каждый вызов вывода данных все это неизбежно приводит к ошибкам округления. Живой пример:
Mysql минимум -9,223,372,036,854,775,808 максимум 9,223,372,036,854,775,807 или при счете от
минимум 0 максимум 18,446,744,073,709,551,615
PHP минимум -2,147,483,648 максимум 2,147,483,647 или php 64 битный
минимум -9,223,372,036,854,775,808 максимум 9,223,372,036,854,775,807
Тоже самое происходит и с другими ЯП или форматами данных.
Намного проще упростить систему по рецепту выше =)
Atllantis: Если не вариант то надо написать скриптик который рекурсивно прошерстит все java файлы перед компиляциеей и если найдет в строке коментарий, скажем, /*------debug-delete*/ то удалит всю строчку целиком. Только в таком случае придется в коде такие места умещать в 1 строку и не задействовать этим кодом ничего другого.
Тогда в каком то смысле это будет заменой #ifdef
Максим Тимофеев: я вообще то не писал конкретно про yii. Но если так то все что связанно с yii требует расширения и стиля писания как yii-way, шаг в сторону сразу расстрел на месте.
К примеру попробуйте сделать сложную форму? Ааа, вроде виджетов много но подходящего нет, пробуй написать свой виджет ииии (yii-way):
"Разрабатываемые виджеты должны быть самодостаточными. Это означает, что для их использования должно быть достаточно всего лишь добавить виджет в представление. Добиться этого бывает затруднительно в том случае, когда для его функционирования требуются внешние ресурсы, такие как CSS, JavaScript, изображения и т.д. "
Отсюда родится костыль или отхождение от стиля фреймворка.
Антон @ Лялин: смотря что в вашем понятии "быстро" и "очень медленно". Обычно в таких случаях надо профилировщиком искать бутылочное горлышко.
Может у вас очень хреновый hdd\ssd или проц не вытягивает.
Руслан Янбердин: строго по интерфейсам. Вы должны знать что этот черный ящик принимает только String дальше идет магия и на выходе получается сортированная строка. Что и как происходит внутри вас волновать не должно.
Еще можно добавить 4й пункт. Один класс решает одну конкретную задачу, не стоит городить комбайны.
dima_meln: Не будут, но станут доступны если сделаете так Save velik = new Velosiped();
Или же скастуете тип:
Transport velik = new Velosiped();
((Save)velik).someSave();
Вообще интерфейсы очень мощная и удобная штука.
dima_meln: я так понимаю вот это Transport velik = new Velosiped();
Тут следующее.
Transport это интерфейс как сразу понятно но ему присваивается реализация Velosiped. Фишка в том что будут доступны все методы которые объявлены в интерфейсе но не будет каких то сторонних которые могли быть объявлены внутри реализации. Т.е. если в классе Velosiped вы напишите совершенно новый метод, к примеру void MegaTurboDvijenie()то вы его не увидите потому что его нет в интерфейсе.
Так же найдете этот метод если объявите явно Velosiped velik = new Velosiped();
Другой вариант каст класса. Например ((Velosiped )velik).MegaTurboDvijenie(); Этот метод станет виден хотя он не объявлен в интерфейсе.
При всем этом нельзя сделать такое Transport velik = new Transport(); Это будет ошибкой.
Денис Загаевский: все ради понимая. Видно что человек изучает тему и хочет понять. В тех же книгах примеры обычно очень скудные для понимания, особенно тем кто только изучает и не может понять а почему так назвали и т.д. В общем не расстраивайся, в реальном коде я такого не делаю =D
Максим Гречушников: описанное выше применимо хоть к клиенту, хоть к серверу. Как только на сервер поступает запрос я так полагаю он у вас уже будет знать начальные точки и их стартовые параметры. Запрос поступил, можете посчитать сразу или сложить в очередь и просчитать через минуту.
А вообще разрыв в минуту это что то с чемто честно говоря =D. За минуту может столько произойти, что синхронизировать клиентов запаришься.
ipswitch: Судя по вопросу автора, а точнее всего по его познаниям юниксовых исходя из вопроса наверное все же поиграть. А убунта стоит только для обучения и познания.
