Языки программирования

[Vagabond]

Это не ляля, а объективность.

Не выдавай свое ИМХО за объективность Не в первой теме этим ты страдаешь)

[Psychonaut]

Vagabond, а ты не выгораживай язык, который знаешь ты. Или приводи примеры серьёзных игр компьютерных, написанных только на одной яве. Чтобы там и соперники с AI, чтобы там и разговоры, и видеоролики более-менее качественные (кинематографичные уже т.н. на современном этапе), и т.п. Страдаешь видимо ты от недопонимания сути вопроса. Технический момент всегда объективен.

[STSOFT]

Vagabond, а ты не выгораживай язык, который знаешь ты. Или приводи примеры серьёзных игр компьютерных, написанных только на одной яве. ...

 

Маш, я не большой знаток игр, но по моим сведениям писать игры на языке типа Java, C++ и др. - несерьезно, действительно. Это может быть 2D-игра для смартфона ("прыгай-бегай", "змейка" и пр.) или даже шахматы, но никак не серьезная игра, начиная со знакомой мне игры "Doom". Уже сто лет тому назад было понятно, что для игр нужен СВОЙ специализированный язык, на котором легко конструируются карты, планы, местность и т.п. Основой для игры всегда являлся, насколько я знаю, некий "мотор", "движок", причем у каждой фирмы был свой или купленный у другой фирмы за большие деньги. Движок зачастую писали на макроассемблере, чтобы не было НИКАКИХ или почти никаких тормозов, насколько это возможно. Было еще и так: сначала писали на С++, отлаживали, верифицировали, затем отдавали кодерам, которые оптимизировали поблочно каждый модуль, переводя его на макроассемблер. Сейчас игры стали настолько сложными, что даже то, что я здесь пишу, уже устарело, скорее всего. Но в любом случае, это не С++ или Java. Это специализированное ПО.

Наши знакомые сейчас живут в Австралии, живут программированием комп. игр. ОНИ НЕ ЗНАЮТ НИ ОДНОГО ЯЗЫКА ПРОГРАММИРОВАНИЯ, это абсолютно точно. Занимаются даже не проектированием эпизодов (за это платят нехило), а занимаются лишь проработкой отдельных моментов. Это хватает им на скромное существование в стране пауков и крокодилов.

 

Легко:

 

public double[] matrvec(double[][] a, double[] b){

double [] c = new double[a.length];

for(int i=0; i<a.length;i++){

double s = 0;

for(int j=0; j<a.length; j++){

s+=a[j]*b[j];

}

c=s;

}

 

return c;

}

 

Сергей! Я чуть позже отвечу на глобальные вопросы, давай займемся более приземленными вещами, как например данный текст на Java.

Насколько я понимаю, в Java все параметры передаются исключительно по значению. Это проще реализовать разработчикам компилятора, но, с другой стороны, согласись, головная боль программиста. Даже в школьном Паскале есть передача по ссылке. Поэтому, результат работы функции умножения матрицы на вектор ты вынужден передавать через имя функции. Все бы ничего, только одно "НО". За каким хр. всякий раз при входе в эту мелко-функцию, менеджер памяти должен решать проблему о размещении нового массива? Это же выход на уровень ОС. С учетом кроссплатформенности, пока движок Java выйдет на уровень ОС 100 лет пройдет. Ведь это не экзешник! Это же исполнение псевдокоманд интерпретатором? Получается двойное замедление. Итак Java работает медленно, т.к. это непрямая последовательность команд, исполняющих алгоритм, а последовательность разбора завалов псевдокода с выползом на уровень команд процессора.

Но это все лирика.

Более конкретно: давай попробуем обратиться к этой функции. Т.е. напишем вызывающий текст.

 

с = d = e = A*b;

 

Я хочу, чтобы результат умножения хранился и в "e", и в "d", и в "c".

Причем они мне все трое нужны в разных ипостасях.

 

Как должен быть описан "e", чтобы ему присвоить результат?

Я полагаю, что

 

double [] e = matrvec(A,b);

 

