Resizing all textures by screen width??

[centenond]

Hello im a total noob in java, im learning game development, i made this game and when i thought i was finish i tested in another android with a smaller screen and puf all the game was ugly. I started rezing evrything by screen width, example

batch.draw(position.x, position.y,Gdx.graphics.getWidth()/7, Gdx.graphics.getWidth()/7 );

ive resized all textures and background and now it looks the same in both devices.

I feel this method to this is sketchy, already did it but in my futures games, is there a easier way to accomplish this ?

Also the speed of the enemy is moving faster in one devices, I did the speed times delta thing and still :/

Sorry for my bad english
Thank you very much

[JamesCherrill]

Maybe you could render all your graphics at some fixed resolution (eg HDTV) and use a scale(double sx, double sy) to scale all the contants to whatever the actual screen resolution is?

As for speed... what Timer are you using?

[centenond]

Im using Gdx.graphics.getDeltaTime();
Thanks for replying

Maybe you could render all your graphics at some fixed resolution (eg HDTV) and use a scale(double sx, double sy) to scale all the contants to whatever the actual screen resolution is?

As for speed... what Timer are you using?

[JamesCherrill]

Normal practice for Java animation is to use a java.util.Timer scheduleAtFixedRate to update the state of the model, then invalidate the GUI state to force a re-draw. That way the animation proceeds at a constant speed and the screen gets updated as often as possible.

[centenond]

I gotta be honest with you james, i did not understood anything you said Im very noob in java, i did this

java.util.Timer timer = new java.util.Timer();
System.out.println(timer);

And it print out this

java.util.Timer@26838573
java.util.Timer@513f9590
java.util.Timer@75ce5af9
java.util.Timer@53850507
java.util.Timer@7233bb11

are u saying that i should multiply speed * timer?
its not printing out a int/float

[centenond]

Say this is my render method

public void render(batch){
     batch.draw(enemy.x,enemy.y += 1) 
}

okay so i did Try and it didnt work

public void render(batch){
     batch.draw(enemy.x,enemy.y += 50 * Gdx.graphics.getDeltaTime()); 
}

how would you that with the java.util.Timer?

Normal practice for Java animation is to use a java.util.Timer scheduleAtFixedRate to update the state of the model, then invalidate the GUI state to force a re-draw. That way the animation proceeds at a constant speed and the screen gets updated as often as possible.

[JamesCherrill]

The Timer method for running an update every 30 mSec (33 fps) looks like

scheduleAtFixedRate(this::updateSimulation, 0, 30, MILLISECONDS) // NB Java 8

where updateSimulation is a method that updates the model, like

   public void updateSimulation() {
        // reliably called by Timer every 30 milliseconds
        xPos += xSpeed; // update position of object
        yPos += ySpeed;
        repaint(); // notify that screen refresh is now needed
        // (that's for Swing, need the GDX equivalent)
    }

your render then just renders things at their latest position - it NEVER updates anything.

ps: This is different from the normal GDX way of doing things because it gives more control, especially when the hardware is struggling to maintain the frame rate.
If you find this confusing then you will probably be better off ignoring it and staying with the ordinary GDX Animation class.

[mKorbel]

quite disagree with @JamesCherrill

1. for Java animation is to use a java.util.Timer scheduleAtFixedRate == not is about Swing Timer with repaint

or it should be from any more accurate timer (doesn't matter - java.util.Timer), but events are out of EDT in Java7/8 (removed all thread safe methods, incl. a few issues with repaint() & EDT)

1. to update the state of the model, then invalidate the GUI state to force a re-draw. == by using PropertyChangeListener/Support

[JamesCherrill]

I don't understand
Are you disagreeing with my choice of java.util.timer, or my use of repaint?

[mKorbel]

• I'm disagree with java.util.Timer in Java7/8 for AWT/Swing based GUI

• it could be possible by to call firePropertyChange from java.util.Timer

• standard is (inaccurate) Swing Timer

_______________________________________________________________________

• (OP wrote) "I started rezing evrything by screen width, example" its about getPreferredSize and together with stopping to use draw() instead of paint/paintComponent in 21th. century

[centenond]

So i was thinking, bare with my english. what if the speed is okay and the one thing is making speed up the enemy is the x/y axis?

here some photos to explain..

@JamesCherrill
@mKorbel

[centenond]

@mKorbel, are u saying i should stop using draw and start using paint()?
and how do i use paint? thanks for replying

[JamesCherrill]

I was suggesting java.util.Timer to update the model, not the GUI.
In general, the model may be CPU intensive (eg checking collisions between arbitrary shaped sprites) so I avoided javax.swing.Timer to keep that processing off the Swing EDT.
Yes, you could use firePropertyChange to trigger a GUI update. I just think repaint() is easier. In this case the OP is using GDX, so the method to invalidate the GUI will be different.

@centenoid. If you want to run on screen with different pixel sizes you need to build your model in some independent units (eg millimeters) then scale that to actual screen resolution when painting/updating the GUI.

[centenond]

Thanks James, the speed problem was the x/y axis, did what u sugested and it works now , same speed in smaller and bigger screen.
Thank you very much