Отзывы, впечатления, критика

StaticZ пишет: То-то различные эмуляторы плодятся как грибы после дождя, сейчас даже запуском виндозных приложений через Wine на Windows никого не удивишь.

Кстати, хорошая мысль.
Запустил Смайлы с линуха через вайн и там работает нормально.
Можно ставить шейдеры и максимальную графику.
FPS 20-30.
Работает на ноутбуке.
Можно пока поиграть так.
Прошёл 10 уровней, пазлы на первый взгляд вполне нормально сделаны, посмотрим как дальше будет.

[offtop]
Ну как сказать, эмуляторы хорошо, в том плане что софтварная эмуляция для нужд старых программ это правильно, например DosBox или что-то в этом роде.
Но современные приложения должны иметь грамотное сопровождение чтобы реагировать на изменения со стороны железа, драйверов, ОС.
Вот в вышеописанной истории с Betrayer, его разработчики ничего сделать не смогли, а разрабы FarCry4 воспользовались новыми возможностями драйверов и увеличили скорость антиалиасинга на 50%.
Для игр вообще принципиально важно, как можно более нативно использовать возможности железа.
[/offtop]

StaticZ пишет: Такое возможно лишь при 100% загрузке процессора, в противном случае все поступающие события обработчик успеет обработать. В случае если у вас 100% загрузка процессора снижение лимита FPS и\или детализации должно решить проблему (честно говоря не думаю, что в этой игре кто-то сможет почувствовать разницу между 20 и 60 FPS).

Я имею ввиду стандартный WndProc обработчик , который пишется ручками, прогер может явно (случайно или намеренно) написать обработку только одного первого сообщения.
Нагрузка на цп не имеет значения -- что закодировано, то и выполняется.
В вашем случае плохо то что это где-то внутри движка.
Изменение может повлиять на нестабильность других частей движка.
Можно конечно пошерстить API движка, если там есть возможность менять поведение обработчика, который внутри.

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

Нужно чтобы больше людей потестило.

UPD: Да ещё немного инфы:
В главном меню, есть анимация, она работает плавно, даже при движении мыши.
При выборе уровней тоже, судя по FPS, идет плавно.
Вот когда начинается уровень, уже при показе хелпа, начинаются фризы.
Также фризы и в меню паузы и в затенённом экране при старте уровня и в режиме завершения (где цветы).
Таким образом если у вас за главное меню и за игру отвечает код двух разных циклов, можно попробовать их повнимательней сравнить, вдруг что интересное выявится.

sam0delk1n пишет: Я имею ввиду стандартный WndProc обработчик, который пишется ручками, прогер может явно (случайно или намеренно) написать обработку только одного первого сообщения

Вроде там все нормально:

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

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

sam0delk1n пишет: В главном меню, есть анимация, она работает плавно, даже при движении мыши.
При выборе уровней тоже, судя по FPS, идет плавно.

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

sam0delk1n пишет: Вот когда начинается уровень, уже при показе хелпа, начинаются фризы.

В чем именно хоть эти фризы выражаются? дребезжание звука\музыки? падение FPS? рывко-образное перемещение курсора?

sam0delk1n пишет: Запустил Смайлы с линуха через вайн и там работает нормально.

Ну если уж на линухе через вайн работает, то дело явно не в железе а в ПО. Возможно кто-то вклинивается и тормозит системные вызовы или кто-то начинает действительно флудить сообщениями окну с игрой.

StaticZ пишет:

ВНИМАНИЕ: Спойлер!

Code:

