|
Результаты поиска
| |
| Morfay | Дата: Понедельник, 23 Июля 2012, 10:53 | Сообщение # 1 | Тема: VI заготовка чат бота с++ |
|
почетный гость
Сейчас нет на сайте
| По идее, БД надо с полями "обращение - ответ", или хотя бы текстовый файлик. Ифами проверять...  (представь что у тебя 300 фраз будет - это ж 300 ифов. а если фраз 2000?). Да и не полностью строку проверять, а делать анлизатор хотя бы примитивный, потому как, для проги "Привет бот" и "Бот привет" (да что там, даже "Привет бот.") будут разными. Следовательно, надо разбивать обращение на отдельные слова и искать в БД лучшее совпадение, и его уже выводить как ответ. Тут уже получится какой-никакой чат бот (тупенький правда).
|
|
|
| |
| Morfay | Дата: Вторник, 10 Июля 2012, 17:38 | Сообщение # 2 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Quote P.S. А вообще для файтингов очень неплохо использовать скелетную анимацию , будет и с анимацией проще и с физикой.
Может и проще, но я не знаю куда копать. На момент начала работы, думал обо всем этом, учитывая все возможные варианты (будет у меня помощь или нет, вложение собственных денег и прочее), решил, что спрайтовый движок для меня будет проще потянуть одному. С физикой особых проблем не должно быть (ну кроме как столкновения), так как ничего сложного не планирую - практически все на базе школьного курса механики и кинематики. С анимацией тоже особых проблем нет - как художник нарисует так и будет (то что художника нет, это уже другая проблема  ). В любом случае, это работа не ради гипотетически возможных денег (не скрою, не плохо было бы заработать, но это не главное), сколько ради опыта и фана (+ в идеале, неплохое подспорье при устройстве на работу).
|
|
|
| |
| Morfay | Дата: Вторник, 10 Июля 2012, 15:26 | Сообщение # 3 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Вот набросал быстренько в пэинте.
Тут два теста - ломанная для левой и правой стороны. Подгонял на глаз (погрешность в 1-2 пикселя), точность = 10 (каждую 10 строку проверяет)
Сообщение отредактировал Morfay - Вторник, 10 Июля 2012, 15:26 |
|
|
| |
| Morfay | Дата: Вторник, 10 Июля 2012, 13:28 | Сообщение # 4 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Quote (Archido) Ммм, ща еще раз все перечитал на свежую голову - т.е. ты получается строишь контур из отрезков на основе пикселей и проверяешь пересечения между, собсна, отрезками. Так? Если так, то можно строить контур заранее при загрузке изображения, например. Для анимированных спрайтов может это и жирновато, но я не думаю, что таких будет очень много.
А вообще, хотелось бы увидеть как выглядит построенный многоугольник. Наверняка для отладки на это можно визуально посмотреть.
Строить и хранить контуры в начале? Ну можно наверное, но может быть жирновато по времени. Дело в том, что еще при описании идеи я понимал - многоугольник, полностью описывающий фигуру, - это очень долго (По первым тестам, полностью описанная сложная фигура с шириной и высотой в 246 пикселей, с точностью 1, многоугольник строиться около секунды). Если представить, что в спрайте около 10-20 сильно различающихся фигур (это как минимум), то уже имеем 20 секунд. А фигур может быть больше. В итоге, тратить пару минут на загрузку даже простенькой бродилки - не хорошо. Потому начал думать, как снизить нагрузку:
1) Использовать вначале прямоугольное определение столкновений - оно быстрое, позволит определить сталкивающиеся объекты.
2) Незачем строить полностью многоугольник, достаточно определить стороны, которые сталкиваются. Это позволяет сделать определение прямоугольных столкновений.
3) В зависимости от направлений, прогоняем нужный кадр спрайта, рисуем ломанную линию, запоминая точки в массив. Адаптировать координаты под экран (сейчас координаты считываются со спрайта)
Это то что реализовано сейчас.Дальше есть варианты:
4) Определяем линии и потом проверяем на пересечения.
Или
4) Нафиг определять линии, сразу использовать точки (нужные формулы уже выведены и только использовать и оттестить).
Вот как показать тебе ломаную (кроме как скрином кадра в спрайте и координат точек), я не в курсе. Сам проверял, отрыв в пэинте спрайт и проведя линии по точкам (точность 10 брал - 13 точек просмотрел быстро).
Сообщение отредактировал Morfay - Вторник, 10 Июля 2012, 13:30 |
|
|
| |
| Morfay | Дата: Вторник, 10 Июля 2012, 11:08 | Сообщение # 5 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Опробовал способ. Для корректировки добавил параметр "точность" - переменная, от которой зависит как точно будет пробегать алгоритм по рядам (при 1 пробегает по всем. При 10 - по каждой 10 строке или(и) столбцу). После некоторых преобразований (нам не нужно описывать весь объект, достаточно стороны, с которой идет столкновение (определяется из первоначального прямоугольного столкновения)), с точностью 1 многоугольник (вернее ломанная) строится за 0,5 секунды - достаточно много (высота изображения - 243 пикселя, количество точек = 143). Если нужно быстрота, то не подходит, если нужна высокая точность (очень высокая, так как линия проведенная по точкам полностью "облегает" объект в мельчайших подробностях), то может и сойдет. Но в большинстве игр такая точность не нужна. Выставив точность = 10, получил результат за 0.03 сек, и 13 точек (Довольно точных, для игры будет в самый раз). Точность = 20 - 6 точек, выполнение за 0,015 сек. Но результат уже чуть хуже, иногда линии проходит через объект (хотя, думаю, даже для файтинга погрешность в 10 пикселей не критична). В общем, результаты неплохие, возможно придумаю еще пару способов, как уменьшить время выполнения без снижения точности.
Не понимаю. Подумал о том, что можно по ряду идти не по каждому пикселю, а проскакивать через несколько. Но, при проверке каждого второго, выиграл примерно 0,001 секунды (погрешность в 1 пиксель мелочь, но и выигрыш не очень ). При проскакивании через 10, выиграл... 0,002 секунды (причем погрешность ~9 пикселей уже не радует). Нда, дополнительные результаты не радуют.
Сообщение отредактировал Morfay - Вторник, 10 Июля 2012, 11:17 |
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 19:00 | Сообщение # 6 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Идеи помогают сделать лучше (была у меня проблемка с отрисовкой всех объектов, так идея решающая ее не дотягивала до того, чтобы ее реализовать. Посоветовался с более опытными людьми, указали от чего избавиться, а на что обратить внимание.)
Quote Скажу только, что попиксельный collision все равно будет относительо медлителен при наличии большого кол - ва объектов, и часто он бывает избыточен
Ага, я тоже подумал, что если проверять попиксельно все объекты, то это будет жестоко. Потому решил скомбинировать с прямоугольной системой обнаружения - сначала проверяем все объекты им, если есть столкновение, то определяем уже точнее.
Я читал про способ что ты описал - он хорош (я его несколько раз видел). Но я как идеалист (  ) хочу попробовать сделать автоматическое распознавание. То есть, впихнул спрайт, а алгоритм сам найдет края и построит многоугольник, описывающий объект. Самая заметная проблема - время (понимаю, что расчет может быть не очень шустрым). Ну как реализую напишу что получилось, если интересно.
|
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 17:20 | Сообщение # 7 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Мне еще многому надо научиться. Спасибо больше, получил больше чем хотел... В общем, не хочу новую тему открывать, решил написать зачем это мне.
Quote Ну, в программировании по-другому и не бывает
Как и многие другие, увлекаюсь играми. Еще в колледже делал простенькие штуки (типа змеек), пробовал замахиваться даже на файтинг. Сейчас, для того, чтобы выучить язык, пытаюсь делать свой маленький двухмерный движок. В связи с этим, появилось несколько моих тем, с различными вопросами (Нохчи уже не раз в них отвечал, за что ему большое спасибо). Сейчас ковыряюсь в физической части движка. Хочу попробовать реализовать автоматическое определение столкновения повышенной точности между сложными объектами. Суть в том, что строится полигоны по точкам у двух сталкивающихся объектах и идет проверка на пересечение отрезков. Точки для полигона определяются перебором пикселей. То есть, идя по перовму ряду, находим пиксель отличный от самого первого (фонового) - это уже начинается наш объект => запоминаем координаты. Идем по следующему ряду и т.д. и т.п. Тесты по работы с пикселями (код адаптировал с одного урока по SDL) показал - на зеркальное отображение картинки весом в пол метра тратилось около 0,5 секунды. После некоторых улучшений, пробег по пикселям составлял до 0.01 - 0.02 секунды. Есть еще пару идей, чтобы уменьшить и это время. В теории все выглядит очень соблазнительно (+ первые тесты неплохи), сейчас проверяю на практике.
Написал как-то сумбурно, надеюсь поймете :D. Выслушаю любые комментарии и идеи.
|
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 16:55 | Сообщение # 8 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| А, понял. bpp идет как Uint8. В моем случае img->pixel доводим до Uint32, а потом складываем с Uint8. Оно-то сложится, но не так как надо. Потому преобразуем все в один тип, сложить, потом преобразовать результат в другой. Так?
|
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 16:35 | Сообщение # 9 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Наверное. Как я понял, img->pixel возвращает адрес на первый пиксель картинки. bpp в данном случае размер пикселя. То бишь, получить адрес первого, прибавить к нему смещение по строкам и столбцам (представив рисунок как массив пикселей) - получим адрес нужного. Потом получаем значение (*(...) вроде как разименовывание). Так что вроде как все логично...
Дело в том, что я самоучка. Потому только за, если ты объяснишь мне что тебя смущает.
|
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 16:19 | Сообщение # 10 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Хм, код такой же. Единственное отличие - у меня картинка формата png. Но раз работает нормально, то значит затуп у меня... и я его только что нашел
было
Code Uint32 pdst = *((Uint32*)img->pixels) + bpp ;
А надо так
Code Uint32 pdst = *((Uint32*)img->pixels + bpp) ;
Черт, мне стыдно - такая глупая ошибка. Но теперь все работает. Спасибо.
|
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 15:14 | Сообщение # 11 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Попробовал. Цвет 137, 0, 21. Странно, почему-то прибавляется к красному смещение по пикселям (По мануалу - пиксель занимает от 2 до 4 байт - потому и первоначальное смещение было на 4). Но почему так, не пойму.
|
|
|
| |
| Morfay | Дата: Понедельник, 09 Июля 2012, 13:22 | Сообщение # 12 | Тема: SDL_GetRGB - неверно определяет цвет? |
|
почетный гость
Сейчас нет на сайте
| Добрый день. Недавно, для одной идеи потребовалось определить мне цвета пикселей одной картинки. Все это делается с помощью SDL. Выкопал функцию SDL_GetRGB(Uint32 pixel, SDL_PixelFormat *fmt, Uint8 *r, Uint8 *g, Uint8 *b) - получает цвет пикселя и записывает его в указатели (r, g, b). Она как бы и подходит для задуманного, но первые тесты выявили странный эффект - берем залитую одним фоном картинку, определяем первый пиксель - 136, 0, 21, - все правильно, цвет именно такой. Берем второй пиксель = 140, 0, 21, следующий = 144, 0, 21 (видно каккое-то смещение на 4). Сначала грешил на то, что неправильно определяю пиксель(а цвет правильно показывает), но если картинка состоит из одного фона, то какой пиксель не возьми, везде же будет одинаковый цвет?!
как "хожу" по пикселям
Code
int bpp = img->format->BytesPerPixel;
Uint32 pdst = *((Uint32*)img->pixels) + bpp*posX +img->pitch*posY ; //переход на необходимый пиксель
Вопросов несколько:
1) Вполне возможно "хожу" по пикселям я неправильно. Потому если кто поправит, то будет хорошо.
2) Пользовал ли кто функцию SDL_GetRGB(...)? И не было подобных проблем?
3) На случай, если решения с SDL_GetRGB не будет - как еще можно определить цвет пикселя?
Заранее спасибо.
|
|
|
| |
| Morfay | Дата: Среда, 27 Июня 2012, 09:55 | Сообщение # 13 | Тема: Подключение своих .h файлов |
|
почетный гость
Сейчас нет на сайте
| Quote (zodiak) Лучше использовать в начале файла директиву гарантирующую разовое включение файла.
Да, действительно помогло. Спасибо.
|
|
|
| |
| Morfay | Дата: Вторник, 26 Июня 2012, 18:28 | Сообщение # 14 | Тема: Подключение своих .h файлов |
|
почетный гость
Сейчас нет на сайте
| ок, спасибо, опробую
|
|
|
| |
| Morfay | Дата: Вторник, 26 Июня 2012, 17:21 | Сообщение # 15 | Тема: Подключение своих .h файлов |
|
почетный гость
Сейчас нет на сайте
| Добрый день. Учу язык (с++) на практике - пробую писать простенький 2D движок. Уже получился довольно большой объем кода, решил его лучше организовать - выделить каждый внушительный класс (вместе с подклассами) в отдельные файлы. Дело пошло, создал пару файлов, перенес код, подключил в общей куче - работает. Но, столкнулся с проблемой:
К примеру, класс с методами отвечающими за работу с графикой у нас хранится в файле "Graphics.h". Эти самые методы нужны нам в многих местах, к примеру, отображение сцены (классы с методами в "Scene.h") - подключаем. Но если его же подключить еще в один файл (а их может быть много - работа с меню, текстом, - везде где могут понадобиться графические операции), то возникает ошибка "переопределение типа class". Реализацию таким образом подсказал друг, дружащий с php (там такой проблемы нет). Возможно стоит отказаться от .h файлов, но чем заменить? Или я что-то не учел и можно оставить как есть (естественно изменив так, чтобы работало)?
P.S. Я понимаю, что при сборке получается несколько описаний класса Graphics в общем котле, что и вызывает ошибку. Не понимаю только как можно это обойти.
|
|
|
| |
| Morfay | Дата: Четверг, 07 Июня 2012, 17:53 | Сообщение # 16 | Тема: Описание действий в игре. |
|
почетный гость
Сейчас нет на сайте
| Ок, с движением так оно и будет.А если от нажатия зависит какую анимацию проиграть? притом, что jump, run и jump+run - разные анимации?
|
|
|
| |
| Morfay | Дата: Понедельник, 04 Июня 2012, 17:53 | Сообщение # 17 | Тема: Описание действий в игре. |
|
почетный гость
Сейчас нет на сайте
| Ну да, большинство из них отвалится само собой. Но пару случаев останется. Но это так, мелкие неприятности.
|
|
|
| |
| Morfay | Дата: Понедельник, 04 Июня 2012, 17:40 | Сообщение # 18 | Тема: Описание действий в игре. |
|
почетный гость
Сейчас нет на сайте
| Quote (Matou) Тут надо с системой ввода разбираться.
Ну, я не знаю как тут придумать. При такой системе все логично: нажимаю jump -> result = 1, down - 2 (к примеру). jump + down -> result = 3. Если на это значение нет действия, то ничего не произойдет. Когда отпускаю какую-нибудь из них, result становится 1или 2, имеет определенные действия на эти значения и они выполняются.
Сообщение отредактировал Morfay - Понедельник, 04 Июня 2012, 17:41 |
|
|
| |
| Morfay | Дата: Понедельник, 04 Июня 2012, 16:35 | Сообщение # 19 | Тема: Описание действий в игре. |
|
почетный гость
Сейчас нет на сайте
| Matou, думал и об этом тоже. С работой и манипуляцией с битами дружу слабо, мой вариант был представить каждое действие в разной разрядности - Action1 - 1, Action2 - 10, Action3 - 100 и т. д. Тогда при сложении получилось бы тоже самое (только вместо Action1 | Action2, было бы Action1 + Action2). Этот вариант схож с тем, что предложил Apati.
Добавлено (04.06.2012, 16:35)
---------------------------------------------
вот, сделал. Вариант Apati, с небольшой доработкой - объявил константы (jump = 1, run = 2, kick = 4 и т.д.) Так проще делать проверку - вместо того чтобы считать какое значение получится (и изменять его, если вдруг в константе значения нужно поменять), я делаю проверку на jump, jump + kick, jump+run+kick и т.д. Срабатывание нормальное. Но, при нажатии левых клавиш, действий к которым нет (к примеру down+jump) персонаж ничего не делает, пока какая-либо клавиша из них не будет отпущена.
Сообщение отредактировал Morfay - Понедельник, 04 Июня 2012, 16:36 |
|
|
| |
| Morfay | Дата: Понедельник, 04 Июня 2012, 15:12 | Сообщение # 20 | Тема: Описание действий в игре. |
|
почетный гость
Сейчас нет на сайте
| Apati, вот, ток недавно думал об этом. В целом, удовлетворяет всем потребностям - больше 3-4 клавиш нажать нельзя => 3 (максимум 4) комбинированных действия. Даже беря максимум (4 действия) - 2+4+8+16 = 30. Отлично, на сегодня, это самый оптимальный вариант.
Было немного про это:
Quote делать побитовое логическое сложение, потом анализировать биты. Складывая и проверяя сумму можно получить тот же результат, но манипуляция с битами проще для понимания.
может кто подробнее объяснить как это реализуется?
|
|
|
| |
|