Как ты засунешь теперь "e" в "d", чтобы затем еще и в "с"?

Я полагаю это возможно будет так:

 

double [] d;

double [] c;

 

d = e;

c = d;

 

Хорошо. Я полагаю, все они (c, d, e) сидят по одному адресу в ОЗУ.

 

Теперь давай это сделаем в цикле (например, работает методика Монте-Карло):

 

...

for (i = 1; i <= 10000000; i++)

{

double [] d;

double [] c;

// c и d мне нужны здесь, на этом уровне

if (fignja > mujnja)

{

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

...

double [] e = matrvec(A,b); // Только не надо выносить double [] e наверх!

... // Одни тыры-пыры

d = e;

c = d;

// Сборщик мусора по отношению к e работает? Если "да" - кранты.

}

else

{

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

...

double [] e = matrvec(A,b); // Только не надо выносить double [] e наверх!

... // Другие тыры-пыры

d = e;

c = d;

// Сборщик мусора по отношению к e работает? Если "да" - кранты.

}

...

}

 

Если сборщик мусора сработает здесь - тем более кранты (10000000 раз будет распределять память, а затем ее чистить.

 

Что, скажешь, Сергей? Не проще ли было бы до цикла один раз (!!!) разместить массивы c, d, e?

 

Переписывай matrvec. Но как, если у тебя нет передачи по ссылке?

[Vagabond]

Сергей! Я чуть позже отвечу на глобальные вопросы, давай займемся более приземленными вещами, как например данный текст на Java.

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

А еще в Паскале есть оператор безусловного перехода, а в Java нет Какой плохой и несовершенный язык эта Java:) А еще в Java множественное наследование через классы запрещено! Чем же думали разработчики языка?! Неужели интерфейс может быть лучше, чем запутанные иерархии классов, частенько встречающиеся в сишных приложениях?

 

Касаемо головной боли. Головная боль программиста - это читать код с процедурами, куда параметры по ссылке передаются и непонятно что откуда и куда следует. Головная боль программиста - это разбирать контекстно-зависимую сишную грамматику. Головная боль программиста - запариваться по три дня над memory leak-ом, возникшим благодаря тому, что кто то где-то некорректно работал с памятью) И т.д. и т.п.

 

Все бы ничего, только одно "НО". За каким хр. всякий раз при входе в эту мелко-функцию, менеджер памяти должен решать проблему о размещении нового массива? Это же выход на уровень ОС. С учетом кроссплатформенности, пока движок Java выйдет на уровень ОС 100 лет пройдет. Ведь это не экзешник! Это же исполнение псевдокоманд интерпретатором? Получается двойное замедление. Итак Java работает медленно, т.к. это непрямая последовательность команд, исполняющих алгоритм, а последовательность разбора завалов псевдокода с выползом на уровень команд процессора.

Но это все лирика.

Более конкретно: давай попробуем обратиться к этой функции. Т.е. напишем вызывающий текст....

 

Что, скажешь, Сергей? Не проще ли было бы до цикла один раз (!!!) разместить массивы c, d, e?

Без обид, но я скажу, что у меня сложилось стойкое впечатление, будто ты не знаешь о том, как работает сборщик мусора в Java и имеешь вообще довольно-таки ограниченное понимание того, как JVM вообще работает с памятью GC естественно не будет вызываться ни после условий, ни после окончания каждой итерации цикла Такой алгоритм работы никогда не вывел бы Java-технологии в лидеры среди языков разработки мощных корпоративных и интернет-приложений.

В моем тестовом классе GC вызвался после выхода из тела цикла один раз) В целом умножение массивов чисел двойной точности ([30][8] * [8]) в цикле из 10 миллионов итераций выполнялось три секунды. Я считаю, что это неплохой результат для полностью кроссплатформенного, надежного и безопасного языка.

 

З.Ы. И кстати, почему бы не вынести Double[] e наверх? Логика то от этого не страдает))

Изменено 27.02.2012 12:28 пользователем Vagabond

[STSOFT]

А еще в Паскале есть оператор безусловного перехода, а в Java нет

