немножко юморка подсыплю

вот с этого угарел недавно :guinda:

http://cs10378.vkontakte.ru/u226973/143686298/x_52fbf05b.jpg

тоже нормально
http://cs5699.vkontakte.ru/u226973/143686298/x_806463e4.jpg

будь тру, ёпта:miha:

Кто-нибудь сталкивался с реализацией изменяющейся плоскости/фигуры в трехмерном пространстве в VisIt?
Нужно со считалки, написанной на с++ передать массив в VisIt, который изменяется со временем, т.е. за единицу времени передаем по массиву. (VisIt 2.4.0, OS Windows XP)

ну я и через for нормально замутил

Можно, но тогда нахуя класс? Если в TField'е они хранятся в матрице и координаты матрицы (индексы т.е.) уже служат как координаты в самом поле, то нахуя там объект хранить с этими же координатами?
Вполне достаточно в матрице просто цвета хранить или, как я уже писал, значение перечисляемого типа, в случае, если там у каждого шара своя картинка.

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

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

Хотя, если делать с анимацией, то методы могут понадобиться для переключения кадра например. Но, в любом случае, координаты там хранить нехуя. Даже если они и нужны, то лучше делать через метод GetPosition: TPoint, который будет пробегать по массиву у TField'а сравнивая каждый элемент с этой хуйнёй и когда они совпадут, возвращать координаты массива. ЧТобы внезапно не вышло хуйни, когда в шаре координаты переписал, а в массиве переместить забыл.

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

Ты имеешь ввиду координаты шара в матрице или на экране?
Для анимации удобно хранить второе. А сами шары в списке списков.


хотя я не знаю какая система рисования в дельфи...
рассуждаю с точки зрения явера))

ну тут спорно :guinda:

Координаты шара на экране не надо хранить вовсе, они вычисляются исходя из координатов в сетке. А анимация происходит следующим образом: стоит таймер, который вызывается с каким-то интервалом. Ну и в нём вызывается TField.Draw, где в цилке идёт проход по шарам, у шаров хранится номер кадра, который и отрисовывается, после чего в таймере увеличивается на единицу, если номер кадра больше количества, то номер обнуляется и анимация идёт с начала.

Цискари здесь есть?)

а че спорно? только асм, только олдскул:boyara:

поясни вот это

Анимация спрайтовая. Вот шар
TBall = class
Frame: Integer; - Текущий кадр анимации
Frames: Integer; - Количество кадров анимации
Animation: Hz; - ссылка на объект, в котором хранятся сами изображения
procedure Animate; - переключается на следующий кадр. Т.е. Inc(Frame); If (Frame > Frames) then Frame := 0;
procedure Draw(x, y: Integer); Рисует Animation[Frame] в точке x,y
end;

По таймеру происходит следующее:
TField.Animate (анимация всего поля)
begin
for i := 0 to ColCount - 1 do
for j := 0 to RowCOunt - 1 do
if Assigned(Balls[i][j]) then Balls[i][j].Animate; - анимируем все шары
end;

TField.Draw;
begin
рисуем само поле на канве, т.е. хуячим сетку
for i := 0 to ColCount - 1 do
for j := 0 to RowCOunt - 1 do
if Assigned(Balls[i][j]) then Balls[i][j].Draw(i*на какой-то отступ, j * на какой-то отступ);
end;

при удалении набора шаров на их места падают верхние
для этого нужны координаты

даже в асме использование goto - очень плохой стиль

Чего?) Либо я тебя неправильно понял, либо ты чё-то с тетрисом путаешь).

наверное я думаю на другие lines... не помню как называются))))
там где вся матрица заполнена шариками и можно поменять местами два ближайших
собрав в линию несколько шаров одинакового цвета (минимум 3 вроде) они исчезают и на их места падают верхние :)

Не, здесь речь про такого плану шарики:
http://img11.nnm.ru/2/5/f/b/4/98c7f5339f8aebd270db0a19bc1.jpg

ага уже понял)
тогда да - всё просто

пиздец.
что-то хуйня какая.

В ксс-нике везде пропписано 330пх и 110пх (ибо 3 элемента, что в сумме дают 330 где надо, есличо)
и все равно, блять, отображается как 300 пх :mad: :mad: :mad:

блять, а проблема была в подключенном .js :trumi:

:black:

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

ну вот уж не знаю...
писал приложение со структурами на асме:blackust: заебался бы я там без goto:voin:

Так а нахуя создавать класс для объекта с одним единственным свойством (если анимации нет)?

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

Есть фигура, допустим прямоугольник, и находится она в точке например x=10 y=50, надо её плавно сдвинуть в точку например x=70 и y=60. Как мне рассчитывать промежуточные координаты? Можно конечно сдвигать по x на 6 и по y на 1 от начальной точки (x2-x1=60 и y2-y1=10, 60/10 = 6), но чую это ебанный сопособ. Можно ещё расчитать точки для прямой по Алгоритму брезенхема и по ним двигать, это вполне может выглядеть нормально, но впадлу алгоритм реализовывать :black:. Есть ещё какие-нибудь варианты?

ребята подскажите програму какуюнить для затирания глаз или лица на видео

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