Прошу советов мудрых по двоичным маскам.

А полный код ты где-нить выкладывал?

В этом твоём языке нет битовых операций?

Ничего не понял. Ты про саму механику битмасок? Загляни в sys/param.h и не изобретай велосипед:

/* Bit map related macros. */
#define setbit(a,i)     ((a)[(i)>>3] |= 1<<((i)&(NBBY-1)))
#define clrbit(a,i)     ((a)[(i)>>3] &= ~(1<<((i)&(NBBY-1))))
#define isset(a,i)      ((a)[(i)>>3] & (1<<((i)&(NBBY-1))))
#define isclr(a,i)      (((a)[(i)>>3] & (1<<((i)&(NBBY-1)))) == 0)

А ещё, если язык C, можно использовать bit fields. Или если место не проблема, не заморачиватья со всем этим и просто использовать int, как самый быстрый по времени доступа вариант.

Беспричинная экономия на битах к добру обычно не приводит.

UPD: проглядел в ОП про gambas, т.ч. бурчание моё не к месту...

выход симметрии за границу максимального количества лап

Шизофазия детектед.

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

Преждевременная оптимизация — корень всех зол. (с) Кнут

В этом твоём языке нет битовых операций?

Не знаю.

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

Я движок делаю.

Как будет лучше?

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

Я движок делаю.

Ну и что с того?

Bits Manipulation Functions
http://gambasdoc.org/help/cat/bit

Спасибо.

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

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

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

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

Я не предусмотрел логических переменных в GODC и не хочу усложнять логику отдавая 2D редактору морфид первого типа дополнительные ID. Впрочем под различные редакторы морфид я зарезервировал диапазон с 10000 до 20000.

Например в функциях поиска индекса свойства, я предусмотрел возможность «китайской» оптимизации которая позволит сэкономить один процедурный вызов.

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

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

В большинстве взаимодействий объектов будут проходить множественные обращения к свойствам и вызов связанного с ними кода который тоже в свою очередь будет обращаться к свойствам другого объекта. К тому же некоторые свойства своим наличием будут вызывать события которые опять же будут порождать обработку свойств. Думаю когда игра будет закончена, обработка каждого объекта будет будет занимать около 500 обращений к свойствам и вложенным в них GODC структурам.

Ты так и не ответил на вопросы.

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

Потому что Gambas, у него компиляция происходит в интерпретируемый байт-код.

Ты так и не ответил на вопросы.

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

То есть твой ответ заключается в том, что тебе кажется, что ты догадываешься, где именно в твоей программе будут узкие в плане производительности места? И ты хочешь заранее их «оптимизировать»?

Так вот в реальности, тот код, который ты сейчас пишешь, тебе придётся еще 5 раз переписать заново. Его нет смысла оптимизировать ни сейчас, ни при следующем переписывании, потому что ты успеешь еще несколько раз кардинально изменить логику его работы. Чем меньше ты сейчас закопаешь своего труда в «ускорение», тем меньше твоего труда будет выброшено в мусорную корзину. Не трать время на преждевременные оптимизации, двигайся дальше: построй полностью работающую игру.

Не знаю.

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

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

Всех функций встроенных библиотек не упомнить. Но мне уже в этой теме подсказали какие функции использовать. Устрою им тест производительности в общем.

https://dl.dropboxusercontent.com/u/86123252/projects/stare/20131225/StarE.zip

Ну тут полный код. Правда пока ещё даже редактор не работоспособен. Работают лишь классы управляющие данными игры и их текстовый сериализатор.

Почитай всё-таки документацию. Беглого взгляда достаточно, что бы сказать:

• сериализацию лучше делать через gb.xml;
• списки объектов лучше хранить в Collection, а не в массивах. Они хэшированные и поиск не нужен. Кроме того эти твои Resize постоянные производительности не добавляют;
• хоть это и не нужно, но разделять строки по '=' можно Split, а прочитать весь файл в переменную read #f, -1.

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

Раз уж ты рисуешь каких-то насекомых, то и погляди на настоящих насекомых. Например на таракана. Можно сказать, что он состоит из одной и той же части, повторенной и слегка изменённой много раз - сегмента (тельца) с четырьмя ответвлениями.

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

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

сериализацию лучше делать через gb.xml;

XML весьма трудно вручную редактировать.

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

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

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

Мне нужно сделать проверку модульной, что бы на сторону сервера передавать проект содержащий список файлов и команд модификаций. А сервер уже проверял бы правильный ли проект ему прислали.

Раз уж ты рисуешь каких-то насекомых, то и погляди на настоящих насекомых. Например на таракана. Можно сказать, что он состоит из одной и той же части, повторенной и слегка изменённой много раз - сегмента (тельца) с четырьмя ответвлениями.

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

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

Я примерно понимаю, но представить не могу.