Войти
СайтФорумОбсуждение

Заявки на публикацию статей. (16 стр)

Страницы: 112 13 14 15 16 17 Следующая »
#225
1:50, 7 ноя 2022

И я написал
https://gamedev.ru/code/articles/cpp_coroutines_1

#226
(Правка: 3:09) 3:08, 7 ноя 2022

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

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

#227
(Правка: 3:38) 3:23, 7 ноя 2022

почитал статьи.

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

по поводу минимальных изменений контента я бы рекомендовал как можно большее внимание уделить самому первому абзацу: после его прочтения даже у человека, не имеющего представления о твоих проблемах, должно сложиться предельно чёткое впечатление, о чём именно будет статья и чего пытается добиться автор. например, сейчас вообще не ясно, чем именно тебя не устраивают наивные решения вроде std::map<std::string, ResourceHandle>, и что именно ты понимаешь под "Но что делать если этот способ не подходит?". потому что не подходить этот способ может по миллиону причин, а ты будешь рассматривать альтернативные подходы для решения какой-то одной (неизвестно какой). даже после прочтения статьи, я так и не понял, по каким именно критериям ты хочешь оптимизировать своё решение: алгоритмическая сложность, расход памяти, время компиляции, динамическое расширение пула ресурсов, итп.

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

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

==Текст==
===Ещё текст===

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

/A\
тоже рекомендовал бы внести ясность в самый первый абзац, добавить ещё более высокоуровневое введение: что такое корутины (возможно, написать термин или оставить ссылку на википедию), какую проблему они решают и почему для их решения вообще необходимы изменения в компиляторе, почему их нельзя написать на уровне библиотеки и существующего стандарта. также пара слов о том, в чём они могут помочь и кому они могут понадобиться. представь, что будет знать твой потенциальные читатель и попытайся максимизировать полезность для него. например, если твой потенциальный читатель уже знает, для чего нужны корутины и как ими пользоваться и он уже программирует на C++, то он с большой вероятностью уже в курсе, как они будут реализованы в С++ в будущем стандарте. если же он этого не знает, то по твоей статье будет трудно разобраться. это особенно актуально в свете того, что ты называл статью "начальный уровень", хотя в текущем положении вещей читатель с начальным уровнем не поймёт, что присходит.

All
если вы вносите изменения, но по каким бы то ни было причинам ваши статьи не публикуются или не рассматриваются, то пишите мне в личку, я готов разбираться.

#228
3:34, 7 ноя 2022

Suslik
> по поводу минимальных изменений
Обращаться следует не ко мне, так как статью уже кто-то удалил.

#229
3:36, 7 ноя 2022

samrrr
> > по поводу минимальных изменений
> Обращаться следует не ко мне, так как статью уже кто-то удалил.
прошу прощения, у тебя статья называлась https://gamedev.ru/code/articles/Resource_nanes_in_engine , я исправил на https://gamedev.ru/code/articles/Resource_names_in_engine и забыл упомянуть, что это ломает существующие ссылки.

#230
(Правка: 3:38) 3:37, 7 ноя 2022

Suslik
> эти теги поддерживаются только в разделе статей и многие пользователи, видимо, не знают об их существовании
так точно) исправлю чуть позже

#231
3:37, 7 ноя 2022

Suslik
> примечательно, что эти теги поддерживаются только в разделе статей и многие
> пользователи, видимо, не знают об их существовании.
А откуда мне было о них узнать? Сорцов форума у меня нету. Никакой инфы найти не смог. Даже чтоб просто нарисовать красивую таблицу пришлось перебирать с десяток вариантов как пропихнуть стиль в элемент.

#232
3:39, 7 ноя 2022

samrrr
> А откуда мне было о них узнать? Сорцов форума у меня нету. Никакой инфы найти
> не смог. Даже чтоб просто нарисовать красивую таблицу пришлось перебирать с
> десяток вариантов как пропихнуть стиль в элемент.
основные правила оформления статей написаны тут: http://wat.gamedev.ru/articles/AddArticles

#233
3:40, 7 ноя 2022

Suslik
> это ломает существующие ссылки.
Исправил 2 ссылки.

#234
4:25, 7 ноя 2022

Suslik
> я не согласен ни с предложенными решениями, ни с аргументацией.
3 из 4 решений набраны из интернета и я их видел в реальных проектах.
Способ с ид-шками от меня. Он лучший по памяти на инстанс. Да и похож на то, как в унижайне наделали ууиды.

Suslik
> алгоритмическая сложность, расход памяти
Вот по этим, добавил там.

Suslik
> не пиши номера пунктов в заголовках параграфов, не встречай юзера стенойкода
> под спойлером в первом абзаце, используй подзаголовки, итп.
То, что ты написал я поправил. Что скрывается за итп мне неизвестно. Код убрал под конец, хотя я часто встречал что исходнички даются на начале статьи.

#235
4:26, 7 ноя 2022

Suslik
> было ли авторам высказано, над чем необходимо поработать для публикации?
Никто ничего не писал мне.

#236
(Правка: 5:10) 5:06, 7 ноя 2022

samrrr
всё равно после введения у меня остаются вопросы по поводу того, что происходит:
> Обычно в движке предоставляется способ создавать и менеджерить ресурсы(ассеты) и получать их с помощью char* строки. А что если самописный движок, или подобной функции в движке нету?
после прочтения у меня лично в голове возникает картина: "окей, хорошо, то есть статья будет про альтернативу std::map<std::string, ResourceHandle> для своего велосипеда?". но следующий вопрос "но что если самописный движок?" построен так, будто он должен спихнуть читателя с наивного решения, которое у него уже наклёвывается в голове, хотя по факту он его только подтверждает. то есть я не понимаю, какой смысл вообще рассматривать менеджмент ресурсов _вне_ контекста самописного велосипеда, так как в существующем движке, наверное, и система ресурсов будет существующая, и подобных вопросов у тебя даже не возникнет. то есть я вообще не понимаю, к чему тут вообще упоминание "что если движок самописный" и что ты этим хотел сказать.

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