Сколько раз срабатывает оператор

double [] c = new double[a.length];

в теле функции matrvec, если мы обращаемся к ней миллионы раз?

[Vagabond]

Сколько раз срабатывает оператор

double [] c = new double[a.length];

в теле функции matrvec, если мы обращаемся к ней миллионы раз?

 

Ответ очевиден Но это не означает, что будет выделено 10 миллионов различных участков памяти для 10 миллионов однотипных double-массивов) Следует помнить, что оператор new в Java и в С++ работают по разному. После выхода из тела метода участок памяти выделенный под массив c будет промаркирован, однако при следующем обращении к методу и выполнении оператора new для нового экземпляра массива c этот участок снова будет задействован. Примерно так же как если бы по ссылке переписывался один и тот же участок памяти. Но при этом безопаснее ибо исчезает риск непреднамеренного изменения контекста вызывающего метода. Запусти тесты, проверь

[Psychonaut]

STSOFT

Берите фрагменты кода в тег [ code /code ], чтобы глаз радовался.

Вот так оно приятнее, согласитесь:

 

...
for (i = 1; i <= 10000000; i++)
{
double [] d;
double [] c;
// c и d

Изменено 27.02.2012 20:44 пользователем Psychonaut

[STSOFT]

STSOFT

Берите фрагменты кода в тег [ code /code ], чтобы глаз радовался.

Вот так оно приятнее, согласитесь:

 

...
for (i = 1; i <= 10000000; i++)
{
double [] d;
double [] c;
// c и d

 

Спасибо. А какие еще теги HTML здесь работают? Проверка:

 

[table]

[tr]

[td]

1

[/td]

[td]

2

[/td]

[/tr]

[/table]

 

Жаль. Не работает [table][/table]. Но

if (a < b)
{
 // Я вот так предпочитаю
 // скобки расставлять
}

 

(стиль Microsoft)

 

а не так:

 

if (a < b) {
 // Я вот так предпочитаю
 // скобки расставлять
}

 

Маш! Какой стиль больше нравится?

 

Ответ очевиден Но это не означает, что будет выделено 10 миллионов различных участков памяти для 10 миллионов однотипных double-массивов) Следует помнить, что оператор new в Java и в С++ работают по разному. После выхода из тела метода участок памяти выделенный под массив c будет промаркирован, однако при следующем обращении к методу и выполнении оператора new для нового экземпляра массива c этот участок снова будет задействован. Примерно так же как если бы по ссылке переписывался один и тот же участок памяти. Но при этом безопаснее ибо исчезает риск непреднамеренного изменения контекста вызывающего метода. Запусти тесты, проверь

 

1) В любом случае 10 млн. срабатываний оператора new с последующими освобождениями участка памяти столько же раз - не есть хорошо. Когда можно было обойтись 1 разом, если бы у тебя была возможность передачи параметров по ссылке. Кстати, в C# эта фишка устранена, по слухам.

2) Я пока не имею возможности и дистрибутива, чтобы установить у себя Java, но при случае, со временем, я найду возможность более детально разобрать этот пример.

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

[Psychonaut]

Маш! Какой стиль больше нравится?

 

Да здесь уже невелика разница

[Vagabond]

1) В любом случае 10 млн. срабатываний оператора new с последующими освобождениями участка памяти столько же раз - не есть хорошо. Когда можно было обойтись 1 разом, если бы у тебя была возможность передачи параметров по ссылке. Кстати, в C# эта фишка устранена, по слухам.

Я уже говорил - нехорошо, это когда непонятно из кода, что откуда и куда следует. По этой причине в свое время практически вся IT-сфера отказалась от использования GOTO. И ладно, если задачка простая на пару классов. Но когда речь идет о масштабном проекте с большим жизненным циклом, обновлениями, распределенной логикой, вот тогда и всплывают различные косяки, возможные только благодаря C++, в виде непрозрачной и сложной работы со структурами данных, графами, передачами параметров по ссылке, незакрытыми указателями, корявыми библиотеками, получасовыми компиляциями и прочими подобными нехорошими вещами, возникающими благодаря тому, что ты выдаешь за преимущества, по сравнению с той же Java. На самом то деле единственное, пожалуй, объективное преимущество этого языка перед Java - это скорость работы на отдельно взятой машине с отдельно взятой ОС, и то это проявляется в основном при работе со сложными объектами, которые JVM сгружает в кучу и, признаться, не самым оптимальным способом обрабатывает, в отличие от C++, где можно самому расписать управление памятью под эти объекты.

