Это копия, сохраненная 1 марта 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Делаю свою йобу c видом сверху.
Передвигаюсь левой кнопкой, а кастую скиллы правой.
Вокруг бегает парочка мобов. Штук 5-10.
Так вот, вроде бы ничего особого не происходит, однако если активно пользоваться передвижением и киданием скиллов то начинает падать фпс.
Как это можно оптимизировать?
Вот цикл, в котором все происходит
http://pastebin.com/uYvF5QjR
Тормоза такие, словно все действия собираются в очередь. Если активно что-то поделать и остановится, то еще секунды 2-3 перс начинает делать то, что недоделал.
И еще, когда я щелкаю мышкой все на мгновение замирает.
Заранее спасибо.
>SDL_PollEvent(mainEvent);
while(SDL_PollEvent(mainEvent))
{
// Твой обработчик событий.
// Это же пул ивентов, зачем отдельно стейты потом таскать.
// Все взял и используешь.
}
Зачем чистишь рендер до начала, собственно, рендеринга? Это не важно на самом деле.
И еще, дельтатайм юзаешь при обновлении? Вертикальную синхронизацию включал?
Первый делает движение независимым от фпса. Второй его капит.
>Зачем чистишь рендер до начала, собственно, рендеринга?
Очищаю от рендера прошлой интерации. Можно сделать в принципе в конце да.
>И еще, дельтатайм юзаешь при обновлении?
это связано с SDL_GetTicks() ?
Если да, то использую.
>Это же пул ивентов, зачем отдельно стейты потом таскать.
Я делаю в самом начале пул, просто адпейты по разным класс растаскал, чтобы не мешать все в кучу.
Ну ты понял, в апдейте для монстров они выбирают куда идти и т.д.
В апдейте для героя я проверяю нажатие клавиш.
Проблема в том, что ты таскаешь события не всем пулом, а каждую итерацию главного цикла.
Условно: ты 10 раз нажал клавишу мыши. В пул записалось 10 событий.
И ты выдергиваешь не все доступные события за промежуток времени, а только одно и раз в итерацию игрового цикла.
То есть за время прошедшее между обновлениями у тебя накапливается еще с десяток событий. А ты продолжаешь тащить по одному. Выборка событий подвисает.
Поэтому пул и просматривается в собственном цикле для все событий, произошедших с момента обновления внутри каждой итерации цикла.
Собственно вот: http://wiki.libsdl.org/SDL_PollEvent
>это связано с SDL_GetTicks() ?
Да. Время прошедшее между итерациями цикла.
Вот есть у меня на экране игровое поле, так сказать, с юнитами и прочим, разумеется. По юнитам можно щёлкать, и в некоторых режимах игры это что-то меняет. В некоторых, заметьте.
Плюс к тому мне нужен интерфейс. Скажем, КНОПОЧКИ КАК В ВАРКРАФТЕ ТРЕТЬЕМ. Опять же, в зависимости от режима, кнопок на экране разное количество, делают они разные вещи и т. д.
Внимание, вопрос: как всю эту окрошку реализовать в коде, заработав минимум геморроя? Классы и иже с ними - на фиг надо, во-первых, никогда с ними не дружил, во-вторых, игровая логика и прочие потроха описаны на С старого стандарта. Спасибо за внимание.
Большое спасибо.
а как мне тогда это исправить в моем случае?
основной цикл работает до тех пор, пока я не закрою окно.
то есть мне внутри этого цикла сделать
while(SDL_PollEvent(mainEvent))
и там писать все апдейты?
http://sourceforge.net/p/sdlui/code/ci/default/tree/
А погуглить? Если юзаешь второй, придется допилить напильником.
Да, если у тебя сами апдейты и обрабатывают события. Если они делают что-то еще, то разделить на какой-нибудь Handle/onEvent и сам Update, чтобы не было лишнего пересчета.
>Классы и иже с ними - на фиг надо
Чувак, классы это наше все.
У меня в моей минимальной йобе 22 класса но с ними намного удобнее.
К примеру есть класс интерфейс.
В интерфейсе есть экземпляры разных классов, типо полоска хп и маны, инвентарь, окно статуса и т.д.
Это очень удобно. И классы несложные. Их за пол часа понять можно.
Кнопочки - это просто типо картинки. При нажатии изменяется картика на "нажатая кнопка", а при отжимании возвращается в исходное состояние.
Вот на примере кнопки можешь написать класс Кнопка, в конструктор туда запихни картинки для этой кнопки и при нажатии кнопки перебирай коллекцию кнопок и смотри совпали координаты или нет. Если совпали, то изменяешь её состояние и запоминаешь нажатую кнопку.
При отжимании вспоминаешь нажатую кнопку, изменяешь её состояние и вызываешь функцию кнопки, что она должна делать. и все.
Спасибо, как раз об этом подумал)
Что, и других вариантов не предвидится? Жаль, жаль.
У меня даже юниты объединены в массив структур - всё равно новые не появляются.
Да просто отвык от всей ООП-хуиты. Хотя года три назад учился именно ей (впрочем, чему учился, то можно было описывать хоть на чистом С, хоть на каком-нибудь питоне). Плюс, как сказал выше, логика и правила уже сделаны под компилятор образца 91-го года. Это потом я полез (на свою голову) прикручивать графморду.
Давайте проясним, кто главный в создании игр, не считая менеджеров и другого рода быдла.
Ага.
Если капитаном становится программист - получается не игра, а движок.
Если капитаном становится художник - получается... как у ВД и Сохея
Нет, им может быть только Кирилл, решивший не распыляться на ремесленничество кодоблядское, а сразу посвятить себя творению волшебных миров, руководствуясь своим безупречным уникальным видением и бесконечным вкусом.
Из твоего поста ясно следует, что художники не нужны, ведь двигателем корабля тоже заведуют механики.
Дал же тебе ссылку >>98092 на СДЛ 1.2 гуи систему на чистом си. Может она и протухла немного, но её допилить не долго даже для SDL2. Оформлена либой, кнопочки, слайдеры, текстовый вывод, все есть.
>>98098
Читай официальные доки и всякие туториалы от Lazy Foo, последние хоть и корявые, но подкидывают годные идеи порой.
Еще раз.
Почему им не может быть одновременно программист?
Мне нравится кодить и продумывать игру одновременно.
5геймдизайнер-4программист-3художник - капитан
(3геймдизайнер-5программист-2художник)и - механики
(3геймдизайнер-3программист-5художник)и - паруса натягивают
5геймдизайнер-5программист-5художник as God // вернет true
> начинает падать фпс
> Как это можно оптимизировать?
Со скольки до скольки? Если оба значения выше 60, то ты придурок и ничего оптимизировать не надо.
Уже обсудили выше. Там не столько фпс падает, сколько обработка событий.
Никак не получится, бро, увы, скиллом программирования ты навсегда закрыл себе дорогу в геймдизайн, это тебе тут любой подтвердит. Всё, что тебе остается - следовать наставлениям старшео товарища, программируя чего скажут.
Ложь. Абсурд. Нет логики в твоих словах.
Я сейчас являюсь и гейм дизайнером и программером.
Сначала у меня родилась идея. Я её начал продумывать. Представляю какой будет моя игра. И мне это нравится и вдохновляет.
Но также меня вдохновляет и программирование всего этого.
ПО понятным причинам я не могу быть художником, однако невозможность быть геймдизайнером и программистом мне кажется необоснованна.
Геймдизайнер - это ветка общий талантов и скиллов.
Дальше идет ответвление, на "Программист", "Художник", "Управленец" и т.д.
Можно не качать общие навыки, а быть кем-то чистым, но что мне мешает прокачать общую?
Это смешивать программиста и художника сложно, но не геймдизайнера и программиста.
Или ты думаешь, что программисты - это просто машины, у которых нет никакого творческого подхода к делу?
Может такие и есть, но не все.
Все люди могут быть и творческими и техническими одновременно.
Вспомнилось:
- Инженер?! Мне пришлось воспитываться как раз в инженерной среде, и я хорошо помню инженеров двадцатых годов: этот открыто светящийся интеллект, этот свободный и необидный юмор, эта лёгкость и широта мысли, непринуждённость переключения из одной инженерной области в другую и вообще от техники к обществу, к искусству. Затем эту воспитанность, тонкость вкусов; хорошую речь, плавно согласованную и без сорных словечек; у одного немножко музицирование; у другого немножко живопись; и всегда у всех — духовная печать на лице.
У всех инженеров всё остальное по "немножко". Можно ли быть одновременно сильным программистом и сильным геймдизайнером, вот вопрос.
Я считаю можно.
Извиняюсь за стену текста.
Не мог сдержать недоумение.
Деление на творческих гуманитариев и технических квадратноголовых машин - полный бред и абсурд.
Можно и нужно быть и тем и другим.
К чему эти глупые взаимоисключающие варианты развития. "Либо А, либо Б" - это заблуждение.
Можно привести в пример Леонардо, который был и художником и изобретателем. Ну художником можно не быть, но геймдизайнером и программером вполне.
Хотят тут все от человека зависит. Есть механические программисты, лишенные всякого творческого взгляда на свою деятельность, которые "просто кодят" и им пох что, главное как.
Короче хуйня какая-то.
Я люблю программировать и думать об игре. Что за тупые ограничения. Мы не в мморпг, нет четкого лимита на скилл-поинты.
Сильным программистом и сильным геймдизайнером можно быть однозначно.
Все определяет либо хар-ки человека, либо намерение их развить (при условии если человек не даун).
Математика нихуево развивает воображение и фантазию, она многогранна. Как и программирование. Зачем самого себя ограничивать лишь "кодингом". Это же интересно придумывать разные миры и как что должно быть.
Я всю ночь не спал, когда обдумывал свою игру, не мог заснуть из-за возбуждения.
А когда кодил так же испытывал сильное удовлетворение.
Все можно, ограничения мы создаем сами.
Геймдизайн и программирование это разные вещи. Программирование - это инструмент реализации идеи. Отсюда можно развивать независимо эти виды деятельности. А если брать, к примеру, математику, то развитие схожих областей позволяют улучшить общее знание и понимание.
Значит можно развивать сразу все.
Блять ну это же интересно. Я бы не смог быть только программистом или только геймдизайнером - это же полная хуйня.
В первом случае ты только придумываешь, но ты ничего не можешь сделать и желание сжигает тебя изнутри.
Во втором случае ты можешь, но у тебя нет никакого желания, нет душевной силы, нет внутреннего вдохновения.
Меня бесит утверждение что нельзя быть и тем и другим одновременно.
Это очень глупый стереотип(?) или ничем необоснованное, недоказанное утверждение.
Аргумент "так сложилось, все подтвердять" объясняет стереотипную природу этого заблуждения.
Может у вас просто нет желания самому все придумывать?
Так зачем тогда вводить в заблуждение других.
Я считаю можно.
Извиняюсь за стену текста.
Не мог сдержать недоумение.
Деление на творческих гуманитариев и технических квадратноголовых машин - полный бред и абсурд.
Можно и нужно быть и тем и другим.
К чему эти глупые взаимоисключающие варианты развития. "Либо А, либо Б" - это заблуждение.
Можно привести в пример Леонардо, который был и художником и изобретателем. Ну художником можно не быть, но геймдизайнером и программером вполне.
Хотят тут все от человека зависит. Есть механические программисты, лишенные всякого творческого взгляда на свою деятельность, которые "просто кодят" и им пох что, главное как.
Короче хуйня какая-то.
Я люблю программировать и думать об игре. Что за тупые ограничения. Мы не в мморпг, нет четкого лимита на скилл-поинты.
Сильным программистом и сильным геймдизайнером можно быть однозначно.
Все определяет либо хар-ки человека, либо намерение их развить (при условии если человек не даун).
Математика нихуево развивает воображение и фантазию, она многогранна. Как и программирование. Зачем самого себя ограничивать лишь "кодингом". Это же интересно придумывать разные миры и как что должно быть.
Я всю ночь не спал, когда обдумывал свою игру, не мог заснуть из-за возбуждения.
А когда кодил так же испытывал сильное удовлетворение.
Все можно, ограничения мы создаем сами.
Геймдизайн и программирование это разные вещи. Программирование - это инструмент реализации идеи. Отсюда можно развивать независимо эти виды деятельности. А если брать, к примеру, математику, то развитие схожих областей позволяют улучшить общее знание и понимание.
Значит можно развивать сразу все.
Блять ну это же интересно. Я бы не смог быть только программистом или только геймдизайнером - это же полная хуйня.
В первом случае ты только придумываешь, но ты ничего не можешь сделать и желание сжигает тебя изнутри.
Во втором случае ты можешь, но у тебя нет никакого желания, нет душевной силы, нет внутреннего вдохновения.
Меня бесит утверждение что нельзя быть и тем и другим одновременно.
Это очень глупый стереотип(?) или ничем необоснованное, недоказанное утверждение.
Аргумент "так сложилось, все подтвердять" объясняет стереотипную природу этого заблуждения.
Может у вас просто нет желания самому все придумывать?
Так зачем тогда вводить в заблуждение других.
> как можно реализовать смену "экранов" (не знаю, как правильнее назвать): экран с лобби, скажем, экран главменю, экран с игровым видом
Лично у меня стейтами сделано. И есть функция переключения между ними. Не самый гибкий вариант, но когда стейтов всего 3-4, нет смысла запариваться.
Только в коммерческих проектах, где кодеры и художники на зарплате.
Во всевозможных фанатских проектах и проектах "на энтузиазме" геймдизов, пускай даже опытных, с успешными проектами за плечами, как правило кормят хуями и дропают. Источник - личный опыт.
Было даже так, что такой директор-геймдиз собирал команду (20 человек), она за полгода нихуя не делала, а потом половина отваливалась, все в руки брали пара кодеров, посылали нахуй директора с оригинальной идеей и делали все по своему.
Мы тут не баб трахать собрались, а льды северного полюса колоть. Запихни паруса в жопу, ведь РОГАЛИКИ УЛЬТРАХАРДКОР
Обычно программист загружен и без гейм дизайна. Другого квалифицированного персонала в командах нету. По этому на совещаниях нормального программиста тяжело заманить.
Геймдевом программисты занимаются в процессе выполнения задачек своих задач. Попробуют то, потом это, сделают выбор и никого спрашивать не будут.
>>98357
Расскажи об этом, когда выпустишь свою игру, которая не будет а) преальфой б) для специально одаренных кирилов.
Спойлер: ты ничего не доведешь до конца
без обид
>>98357
>>98190
Да ты же поехавший, у тебя даже в постах отступы. Ты просто машина для написания кода и не больше. Смирись с этим.
На основании чего ты сделал такой вывод?
Слова типичного программиста. Ты ведь имитация творчества. Разве ты можешь написать симфонию, сделать шедевр?
Не стоит злиться. Я знаю, правда иногда бывает горькой, но ты должен это принять.
> Хотите быть офисными планктонами и тупо кодить - ваше дело. Вы лишь инструмент. Но говном вы не становитесь. Лишь мочой.
Вы просто придумываете самим себе отмазки, чтобы не совершенствоваться и не вылезать из зоны комфорта.
Лень расширять свой род деятельности и т.д.
Гораздо проще быть лишь шестеренкой в механизме, чем самим механизмом.
> совершенствоваться
В чем?
> расширять свой род деятельности
Расширение не сделает его лучше, а наоборот. Так же как зад твоей мамки.
> Гораздо проще быть лишь шестеренкой в механизме, чем самим механизмом
Гораздо проще "камандавать" чем делать самому.
Начал долбиться с разрешениями экранов и адаптировать игру под эту дрочь.
Ничего умнее, кроме как в лоб проверять размеры экрана и в зависимости от них изменять размер интерфейса я не придумал.
Можно ли как-то умнее это сделать? Масштабировать все изображение к примеру. Я не знаю.
Как вообще решают проблему разрешений экранов?
Никак. Уёбки с сдл сосут хуи, в то время как настоящие программисты пользуются директиксом.
Лично я, решая вопрос в лоб, сделал бы несколько вариантов интерфейса для разных разрешений (опираясь на наибольшее, разумеется). Можно действительно прикрутить поддержку вектора, как у >>101101 (и не как у людей). Тебе размер чего нужно менять: только элементов интерфейса или ещё и текстур/прочего?
Можно всё сжимать встроенными функциями SDL. Но не факт, что они сработают лучше, чем твой фотошоп/гимп/что там у тебя.
Он тебе намекает на двоичную кучу, которая является причиной тормозов. Нужно использовать менее затратные и более продуктивные алгоритмы, например, я таких не знаю и потому сам всё делаю через квадратноедерево, прости господи.
Слишком сложно для меня, мне уже подсказали как убрать тормоза и заработало. Этого хватает пока.
Ага. Кажется, я всё понял. Сам организовал бесконечный цикл, сам и удивляюсь. Нечего код писать по ночам.
ой, ёй не делай так. еще годится если ты залочишь текстурный массив и получишь указатель. Вызывать функцию в цикле это расточительно. функция делает следующее: сверяет координату с границами. лочит текстуру и получает указатель. правит байт по смещению x + y * w. и освобождает текстуру. Блокировку и проверку нужно убрать из цикла, как и call функции
Ай. Зря я амперсанд поставил. В SDL же пользователь никогда не объявляет структуры SDL_Surface, только указатели на них
А еще это просто охереть как медленно, попиксельно весь Surface закрашивать. Аноны правильно про SDL_FillRect() говорят
Пояснити по хардкору неофиту, который кроме ООП пороху не нюхал, событийная ориентированность это сложно сильно?
Нет.
Писать на событийно ориентированном языке/движке - легко. Самому писать такой движок на крестах, наверное, не очень легко.
Динамические тени. Я так и накладываю, но их же нужно сначала для каждого пикселя посчитать, а если тут при простой заливке серфейса одним цветом такие тормоза, то, представляю, что начнется когда я добавлю несколько источников освещения и начну все это рассчитывать.
>>129952
Я так и понял, что делаю что-то не так, но, так как этом деле новичек, то что-то не пойму как это на гпу переложить. Сижу на сдл 2, кстати. Подскажи хоть материалов каких, почитать об этом деле.
Забудь про саму идею динамических теней через Surface. В 2D тени делаются через копирование и модификации спрайта, который должен отбрасывать тень.
Т.е.:
1.Создаешь копию спрайта и заливаешь его темным цветом
2.Растягиваешь-сжимаешь-поворачиваешь эту копию так, чтобы она напоминала тень.
3.Накладываешь сверху оригинальный спрайт.
Если тебе затенение нужно, то сверху Surface спрайта накладывай Surface с формой тени.
Если возникают проблемы с производительностью:
Не забывай переводить созданные из изображений Surface в формат дисплея и только потом с ними работать.
Накладывать в памяти, выводить на экран только готовое изображение. Еще ни в коем случае не отрисовывай/обрабатывай изображения, которые на данный момент не видны на экране.
//Почти закончивший свою игру на SDL1.2 -кун
В каком месте? Вроде куда ни пробовал - так и не помогло.
Еще актуально.
Опытным путем было установлено, что при вызове SDL_CreateRenderer окно создается, появляется, потом пропадает, и через секунду создается вновь. При вызове SDL_RenderPresent происходит мерцание, как будто нет двойной буферизации.
SDL1.2 работает стабильно.
Где копать, кто сталкивался, что возможно поломалось и как это исправить?
Проблему с функцией SDL_CreateRenderer удалось решить заменой флагов с
SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC
на
SDL_RENDERER_SOFTWARE
Но интересно, чем была вызвана проблема, если с дровами все норм.
Может есть знающие люди?
>как это исправить?
Перелезь на OpenGL, поможет точно.
Алсо у меня раньше на старой пеке SDL так же выёбывался, возможно от пекарни зависит. Сейчас у меня всё норм, но я всё равно слезу на OGL ради шейдеров.
Окей, тогда следующий вопрос. Использую связку SDL2 + OpenGL - если ли возможность нечерезжопно отрисовывать SDL_Texture?
Если есть, то покажите пожалуйста свои реализации, а то у меня в связи с посредственным знанием OpenGL выходит внушающий ужас говнометод.
А в чем проблема? В glTexImage2D передаю Surface->pixels, брат жив.
Я рисую окно, внутри окна летают кружочки.
Я хочу сделать, чтобы кружочки не вылетали за поле видимости.
Как узнать размеры этого самого поля видимости? Они точно не равны размерам окна.
гугли window size в сочетании со словом insets и твоей технологией
Осиливаю пикрелейтед, столкнулся с проблемой при реализации TextureManager. По сути обертка над
[code]std::map<std::string, SDL_Texture> m_textureMap;[/code]
Есть загрузка и отрисовка
[code]bool TextureManager::load(std::string fileName, std::string id,
SDL_Renderer pRenderer) {
SDL_Surface pTempSurface = IMG_Load(fileName.c_str());
if(pTempSurface == 0){
return false;
}
SDL_Texture pTexture = SDL_CreateTextureFromSurface(pRenderer, pTempSurface);
SDL_FreeSurface(pTempSurface);
if(pTexture == 0){
m_textureMap[id] = pTexture;
return true;
}
return false;
}
void TextureManager::draw(std::string id, int x, int y, int width, int heigth,
SDL_Renderer pRendrer, SDL_RendererFlip flip) {
SDL_Rect srcRect;
SDL_Rect destRect;
srcRect.x = 0;
srcRect.y = 0;
srcRect.w = destRect.w = width;
srcRect.h = destRect.h = heigth;
destRect.x = x;
destRect.y = y;
SDL_RenderCopyEx(pRendrer, m_textureMap[id], &srcRect, &destRect, 0, 0, flip);
}[/code]
1. Загружаем
[code]m_textureManager.load("res/1.png", "asd", m_pRenderer);[/code]
2. Рендерим
[code]void Game::render(){
SDL_RenderClear(m_pRenderer);
m_textureManager.draw("asd", 0, 0, 100, 100, m_pRenderer);
SDL_RenderPresent(m_pRenderer);
}[/code]
3. segfault
Я в крестах полный нуб, гугл не помог (нашел чувака со схожей проблемой, но там решения нет http://www.gamedev.net/topic/658462-stl-map-and-sdl2-texture-segfault/)
halp?
Осиливаю пикрелейтед, столкнулся с проблемой при реализации TextureManager. По сути обертка над
[code]std::map<std::string, SDL_Texture> m_textureMap;[/code]
Есть загрузка и отрисовка
[code]bool TextureManager::load(std::string fileName, std::string id,
SDL_Renderer pRenderer) {
SDL_Surface pTempSurface = IMG_Load(fileName.c_str());
if(pTempSurface == 0){
return false;
}
SDL_Texture pTexture = SDL_CreateTextureFromSurface(pRenderer, pTempSurface);
SDL_FreeSurface(pTempSurface);
if(pTexture == 0){
m_textureMap[id] = pTexture;
return true;
}
return false;
}
void TextureManager::draw(std::string id, int x, int y, int width, int heigth,
SDL_Renderer pRendrer, SDL_RendererFlip flip) {
SDL_Rect srcRect;
SDL_Rect destRect;
srcRect.x = 0;
srcRect.y = 0;
srcRect.w = destRect.w = width;
srcRect.h = destRect.h = heigth;
destRect.x = x;
destRect.y = y;
SDL_RenderCopyEx(pRendrer, m_textureMap[id], &srcRect, &destRect, 0, 0, flip);
}[/code]
1. Загружаем
[code]m_textureManager.load("res/1.png", "asd", m_pRenderer);[/code]
2. Рендерим
[code]void Game::render(){
SDL_RenderClear(m_pRenderer);
m_textureManager.draw("asd", 0, 0, 100, 100, m_pRenderer);
SDL_RenderPresent(m_pRenderer);
}[/code]
3. segfault
Я в крестах полный нуб, гугл не помог (нашел чувака со схожей проблемой, но там решения нет http://www.gamedev.net/topic/658462-stl-map-and-sdl2-texture-segfault/)
halp?
>SDL_CreateTextureFromSurface
Выкинь это нахуй, юзай сразу текстуры.
SDL_Texture pTexture = IMG_Load(pRenderer, fileName.c_str());
А! Нашёл.
SDL_CreateRenderer(m_pWindow, -1, 0); - твой вариант
SDL_CreateRenderer(m_pWindow, -1, SDL_RENDERER_ACCELERATED); - надо
Без флага хардверной акселерации текстуры нельзя юзать, будут сегфолты.
Алсо, если в будущем будут возникать ошибки, то пробуй дебаггером построчно прогонять и смотреть, на какой строчке оно вываливается.
Можешь ещё дебажить принтами, но это топ кек и ёбаный стыд, поэтому юзай дебаггер.
Алсо, можешь пхать в key сразу имя файла.
Я дурак, нашел ошибку. Дело не в
>SDL_RENDERER_ACCELERATED
Оно что с ним что без него крашится.
На самом деле все банально.
>if(pTexture == 0)
вместо
if(pTexture != 0)
Спасибо за советы, добра.
`code`
code
Хэй, Полсоны, как мне передавать переменные между функциями / процедурами? У меня сейчас что-то вроде state machine, всё идёт от обработчика событий. ГовноПсевдокод:
//обработчик
...
case button1: //нажали 1-ю кнопку
av_table = calc_av(num, cond); //рассчитываем доступные для хода поля в зависимости от номера фишки и внешних условий
//(выделены кружками на пикче)
break;
case field: //щёлкнули в игровом поле
//а вот тут нужны num и av_table для проверки:
//входят ли координаты щелчка в набор доступных
//если входят - перемещаем фишку
break;
Шахматы на пикче для примера, на деле доступность поля определяется сложнее.
Собственно, как num и av_table загнать внутрь второго кейса? Глобальными делать не хочется, какие-то замшелые костыли. Эни айдиас?
>как num и av_table загнать внутрь второго кейса
Глобально, на уровень выше скопа этой функции.
Или временный хранитель - оно же состояние.
Говнокод.
MyStateOfButonDestruction mSt;
Buton_Cuse_Fun()
{
case button1:
mSt.av_table = calc_av(num, cond);
mSt.num = num;
break;
case field:
SomeCrazyDoing(mSt.av_table, mSt.num)
break;
}
Не слишком поможет, я тут подумал. Фишек за один ход можно двигать несколько (хоть каждую один раз). Если только рекурсивно вызывать обработчик (обработчик <- процедура передвижения <- обработчик) для каждой движущейся фишки (они отмечены флагом). Должно сработать, но это какой-то велокостыль.
>но это какой-то велокостыль
Щито поделать, вся жизнь фрактальный велокостыль.
Услышал его голос, лол.
С другой стороны, сегодня подумал: есть вариант впилить av_table в структуру, описывающую отдельную фишку. Памяти больше уйдёт, зато не придётся нарушать порядок вызовов.
Загрузил в сурфейс несколько картинок.
Залочил сурфейсы и вот этой вот функцией http://sdl.beuc.net/sdl.wiki/Pixel_Access
беру пиксель из сурфейса.
Что не так с цветами?
Вместо зелёной стенки должна быть синяя, а вместо этих бирюзовых камней - сервая стенка.
>>137268
2,5d
Ещё раз проверь типы и прочее такое. int, short int, ну ты понел. Хотя компилятор и должен ругаться на их несовпадение.
А вот сейчас сел и починил.
Первый раз я создавал свой "фреймбуфер" вот так:
[CODE]texture = SDL_CreateTexture( render, SDL_PIXELFORMAT_RGBA8888, access, width, height );[/CODE]
А проблема была в том, что текстурки имеют глубину 24 бита.
Сменил формат на:
[CODE]texture = SDL_CreateTexture( render, SDL_PIXELFORMAT_BGR888, access, width, height );[/CODE]
И всё заработало.
В общем, я этой глубиной и форматами пикселей я очень плохо понимаю.
Поэтому реквестирую литературу или статьи какие нибудь.
Что ты там не понимаешь?
RGBA8888 значит что по 8 бит на канал
4 канала: R = red (красный), G = green (зеленый), B = blue (синий), A = alpha(прозрачность)
BGR888
предлагаю самому расшифровать
Собственно - вопрос по SDL2.0
Как создать SDL_Surface по заданным размерам, программно нарисовав в нем изображение?
Вопрос номер два - можно ли это сразу сделать с SDL_Texture?
Естественно, все это без связки с OpenGL.
Все меня разбанали, вопрос снят.
> Анон, подскажи, как всякие кириллы неплохие игры пишут?
Молча сидят и делают.
> Совмещать ли SDL с OpenGL?
Я бы выбрал glfw.
Почему бы не использовать просто SDL? В чем преимущества связки?
> Кстати да, вопрос: можно ли запилить средствами SDL трёхмерность в духе первого Дума
Лучше использовать опенгл или директ 3д для нормального рисования и с помощью них как бы эмулировать псевдотрёхмерность дума.
> Почему бы не использовать просто SDL? В чем преимущества связки?
SDL обеспечивает создание контекста, окна, управление вводом и другими мелочами. Делать какую-то 3д игру типа квейка/дума на чистом сдл это извращение, на мой взгляд. Попробуй вывести крутящий куб и ты поймёшь.
>SDL обеспечивает создание контекста, окна, управление вводом и другими мелочами. Делать какую-то 3д игру типа квейка/дума на чистом сдл это извращение, на мой взгляд. Попробуй вывести крутящий куб и ты поймёшь.
Можно пример использования связки на чистом C? В гугле почти ничего нет по SDL2.
>Попробуй вывести крутящий куб
Не так и сложно, как по мне. Wireframe вообще влёгкую, над раскраской граней надо подумать.
Вопрос с загрузкой текстур. Допустим, есть у меня папочка "assets". Целесообразно ли делать так, как я делаю сейчас? Прохожу в цикле по всей папке, если файл является картинкой, подгружаю его в surface, делаю текстуру. Все происходит перед началом мэйнлупа.
Да можно делать как угодно.
Всем похуй.
>Wireframe вообще влёгкую
Кстати, чуть сложнее оказалось, чем думал. В SDL2 запилили высокоуровневую функцию, которая проводит прямую между двумя точками на экране, а в 1.2 приходится велосипедить попиксельно, как я понял.
В общем, тут странная ситуация. Есть некое поле, состоящее из квадратов. При клике на квадрат происходит некое событие, зависящее от типа этого квадрата. Штука в том, что при клике на один и тот же квадрат все работает отлично, а если одновременно с этим мышкой водить по всему полю, начинает поттормаживать. С чем это может быть связано?
Он, по сути, "активным" не является.
Проходит цикл по всему полю.
for (int i = 0; i < TILESET_X; i++)
for (int j = 0; j < TILESET_Y; j++){
if (Chunk.Tileset[j].x < x && Chunk.Tileset[j].y < y && Chunk.Tileset[j].x+TILESIZE > x && Chunk.Tileset[j].y+TILESIZE > y){
player.gold++;
}
Задействован ведь. Это то же самое, что и следующее.
for (int i = 0; i < TILESET_X; i++){
for (int j = 0; j < TILESET_Y; j++){
if (Chunk.Tileset[j].x < x && Chunk.Tileset[j].y < y && Chunk.Tileset[j].x+TILESIZE > x && Chunk.Tileset[j].y+TILESIZE > y){
player.gold++;
}
}
}
А зачем все тайлы перебирать для поиска нужного? Если у тебя фиксированный размер, то можно обойтись чем то вроде http://pastebin.com/CwpbN6a6
Вот этому гражданину много чаю.
Пилю небольшую эрпэгэ. Ну, по сути, это мой курсач. Но пилю, в основном, для себя. Довольно интересно.
Хорошая статья
Почему не работает? Моб умирает, остальные должны сдвинуться влево, после чего создается новый моб(не в этом куске кода). По идее, этот должен исчезнуть. Но он не исчезает, а исчезает следующий.
int EnemyDie(int id)
{
for (int i = id; i < eAmount - 1; i++)
{
enemies = enemies[i+1];
printf("Enemy #%d changed to Enemy #%d\n", enemies.id, enemies[i+1].id);
}
eAmount--;
printf("Enemy #%d died!\n", id);
printf("Enemies total: %d\n", eAmount);
}
Да, вроде, не пожрал.
Ты уверен что исчезает не тот, который должен? Или ты смотришь в консольку и видишь не те id'ы которые ожидал? Вставь printf ПЕРЕД enemies = enemies[i+1]
я проверял не только по консольке. Бью врага, рядом шляется второй, этого убиваю, второй пересоздается в другом месте. А у того, который должен был умереть, просто хп уходит в минус. И потом при каждом ударе по нему пересоздается второй.
Я не видел того кода где он респавнится, но могу предположить что это происходит после этих смещений. Ты сместил живого врага на место сдохшего, вот он и пересоздает сдохшего, точнее живого на его месте. Ну ты понял.
В чём ошибка-то хоть была?
И в чём преимущество описания функций прямо в хедере, кстати? А то я через хедер только связываю: в iface.h, например, объявления функций, а код в iface.c.
Честно? Понятия не имею, мне так удобнее Киррилить. А есть ли вообще разница?
>А есть ли вообще разница?
Хороший вопрос, сам задумался.
Не, ясен перец, разница в зависимостях при линковке. CodeBlocks их разрешает автоматически, я тут руками мейкфайл пишу.
Ну, конкретно - различные окошки, отрисовывающиеся по ситуации. Например, всплывающее окошко о получении уровня, окно настроек, окно инфо о персе, etc.
> Зачем чистишь рендер до начала, собственно, рендеринга? Это не важно на самом деле.
По идее можно вообще не очищать экран, если ты его полностью перерисовываешь.
Я сделал так. GUI хранит в себе GuiElement и раздаёт им update(), onMouseClick(), onMouseMove().
В игре так:
Rectangle rect = gui->addElement(new Rectangle(0,0,50,50, Color::Red))
rect->addMouseClickCallback(...) // Кнопка
rect->destoryAfter(1.f) // Это уже попап
и т.д.
Глянул, но не сильно понял. Но все равно спасибо.
>>140720
А обработка как конкретно происходит?
Показывай код.
Отклеилось. Это старая версия, сейчас немного по-другому, но суть та же.
В ui::draw просто делаем итерацию по контейнеру и ->draw(). Реализовал гуи 1 раз, вроде удобно получилось.
При клике гую передаётся позиция курсора, затем для квадара 1х1 пикселей ищется пересещение с AABB всех элементов гуя. Если пересекается и у элемента есть коллбэк, он задействуется.
нет у тебя кота, ты просто педик
А другим студентам тоже дали задание написать игру или каждый выбирает что хочет?
Особо не вникал в тему, но нельзя ли попробовать что-то типа SDL + Qt? Не гоните на меня сильно, если я не правмимосдивана
Лол.
На самом деле, просто я немного знаком с Qt, даже что-то делал шашечки, лол, вот и задался вопросом - можно ли написать что-то более сложное, 2д-игру с видом сверху? Ведь там же есть QGraphicsScene, QGraphicsPixmapItem, QAnimation и прочее, казалось бы, что еще надо? Или я не прав, и все это будет не очень легко?
Да откуда ж мне знать?
А что не так?
Имхо или чистый OpenGL, или вообще на js с qtquick (перенося узкие места в кресты). Можно конечно и sdl впихнуть, но зачем, когда вся обвязка над ОС уже есть?
Я могу в программирование, но нужен ещё кто-то.
Ну в общем-то хотелось чтобы тоже немного понимал в программировании, а остальной кодинг я беру на себя.
скоординировался
1. Рендерить текст в SDL_Surface (SDL_Surface, я так понял находится в оперативке).
2. Скопировать данные из SDL_Surface в текстуру.
3. Рендерить текстуру с текстом.
Но если это все делать при рендеринге сцены - это ж получается очень накладно, верно? Как сделать по человечески?
Кажется понял. Этот метод подходит только для статичного текста, либо для создания таблицы символов, на основании которой можно потом рисовать текст методом копирования.
так-же как и в тридэ, только саму трассу в риалтайме пересчитывать не надо, у нее все время один спрайт отображается, ну и у машинок спрайтов лимитированное количество, сколько именно - от тебя зависит
Ну с машинками все ясно. Поясни нубу про трассу, я до этого только саперов делал.
То есть если какой-нибудь хуй с нестандартной раскладкой клавиатуры станет играть в игру с keycode, у него WASD распидорасит по всей клавиатуре?
Тогда лучше scancode, не?
IEEE 754
Загружаешь сам и SDL_CreateRGBSurfaceFrom или SDL_CreateTexture\SDL_UpdateTexture, только зачем?
Хотя я давно уже на опенгл перешел.
Кстати, встроенный импорт GIL'a не рекомендую использовать, png загружает 1 из 20, чтобы четко по стандарту. Рабочее пространство не указано? Эксепшн! Еще что-то не так? Эксепшн! А jpeg у меня вообще не завелся. Но для обработки норм вещь. Это я так, на всякий.
Новое изображение не выводится на экран, но программа продолжает работать - сообщения на консоль выводятся.
Пример кода http://ideone.com/Fu66DW
По уроку 5 туториала TwinklebearDev SDL 2.0 Tutorial.
Если запустить в режиме отладки в VS 2013 Express, то все нормально работает.
чяднт
Потому что процедуроговно без мультитрединга не нужно. Либо ткните меня в надпись, что SDL умеет в млуьтитрединг. SFML умеет.
Нет, я о разделении данных внутрях SDL-а. Я как-то попытался полистать его сырцы — из-за ёбнутого процедурного стиля НЕПОНЯТНО что внутри и как оно работает. Можно ли пересылать в другой поток или нельзя. В таком духе. Весь SDL выглядит как монолитная непараллелящаяся каша — но я могу быть неправ.
Блджад, как будто я помню, что мне захотелось тогда распараллелить. Но однотредовые приложухи — для пидоров.
О, живой архитектурный астронавт. Что, без фабрик абстрактных синглетонов не пишется?
Так никто и не говорит про однотредовые (хотя всему свое место). Просто зачем что-то параллелить в ебаном SDL'е?
Ну вот я и спрашиваю. Зато биндинг SDL для питона - pygame - пока что самая популярная библиотека для игор на питоне.
Создаешь окно, работаешь с событиями. Что тут может быть непонятного? Ты же не будешь ее непрерывно использовать. Создал окно, контекст и забыл.
А картинки загрузить, двигать их, вся фигня. Откуда мне знать, может это там через три пизды делается.
Пацаны, а как работает SDL_RENDERER_PRESENTVSYNC?
То есть по сути это халяный фпс-локер? И мой геймлуп может выглядеть как:
void Igra::Run()
{
while(gamaem)
{
obnovit();
render();
}
}
Короче. Если выставить флаг SDL_RENDERER_PRESENTVSYNC, то никакая ебля с таймерами в геймлупе не нужна. Я правильно понял? Если да, то насколько такой подход эффективен? Может, есть смысл самому поебаться с таймерами?
Да, перед тем как переходить с 2д на 3д обязательно прочитаю весь цикл и напишу свой велосипедный рендерер. Всем советую того же.
Я к тому, что если стоит всинк, то он сам как-то лочит фпс на 60, и мне не нужно писать велосипед. Я прав или не прав?
Таймеры нужны, чтобы лочить фпс
Он лочит на частоту обновлений монитора. А так да, никаких велосипедов не надо. Я писал ответ ранее, но его съела макаба.
>SDL_HINT_RENDER_VSYNC overrides the SDL_RENDERER_PRESENTVSYNC flag in SDL_CreateRenderer().
Ну типа в реалтайме можешь включать/выключать всинк.
не тонем
Глянул, сойдет, если не хочешь сильно разбираться с внутренностями и сразу начать делать. Хотя я все таки предпочитаю Boost.Asio.
Это копия, сохраненная 1 марта 2016 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.