Программирование графики всегда веселее, чем просто программирование. Т.к. картинка на экране - это уже своего рода дебаг, сразу видно если что-то не то. Если одно видимое, конечно.
Я так и не могу найти в сети точные причины засекречивания документов. Получается, причина есть только в момент скрытия информации, но ведь при рассекречивании можно хотя бы предполагать почему они были засекречены и почему такие даты. Никто так не делает, почему-то.
While the BOUND instruction does provide hardware bounds-checking, I understand it indirectly caused performance issues because it breaks the hardware branch predictor (according to a Reddit thread, but I'm unsure why), but also because it requires the bounds to be specified in a tuple in memory - that's terrible for performance - I understand at runtime it's no faster than manually having the instructions to do an "if index not in range [x,y] then signal the BR exception to the program or OS" (so you might imagine the BOUND instruction was added for the convenience of people who coded assembly by-hand, which was quite common in the 1980s).
The BOUND instruction is still present in today's processors, but it was not included in AMD64 (x64) - likely for the performance reasons I explained above, and also because likely very few people were using it (and compilers could trivially replace it with a manual bounds check, that might have better performance anyway, as that could use registers).
MPX is superior to BOUND in that it provides dedicated registers to store the bounds range so the bounds-check should be almost zero-cost compared to BOUND which required a memory access. On the Intel 486 the BOUND instruction takes 7 cycles (compare to CMP which takes only 2 cycles even if the operand was a memory address). In Skylake the MPX equivalent (BNDMK, BNDCL and BNDCU) are all 1-cycle instructions and BNDMK can be amortized as it only needs to be called once for each new pointer).
I cannot find any information on wherever or not AMD has implemented their own version of MPX yet (as of June 2017).
Вроде бы, в старых и уже заброшенных инструкциях x86, или же в каком-то другом процессоре пытались проверять границы аппаратно. Знать бы, почему не взлетело.
Да, но некоторые из нас выбрали отыгрывать ГГ, в итоге влияют на судьбы миллионов NPC.
Да, есть и возможность отыгрывать NPC. Каждый выбирает свою роль.
А то что? Его адепты придут и убьют?
Программирование графики всегда веселее, чем просто программирование. Т.к. картинка на экране - это уже своего рода дебаг, сразу видно если что-то не то. Если одно видимое, конечно.
Я так и не могу найти в сети точные причины засекречивания документов. Получается, причина есть только в момент скрытия информации, но ведь при рассекречивании можно хотя бы предполагать почему они были засекречены и почему такие даты. Никто так не делает, почему-то.
Видимо, причина тоже секретная.
Так ведь дата рассекречивания не от них зависит.
Вторую можно наносить у всех в самом низу/верху.
Аккумулятор ядерный что ли? Или это если его не использовать?
А если кто-то вставит дело перевёрнутым?
Я могу нарисовать в Пэйнте, что и сделал. Но это было долго, хочется моментально.
О, а это вариант. Но для начала всё же хочется именно от рисующей нейросети.
Хоть одна из рисующих нейросетей может нарисовать простую попиксельно идеальную сетку? Попробовал и не получается, только кривые и размытые.
Похоже, это инструкция Bound:
Вроде бы, в старых и уже заброшенных инструкциях x86, или же в каком-то другом процессоре пытались проверять границы аппаратно. Знать бы, почему не взлетело.
std::vector::at не оно?
Но потом двадцать один, двадцать два...
На Godot более презентабелен Sonic Colors.
Вы там его не портируете уже на следующий Switch, а? :)
Если движок должен учесть опыт создания других движков и быть лучше, то хотелось бы узнать про эти другие движки.
Если же должен просто догнать другой движок, то тоже хотелось бы узнать его название.
А так больше походит на ограбление корованов.
Я даже не понял, почему "Ещё раз". Какой-то новый подход, похоже?