Mercury13

Дело в том, что 4,2 и 4,3 невозможно представить в виде double. И система, например, сохраняет 4,3 в виде 4,2999999, которое при умножении на 10 станет 42,999999.
Нужно убедиться, что при преобразовании double → int происходит round, а не усечение.

Главная проблема.

const char *source = fmt::format("/tmp/{}.ini", unid).c_str();

Объект fmt::format сразу же исчезнет, и source будет «висеть».

Придётся писать…

fmt::format fmSource("/tmp/{}.ini", unid);
const char *source = fmSource.c_str();

И так далее.

Считаем, что у нас FPS, т.е. есть некая абсолютная «горизонталь». Обычно в таких играх взгляд хранится через углы (yaw, pitch, roll).
Взад-вперёд: знак скалярного произведения двух векторов: единичного вектора взгляда без учёта тангажа (cos(yaw), sin(yaw)) и вектора на персонажа (x1−x0, y1−y0).
Влево-вправо: знак косого произведения той же пары векторов.
Вверх-вниз: и так понятно.
Все три в одних единицах, и у кого модуль больше, то и пишем: сверху, справа и т.д. Возможно, придётся сделать скидку на рост персонажей и их диаметр.

В играх типа Descent нет верха и низа, горизонтали и вертикали. Верх и низ есть только относительно кабины нашего аппарата, а взгляд хранится в виде ортонормированной матрицы, куска этой матрицы или кватерниона.
1) Скалярное произведение единичного 3D-вектора взгляда (обычно в таких играх хранится напрямую или считается через кватернион поворота) и 3D-вектора на персонажа.
2) Скалярное произведение единичного вектора, который смотрит вбок (если такой есть), и вектора на персонажа. Либо смешанное произведение единичного вектора взгляда, единичного вектора макушки и вектора на персонажа.
3) Скалярное произведение единичного вектора макушки и вектора на персонажа.

Смешанный случай — с переменным вектором гравитации (в глобальных авиасимуляторах или играх на астероидах) — распиши сам.

Есть две разные задачи.
1. Просто. Пронести программу через систему безопасности при условии, что твой компьютер — «тихая гавань» и можно спокойно декодировать и запустить. Например, чтобы сбить с толку антивирус Gmail.
2. Сложно. Твой компьютер — уже не «тихая гавань», на нём действуют системы безопасности, и требуется их как-то обойти. Или, например, мы распространяем вирус, а в роли системы безопасности — бдительный пользователь.

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

Чтобы решить вторую задачу, надо в программе (Word, WinRAR и т.д.) найти эксплойт типа «исполнение произвольного кода».

Перенести пользовательскую функциональность в другое место — так называемый «слушатель».

using EvClick = void (*)();

Class Model{
public:
  void click() { if (fOnClick) fOnClick(); }
  void setOnClick(EvClick x) { fOnClick = x; }
private:
  EvClick fOnClick = nullptr;
}

Подобные слушатели есть в любой визуальной оконной библиотеке: VCL, Qt. В VCL так и есть, за исключением вписанных в синтаксис свойств. В Qt для этого используют сигналы-слоты.

Наладить передачу любых данных в эту функцию — шаблон «команда».

class ClickEvent {
public:
  int x, y;
  virtual ~ClickEvent();
}

using EvClick = void (*)(ClickEvent&);

Именно так и делать. Потому что от вас требуется наладить шаблон «Public Морозов» в очень тяжёлых условиях (нет даже заголовка). Так что вам придётся повторять то, что обычно делают компилятор и линкер.

Может помочь устройство таблиц виртуальных методов и dynamic_cast именно в вашем компиляторе. Например, на MinGW у меня получилось вот такое.

#include <iostream>


class A {
public:
    int a;
    virtual void doA() {}
    virtual ~A() = default;
};

// class B, C, D, E  аналогично {

class DE : public D, public E { int de; };
class AB : public A, public B { int ab; };
class CDE : public C, public DE { int cde; };

class All : public AB, public CDE {};


struct Vtable {
    uint32_t d[1];
};

union PObject {
    void* asVoid;
    Vtable** asVtable;
    char* asRaw;
};

int main()
{
    All all;
    All* pAll = &all;
    E* pThis = &all;
    std::cout << pAll << " " << pThis << std::endl;

    PObject pX;
    pX.asVoid = pThis;
    while (true) {
        uint32_t offset = -(*pX.asVtable)->d[-2];
        std::cout << "Got offset " << offset << std::endl;
        if (offset == 0)
            break;
        pX.asRaw -= offset;
        std::cout << "Got pointer " << pX.asVoid << std::endl;
    }

    return 0;
}

До промежуточного потомка (DE или CDE) достучаться не удалось.

https://www.youtube.com/watch?v=0xBJwrm9C8w
https://www.gdcvault.com/play/1023139/Level-Design...

https://www.rockpapershotgun.com/2015/01/22/how-to...

https://www.gamasutra.com/blogs/AsherEinhorn/20150...

Есть ещё книга «Fundamentals of puzzle and casual game design», но я её пока не видел в лицо.

И без бета-тестеров никуда. Сам не делал уровни, но один знакомый нарисовал немаленький мод к Braid — бета-тестерами служили его отец и я.

