Trouble rendering using BufferedImage, pixels and for loops.

Newbie & Debugging Questions
#1

Quite a complicated one, I’m trying to render graphics with the CPU pixel by pixel. I would love to use the GPU for such things but lack the know how. Any recommendations?


BufferedImage image = "theGraphics;"
int pixels = new int[width*height];

for(int x = 0; x < width; x++){
    for(int y = 0; y < height; y++){
    screenPixels[x + y * width] = pixels[x + y * width];
    }
}

I’m trying to find another way as I’m discovering that this isn’t very efficient the more I use it :(. I’ve tried many methods of updating the screen, refreshing only sections of the screen that change, creating a pixel array that gets updated with smaller previously generated pixels. It always takes chunks from the fps every time i add something like a menu with buttons. What could i be doing wrong :emo: ? I’ve uploaded it to github if anyone wants a gander? Stealth is just a genre not the name. Thank you!

Shows what I’m trying.
GameWindow.java
ButtonInterface.java

#2

So you cannot do this with pure java , I found this out. The best way to do this efficiently is to use OpenGL or librarys such as libdgx or LWJGL. There are a lot of tutorials out there.

#3

Aww, I was getting that impression. Are the libraries usable without any restrictions? Like, must I make it open source. Not that I have a problem with that! I’ve been looking at some of the libraries, they seem way more viable.

https://www.youtube.com/watch?v=5oiNmABPeR4 Explains my problem rather well. Awesome channel btw

#4

Use the libraries however you like. I’m sure there’s quite a few paid Android and iOS apps made with libGDX and even more desktop games use LWJGL (such as Minecraft).

#5

Probably go as far as saying most of them will be coded using LibGDX, on Android anyway.

#6

you can get reasonable performance with javas Graphics2D and enough willpower.

dont use the default swing paint methods tho’. create something like this :

http://docs.oracle.com/javase/7/docs/api/java/awt/image/BufferStrategy.html

buffer-strategy is key.

#7

BufferedStrategy is what I’ve been using. I can’t seem to get very far with it since everything is processed via the CPU. I don’t have a bad CPU either. It seems as if I’m pretty restricted and have to down scale everything to reduce the pixel per cycle. :confused: If I have something like a button, I have to keep it updated for the highlight when hovering over it. I’ve tried updating when necessary but it just gets so messy and harder to work with. Say if I had an animated ball bouncing around the screen. I would have to update the balls pixels and the background pixels behind the ball. Which adds pixels per cycle. The problem is when animating. You have to remove the previous pixels before adding the next.

Thanks for the help!

#8

so you paint using a buffered-image or a canvas.

on a canvas you should achieve superb performance for just a tiny bouncing ball. :clue:

#9

Yeah I use a canvas. I’m saying it adds to the pixel per cycle count. If I added an animated background that would get updated so thats like 800600 screen + a 5050 ball thats 24002500 things that needs changing from previous pixel colour to new. If I then add transparent things like a pause menu I would just about double that. Which I’ve tested and it gives me something like 30fps from 200+

Edit: I might not be doing what you said. Take a look at the GameWindow.java , its pretty straight forward. Is that what you mean?

And this is the Canvas


public class GameCanvas extends Canvas{
    public void addListeners(MouseInput mouseInput, MouseMotion mouseMotion, KeyboardInput keyboardInput){
        addMouseListener(mouseInput);
        addMouseWheelListener(mouseInput);
        addMouseMotionListener(mouseMotion);
        addKeyListener(keyboardInput);
    }
}
#10

aah i see. yes, you have the canvas set right (probably).

if you profile your game-loops i guess updateScreen() sticks out. basically you paint on a image (should be speedy), then paint the image on the canvas (slow). as lcass said, it’s not possible to do this with good performance.

see if you can achieve similar results by just using “g” without any extra images.

#11

There’s a lot of scope for micro-optimisation in your code. Back in 2007 I could get 60fps, admittedly at 640x480 resolution, but using software rendering of a 3D scene with z-buffering by updating an int[]. For a start, ditch the calls to List.get every pixel and replace the multiplications with additions. Then ditch the multi-step process where you paint from the button template buffer onto a button buffer and then paint the button buffer onto the screen buffer: you want to do all your painting directly to the output buffer.