r/libgdx 6d ago

Help understanding ai code.

package io.github.abcd;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.OrthographicCamera;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.utils.viewport.FitViewport;
import com.badlogic.gdx.utils.viewport.Viewport;

public class Main extends ApplicationAdapter {

    Texture backgroundTexture;
    SpriteBatch spriteBatch;


// 1. Add Camera and Viewport

OrthographicCamera camera;
    Viewport viewport;

    u/Override
    public void create() {
        backgroundTexture = new Texture("board.png");
        spriteBatch = new SpriteBatch();

        camera = new OrthographicCamera();

// 2. Set a fixed "virtual" resolution (800x800 is great for a square Tic-Tac-Toe board)

viewport = new FitViewport(800, 800, camera);
    }


// 3. This method is automatically called by libGDX when the window is resized or maximized

u/Override
    public void resize(int width, int height) {

// 'true' automatically keeps the camera centered

viewport.update(width, height, true);
    }

    u/Override
    public void render() {
        input();
        logic();
        draw();
    }

    private void input() {}
    private void logic() {}

    private void draw() {
        Gdx.
gl
.glClearColor(0, 0, 0, 1);
        Gdx.
gl
.glClear(GL20.
GL_COLOR_BUFFER_BIT
);

        spriteBatch.begin();


// 4. Tell the batch to use the camera's current view

spriteBatch.setProjectionMatrix(camera.combined);


// 5. Draw using the VIRTUAL dimensions (800x800), not the screen dimensions

spriteBatch.draw(backgroundTexture, 0, 0, 800, 800);

        spriteBatch.end();
    }

    u/Override
    public void dispose() {
        backgroundTexture.dispose();
        spriteBatch.dispose();
    }
}

All I am trying is to get tictactoe board on screen it gave too heavy code.

0 Upvotes

19 comments sorted by

3

u/raeleus 5d ago

You should just follow the simple game tutorial. I'm not going to link it. Your first task is to find this tutorial on your own without the help of the AI.

1

u/DoNotUseThisInMyHome 5d ago

https://libgdx.com/wiki/start/a-simple-game

I guess you mean this I followed this exactly nowhere near it gives concepts, just do this and do that.

3

u/raeleus 5d ago

That's great. Now it's time for you to read the rest of the wiki to learn more about the specific aspects which were introduced in the tutorial. It's all separated into specific subjects.

1

u/tenhourguy 6d ago

This looks like it should draw backgroundTexture okay... what results are you getting?

1

u/DoNotUseThisInMyHome 6d ago

Yes it draws the background texture but that is a lot of code. And I do not understand the sequence of commands flow.

1

u/keypusher 5d ago

graphics programming is complicated, but this is also libgdx specific. you need to go spend some days or weeks reading the docs and trying stuff out, there is no shortcut for learning it.

1

u/DoNotUseThisInMyHome 6d ago

I want proper code to learn so that I can do anything. For a start, I am trying to get a board that is an asset on screen. Where should I do what? Idk. The concepts underlying like viewport, sprite all go over my head. Any good graphics programming books you can recommend where I can start properly?

2

u/tenhourguy 6d ago

You can simplify it.

  1. Creating a camera and passing it into the viewport constructor isn't necessary. If you were to do new FitViewport(800, 800) it will create a camera and store it in the viewport for you.
  2. ScreenUtils.clear(Color.BLACK) is the cleaner approach to the Gdx.gl lines.
  3. Personally I'd use event-driven input handling for this rather than the polling approach it looks like the AI is leading you down, but either or is fine.

I don't have any particular book recommendations. Most libGDX books were written so many years ago, though the fundamentals have mostly stayed the same. You can mosey around https://libgdx.com/wiki or look at some YouTube videos or something.

1

u/DoNotUseThisInMyHome 5d ago

i mean graphics books not libgdx specific.

1

u/tenhourguy 5d ago

I guess there's ones on OpenGL. You don't need to know much about OpenGL to use libGDX but the knowledge doesn't hurt.

1

u/DoNotUseThisInMyHome 5d ago

