AN
Я если и собираюсь их писать в проекте, то начинаю сразу
Size: a a a
2020 April 02
AN
А там где не хотел их писать их просто нет (проекты такие маленькие)
L
(а вот это как раз для рнд неважно)
Но когда я в итоге буду это всё выкладывать, то там оно останется. Все эти бесконечные коммиты
fix, it works, add something, wtf и так далее. Впрочем всем пофиг, если оно после релиза будет нормальноL
Кстати уменьшение количества RenderPass ещё и на производительности сказывается. При том достаточно сильно для некоторых случаев. Например если я пытаюсь рендерить 6 шадоумапов по 8196x8196 и чтоб всё это в 4к, то демка уже начинает тормозить.
L
А на счёт говнокода тут есть и более весёлые штуки. Это я в ближайшее время уберу, но пока так
R
Pro Tip:
fn re<'a, 'b, T>(v: &'a T) -> &'b T {
unsafe { &*(v as *const T) }
}R
Так сильно лучше
L
Так сильно лучше
Да, ты прав. Но вообще эта штука - временный костыль, который есть тут из-за того, что разные части кода находятся на разном этапе рефакторинга. Добавлю нормальный (в пределах этой демки) менеджер ресурсов - так сразу лучше станет.
R
Вообще
std::mem::transmute почти никогда не нужен. Лучше обойтись указателями с кровьюL
Вообще
std::mem::transmute почти никогда не нужен. Лучше обойтись указателями с кровьюА когда без него прям ну совсем совсем никак?
AN
В общем делаем вывод, что рефакторинг нужен всегда
p
Вообще
std::mem::transmute почти никогда не нужен. Лучше обойтись указателями с кровьюЯ трансмьютил лайфтаймы ним
p
А на счёт говнокода тут есть и более весёлые штуки. Это я в ближайшее время уберу, но пока так
На всякий случай: трансмьют из меньшего лайфтайма в бОльший - УБ если данные живут меньше чем бОльший лайфтайм
L
На всякий случай: трансмьют из меньшего лайфтайма в бОльший - УБ если данные живут меньше чем бОльший лайфтайм
Я знаю. Но в данном конкретном случае у той штуки, к которой я применяю, на самом деле гораздо больший реальный лайфтайм. А с учётом того, что это демка, то этот лайфтайм вообще можно считать статическим. С другой стороны там всё равно удобнее сделать отдельную сущность, которая хранит эти штуки.
p
Я знаю. Но в данном конкретном случае у той штуки, к которой я применяю, на самом деле гораздо больший реальный лайфтайм. А с учётом того, что это демка, то этот лайфтайм вообще можно считать статическим. С другой стороны там всё равно удобнее сделать отдельную сущность, которая хранит эти штуки.
Данные живут столько сколько ссылка или меньше?
p
Если меньше - УБ
L
Данные живут столько сколько ссылка или меньше?
В данном конкретном случае данные живут столько же, сколько и программа. Но вообще я просто не доделал там кое-что. Доделаю и хак полностью исчезнет.
R
На самом деле нет. Можно иметь ссылку с большим лайтаймом чем живут данные