Хотя в след. релизе JDK обещают поправить алгоритмы, из чего следует, что Java еще сильнее прирастет в скорости. Посмотрим, в общем.

 

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

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

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

 

З.Ы.

Откуда вообще такой зуб на Java?

Изменено 28.02.2012 07:48 пользователем Vagabond

[STSOFT]

...

З.Ы.

Откуда вообще такой зуб на Java?

Какой зуб? Каждый язык в своей сфере работает. Просто надо убедиться в них. В сферах. Если мне бы платили за работу на Java, я бы на ней и работал. Кстати, последнее время появились такие предложения. Они как раз с Андроидом и связаны.

[Psychonaut]

Кстати, последнее время появились такие предложения. Они как раз с Андроидом и связаны.

 

Дык платят, но не очень много, потому что высок уровень конкуренции. У меня знакомые никак не могут специалиста по Питону найти, например. И з/п повысилась - нету человека. Навык не купишь. Яву - пруд пруди.

[STSOFT]

Дык платят, но не очень много, потому что высок уровень конкуренции. У меня знакомые никак не могут специалиста по Питону найти, например. И з/п повысилась - нету человека. Навык не купишь. Яву - пруд пруди.

 

Маш, тут вот в чем дело - видимо им нужен чел, который на Питоне сразу с первой минуты вклюнется в проблему на 100%. Вообще-то Питон - далеко не тривиальный язык. Признаться, я на нем не то, чтобы ничего не программировал, но даже не слышал об его коммерческом использовании (что, конечно, говорит не в пользу нашей провинции). Питон по сложности превосходит культовый язык Перл. Знаю случай, когда специалист по Перлу нашел работу в США за 3 секунды.

Интересно, а примерно какой у них круг задач, где используется Питон?

Не удивлюсь, если контора эта весьма серьезная и крупная. О серьезности Питона говорит тот факт, что на этом языке пишут даже предпроекты - монтируют крупные программные комплексы, отлаживают концептуально, затем ссылки реализуют на С++, с котором у Питона особенно дружеские отношения. Меня поражает в Питоне: он вполне допускает реализации отдельных частей программ на С++. А еще, что Питон поддерживает динамическую модификацию не только самого текста методов класса, но и конкретики наследования.

Например, есть класс A. В обычном языке ты пишешь "В наследует A". А в Питоне можно сказать примерно так: "В наследует A, если x < 0.5*y".

Удивительно также и то, что наряду с объектно-ориентированностью, у Питона есть всё, чтобы развивать и функциональное программирование, вплоть до гениальных лямбда-функций (я знаю только один язык, кстати мой любимый язык, где есть поддержка лямбда-функций - это Фортран-90, не путать с обычным фортраном).

[BlackTemplar]

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

К слову, в Facebook создали HipHop for PHP - транслятор php-шного кода в код C++. После чего оный компилируется и исполняемые файлы отправляются на серверы. Видно, очень критично было повышение производительности, но переписывать всё на С++ сами с нуля не решились.

[Psychonaut]

Маш, тут вот в чем дело - видимо им нужен чел, который на Питоне сразу с первой минуты вклюнется в проблему на 100%...

 

Нашли

[STSOFT]

К слову, в Facebook создали HipHop for PHP - транслятор php-шного кода в код C++. После чего оный компилируется и исполняемые файлы отправляются на серверы. Видно, очень критично было повышение производительности, но переписывать всё на С++ сами с нуля не решились.