Вот ещё нашёл по Braid: gamedesignreviews.com/reviews/braid-understanding-...

ПОЛОЖЕНИЕ В ПАМЯТИ
Без new: static/глобальная — в сегменте данных, локальная — на стеке. В сегменте данных память отводится при компиляции линковке, создать стековый фрейм — две команды процессора.
С new: в куче. Управление кучей — довольно сложная задача, и если этих new много, программа может начать тормозить.

ВРЕМЯ ЖИЗНИ
Без new: объект живёт, пока выполнение находится в данном блоке. При выходе из блока автоматически срабатывает деструктор.
С new: уничтожаем, когда хотим.

ИМЕНОВАНИЕ
Без new: объект привязан к своему имени.
С new: объект безымянный (имя только у указателя). Потому возможны структуры данных переменного размера: динамические массивы, связанные списки, деревья и прочее.

РАЗМЕР
Без new: задан при компиляции. То есть массив на 10 позиций, и точка, больше — только перекомпиляцией.
С new: произвольный.

После move-каста содержимого shared_ptr мы говорим: объект под shared_ptr идёт на заклание, и в операциях перемещения мы можем потрошить его как угодно — лишь бы объект остался корректным. В данном коде (как я уже писал, он не компилируется) у нас одни ссылки, и не будет ровным счётом ничего: не выполнится ни одна операция перемещения.

Однако возможна такая ситуёвина, никак не связанная с временными ссылками. Во втором есть неуправляемая ссылка на первый — и при определённых условиях она может стать висячей.

Если в T2 всё-таки не ссылка, а экземпляр (T1 m_var), возможно, операция перемещения оставляет объект под ptr в некорректном состоянии, и деструктор ~T1() не может его уничтожить, или какая-то из операций над ptr не подозревает, что объект под ptr выпотрошен.

UPD. Что делает updateSearchResults? Только он может продлить время жизни объекта, сохранив где-то shared_ptr.

UPD2. Константная временная ссылка (const T&&) никакого смысла не несёт (по факту в STL пару раз используется). «Неизменный» и «можно выпотрошить» — это слегка противоречивые вещи.
И всё-таки я грешу на updateSearchResults, который сохраняет где-то объекты. Проблема может решиться, если в PoiSearchPlacesLocation ссылку заменить на shared_ptr. И — ВНИМАНИЕ — соответствующим образом подкорректировать сигнатуру конструктора. У shared_ptr есть конструктор, который берёт под управление любой объект-указатель, создавая новый счётчик, но хреново будет, если один и тот же объект управлять двумя разными счётчиками.

Пусть турнир назначен на этаже X.
На этажах 1…X живут L’ людей, на этажах X+1…N — H′ людей.
Вопрос 1. Стоит ли переносить турнир на этаж X+1?
Тогда для L′ людей добавляется лишний этаж, для H′ — исчезает лишний этаж, и выигрыш будет H′−L′.
Стоит, если H′ > L′. Не стоит, если H′ < L′. Безразлично, если H′ = L′.

Вопрос 2. Возможно ли такое: вверх на 1 перенести не удаётся (будет хуже или безразлично), но этаж Y > X оптимальнее (строго)?
Раз вверх на 1 перенести нельзя, то H’ <= L’.
Если этаж Y − 1 безразличен с Y, перенесём турнир туда. Если Y − 2 тже безразличен, то туда, и т.д. Остановимся на этаже Z. Видно, что Z > X + 1: если мы в результате этих движений добрались до X+1, то он лучше X, противоречие.
Раз Z — оптимальный этаж, то у этажа Z−1 > X есть свои L″ и H″, и поскольку с Z−1 на этаж вверх перенести всё же можно, то H″ > L″.
С другой стороны, при повышении этажа увеличивается L и уменьшается H, и L″ >= L′ >= H‘ >= H″, то есть H″ <= L″. Противоречие.

Следствие 3. Если турнир выгодно перенести на несколько этажей выше/ниже, то его выгодно перенести и на этаж выше/ниже.

Задача 4. Пусть на этажах 1…X−1 живут L людей, на этаже X — M людей, на этажах X+1…N — H людей.
Для простоты считаем, что сверху и снизу есть по фиктивному пустому этажу — то есть теоретически можно (на практически неоптимально) проводить турнир в подвале и на чердаке.
Задачу с переносом турнира вверх мы уже решали, и условие того, что турнир нельзя (или безразлично) перенести на этаж вверх: H <= L + M.
Условие того, что турнир можно (или безразлично) перенести с этажа X−1: H + M >= L.
Поскольку H + M + L = N (кол-во людей), то эти условия можно записать в виде: L + M >= N/2, L <= N/2
(всё, получили чеканное условие, и ключи от чердака и подвала можно отдать техслужбам гостиницы.)

Решение: Идём по этажам, считаем людей. Где накопится N/2, там проводим турнир.

// считаем полное кол-во
N = 0
для i = [0..nFloors)
  N += a[i]
// ищем, где половинка N
sum = 0;
для i = [0..nFloors)
  sum += a[i]
  если sum * 2 >= N
    вывести: i
    СТОП

Расширенное решение: Если накопилось ровно N/2, безразличны данный этаж, все нулевые над ним, и ещё один ненулевой. (Можно без кода?)