Добрый день!
Хорошая статья, но мне кажется для начала стоило бы показать реализацию 1D, а потом расширить ее на 2D случай, для тех, кто никогда не сталкивался с кольцевыми буферами. Мне кажется, во-первых так было бы проще для понимания для новичков, во-вторых, было бы видно, как правильно делается переход между 1D->2D, ну и далее по аналогии можно перейти 2D->3D.
Сам в основной своей деятельности использую 1D версию, с 2D приходилось работать только 1 раз.
Простите пожалуйста, это первая статья, материал как я понял должен быть полностью уникален, а канонический «кольцевой буфер» первой ссылкой из гугл идет на статью википедии, предельно подробно его описывающую. Но наверное я тут все же схалтурил, стоило привести ссылку.
Просто по каноническому 1д случаю мне нечего привести сверх того. На всякий случай, вот ссылка
Я возможно буду не прав, но имел ввиду что подобный материал лучше подавать от простого к сложному, пусть даже часть материала будет присутствовать где-то на других ресурсах. Я лично не вижу в этом ничего плохого. И мне лично кажется, что хорошо, когда весь материал в одном месте и не надо прыгать по сторонним ссылкам и искать материал в Гугле.
Лично я довольно неплохо знаком с классическим кольцевым буфером, но возможно тем, для кого эта тема нова, будет интересно прочитать все в одном месте.
Очень рад, что вам так понравился мой первый пост. Надеюсь это начало интересного и полезного многим цикла. Имел практику ведения IT кружка в школе, с тех пор фанат обсуждения и проектирования алгоритмов, постараюсь и впредь «разжевывать» все не менее подробно!
На сколько я вижу на картинке тор (поверхность тора) — это уже топологическое представление опубликованного алгоритма — 2д случай буфера. Хотя визуализация может зависеть от того какой «вид» требуется.
А для простоты понимания, я сам предпочитаю не вводить абстракции вносящие «искажения пространства»
Особенно 3д случай представлять рекомендую просто как куб, противоположные стороны которого связанны «перемещающими порталами». Скучно, зато просто и понятно =)
А я написал не «2д буфер», а «RING буфер — 2д случай». Вы правы, конечно, я сам думал назвать ли алгоритм «тор-буфер», но решил не плодить громких не канонических названий. Все таки, RING буфер на слуху. И я предположил многим такое название скажет больше.
Именно такое я использовал на Java ME для реализации прокручивающегося плиточного фона.
Определённый расход памяти компенсировался высочайшей скоростью (ок. 8 fps в окончательной игре на Samsung C100, 12…15 fps — на Nokia S40).
Вот это совпадение! Я тоже использовал его первый раз для прокрутки тайл карты для J2ME, для экономии скорости тоже. У меня там был генератор рельефа, и хотя он был достаточно быстрый. (давал 8fps вообще без кеширования) я счел сделать запас на слабые модельки. С ним за один кадр не требовалось генерировать больше одной строки или столбца карты.
Там кстати был еще один интересный алгоритм: рендер тайлов «переходов» текстур. Аналог marching squares, о котором я узнал потом. Но, при всей скромности, мой кажется лаконичнее, при внешне близком результате.
Я наконец дорос (или осмелился) вынести на суд Хабру некоторые наработки. Если интересно могу написать и про него.
You can still code in an object oriented style in C, simply using struct's as classes, and 'methods' are just functions that take a pointer to a class.
in low-level like C, this can be done greater, but not a lot of hight-level languages can be done this so
I guess, this is available when i use one-dimensional array, and whatever i must fix tail-head join. If you mean that i can rebild the structure ever when i need to «spin» the buffer — NO, i don't want!
RING буфер — 2D cлучай