Вопросы от Непрограммиста (13 стр)

Dmitry_Milk, я про эмуляторы DosBox и его разнообразие. Хотя там ещё какие-то есть, где нормально основа эмулируется.
  Но да, можно и ZX Specrum изучать, главно что основу поймёшь.

Господа, вы лезете не на ту гору. Что с того, что вы научитесь сначала двигать квадраты, потом кубы, а потом реалистичное 3D? Тем более, какой прок от понимания того, как это реализуется в железе вашего суперкомпьютера? Надеяться, что на каком-то этапе это знание/умение/проект можно будет продать?
Во-первых, в результате не получится игра. Будет лишь обязательный набор игровых/мультимедийных элементов, который внешне похож на игру. Ведь игра подразумевает психологию, поведенческий анализ, математическое моделирование, которые вы отложили на потом. Но как вы это сделаете, имея на руках проблемы кубических шейдеров?
Во-вторых, со стороны окружающих это будет блажью. Иметь на руках супермощную машину и не применять ее в реальной жизни. Искать дураков, которые живут в игровых мирах, и платят за виртуальные поделки. Вместо помощи и удовольствия ближним.

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

gudleifr
> Что с того, что вы научитесь сначала двигать квадраты, потом кубы
  Ответ очень прост - геймдизайн.

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

> мультимедийных элементов, который внешне похож на игру.
  Дык это сделать самое главное и сложное.
  Всё остальное, это рутина.

> игра подразумевает психологию, поведенческий анализ, математическое моделирование
  Знать бы ещё, что это и как выглядит.
  Я ж интересуюсь только 2D казуалом.

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

711
> Дык это сделать самое главное и сложное.
> Всё остальное, это рутина.
Наоборот. Первое - рутина. Второе - искусство.

gudleifr
> Нет. Если до них дошло, значит программирование не удалось.
> 1) сначала нужно попытаться вычислить
  А разве эти функции, которые используются для вычисления, внутри себя не состоят из тех же самых ёлочек “if”, “ else” ?
> 2) если не выходит - построить таблицу
  А что за таблицы ?

711
> А разве эти функции, которые используются для вычисления, внутри себя не состоят из тех же самых ёлочек “if”, “ else” ?
он имеет в виду сведение программирования к математике.

например, какая-нить классика:

function max(a,b: integer): integer;
begin
  max := ((a+b)+abs(a-b))/2;
end;

или так:

function max(a,b: integer): integer;
begin
  max := a-((a-b) and ((a-b) shr 31));
end;

или этак:

function max(a,b: integer): integer;
var  
  s : integer;
begin
  s := (a - b) and $8000000;
  s := s shr 31; 
  max := (1 - s) * a + s * b;
end;

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

Соответственно, "построить" таблицу, это как вспомогательная вещь для вычислений. Либо, как замена оным.

const
  moda: array [0..1] of integer = (1, 0);
  modb: array [0..1] of integer = (0, 1);

function max(a,b: integer): integer;
var  
  s : integer;
begin
  s := (a - b) and $8000000;
  s := s shr 31;  
  // лютая экономия на отсутствии вычитания
  max := a * moda[s] + b * modb[s];
end;

Но тут проблема в том, что индустрия развивается в сторону удешевления разработки.

А значит не нужно замарачиваться с этой фигнёй, и просто писать if и for.
Давно нет нужды описывать логику арифметикой. Просто описывать логику - логикой.

ЗЫ: Кстати! ООП в ту же кассу.
уменьшить количество IF-ов, заменив их таблицами вызовов.

711
> А разве эти функции, которые используются для вычисления, внутри себя не состоят из тех же самых ёлочек “if”, “ else” ?
skalogryz
> он имеет в виду сведение программирования к математике.

Вы забыли про адресную арифметику.

А, нет, не забыли...

skalogryz
> уменьшить количество IF-ов, заменив их таблицами вызовов.

И, да, вы правы, многие простые выборы трудно вычислить "в лоб". Но насколько чаще в программах можно встретить "елочки" и "матрешки" там, где результат, как в "анекдоте", легко вычислим, или легко табулируется, или, наконец, легко создать объект "вычислитель" и забыть "как реализована max()".

skalogryz
> Хотя раньше, это было "нормой" для программиста: "пытаемся найти математическое решения".
изначально это делалось именно для экономии тактов. Потом уже о кэше думать стали.

711
> А что за таблицы ?
)))
прикольно. Но я бы ни когда не задал подобный вопрос. Хотя если вспомнить, я тоже не знал когда-то.

Mirrel
> для экономии тактов. Потом уже о кэше думать стали.
Выпендрежники!

gudleifr, конечно выпендрёжники. Ведь получая на 40 мегагерцовой машине вместо 1000 тактов работы программы, 600-700 - это выпендрёжничество. А если это ещё и в цикле работать будет, так вообще циклическое выпендрёжничество.

Mirrel
> Ведь получая на 40 мегагерцовой машине
Ага, и был у Вас такой случай один-два раза в жизни. В большинстве случаев программы тормозят просто потому, что совершают ненужные действия. Обычно, как раз в силу того, что кодер увлекается танцами с бубном...

https://gamedev.ru/industry/forum/?id=242661&page=2&m=4936662#m17

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

Mirrel
> Только пользуются подобными "упрощениями" по сей день, в компиляторах.
Кто пользуется? Дядя Вася? О котором Вам рассказывал дядя Петя? По пьяни и по великому секрету? Будьте проще! Ваша основная задача - не запутаться в том, что сами понаписали. Ошибетесь? Перепишете! Будет тормозить? Опять перепишете! Не пытайтесь писать на века. Ибо сказано: НЕ ПРЕДПОЛАГАЙТЕ!

skalogryz
> он имеет в виду сведение программирования к математике.
  Да я так и понял. Просто я что-то со встроенными мат.функциями запутался и меня немного не туда понесло.
  Но вот после твоего объяснения для меня как-то чтоль всё стало: очевидно.
  Из тебя вышел бы неплохой преподаватель.

skalogryz
> + даже анекдот такой был
  Шутки не шутки, но это прекрасный пример из вселенной программирования. Это вот прям доносить всю суть.
  Вот про книгу с такими задачками я и спрашивал (но, именно бумажное издание). Ей бы цены небыло.

skalogryz
gudleifr
  Но в целом - это ж рехнуться можно, так всё адаптировать. Это ж настоящая головоломка. Я понимаю такое для удовольствия поделать. Но писать так код для игры, где Главный Герой находиться одновременно в различных, но взаимосвязанных условиях, а ещё эти условия меняются… ну, не знаю. И задачи там могут быть посложнее, чем просто получить остаток от числа.

  Так что, я думаю, выгоднее заморочится над правильной архитектурой, о которой говорит tac (если я, конечно, правильно понял).
  Выстроить взаимосвязи между разными классами/объектами - это та ещё логистика.
  Я сейчас пытаюсь сделать в игре выбор персонажа с учётом сопутствующих переменных. Так у меня больше проблема не в коде, а в последовательностях (какой скрипт за каким и в какой момент должен срабатывать).

Mirrel
> Но я бы ни когда не задал подобный вопрос.
  Да потому что надо всё называть привычными словами. Что ещё за “таблицы”... Массив и есть массив. Массив - это понятно (немного)

> gudleifr
> и забыть "как реализована max()
  Кстати, а где можно глянуть, как он внутри устроен ?
  Это ж очень интересно, как реализованы те или иные функции.