Дневники разработчиков

[HIman]

ИМХО арифметика простая.

Новый движок с огромным заделом на будущее должен показывать 3000фпс на минимальной конфе указанной на коробке.
3000 - только полигоны земли без текстур, без спец эффектов, кокпита, ФМ, ДМ. самолетиков и т.п.
добавляем текстуры земли 3000-100ФПС
добавляем деревья 2900-400ФПС
добавляем домики 2500-200ФПС
добавляем ФМ, ДМ кокпит, облака, дымы, самолетики и т.п. и все это должно с вычетом из 3000ФПС показать как минимум 300 чтобы было что ещё добавлять(тот самый огромный задел на будущее).

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

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

Патчами это не поправится, или вас устроят патчи отрезающие от лондона половину домов чтобы поднять фпс с 5 до 10.
Разрядить плотность облаков чтобы поднять фпс ещё на 10
И т.п. патчи которые будут помаленьку резать все ожидания, дабы вложиться хотя бы в 50ФПС для топовых компов.

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

[Tazmanskiy[Taz]]

ИМХО арифметика простая.

Новый движок с огромным заделом на будущее должен показывать 3000фпс на минимальной конфе указанной на коробке.
3000 - только полигоны земли без текстур, без спец эффектов, кокпита, ФМ, ДМ. самолетиков и т.п.
добавляем текстуры земли 3000-100ФПС
добавляем деревья 2900-400ФПС
добавляем домики 2500-200ФПС
добавляем ФМ, ДМ кокпит, облака, дымы, самолетики и т.п. и все это должно с вычетом из 3000ФПС показать как минимум 300 чтобы было что ещё добавлять(тот самый огромный задел на будущее).

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

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

Патчами это не поправится, или вас устроят патчи отрезающие от лондона половину домов чтобы поднять фпс с 5 до 10.
Разрядить плотность облаков чтобы поднять фпс ещё на 10
И т.п. патчи которые будут помаленьку резать все ожидания, дабы вложиться хотя бы в 50ФПС для топовых компов.

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

объясните мне тупому програмисту как знать заранее сколько будет выдавать движок на какойц либо тачке?
как только ответите можете открывать свой контору и озолотиться

[Trident]

объясните мне тупому програмисту как знать заранее сколько будет выдавать движок на какойц либо тачке?
как только ответите можете открывать свой контору и озолотиться

Поскольку не создали ни одной текстуры, не вмещающейся в память, то размер каким-то образом считали ?
По совокупности в объектах, количество объектов тоже. Пусть и "на глазок".
Если известны объемы, производительность оборудования, пропускные способности и вместительность и средства ОС, то посчитать можно. Лучше - пусть комп считает.
А готовить ему исходные данные для такого расчета надо на этапе начала пректирования и постоянно обновлять. Тяжко ?
Но если растянуть на 6 лет - то не слишком, ИМХО.

[spax]

ИМХО арифметика простая.


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

Не учел, что возможности железа тоже растут.
Движок на будущее, это тот, который загрузит по полной компы с максимальной конфигурацией и через 5-6 лет.
А если он сейчас будет на слабых конфах крутиться в 300fps, значит в нем так мало всего заложено, что грузить-то систему практически нечем.
Чем больше возможностей по расширению функционала, тем больше в движке мертвого груза. Тем меньше fps. Но тем проще добавить новые возможности в симулятор.

Можно написать программу на ассемблере, которая тупо решит какую-то одну задачу на конкретном компе за 10 секунд. И занимать места она будет 100кб. Но писать ее надо будет 3 месяца и она больше нигде не заработает. Чтобы добавить другую задачу, нужно писать еще одну такую же программу, еще за 3 месяца.
А можно ту же программу написать на Delphi или С#(добавить по вкусу). Решать задачу она будет 10 минут и займет 100мегабайт, но при этом работать она будет везде, где можно, напишем мы ее за 3 дня, и добавление другой задачи в нее займет еще пару часов.

[Geniok]

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

Стесняюсь спросить, вы программист?

--- Добавлено ---

объясните мне тупому програмисту как знать заранее сколько будет выдавать движок на какойц либо тачке?
как только ответите можете открывать свой контору и озолотиться

Тоже очень интересен этот момент.

[Nikitus]

Стесняюсь спросить, вы программист?[COLOR="Silver"]

он же написал =) арифметик

[Glob]

ИМХО арифметика простая.

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

Правильно ли я Вас понял -- написание движка есть процесс со случайным результатом: где-то накосячил (эффект вставил прожорливый), то нужно всё переписывать заново, начинать с нуля? Иными словами, начали строить дом, фундамент, стены, крышу сделали, но ошиблись с цветом стен в туалете -- всё рушим и возводим по-новому?

[Tazmanskiy[Taz]]

Правильно ли я Вас понял -- написание движка есть процесс со случайным результатом: где-то накосячил (эффект вставил прожорливый), то нужно всё переписывать заново, начинать с нуля? Иными словами, начали строить дом, фундамент, стены, крышу сделали, но ошиблись с цветом стен в туалете -- всё рушим и возводим по-новому?

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

[Xtentor]

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

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

[ZloyPetrushkO]

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

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

но тут ключевое-при правильном коде, ибо большая часть вариантов то работать будет, только криворукость человеческую компиллятор будет не в силах поправить=)
итого резюме: каждый ООП-кодер должен ОБЯЗАТЕЛЬНО уметь уверенно писать на асме и знать во что его код превращается после компиллирования
----
а обзор И-грабля какой то покупной походу...или у них была другая игра.
ровно как и обзор от Канобу...
а Игромании респект, ибо не побоялись написать как есть