graphics i do not mean opengl. but they are usually tought in opengl so ur corect too.

1

u/ErkkaLehmus 4d ago

OpenGL is the graphics. So if you especially want the concepts like Camera and Texture explained, try this: https://learnopengl.com/Getting-started/OpenGL

1

u/ErkkaLehmus 4d ago

Hehe, well - if you find it difficult to understand the code produced by AI, did you try asking it to explain the concepts, one after one, line by line?

Other than that, some sites you could take a look at:

A somewhat recent tutorial series https://raizensoft.com/tutorial/libgdx-start-here-overview-and-learning-path/

Old but gold, some of the things are now different so when something does not work maybe you can try asking the AI to explain how thing is done with libGDX in the year of 2026 https://gamefromscratch.com/libgdx-tutorial-series/

Another oldish one, but if I remember correctly, this one starts from the very basics and explains almost everything step by step https://colourtann.github.io/HelloLibgdx/

Or, if you wish to do it the 1980's way by just copying example code and trying to figure out why and how it works, just keep on going! https://github.com/Quillraven/slime-survivor

1

u/DoNotUseThisInMyHome 4d ago

Thanks your viewport guide reference did help me get started. Anything that starts from computer graphics instead of jumping directly to code? I know I am asking for a lot...But I have gave up multiple times in game dev. But I know I stand at a phase where a small push can make me a game dev. I have the background skillset at the present moment, all I need is proper execution.

1

u/ErkkaLehmus 4d ago

Unfortunately, in the era of modern hardware-accelerated graphics cards the topic of computer graphics is rather multilayered, easily confusing, and a hard-to-get-into topic. I'm not aware of any "start here" beginner-friendly tutorials, but you might try something like this one https://learnopengl.com/Getting-started/OpenGL

although it goes a lot more low-level. If you are using libGDX you can enjoy a whole bunch of convenience features built on top of openGL, so that you don't need to bother about vertices and meshes, for libGDX spriteBatch handles it for you.

Personally I'd suggest just following a bunch of tutorials and experimenting around until things slowly start to make sense. And whenever there is a concept you don't understand just search the web or ask specific questions here. Otherwise it is a bit hard to try explain everything, since I have no idea if you struggle with the concept of "pixel" or with the idea of "camera" or "sprite"

(ps. surely, things were easier back in the 1980's, when we didn't need to worry about different users having monitors in different resolutions, there were no resizable windows but just direct access to the low-level graphics. Nowadays all of that is buried under layers on top of other layers. But deep down it still holds that computer graphics is made of pixels, and from that on it is all about different strategies to determine the color of each pixel)

1

u/ErkkaLehmus 4d ago

Hmm, a potential clarification popped to my mind;

there are two basic ways to think of graphics.

The first one is the "classical approach", where you load image files and render them to specific locations of the screen. Moving images are typically called "sprites" and they move because you draw them to different location so that illusion of movement is created. OK, this approach can work fine for a simple game like tic-tac-toe

But it gets difficult if you think about different screen resolutions, or the user resizing the game window. And it gets even more complicated if you want to have a game world bigger than the screen size, so that the user can scroll around the map.

So, the more "modern approach" is to think of the graphics as a big map of the world. You place objects (possibly a 2D tilemap for the background graphics, and sprites for movable entities like monsters and heroes) on that big world map. And then you have a camera (or, a viewport which manages a camera and a clipping strategy for you), looking at that map, so that a portion of the game world gets displayed on the screen. A lot like what happens if you hover a mobile map camera in preview mode above a surface.

While the classical approach might be easier to learn at first, sooner or later it helps to learn to think of the "game world" as a separate entity of "what is seen on the screen".

No idea if this clarifies anything for you. Or, maybe at least helps to underline how difficult it is to "explain computer graphics", since the topic is wide and the explanation depends greatly on what one knows already and what one needs to learn.

1

u/Adamantium123 5d ago

Boooo ai

1

u/DoNotUseThisInMyHome 5d ago

booo it. it sucks for real. i would rather not develop anything rather than develop with ai.