Инициатива Facebook'а 2010 г. не нужна тем, что изначально строил свою Web-стратегию не на PHP. Уже давно всем понятно, что существуют пределы производительности скриптовых систем в мега-условиях. Сервлеты лет 10 в серьезных проектах процветают взамен PHP с его CGI-допотопностью.

Впрочем, интересно, как они переводят на C++ такие, например, тюльки:

 

$a = 1;

...

$a = "Вася";

 

А чередование HTML и PHP-вставок?

[GT35]

Есть такой вопрос. На Android есть игра Organ Trail Director's Cut. Хотел ее локализовать, но обычного понятия "текст" в ней нет. Т.е. текст оказался прорисован в картинке. Порывшись в apk файле обнаружил файлы assest, которые скорее всего и являются необходимыми данными. Но вот чем вскрыть я не нашел. Есть идеи как отредактировать файл *.assest?

[STSOFT]

Есть такой вопрос. На Android есть игра Organ Trail Director's Cut. Хотел ее локализовать, но обычного понятия "текст" в ней нет. Т.е. текст оказался прорисован в картинке. Порывшись в apk файле обнаружил файлы assest, которые скорее всего и являются необходимыми данными. Но вот чем вскрыть я не нашел. Есть идеи как отредактировать файл *.assest?

 

Может это поможет.

[GT35]

STSOFT, это я смотрел. Особо мне понятно не стало. Unity даже скачивал. Но как вскрыть файл тоже не нашел. Только создать можно.

[STSOFT]

STSOFT, это я смотрел. Особо мне понятно не стало. Unity даже скачивал. Но как вскрыть файл тоже не нашел. Только создать можно.

Winrar пробовали? Чем-то ведь можно эти файлы редактировать...

Можно попробовать на англоязычных поисковиках поискать. На их хакерских сайтах. Там многое что раскладывается по полочкам, начиная с .doc-файлов.

[Norman94]

Начал изучать С++. Довольно интересный язык, но Паскаль мне кажется гораздо проще

[Scud-IIEPBblu]

Было интересно прочесть такое разнообразие мнений. А теперь, если никто не против, позвольте и мне рассказать то, с чем я знаком. Я имею здесь в виду исключительно применение языков программирования именно в компьютерных играх.

Во-первых, да – любая достаточно солидная игра (3D-action, как минимум) основана на "движке", EXE-файле, который обычно и принято называть самой игрой. Но это – даже не верхушка айсберга. Если уж вдаваться в аналогии – это лишь тень снежинки, лежащей на вершине плавающей в океане многокилометровой глыбы льда.

Смотрите. Игрок управляет игрой посредством мыши (клавы, джойстика и т.п.), общение с этими девайсами обеспечивает операционная система – через встроенные и инсталлируемые драйверы. А те, в свою очередь, работают через HAL – надстройку ядра операционной системы, собираемую ещё при её первой установке на данный компьютер, чтобы ОС даже не заморачивалась, на каком именно железе ей предстоит работать.

Идем дальше – графика. Её рисование обеспечивают сразу три слоя программ: DirectX, представляющий собой комплект DLL для моделирования трехмерных объектов, графическое ядро ОС, отличающееся от него тем, главным образом, что работает на уровне системного приоритета (т.н. Ring-0), и микропрограммы графического процессора, непосредственно "выдающие картинку" на экран. Если первые ещё написаны, отчасти, на C++ хотя и с использованием оптимизированных на быстродействие ассемблерных вставок, где это только возможно (а для "чистого" ассемблера просчет трехмерного мира всё же сложноват), второе сделано так, что кроме "мягко-мелких мальчиков" никто даже не имеет формального права этим интересоваться, то третьи и вовсе "зашиты", большей частью, в GPU видеокарточки. И написаны они уже, соответственно, на специализированном языке нанокоманд, оптимизированном для управления обработкой потоков данных на многоконвейерном специализированном под графику видеопроцессоре.

Но всё перечисленное смогло бы обеспечить вам не больше, чем вид вращающегося кубика из видеотеста DX-Diag.exe, – самой игры здесь ещё нет, ею тут пока ещё и не пахнет.

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