пытаясь понять твою мотивацию, я читаю дальше по тексту:
> Всё бы хорошо, но 8 байт для имени слишком много, да даже 4 многовато. А что если постараться ужать до 2?
> В итоге получается ещё 1 вариант, когда сохраняется не указатель, а индекс.
> Более 60к различных строк так не уместить
откуда взялось число 60к? что мешает мне выделить память под гигабайт 8-битных идентификаторов и обмазаться строками на всю жизнь?

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

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

под "итп" в оформлении я бы рекомендовал обратить внимание на то, чтобы курс статьи прослеживался, если просто пробежаться по заголовкам. в настоящий момент у тебя название статьи и введение содержат в себе тему менеджмента ресурсов, а тело — способы хранения строк. то есть, прочитав название и введение я ожидаю увидеть статью про стриминг, отложенную загрузку, кеши ресурсов, а вижу почему-то что-то про хранение строк. вероятно, имеет смысл прояснить — ты либо пишешь статью про хранение строк, либо про менеджмент ресурсов, либо стоит объяснить, как они оказались в одной статье.

также для хранения эффективных строковых идентификаторов ты не рассмотрел стандартные/типовые решения: компайлтайм хеши строк.

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

All
ещё к сведению всех авторов: классическая схема: Введение-Мясо-Заключение существует не просто так. если у вас мутное введение, то ясня мотивация, какую именно проблему вы решаете и в каком контексте. если у вас нет заключения, то статья выглядит незавершённой и не понятно, что вы хотели сказать. большинство авторов типично уделяют наибольшее внимание мясу статьи, поэтому тут обычно вопросов меньше всего.

#237
(Правка: 5:52) 5:52, 7 ноя 2022

Suslik
> и система ресурсов будет существующая
Практика показывает, что это не всегда так. Не все движки допилены до уровня анреала и не у всех система ресурсов вообще есть. В том-же анреаде просто найти актор по имени невозможно, и предлагается пройтись по всем инстансам в мире чтоб найти нужный. https://docs.unrealengine.com/4.27/en-US/InteractiveExperiences/H… indingActors/

Suslik
> откуда взялось число 60к?
65536 это изменил там

Suslik
> что мешает мне выделить память под гигабайт 8-битных идентификаторов
8 бит хватит только на 256 строчек.

Suslik
> если будешь использовать адреса статических строк в качестве идентификаторов
Нахаченные способы завязанные на компилер и ведущие к множеству багов я не рассматриваю в этой статье.

Suslik
> также для хранения эффективных строковых идентификаторов ты не рассмотрел
> стандартные/типовые решения: компайлтайм хеши строк.
Один хеш записать не прокатит, так как коллизии никто не отменял. Да и способ с пуулом выйграет его по практически всем параметрам. На память это тоже никак не повлияет. Если же ты про фантазии от автора entt, то этот фокус у него прокатывает только пока строк сотни-тысячи(где он его и юзает), на миллионах уже не прокатит и при коллизии проблем начнётся дофига, так как даже обнаружить что произошла коллизия практически нереально.

Suslik
> у тебя название статьи и введение содержат в себе тему менеджмента ресурсов,
Я про менеджмент ничего не писал, только про имена ресурсов. Постарался описать какие есть способы представления строк.

Если есть идеи получше как назвать статью, готов выслушать.

Suslik
> то есть я вообще не понимаю, к чему тут вообще упоминание "что если движок
> самописный" и что ты этим хотел сказать.
Немного переделал, вроде лучше стало.

#238
6:14, 7 ноя 2022

samrrr
если я правильно понимаю, что ты хотел донести, то статья вообще не про ресурсы, она про строковые идентификаторы. то есть слово "ресурсы" в названии и введении только создаёт ложное впечатление, что статья будет о менеджерах ресурсов в каком-то виде, когда она по факту — про идентификаторы. возможно, имеет смысл сформулировать как-то так:

"В программировании игр часто приходится ссылаться на объекты, используя строковые едентификаторы: например, получить текстуру по имени её файла или найти актора по его имени. Однако, хранение и частое сравнение большого количества строк может оказаться дорогим как с вычислительной точки зрения, так и с точки зрения используемой памяти. В этой статье мы рассмотрим альтернативные способы представления строк, которые позволяют оптимизировать эти операции."

> Нахаченные способы завязанные на компилер и ведущие к множеству багов я не рассматриваю в этой статье.
ты можешь рассматривать что угодно, но это вовсе не обязательно будет очевидным для читателя. в любой технической статье, предлающей решение какой-то проблемы, есть раздел с "Background/Prior work", где описываются преимущества и недостатки существующих решений, чтобы создать контекст. и замечания про "в принципе можно вот так, но мы не будем рассматривать такие решения, потому что вот" типично оставляются именно в этом разделе.

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

#239
12:59, 7 ноя 2022

Suslik
> классическая схема: Введение-Мясо-Заключение
Кажется я слышал анекдот, про то, что некоторые читают только заключение)
Правильнее все же: Мотивация->Реализация, заключение у каждого должно сформироваться свое, по мере прочтения статьи.

Кстати, обсуждение статьи перед публикацией можно делать в ней же в коментах, иначе в этой теме может переплетаться несколько веток обсуждений.

Страницы: 112 13 14 15 16 17 Следующая »
СайтФорумОбсуждение