Вы видите копию треда, сохраненную 12 сентября в 09:57.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
800x800, 2:15
pygame.mouse.set_cursor(hotspot, cursor_surface)
Так он еще и хардварный! Странно что ВолосатаяКартоха парится с софтварным.
... и получаешь репорт за политоту.
Пока через либу PyTMX: https://github.com/bitcraft/PyTMX
Потом, может, свой лисапед сочиню.
820x580, 0:08
820x580, 0:11
Вопрос к олдам. Как 2Д вектор скорости модифицировать, зная ректы игрока и стенки?
>Вопрос к олдам. Как 2Д вектор скорости модифицировать
В думе можно было разгоняться за счет стен т.к. они выталкивали игрока если в них упереться.
Зачем нужен pygame, если тебе больше 14 лет?
Можно же пользоваться нативным SDL/SMFL или библиотеками вроде raylib. Pygame хорош для обучения детей.
В современном C++ такого не должно быть, если грамотно использовать смарт пойнтеры. И компиляция на современных процессорах - доли секунды.
282x262, 0:01
Чё за хуйня со спрайтами? Кароч нарисовал чувачка с двигающимися ручками/ножками, когда двигаю влево/вправо местами спрайты идут по пизде и превращаются в пиксельное месиво, но сука при записи нихуя такого нет. Что это блять?
Возможно, блитишь поверх того, что в предыдущих кадрах наблитил? Во всяком случае, когда я столкнулся с чем-то подобным, дело было в этом. Фиксится обновлением поверхности каждый кадр: surface.fill('black')
Я думаю что может быть проблема в говновидяхе либо с методом вращения спрайтов. Хз.
Как привязать цикл анимации к pygame.time.Clock() если вообще возможно? Вроде читал что-то такое...
Наверное как-то так:
time = pygame.time.get_ticks() / 1000
anim_frame = int(time * anim_fps % anim_frames)
Это внутри вайл лупа.
Но я пока анимацию не изучал, может есть что-то готовое.
640x360, 0:26
Кароч как я понял проблема была в перемещении спрайта, я типа прибавлял к поз.х += 4 на каждом фрейме анимации, что заставляло пугаме перерисовывать спрайт каждое перемещение. Правильно перемещать спрайт нужно функцией пугаме move_ip(*вектор) которая смещает прямоугольник по вектору (который изменяешь в корневом цикле, в зависимости от клавиши) спрайта и вместе с ним уже отрисованный спрайт!
820x580, 0:32
Отсекаем ректы и не тратим время на определение столкновений с ними.
Без оптимизона:
hit_rects = move(player, velocity, collisions=all_rects)
С оптимизоном:
scanrect = player.rect.inflate(20, 20)
rects = [all_rects for i in scanrect.collidelistall(all_rects)]
hit_rects = move(player, velocity, collisions=rects)
Ограничение: плюссайз сканректа не может быть меньше скорости, иначе теряется свойство CCD и приобретаются спидраннерские фичи.
Разве на отсечение ненужных ректов не тратится примерно то же время, что и на столкновения?
Неа. Это оптимизированная операция, исполняемая сишной либой.
Чтоб ты понимал:
5к ректов, без оптимизона, векторы: ~30 фпс
5к ректов, без оптимизона, тупли: ~60 фпс
5к ректов, с оптимизоном, векторы: ~600 фпс
5к ректов, с оптимизоном, тупли: ~600 фпс
820x580, 0:11
Я впечатлился опенсорсными работами этого гения: https://dafluffypotato.itch.io/shifting-edge
Офигел, что на Питоне можно писать функционирующие и динамичные игры, решил попробовать.
Разобрал одну до винтиков, параллельно всё делаю по-своему, как мне нравится. Не все идёт гладко, но есть и успехи. Например, удалось запилить подгрузку карт из Tiled: >>800412 (уже и спрайты работают) и свою систему обработки столкновений выше.
В планах на будущее: прыжки, анимации, звуки, проджектайлы, частицы, тряска камеры. Потом, может, простой ИИ врагов.
Фух, нашел баг. Подлое -1e-15 вкралось там, где ожидалось ≥ 0. Расчехлил эпсилоны, и теперь всё идеально.
820x580, 0:15
820x580, 0:20
1440x900, 0:27
Т Р И Г О Н О М Е Т Р И Я
Р
И
Г
О
Н
О
М
Е
Т
Р
И
Я
Мозг взрывается. Сейчас дошёл до того, что ищу вектор до точки, получаю угол между ним и вектором спрайта, поворачиваю спрайт на этот угол, двигаю спрайт по вектору до точки. С телом интереснее - смещаю центр по окружности вокруг центра головы, нахожу вектор между телом и головой, поворачиваю на угол вектора, перемещаю к голове.
1440x900, 0:24
640x360, 0:26
Я даже слов таких не знал. Скелетная анимация думал.
1280x720, 0:18
Я зделол.
Кстати, чем короче вектор мыши, тем сильнее направление квантуется на восемь сторон, отчего возникает дребезг.
От дребезгов помогает старый советский лерп:
sprite_dir = normalize(lerp(mouse_dir, sprite_dir, delta_time))
Жалко, что нет функции, которая вращает спрайт вокруг пивота и возвращает спрайт и новый рект. Приходится вычисислять новый рект отдельно.
x = rcos(fi)
y = rsin(fi)
Например "найти точку на окружности имея радиус и угол"?ну и центр окружности = пивот
r это радиус
там пропущен *
ты смещаешь центр ректа расположенный от пивота на расстоянии r на угол fi, где тут вычисление нового ректа?
Короче, я всё понял, что ничего не понял.
Я сделяль через так:
rot_sprite = rotate(sprite, -degrees(angle))
rot_rect = rot_sprite.get_rect(center=pos - rotate(pivot, angle))
screen.blit(rot_sprite, rot_rect)
ну, конечная формула сложнее чем просто:
self.rect.centerx = pivot_x + r cos(-fi)
self.rect.centery = pivot_y + r sin(-fi)
там всякие Пи и циферки в разные места надо сувать.
Ну, в любой момент можно менять радиус (r + i), рект остаётся, и то и другое - ситуативно, я полагаю.
сам r инициируется со спрайтом через:
self.r = math.sqrt((self.rect.width 2) + (self.rect.height 2)) // 2
что тоже полезно, если разные исходные размеры.
В моем варианте для этого двигается пивот.
1920x1080, 0:10
Спс. В тему треда, в принципе. Но задачу "поумнеть" можно вычеркнуть. Нам умнеть дальше уже некуда. Поумнено до упора уже.
там Pygame начиная с 13 главы, результат вебмрил, +ёбаная гора ссылок, +весь код разжован, штош пойду картографировать Марс
Здорово. Я тоже скоро за партиклы возьмусь. Где-то после... этой секунды.
Как простыню "for event in events" с обработкой миллиардов кнопок выделить из гейм лупа в отдельный класс, и желательно сделать так, чтобы инпут могли получать обрабатывать произвольные классы?
Action происходит однократно, типа "игрок нажал кнопку прыжка".
Axis происходит каждый тик, типа "игрок двигается вертикально" и значение этой оси. Для кнопок это обычно 1.0/-1.0, а для геймпад стиков плавает между этими границами.
И можно назначать на них произвольные кнопки, даже больше одной.
events ИМХО годится только для KEYDOWN/KEYUP, типа открыть инвентарь, меню выхода и всё такое.
>и желательно сделать так, чтобы инпут могли получать обрабатывать произвольные классы
Заводишь метод класса и суёшь его в update().
Там в книге всё это есть.
Я пока решил запилить велосипед, а именно зоонаблюдателя:
>from input import handle_input, subscribe
>quit_requested = False
>def handle_quit():
> nonlocal quit_requested
> quit_requested = True
>subscribe(name='Quit', callback=handle_quit)
>while True:
> handle_input()
> if quit_requested: break
Внутри input.handle_input пока что происходит взлом жопы луп по эвентам и вызов коллбэков всех падпищеков.
820x580, 0:33
Теперь у меня свои Аксисы и Акшоны, круче чем в Анрилах этих ваших. Основная сложность в том, что в Пугейме это всё раскидано по разным сущностям, и собрать их в единый интерфейс довольно сложно.
Значит, теперь можно подписываться и обрабатывать инпут где угодно. И на сладкое: можно прямо из игры динамически переназначать кнопки, это из коробки работает с этой системой.
Забиндил управление на мышь, клаву и геймпад. Всё работает. Даже кнопка следования камеры появилась.
Довёл до ума! Теперь эта штука переконфигурируется на лету через простой дедовский дикт или джейсон какими угодно действиями и коллбэками. Строго заданы только имена кнопок, и то можно переименовать. Без проблем могёт в many-to-one, one-to-many и даже many-to-many настройки, хот свап джойстика, инвертирование и масштабирование осей, и наверняка еще что-то грандиозное, что даже я сам еще не знаю.
Уечникам это покажется знакомым, думаю. Художественный фильм "Вдохновились".
1) Для илиты, не добавляя в индекс документации, чтоб быдло не спалило, запилили pygame._sdl2.controller, который в тыщу разов лучше pygame.joystick. Сделан с мыслью о современных геймпадах, а не о джойпадах NES и палках от Atari 2600. Имеет адекватный интерфейс. Есть эвенты на все актуальные кнопки, включая тачпад дуалсенсовский. И последнее, но не менее важное: кнопки ди-пада, которых нет в joystick, где это называется hat и предлагается использовать голые оси без смс и регистрации нажатий и отпусканий. А вот под триггеры всё равно нет кнопок, только оси. Хаха, я здесь живу.жпг
https://www.pygame.org/docs/ref/sdl2_controller.html
2) Минималистичная либа, которую уже больше 20 лет пилят по принципу "лучше делать одну вещь хорошо, чем всё подряд плохо" местами может быть сырой и недописанной, фейля в простейших вещах. Например, крашится, если _sdl2 контроллер выключить или вытащить из юсб порта. Фиксится НЕиспользованием pygame.event.get() без аргументов. И pygame.event.clear() в конце цикла (на всякий пожарный). Это опенсорс, сынок, кушой.
Ну, песочек, хотелось бы. А-ля Oxygen Not Included, по крайней мере в голове образ чего-то такого. Докатился до уровня где понадобилось перемещение персонажа к точке выполнения задания и тут А* с Графами кааак налетели, Графы - вообще особый путь поехать кукухой, а у меня ни опыта, ни знаний, в итоге Вороного таки осилил, теперь буду улучшать алгоритм создания, всякие там сохранения мира, перемещения камеры, и потом уже по Графам взад-вперёд ездить до посинения.
Мимолётом ещё узнал, что блит всего экрана каждый цикл - ваще не вариант, и буду по-ходу ещё вникать в отдельные прорисовки того что подвигалось.
>блит всего экрана каждый цикл - ваще не вариант, и буду по-ходу ещё вникать в отдельные прорисовки того что подвигалось
Так ведь с перемещением камеры у тебя всё подвигалось, не?
Да, но не каждый цикл. Интерфейс тоже не подвигался. Кароч буду разбираться.
1920x1080, 0:18
Вытащил обработку сдвига в отдельный класс. Повесил забавы ради обработку осей мыши, чтобы делать ручной скрин шейк. Бдщщщ! Бдждвдждж! Буууум! Уже эпичней некуда, а ведь я еще звуковые эффекты и частицы не запилил.
Оказывается, если не скейлить ОБСом видосики с пиксель артом, то они весят даже меньше, чем даунскейл.
1920x1080, 0:10
Запускать и апдейтить частицы будет, наверное, эмиттер. Погнали.
1920x1080, 0:18
Всё это время я рендерил маленькую картинку и растягивал её в конце в N раз. Я подсмотрел это в сорцах ВолосатойКартохи. Так и не понял, почему он так сделал. Однако это весьма удобно, потому что всё рулится глобальным масштабом в настройках, можно задать какой хочется. Всё бы ничего, но движение спрайтов и камеры с шагом N пикселей заставляет вытекать глаза: когда камера замедляется, приближаясь к игроку, она начинает двигаться ступенчато. То же самое с медленно двигающимся игроком, его спрайт сильно дребезжит.
Решение:
Переделать логику масштабирования. Теперь я масштабирую тайлы и спрайты при подгрузке ассетов, а рендерю всегда большую картинку. Графоний улучшился в триллионы раз. Камера стала плавной, дрожание героя исчезло. Ну и всё по-прежнему рулится глобальным масштабом в настройках, и всё ещё можно задать какой хочется.
До и после:
В Пугайме нет 3д графики. Придется подключать Пуопенжиэль и работать уже с ним, а Пугаем будет как прослойка для окна и т. п.
1920x1080, 0:17
Удивительно, насколько возможность прыгать всё усложняет.
То то на сони любят даже в ааа прыжки убрать.
640x480, 0:32
Это свои потуги.
Теперь буду каждому материалу своё поведение присваивать.
Ну и как ты там скейлишь на выводе думать. Потому что ФПС прямо пропорционален площади мира делёной на размер квадратов.
И ещё надо как-то сузить цикл по квадратам которые надо отрисовывать, но в то же время как-то успевать их отрисовывать когда они близко от экрана/расположены на экране и вроде действия внутри квадратов должны происходить, но не отрисовываться до тех пор пока они не находятся в пределах около экрана, и уже два цикла получается - на действия и на отрисовку, и хз в какой жопе в итоге будет ФПС. Кароч ноды это пиздос.
>Ну и как ты там скейлишь на выводе думать. Потому что ФПС прямо пропорционален площади мира делёной на размер квадратов.
Скейлю спрайты при загрузке. Чтобы обойтись без pygame.transform.scale в геймлупе.
settings.py:
> GLOBAL_SCALE = 3
> UNIT_SIZE = TILE_SIZE * GLOBAL_SCALE
А, ну это не то, у меня скейл при инициализации класса спрайта сейчас, и мне скорее в лупе надо его делать, типа увеличенной проекции сурфасе мира на экран что-то. Сейчас у меня субсурфасе от сурфасе мира блитится на экран, поэтому я могу изменяя положение субсурфасе на сурфасе мира иммитировать перемещение камеры, значит мне надо скейлить субсурфасе перед тем как блитить на экран, в то время как
оригинальную площадь мира(в пикселях), оставив колличество квадратов, можно будет сократить. Я просто не разобрался ещё как именно её скейлить, вернее скейлю но фпс падает, что мне не нужно. Там код такой:
screen.blit(subsurface, (0,0), (и вот тут типа скейл, называется AREA, но этот скейл отрисовывает за экран в итоге тупо))
Как-то с этими циферками надо играться.
или даже эта DiArea тупо разположение на экране меняет, а не скейлит, и где-то в кваргах валяется заветное ключевое слово.
450x360, 0:02
Кароч subsurface создаётся меньшего размера, потом через pygame.transform.scale создаётся другая растянутая из subsurface и новая блитится на экран, все координаты мыши и границы за которые нельзя уезжать - у меня, разумеется пошли по пизде, но фпс вроде отрастает. Настало время переписывать весь код.
>Определяем тип пола. Кто угадает зачем?
Чтобы изменять скорость движения?
>>804334
В чём проблема? КВС мало?
Есть одна старая методика для 2D тайловых карт, которые рисуют бит блиттингом. Объединяй тайлы в чанки (группы), рисуй каждый чанк на отдельной текстуре, затем рисуй на экране чанки. Итого, если карта не обновляется, ты делаешь значительно меньше дроуколлов. Если карту нужно иногда обновлять, т.е. менять тайлы - после изменения тайла заново рисуешь текстуру чанка, в который входит этот тайл. Всё просто и скорость при этом большая. Если у тебя есть слои, их придётся рисовать в отдельные текстуры. Учитывая вид твоей графики, не забудь включить прозрачность у текстур чанков, иначе уголки будут перекрывать соседние чанки.
Если же у тебя не бит блиттинг, а 3D API, то теоретически можно комбинировать вершины в один массив и с разными материалами, но таким в чисто 2D движке позорно заниматься.
мимо проходил
Вообще, я не знаю, как там оно под капотом устроено: используется ли встроенный рендерер SDL (с бит блиттингом)? Если так, то другого выбора как рендерить чанки в текстуру вроде и нет, SDL вроде не имеет встроенного механизма батчинга.
Просто тут недавно кто-то возмущался, зачем рендерить чанки в текстуру, в чём смысл. А на SDL другого пути нет, только если на OpenGL переезжать, но там ты теряешь контроль за пикселями, т.е. это уже не пиксель-перфект 2D получается...
1920x1080, 0:102,6 Мб, mp4,
1920x1080, 0:082,6 Мб, mp4,
1920x1080, 0:103 Мб, mp4,
1920x1080, 0:10
Дешевле всего оказалось просто слить все 2500 тайлов в один гигачанк размером с карту.
Без чанков без цветомаски 90 фпс
Без чанков с цветомаской 250 фпс
Гигачанк без цветомаски 400 фпс
Гигачанк с цветомаской 410 фпс
>альфа-канал
Да... Там вроде умножения постоянно производятся вместо прямого копирования пикселей. Или как минимум проверка каждого пикселя на наличие альфы < 1.0.
>цветомаски
А разве не достаточно отметить "прозрачный" цвет?
https://wiki.libsdl.org/SDL_SetColorKey
>2500 тайлов
Это не так уж много, 50x50.
Теперь попробуй сгенерировать/загрузить карту ещё больше)
Да, я имел в виду прозрачный цвет.
>попробуй сгенерировать/загрузить карту ещё больше
В моем случае ничего не меняется. Чем больше чанки - тем выше производительность.
А вот с памятью проблема, вплоть до:
> pygame.error: Out of memory
Это на 500х500 (250 000 тайлов) и одном гигачанке. Но на 4 чанках работает, кушая 10 гигов оперативы.
Хотя, 50х50 в моем случае более чем помещается в экран с запасом, так что смысла в большей карте пока нет.
https://pastebin.com/raw/66b4b1Kj
Делит сетку произвольного размера чанками произвольного размера. Если кратности нет, в конце будут чанки-обрезки. Порядок слева направо сверху вниз.
я хз про все эти ваши чанки, но когда пилил свою матрицу, пришёл к списку list = [0,1,2,3,4,...,n] из которого высчитываю координаты на сетке через y = n//grid_width x = n%grid_width ебля с определением клетки внизу через клетка = list[(self.x)+(self.y*grid_width)] included, наверное какой-то тупль можно кидать как чанк в этот лист.
У тебя всё плохо. У меня-то статичная земля: склеил всё в один жипег и показывай. А тебе еще и обновлять надо динамически, чтобы песочек подбличивать в кучу.
Попробуй при каждом добавлении песочка регенерировать всю кучу и склеивать их в один большой сюрфейс.
Это скорее всего будет статтерить при добавлении песка. Но при бездействии и скролле будет видна максимальная теоретическая польза от чанкинга. И уже думать как оптимизировать кусок чанка в месте подсыпания.
Сейчас использую такое:
> image.fill(color, rect=None, special_flags=pygame.BLEND_RGBA_MULT)
Тут цветомаска тоже умножается, и перестаёт быть цветомаской. Пробовал все флаги.
Короче, решил через цикл по всем пикселям оригинала и восстановлением пикселей цветомаски на тинтованном изображении. Странно, что нет такой банальной функции.
640x480, 0:30
У меня мир из тех же чанков, только они объекты класса Node, наследник класса pygame.Surface, у каждого объекта свой контейнер спрайтов, который объект сам на себя блитит, и потом блитит себя на картинку мира, сейчас сделал начальную отрисовку всего мира и потом отрисовку изменений только во время нахождения на экране и пилю цикл изменения объектов и помещения в сет изменённых чтобы при пересечении сета экрана и сета изменённых происходила отрисовка. Пока что только под себя умеем перекидывать, после изменения функция возвращает в сет объектов в очереди на изменение None объект.
ну и OBS кушает проц ващет
Понял. Какой размер чанка-ноды? Меня чанки поменьше как-то не впечатлили по сравнению с одним гигачанком.
В пикселях 10х10, при инициализации каждому объекту роллится свой цвет, чтобы потом филл накидывать, в тестовом режиме. Всего их 12288 пока что. На экране 48 срезов листа по 64 объекта брошенных в сет.
А что содержит контейнер спрайтов ноды?
Ты уже финальную картинку мира скроллишь, я так понимаю?
Изначально ничего не содержит, по клику кидаю в контейнер спрайт, спрайт проваливается в контейнер нижней ноды, если нижняя занята - случайная слева или справа от нижней.
>Ты уже финальную картинку мира скроллишь, я так понимаю?
>>804550
>сейчас сделал начальную отрисовку всего мира
Перед запуском while. Потому что изначально сет изменённых пуст и прорисовывать нечего хоть с пересечением экрана, хоть без.
А, вот чего у тебя фепесы подросли. Сами сюрфейсы без альфы? Просто image.convert()? А то Пугейм никак не препятствует выстрелам себе в ногу. (И это хорошо!)
Вспомнился Song of Conquest который 2D спрайтовый и нещадно тормозит при скролинге карты на 1060, в то время как такие же спрайтовые герои 3 сносно идут на пека до 1го пентиума...
В чём магия оптимизации?
>Song of Conquest
Не играл, но судя по скринам, это полностью 3д игра с реалтаймовыми тенями, пбр графикой, пост-процессом, налогом на юнити и т. д. Пффф! Щенки.
То ли дело Пугайм, пердящий на 90 фпс, отрисовывая пару тысяч 2д спрайтов на чистом SDL. Вот это да, внушает уважение.
Ну как бы да, но выглядит это как пикселявые спрайты, особенно при приближении камеры. Предполагаю что там туман войны ещё какой-то ёба эффект который рендерится на всю карту сразу.
Сами сурфасе вообще без имаге, это же поверхность для отрисовки, на них self.fill(self.color) для того чтобы видеть как расположены сами ноды и как отрисовываются, было дело что пол экрана только заполнялось. Альфа там только для прозрачности, насколько я понимаю. Типа делаешь set_alpha и цвет альфы выпиливается при отрисовке. У меня так обводка на координатах возле курсора сделана, хотя я её не планировал, но она вылезла. У координат тоже своя сурфасе, которую надо филлить каждый цикл, чтобы циферки не сливались в гавно, но и летающий прямоугольник возле курсора - так себе смотрится, поэтому сетаешь альфу и pygame.SRCALPHA её глушишь. А спрайты загружаю с .convert_alpha(), на простом конверте альфа заполняет спрайтовые пустоты.
>convert_alpha
Во, вот эта хрень мне 50% перформанса убивала. Схитрил, загружая пнгшку и блитя её на сюрфейс розового цвета, которому ставил розовый цветом прозрачности при помощи set_colorkey. Но я все тайлы каждый кадр в гейм лупе рендерил.
640x480, 0:38
А что ты делаешь? Клон The Powder Toy?
https://powdertoy.co.uk/
Кстати, песочница эта, оказывается, опенсурс:
https://github.com/The-Powder-Toy/The-Powder-Toy
Много лет назад игрался с ней, быстро надоело. А ведь некоторые целые компьютеры сооружали. Очень жаль что мир ограничен рамками экрана.
В общем, интересно, будешь ли ты делать электронику в своей песочнице, с полупроводниками и т.д.?
Аудиосопровождение постоянное на фоне? В таком случае звуки шагов будут неслышны.
Там скорее всего в контейнер падает больше одного спрайта, а активность ноды выключается после переноса одного, полуфикс - замена постоянного закидывания при нажатии на мышь на одно действие по клику - event.type и MOUSEBUTTONDOWN перед click[0], либо целыйфикс - прописывание условий на повторную проверку осталось ли что-то в контейнере, по сути мне будет достаточно полуфикса.
>>804940 -> >>803309
Не знал про сабж.
>будешь ли ты делать электронику в своей песочнице
До этого ещё далеко, я не очень опытный программист.
Ну, кстати можно тип контейнера сменить на переменную со значением между None и спрайтом, но там лежит много всякой фигни типа у None объекта нету имаге и ректа или ещё какая-нибудь срань в дальнейшем, так же у Пугейма есть своя группа одного спрайта, которая если получает спрайт выкидывает тот, который уже в ней есть, можно через неё, но там чтобы вызвать аргумент спрайта всё время надо обращаться к спрайту через group.sprites()[0].image например и в итоге строки по 200 символов, ну, и для того чтобы помещать несколько спрайтов разных сущностей надо будет пилить отдельный контейнер под каждую сущность. для песка, для персонажа, для проводов, etc.
Почитал, там обращение к спрайту в одиночной группе через:
group.sprite
Отдельные контейнеры скорее всего надо будет запилить.
>Не знал про сабж.
Поиграй. Там много интересных механик и физика сложная. Есть встроенная онлайн галерея пользовательских работ, которые можно в пару кликов скачать и попробовать. В ONI тоже есть физика газов и жидкостей, но в ONI оно как-то грубо выглядит. Может, из-за оптимизации, всё же размеры мира большие, или из-за крупного размера тайлов (в The Powder Toy буквально пиксели).
Но, как я понял, у тебя жанр совсем другой, ты хочешь симулятор колонии как в ONI? Тогда нужно фокусироваться на ботах, там отлаживать ИИ довольно сложно, наверное.
>Поиграй
Я скачал, потыкал в разные стороны, не разобрался. Сложно позволить себе поиграть во что-то, когда поставил цель писать и надо думать над кодом.
>в ONI оно как-то грубо выглядит. Может, из-за оптимизации
Там обнову завезли, обещали экономию памяти на всех этапах игры. Хочется глянуть, но не могу себе позволить, опять же.
>симулятор колонии как в ONI
Да. Но конечная картина игры в голове постоянно меняется в разные стороны.
>ИИ довольно сложно, наверное
По сути весь ИИ там заключается в поиске пути от точки нахождения до точки задания, алгоритм А*, из-за этого и начал ковырять все эти ноды. Эмуляция выполнения задания на месте - скорее просто: если а - то покрути ручками и потом б.
1920x1080, 0:10
1920x1080, 0:11
Назначил материалы тайлам пола, чтобы использовать при обработке шагов.
1920x1080, 0:15
В Пугайме есть пересечение точки с ректами, но это отстой для изометрии, если именно экранные ректы трогать.
Если у тебя каждый объект находится точно в клетке карты, и размеры коробки равны размеру клетки и отличаются только высотой, то может можно все свести к алгоритму Digital differential analyzer?
1920x1080, 0:08
>>805867
У меня произвольные AABB. Видимо, придется 3д рэй-бокс использовать.
Не знаю зачем. Но при 5000+ объектов это заметно.
Месяц назад я и представить не мог, что удастся даже так далеко зайти, пользуясь практически голым Питоном+Пугаймом.
И господи, как же это приятно, когда просто добавляешь функцию на несколько строк, и всё просто и без задней мысли работает: объекты убираются, подсветка очищается, коллизии удаляются. Не надо с болью перепиливать половину кода. Бог-император архитектуры в треде!
1280x720, 0:40
Красава!
На днях буквально тыкал в ренпи ядро, и там был список функций пигейма залоченных. Может разлочить пошаманить тоже с чем-нибудь. Выглядит прикольно.
Осторожно! Так можно докопаться до скрытых [ВЫМАРАНО].
Материалы по объектам этого класса не должны быть доступны обычным пользователям.
>пики 1 и 2
Это ж наклейка на полу с принтом ямы. Обман на доллары. В принципе, такое без проблем сделать можно запилить на текущем коде.
Ну, вот тогда. Проект забросили в раннем доступе, вроде был какой-то конкурент получше.
Ну, или не забросили.
Тут, как видишь, независимые плоские этажи и лестницы-телепорты между ними.
Лично мне на ум приходит Стронгхолд 1, там настоящий террейн с перепадами высот, но там какая-то йоба технология, а не тупо 2д массив с тайлами. Для меня это технологии 22 века.
Экран компьютера - это двухмерная наклейка с принтом из пикселей. Обман на далары.
640x480, 0:21
отклеилось
Зелёные - по которым можно пройти, они же путь.
GUI просто слой, который блитается на экран, на котором надписи, если мышь в пределах прямоугольников и кликает - делаем Тру-инструмент, если инструмент Тру, ну, ты понял.
По поводу физики, кста, натыкался на Хабре на статью про Pymunk либу, вроде что-то делает, у меня движок не про это просто, мож кому пригодится.
ля, копировал в пнг нах
Типа реалтайм изменение пути? На поиск уходит, пока что 0,001-0,002, один персонаж может и норм по ФПС выйдет, но несколько в дальнейшем сожрут проц.
Пока что успешно открываем и закрываем главное меню, а также закрываем игру.
Научился обрабатывать событие масштабирования окна игроком и перерисовывать интерфейс на лету.
1920x1080, 0:09
1920x1080, 0:15
Реалтайм из прошлого десятилетия, а.к.а мой проц.
На самом деле - пилю физику, с вектором силы и массой, и камень об камень - отскакивает вверх(когда-нибудь и искрить будет), камень об песок - выталкивает из под себя или выталкивает крайний/ие в нижнем ряду, песок - скользит по диагонали обо всё. Функция на два типа материалов(твёрдые и полутвёрдые) занимает 250+ строк. На очереди жидкости, у них ещё и деление объёма по-хорошему надо делать. Ожидаемая длина функции=1кк. Полупуки по теме жидкостей в гугле - вообще ни о чём.
1920x1080, 0:24
Наверное, стоило всё сделать плоской простыней волшебных чисел с ректами и спрайтами-кнопками, но я психанул и навелосипедил недофреймворк с иерархическими виджетами, слотами, якорями, z сортировкой и прочим никому не нужным хламом. Причем сам, так как по всем запросам всплывало только программирование на гуи фреймворках, а не создание гуи систем с нуля.
Пока что это самый большой файл в проекте (213 строк), но, думаю, сильно больше будет, ведь пока есть только пять виджетов: базовый, текст-строка, кнопка-вызывалка, кнопка-листалка и бесполезный виджет-двачер, выполняющий одну функцию: он синий.
Хз, пиратка у меня, на том же процэ, вылетала тупа. Мож кряк такой, а мож и оптимизация говна.
>Полупуки по теме жидкостей в гугле - вообще ни о чём
https://ru.wikipedia.org/wiki/Уравнения_Навье_—_Стокса
1280x720, 0:02
Это четверть пука, максимум - треть.
Ну, да, примерно такие мысли о написании.
Так же не знаю как запилить сообщающиеся сосуды(хотя скорее всего смогу, т.к. есть уже функции работающие по нижнему ряду и поиску всех заполненных нод ниже предложенной, и соответственно давление = сумма всех весов сверху, но там есть ещё заморочки с ситуациями пикрилл - где над/под нодой лежит нода не оказывающая давления, а за ней продолжается ряд давящих), и так же деление объёма на соседей.
Просто на предыдущей реализации физики векторов силы не было, а теперь они есть и вот уже почти начал писать, ленб только.
1920x1080, 0:16
1920x1080, 0:23
Эм, с питоном же датасаентисты работают в том числе занимающиеся физикой. Что-то не верится что либы до сих пор не запилили где есть расчёт физ.процессов разных.
640x480, 2:14
Я вот тоже решил прототип прототипа клиента к своей онлайн дрочильне на pygame накидать, бэкенды тоже на питоне с pymunk правда. Сложно пиздец, я веб дев и с вебом вообще лады, а тут вообще голова пухнет, особенно от попыток организовать норм архитектуру-структуру кода и тысяч физики и геометрии, которых я забыл к хуям после универа. Сложно но интересно сука, весь тред прочитал взахлёб
А никак. Есть возможность написать свой велосипед с нуля.
Как ты его напишешь - такие возможности и будут, получается.
Питоновский PyPI и есть: https://pypi.org/search/?q=pygame
Еще на сайте есть проекты разной степени качества: https://www.pygame.org/tags/all
Вот, например, целая ГУИ либа: https://www.pygame.org/project/4381
Спасибо, пока только очевидные вещи встретил, но как то и интересно даже
>>816722
А там в юае надо разбираться, по мне так проще новый язык освоить чем с этими интерфейсами дрочиться ещё и при том что совсем не знаешь best practices. Ну энивей на пайгейме только прототип клиента конечно же, если вдруг получиться неплохо буду движок выбирать
Инишники аккуратны, но их надо парсить и валидировать. Встроена поддержка пользовательских настроек и значений по умолчанию.
Джейсон компактный и строгий, прямолинейно переводится в питоновские структуры. Специальных конфиг-функций нет. Впрочем, со словарями всё просто из коробки: "settings = defaults | overrides", а метод dict.get позволяет задать значение по умолчанию.
И сразу тихо спарсилась несуществующая кнопка 'Space JoyDown' (забыл разделитель |), а персонаж в игре не прыгает. Без валидации жопа.
стил нат енаф, бат...
Застрял на понимании откуда брать вещ-во для переноса вверх если в ряду с тайлом(1) есть тайл(2) с давлением сверху больше чем у тайла(1) и над тайлом(1) есть пустой/с водой тайл(3), которое даст сообщ-ся сосуды, и возможно даст понимание облегчения всей физики жидкости. сложна блять
1920x1080, 0:24
Так можно запретить герою ходить и интерактировать с предметами, когда кликаем по кнопкам в главном меню. Или разрешить только ходить, смотря на карту. Или позволить делать что угодно и при этом шариться в окошке инвентаря одновременно.
Также поменял поведение эскейпа на контекстное действие (пока только закрытие текущего окна). Вместо того, чтобы всегда открывать главменю.
>с чего начать
С документации. https://www.pygame.org/docs/
https://www.pygame.org/wiki/GettingStarted
>Как вообще с библиотеками работать?
Лол, ну как с любыми модулями питона, нет?
мимо щупал питон на уровне hello world
>Лол, ну как с любыми модулями питона, нет?
А как с любыми другими модулями питона работать?
Я просто в питоне не особо понимаю, но вижу большой интерес. Ладненько, завтра попробую что нибудь сделать.
За документацию спасибо!
Пайгейм это сторонний питоний модуль. Сторонние модули устанавливаются через командную строку программой pip:
> pip install pygame
После чего импортируются как стандартные модули в скрипте. Пугайм требует бойлерплейта небольшого - инициализации, создания окна, вайл лупа.
Попробуй этот тутор:
https://www.youtube.com/watch?v=QU1pPzEGrqw
>>820312
А, тебе в целом интродакшн в Питон нужен? Тогда сюда ходи:
https://www.coursera.org/learn/interactive-python-1
https://www.coursera.org/learn/interactive-python-2
Это курс, преподающий Питон через геймдев. Они используют Пайгейм-подобный фреймворк.
Не надо pygame, он слишком низкоуровневый. По сути позволяет только создавать окно, ловить события мыши и выводить картинки по заданным координатам. Попробуй Arcade, Pyxel, Ursina engine (обёртка над Panda 3D) - там есть игровые сущности.
Аркадий привлёк внимание.
>По сути позволяет только создавать окно
Там есть пиксельаррай и класс вектор с горой методов.
Можно сочетать, потому что у Аркадия в сравнении с Пугеймом честно написаны плюсы и минусы друг против друга. Главное чтобы х, у, и сходились.
1920x1080, 0:06
Но я сделал старый дедовский журнал. А именно простенькую систему заданий и виджет журнала. Пока окно не умеет реагировать на клики и обновляться, но основа для интереснейших квестов уже видна. Осталось понять, как бы получше запилить проверки и продвижение по заданиям, чтобы можно было их завершать и проваливать.
1920x1080, 0:07
Добавил таки базовый функционал в окно журнала. Внимание, спойлеры эндгейма!
Квесты - зарыться под землю, притворится деревом, вырастить из куста аниме девочку.
Вы приняты
1920x1080, 0:25
Вот у чувака в самом начале всего 3 файла есть, он открывает main и у него открывается окно с Pygame, а у меня откроется и за долю секунды закроется сразу. Что я делаю не так?
У меня 1 в 1 как у него все, я списал. Все 3 файла в одной папке лежат.
Отбой, получилось починить - я двоеточие забыл поставить в начале класса.
Я использую PyCharm Community от JetBrains:
https://www.jetbrains.com/pycharm/download/
Офигенно удобная и быстрая IDE, самое то для игрового проекта с кучей файлов.
Но если хочешь что-то полегче, можешь попробовать редактор Visual Studio Code от Microsoft. Не путать с Visual Studio, неподъемной неповоротливой IDE.
https://code.visualstudio.com/
И то, и другое бесплатны и кроссплатформенны. Рекомендую заменить ATOM на VSCode в любом случае, даже если PyCharm будешь ставить.
>Ты чё совсем? Запускай код из командной строки, а не кликом по иконке. Так у тебя будет время прочитать ошибку в терминале.
Ну да, ради ошибки наверное стоит, но так то кликом быстрее и удобнее чем через терминал. У меня 1 монитор, и лишнее окно держать не очень хочется.
>Ну и в глобальное окружение пакеты не рекомендуется ставить - используй virtual environment.
Пакеты это ты про pygame ? Ну уже поздно, а так да, затупил, у меня есть виртуалка с линуксом.
>У меня 1 монитор, и лишнее окно держать не очень хочется.
А лишнее окно проводника держать хочется? Как ты отлаживать код будешь без терминала? В VS Code он встроенный в основное окно, кстати.
>Ну уже поздно, а так да, затупил, у меня есть виртуалка с линуксом.
Я про https://docs.python.org/3/tutorial/venv.html
Знаешь, пожалуй ты прав, стоит сразу по нормальному учиться делать.
А если в винде, то что лучше использовать - повер шелл или простую цмд?
Слушай, я вот создал виртуальное окружение, установил туда Pygame. А куда кидать мои готовые файлики с игрой? Прямо в корень каталога этого окруждения или в новую папку для удобства?
И я правильно понял что алгоритм работы окружения такой: запускаю активирующий скрипт в командной строке, запускаю свою игру, потом запускаю деактивирующий скрипт. Правильно? Если я запущу сразу свою игру без запуска скрипта, то она запустится не в моем виртуальном окружении?
1920x1080, 0:15
Где-то ошибочно вычитал, что для пользователя зарезервировано всего 30 с чем-то видов событий. Не то чтобы сложно было уложиться в этот лимит, либо навелосипедить свои события поверх неё, использовав всего лишь один полиморфный тип для всех событий в игре, но оказалось, что пользовательских событий можно напилить 32685!
> >>>pygame.constants.NUMEVENTS - pygame.constants.USEREVENT
> 32685
Ну и остается только запиливать свои тивпы событий с минимальной обвязкой. Короче, события офигенны, не представляю, как бы я жил без событий, когда всё начинает референсить друг друга, а Питон не умеет в круговые импорты.
>А если в винде, то что лучше использовать - повер шелл или простую цмд?
Windows Terminal + Git for Windows
красота
1920x1080, 0:23
И даже перетаскивание вещей с одной панели на другую. Можно и вещь на вещь перетаскивать, но сейчас это ничего не делает.
1920x1080, 0:09
Добавил обратной связи. Обратной связи много не бывает. Еще бы курсор менять, но это целый отдельный квест.
1920x1080, 0:10
1920x1080, 0:11
А в чём смысл? Питун это не язык для геймдева от слова совсем.
Питон на данный момент является лучшим языком для новых проектов. Исключительная выразительность языка и мощная система аннотации типов позволят Вам быстро писать элегантный и надежный код. Язык еще не столь распространён в геймдеве. Пока ваши конкуренты используют устаревшие технологии на базе Сишарп или Си++, вы сможете в разы поднять свою эффективность, задействовав pygame.Sprite - последнее достижение науки в области высокоуровневой отрисовки графики. Но это еще не все. В жизни любого проекта наступает момент, когда он превращается в продукт и к сопровождению проекта привлекаются дополнительные разработчики. На этом этапе распространённость и доступность движка начинает играть решающую роль. Благодаря активной популяризации Пугайм в среде профессиональных игроделов, а также поддержке этого фреймворка со стороны библиотеки для создания кроссплатформенных приложений - фонда Симпл ДиректМедиа Леер, Вы можете быть уверены, что в будущем Вам не придется переписывать свой проект на Юнити, как это произошло с проектами на печально известном движке Аур Машинери. Пугайм обеспечит вам гарантии успеха и стабильности Ваших начинаний. Выберите Пугайм сейчас и через несколько лет Вы сможете наслаждаться результатами своих трудов - успешным проектом, выполненным с учетом всех современных технологий и индустриальных стандартов. Пугайм - Ваш проводник к успеху в мире разработки игр. Выбирайте Пугайм.
1920x1080, 0:25
А анимацию и сценграф ты на чём пишешь?
1920x1080, 0:09
В Noita эту хуйню не осилили.
Я бы решал задачу от гравитации. Каждый тайл имеет единичную гравитацию. Если он может двигаться вниз, он каждый кадр движется вниз на 1хG, где G - гравитация игрового мира. Если под тайлом есть другой тайл, то этот тайл не может двигаться вниз, тогда он сообщает тайлу снизу некоторый коэффициент, например треть своей суммарной массы (а масса у нас это 1хG, если кто не догадался), затем наш тайл проверяет, может ли он соскользнуть в сторону? выбирает рандомное направление и пытается соскользнуть, если не удалось, то вторую треть от сообщает тайлу в той стороне, куда хотел соскользнуть, и выбирает оставшееся направление, и если не удалось соскользнуть то последнюю треть своей массы он сообщает третьему тайлу. Если соскользнуть удалось, то он падает с 1/3 x G только в этом кадре, в следующем кадре он снова обладает полной массой в 1xG.
Теперь рассмотрим слой ниже. На тайл сверху давит несколько тайлов и каждый кадр сообщают ему коэффициент в скажем, 3.5, тайл домножает на G и теперь его полная масса 3.5xG, и он каждый кадр пытается упасть вниз с этой массой, если снизу неподвижный тайл, то он переданный ему коэффицент посылает обратно. Это у нас реакция опоры. Наш тайл получает этот возврат в стек, но будет суммировать его на следующем кадре. Далее он пытается соскользнуть по схеме выше. Если сбоку опора, то импульс соскальзывания тоже возвращается ему в стек. На следующем кадре каждый тайл смотрит, что у него в стеке и импульсы справа передаёт влево, и наоборот, а импульсы снизу передаёт наверх. Затем обрабатывает импульсы сверху. Снова.
Таким образом, если у нас сообщающиеся сосуды, то спрайты естественным образом распределят давление и выдавятся в незанятую полость. Только вот, насколько я слышал (а сам не пробовал) такой поатомный расчёт жидкостей заставит приуныть даже топовую пекарню.
1920x1080, 0:19
С годовщиной.
Вы видите копию треда, сохраненную 12 сентября в 09:57.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.