Но пустой МИР – это ещё далеко не игра, его ещё необходимо населить персонажами. К последним, как ни странно это может показаться, относятся не только "все плохие и хорошие", но точно так же: стулья, ящики, растения, животные, огни факелов, оружие и всё, чем оно стреляет – вплоть до дыма, остающегося за ракетой, и осколков, выбиваемых пулями. Всё то, короче говоря, что в процессе игры должно хоть что-то делать: появляться, куда-то как-то двигаться, открываться, закрываться, исчезать (как исчезает снаряд, взорвавшись, порождая при этом взрыв и осколки).

Ну, я не стану акцентировать внимание на том, что всё это требует ещё и бездну текстур, которые видеопроцессор потом будет "натягивать" туда, где ему указанно, чтобы игра не стала "жизнью восковых фигур в ледяных катакомбах" (в TR: Legend от Cr-Dy есть чит-код, очень наглядно показывающий, о чём здесь речь), и множества звуков (музыка, эмбиент, экшин, демо и т.д.), ибо большинство игроков не глухонемые, и от беззвучных игр давным-давно отвыкли. Не забудем лишь здесь отметить, что из-за огромного объёма всего этого "арт-стаффа" игре необходимо иметь не только возможность быстрого и удобного способа редактирования всего этого дела, не только набор утилит, автоматически привязывающий редактируемые объекты в нужных местах (чтобы текстура ковра на стене не оказалась натянутой на протагониста – и наоборот), но, как правило, ещё и ведущих мощную и эффективную базу данных, позволяющую впоследствии "движку" быстро и безошибочно находить нужные объекты среди многих гигабайт этого добра.

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

А вот дальше идет уже самая изюминка игры, её AI. То самое, вообще-то, ради применения чего вся игра, собственно говоря, и создается. Здесь прописано всё: и как пули должны летать, и как мобы будут бегать, и как звуки меняться эхом и доплеровским эффектом. AI игры (иногда это называется её скриптом) – то самое, что, главным образом, её и отличает от множества подобных. Здесь есть два существенных момента:

1. Это – самая сложная, самая интеллектуальная часть всех программных компонентов. Она просто обязана быть максимально удобочитаемой для разработчика. Особенно, учитывая то, что ею занимаются по несколько человек сразу. Её больше всего меняют, настраивают, подстраивают… и не только во время разработки – бывает, что она и после выхода игры всё ещё подвергается обновлениям ("латается и подчищается").

2. Несмотря на свою сложность, эта часть программного продукта потребляет настолько мизерную долю компьютерных ресурсов, что здесь можно позволить себе буквально АБСОЛЮТНО любой язык программирования.

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

 

Осталось отметить, что всё вышеописанное – лишь наиболее общий случай, стандартный подход. Кто-то, разумеется, может себе позволить поступать и "в точности наоборот". Например, если так уж задаться целью, чтобы самая примитивнейшая игра могла потом работать лишь на самом-самом навороченном железе – да и то с дичайшими тормозами и поминутно вылетая в BSOD.

 

А для чего я всё это изложил? Да лишь чтобы показать: любое и каждое категорическое мнение с величайшей вероятностью оказывается… нет, не неверным даже – а просто несостоятельным, самому же себе в корне противоречащим. Особенно, когда все спорящие в одинаковой мере абсолютно правы… но, увы, понимают при этом лишь свою личную правоту.

Изменено 20.12.2013 03:11 пользователем Scud-IIEPBblu

[active69]

Программеры любят тут тусоваться?

Нужна утилита для облегчения просмотра фильмов и сериалов...

Когда их терабайты, возникают проблемы с вспоминанием - какую серию смотреть?

Утилита бы пригодилась...

Написать не сложно...

Указываешь ей папку с сериалом, и всё...При следующем запуске - запустится именно тот момент, где прервалось...

Лучшая - войдёт в анналы Кинопоиска...

Выкладывайте тут...

С меня - любая выполненная просьба...

[GlitchMob]

Я умею переустанавливать любой Windows, и этим Я горжусь.

[4upaKabra]

А Win3.11 с дискет слабо?