while (1) { if (! PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { // Get current time tick. QueryPerformanceCounter(&nNow); // If it's the time to draw next frame, draw it, else sleep a while. if (nNow.QuadPart - nLast.QuadPart > m_nAnimationInterval.QuadPart) { nLast.QuadPart = nNow.QuadPart; CCDirector::sharedDirector()->mainLoop(); } else { Sleep(1); } continue; } if (WM_QUIT == msg.message) { // Quit message loop. break; } // Deal with windows message. if (! m_hAccelTable || ! TranslateAccelerator(msg.hwnd, m_hAccelTable, &msg)) { TranslateMessage(&msg); DispatchMessage(&msg); } }

Выглядит так, что управление никогда не войдет в условие if ( !PeekMessage( ... ) ), пока не закончатся сообщения. А они незакончатся если не останавливать движение мыши.

Возможно рисовалка вызывается ещё где-то в другом месте, например в 3 куске кода, по сообщению WM_PAINT (там к сожалению многоточие и не видно что происходит), но рисовать по WM_PAINT не очень надёжно, потому что ОС может предположить что окно имеет статическое содержимое и не будет его обновлять.

Если бы делал я, то написал бы например так (возвращаясь к условию из 1 части кода):

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

Вообще вот что: мне надо найти другую игру на кокосе или скачать демки с его сайта и посмотреть как они будут работать.

sam0delk1n пишет: Вообще вот что: мне надо найти другую игру на кокосе или скачать демки с его сайта и посмотреть как они будут работать.

Игр не нашел, но скачал sdk и собрал проект (тот что /build/cocos2d-win32.vc2012.sln), проверил на двух машинах -- работает нормально, без тормозов и фризов от курсора.
Качал последнюю версию, видимо у вас была старее.
Если укажете конкретно, могу её собрать.

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

Также заметил с таймером затеняющим смайл что-то странное бывает: он бывает делит смайл на 3 части: очень тёмная, слегка тёмная и незатенённая части, это нормально?

sam0delk1n пишет: Выглядит так, что управление никогда не войдет в условие if ( !PeekMessage( ... ) ), пока не закончатся сообщения. А они незакончатся если не останавливать движение мыши.

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

sam0delk1n пишет: Возможно рисовалка вызывается ещё где-то в другом месте, например в 3 куске кода, по сообщению WM_PAINT (там к сожалению многоточие и не видно что происходит), но рисовать по WM_PAINT не очень надёжно, потому что ОС может предположить что окно имеет статическое содержимое и не будет его обновлять.

WM_PAINT это запрос системы на перерисовку контролов, что посылается при каких либо изменениях (ресайз окна, сворачивание\разворачивание, скрол, перекрытие формы и т.д.). Все это не нужно для игр, т.к. они и так отрисовывают "экран" десятки раз в секунду. Тем более это OpenGL ему как и DX вообще побоку окно, им нужен лишь хендл для отрисовки. А рисовать впринципе можно где угодно, хоть в чужом окне или на рабочем столе (подобным образом кстати и работают некоторые видео плееры с такой фичей).

sam0delk1n пишет: Качал последнюю версию, видимо у вас была старее.
Если укажете конкретно, могу её собрать.

Естественно, использовалась версия 2.1.0 (2012-12-05), ревизия хз какая - качал релиз с сайта ибо замарачиваться чужими багами было лень.

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

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

sam0delk1n пишет: Также заметил с таймером затеняющим смайл что-то странное бывает: он бывает делит смайл на 3 части: очень тёмная, слегка тёмная и незатенённая части, это нормально?

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

Сейчас это должно выглядеть как-то так:

StaticZ пишет: А скрин можно? Вообще не нормально, это в первых версиях, что были на шейдерах был плавный переход от затемненной области к светлой.. Когда шейдеры убрали от всех красивостей пришлось отказаться .

А я шейдеры включил в файле конфигурации.

StaticZ пишет: Хотите сказать что каждую нано секунду курсор меняет свое положение? За одну милисекунду процессор выполняет огромную тучу кода. К тому же тогда было падение фпс. В обработчиках игр никогда тяжелого кода не бывает, да и до тех пор пока игра выдает хотя бы десяток фпс обработка событий не доставляет неудобств.

Почему нано? Там миллисекунды.
Там вызывается Sleep(1).
Вот его описание.
То есть проверка сообщений идет каждую миллисекунду.
А у меня самого есть мышь Razor 1000Гц, давно покупал.
Возможно сейчас половина мышей может работать на такой частоте.
А вот Вайн может и не обновлять так часто, там например стандартные 125Гц или даже меньше.
На самом деле можно проверить, чтобы не гадать.
Это же не сложно перекомпилировать?
Можно попробовать поставить Sleep(25) тогда любая мышь залепит приложение и возможно у Вас получится воспроизвести данный баг.

К WM_PAINT'ту тогда больше никаких вопросов.

Скрин стремный, чего-то не то явно...

sam0delk1n пишет: А я шейдеры включил в файле конфигурации.

На самом деле эта опция не работает.

Почему нано? Там миллисекунды.

Потому что обработка событий занимает наносекунды... Sleep(1) это приостановка активности приложения на 1 миллисекунду, иначе приложение будет грузить процессор на 100%, а с этой паузой загрузка будет 0% + % от логики приложения.

А у меня самого есть мышь Razor 1000Гц, давно покупал.

Это тут вообще не причем, это частота опроса грызуна, нужна для большей чувствительности и "разгона" грызуна (т.е. позволяет лучше учитывать не только пройденное расстояние, но и скорость перемещения). Всем этим занимается драйвер грызуна, система же посылает сообщения окнам только при каких либо изменениях.

Возможно сейчас половина мышей может работать на такой частоте.

Никогда не задавался таким вопросом, я даже без понятия какая частота у моего грызуна )

Это же не сложно перекомпилировать?
Можно попробовать поставить Sleep(25) тогда любая мышь залепит приложение и возможно у Вас получится воспроизвести данный баг.

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

sam0delk1n пишет: Это же не сложно перекомпилировать?
Можно попробовать поставить Sleep(25) тогда любая мышь залепит приложение и возможно у Вас получится воспроизвести данный баг.

Пробовал и 100 - разницы вообще не заметил, лишь при значениях близких к 1000 получаю тупо черный экран. Тем не менее сделал, как просили: rghost.ru/60187837