>посылаю тонны НЕНАВИСТИ

лучше багрепорты, да

Слишком уже похоже не на баг, а на очередную «фичу» в стиле оперы а-ля «быстрая прорисовка, и пофиг на стандарты и что там написано в этих быдлоскриптах», потому как в load_n_play () происходит полная перерисовка поля.

Вот ты думаешь, что мы сейчас по этому куску, оторванного от вселенной, найдём в чём проблема?

Слишком уж похоже, что ты толст и будешь решать свои проблемы сам :}

Ах, да. Делать 'Уровень пройден!' через alert это просто песец.

Я спрашиваю про порядок выполнения внутри одной функции, остальное на нее не влияет. Код целиком можно здесь посмотреть: http://byss.ru/kosilka/ (осторожно, быдлокод!), только проблема таки если и есть, то внутри этой функции.

Там все настолько примитивно, что alert () туда вписывается наилучшим образом :)

А пользователей не жалко? Сейчас в Опере, конечно, этот диалог не модальный, но всё-таки :)

Хм… причём опция «прекратить выполнение скриптов на этой странице» в алерте прекращает скрипты, но квадрат дорисовывается.

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

Дело не в Enter, а блокировании гуя.

Есть мнение, что alert() блокирует выполнение (так оно и есть), а перерисовка происходит только после завершения. Надо бы проверить.

Действительно. Может, какая-то асинхронная отрисовка по canvas'у идёт, а alert ее почему-то блочит? Но всё равно, так быть не должно, я думаю.

Догадки

Сделай див и запиши в него, что предыдущий уровень пройден. Автоматически начинай новый :)

С текстом, такого, кстати, не случается. На миниатюрном примере также происходит — если просто поменять текст дива, например, то апдейт виден, при рисовании по канвасу — прорисовывается только после алерта. Сомневаюсь, что drawImage асинхронный сам по себе (куча алертов в бесконечном цикле оставляют всё как есть, хотя время то прошло по сути), но перерисовка, скорее всего, происходит только после завершения, т.к. draw-чего-то может быть много и постоянно перерисовывать то, что изменяется сейчас в скрипте неэффективно.

Хотя с другой стороны, текст то тоже меняется, ну да не знаю. Как вариант — спросить на форуме Оперы :)

>и пофиг на стандарты

И кстати что там в стандартах написано насчёт буферизации вывода на экран? alert() - на что обращает внимание Mystra_x64 - лишь прерывает исполнение.

Не нравится такое поведение - пеши в спортлото, там помогут.

Попробуй на последнем шаге воткнуть
var tmp_png = document.getElementById('gamefield_canvas').toDataURL();

А вот это помогло, спасибо. Кривовато, конечно, зато работает.

Давно же существует средство самоконтроля для программистов от криворукия. Называется ООП.

Имитация ООП очень повысит удовлетворение от работы, да :}

Який такой имитация?

В Javascript ООП это прототипированный песец, а не ООП :}

Ну а я о чем говорю? Какая имитация? Как в C++, чтоли?

>В Javascript ООП это прототипированный песец, а не ООП :}

Ви таки не любите прототипное ООП? Оно же прекрасно.

>Давно же существует средство самоконтроля для программистов от криворукия. Называется ООП.

JS

Либо ты считаешь, что JS это Ъ ООП (== извращенец), либо ты сам не помнишь, о чём речь.

Это ужасно и уродливо %)

>Это ужасно и уродливо %)

Отличное ООП там, просто привыкшим к простыне классов людям тяжело перестроиться.

В JS простыня не только не исчезает, но становится ещё уродливее. Стоит только посмотреть как это записывается.

Мне интересно, а вот как бы мне это Ваше ООП помогло бы прорисовывать клетку до алерта? Или лишь бы что сказать?

>В JS простыня не только не исчезает, но становится ещё уродливее. Стоит только посмотреть как это записывается.

Смотрел. В некрупных проектах (а какие нафиг крупные проекты на js в наше время то) необходимость наследования в том виде, в котором оно применяется в классическом ООП практически отсутствует. А объекты всё равно нужны, причем иногда как раз проще покрутить всякие prototype (не фреймворк), чем строить деревья классов. А обычного Object может не хватать. Вот тут и круто js-ное ООП.

>а какие нафиг крупные проекты на js в наше время то

Жквери, Прототипы не так что бы крупные, но уже немаленькие.

необходимость наследования в том виде, в котором оно применяется в классическом ООП практически отсутствует.

Есть или нет вопрос десятый (как по мне, то нужно, по крайней мере от одного предка), я про синтаксис. И JS-ной ООП выглядит как наверченная лапша. Уж лучше по старинке, класс описывать, чем так…

Есть такое слово «инкапсуляция».
Это когда все по полочкам, а не через ж*пу.
Один из ключевых принципов этого нашего ООП.

>Жквери, Прототипы не так что бы крупные, но уже немаленькие.

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

Есть или нет вопрос десятый (как по мне, то нужно, по крайней мере от одного предка), я про синтаксис.

Да ладно. Вместо классов - функции, пару непривычных приколов с private переменными, да и всё. Наследование через prototype. Чего там такого неудобного то.

Кстати прототипное ООП ещё в lua есть.

Повторяю вопрос: если бы я создал объект «Field», у которого был бы метод draw_pos (x, y), с тем же телом, что и у текущей функции draw_pos, что бы от этого изменилось? //Не понимаю, зачем применять ООП там, где оно не нужно.