Вот скрин:
при движении персонажа по миру, стрелочки движение в лева и вправо остаются на координатах которые были им заданы изначально в конструкторе, то есть если персонаж находится допустим в правом конце мира, стрелочки останутся в начале, их не будет видно если мир больше экрана в два раза, пробовал просто брать координаты персонажа и задавать эти координаты стрелочкам управления, выглядит не эстетично, все подергивается да и не хочется всем элементам которые должны располагаться по верх мира и не двигаться относительно мира задавать координаты персонажа, я вот случайно наткнулся на это видео
здесь антологичная проблема, текст с очками уходит за границы экрана, он ее решает просто добавляя дополнительную камеру, это выглядит примерно так:
//JAVA CODE SpriteBatch spriteBatch = new SpriteBatch(); OrthographicCamera cam = OrthographicCamera(); OrthographicCamera twoCam = OrthographicCamera(); public fish() { //Конструктор... } @Override public void render(float deltaTime) { spriteBatch.setProjectionMatrix(cam.combined); //Рисование персонажа врагов и тд а также движение камеры относительно персонажа spriteBatch.setProjectionMatrix(twoCam.combined); //Рисование очков, значков управления, жизней, и т. д. }
и как видно на видео это работает...
у меня архитектура игры scene2d где есть Stage stage (сцена), которая имеет лишь одну собственную камеру и я понятия не имею как применить такое же решения для этой архитектуры...
//JAVA CODE SpriteBatch spriteBatch = new SpriteBatch(); Stage stage = new Stage(WORLD_W,WORLD_H, false, spriteBatch); Fish fish = new Fish(this); //Fish наследник Actor public Fish() { //Конструктор... stage.addActor(fish); } public void setCamera(float x, float y) { stage.getCamera.position.set(x, y, 0); stage.getCamera.update(); //В классе fish и меняем позицию камеры относительно персонажа } @Override public void render(float deltaTime) { stage.act(deltaTime); stage.draw(); }
решил задачку))))) все оказалось очень просто, добавил еще одну сцену в которой камера статична и к этой сцене добавил актеров (управление), аж стыдно за потраченное время, которое вы уделили читая это( если уже зашли помочь то как вы считаете такое решение нормальное? не костылек ли это?
Вот когда я только начинал писать под андроид, мне LibGDX очень нравился, но чем дольше я на нем писал, тем больше складывалось впечатление, что он практически целиком состоит из таких вот "костыльков". Вроде бы и возможностей дофига, но нет такой четкой взаимосвязанной структуры всего движка в целом. Камера, actor-ы вроде и есть, но можно писать и без них. Получается так - пишешь какой-нибудь тетрис, потом хочешь всунуть какой-нибудь эффект типа дрожания камеры при падении фигур смотришь документацию (которой практически нет или написана левой ногой), ага - вроде есть камера для этих целей, день вкуриваешь, как ее использовать и в итоге приходишь к выводу, что тебе надо переписать весь код с нуля или костылить свою камеру, ибо в твою архитектуру та камера уже не вписывается. Как сделана анимация - я вообще не говорю. Когда я после HGE стал смотреть, как вывести простую анимацию из sprite-sheet-а, так это же просто апогей идиотизма. Мне даже не хватило сил туториал с анимацией пройти - за день написал свой класс для этих целей и он у меня благополучно перекочевал в собственный движок. Короче, ИМХО LibGdx - это такой набор костылей и костыльков уже от разных производителей, которые между собой вроде бы и стыкуются и работают (как ни странно!!!), но очень разрозненные и, как правило, с устаревшей документацией (в лучшем случае) или чаще вообще без нее. В любом случае, для полноценной игры к самому LibGDX нужно еще прикручивать кучу всего - GUI(встроенного вообще нет), атласы, нормальные аниматоры, нормальные частицы и т.д. и т.п.
ЗЫ. Еще жутко бесит в LibGdx, что координаты экрана считаются снизу вверх при выводе графики, и наоборот при обработке тачей.
Нормальное решение, сцена с игрой и сцена с гуём. Собственно, так это и делается
Вообще можно batcherу сначала приписывать первую камеру, рисовать объекты, потом вторую, и дорисовывать gui.
Тема в архиве.