Tile images are doing weird things

Newbie & Debugging Questions
#1

Here’s a running example

Controls: W,A and D moves the player; left-click on mouse (or Z) shoots, ESC closes properly.

When you move (and the tiles move around you) they seem to get darker. Looks like some weird bleeding while moving.
I’m using ra4king’s deltaTime loop, I use g.translate to have the player in the middle and place everything around him.
I’ve done everything I could think of, like rounding the doubles for player position and such, and everything else seems to be very smooth.
I use BufferedImages for all my sprites and tiles, and I’m loading them with ImageIO.

I also sometimes see that the tiles are not being rendered for just one frame or so. Any ideas? What part of the code would you like to see?
It’s a pretty standard tile-rendering loop…

Note: This is using just Java2D. Is this one of the weird things Slick2D might solve?

#2

I just ran it and I didn’t get any sort of darkening effect.

What I did get was very jerky/sporadic framerates. When in the ‘starting’ area it would just between 27 and 41 FPS. When I moved out away from the walking critters it went up to about 30-59.

#3

What? That’s weird…my crappy laptop runs it just fine.

Thanks for trying it out, though!

#4

Runs just fine but I did get some strange stuff with just the ground tiles. When camera moves left right up or down, there is a strange gradient type lines that go through just the tiles. I would say try it not in full screen and see what happens.

#5

Yes, and the jumps in FPS are accompanied by sporadic input identification. What I mean is that if I’m holding down the shoot button when I get one of those jumps from 41 to 29 FPS I’ll end up with less bullets fired during that period (Typically in the form of going from C> C> C> to C> C>).

I might blame it on my computer, since it sometimes acts weird, but…

#6

I’ve just ported it from being an applet, because it did the same thing. I was hoping it might just be a problem with the way applets render.

#7

Well, I just tried it on my desktop computer, and it gets the exact same problems and performance as my laptop (they’re equally crappy :slight_smile: ).
Are you by any chance on a computer with an onboard gfx-chipset or something?

#8

Narp.

I’ve got a… Dual Core 3200MHZ AMD Phenom, with 8gigs of ram and an AMD Radeon Chip HD Chip.

#9

Hmm, mine are both Intel dualcores and Geforces…my game must not like AMD :frowning:

#10

I’d try it on another computer, however my laptop’s power cord died last week (Just an insult to various injuries at this point in summer).

I’ll restart my computer and try then. It’s been running for some time now.

#11

Alright, restarting my computer took care of most of the graphics jumps. My iTunes tends to mess up badly when I listen to Audiobooks (Which is to say always, hah. It gets up to almost 2gigs of Ram.)

What I glean from it, now that I’m not suffering the FPS hiccups:

  1. What it looks like to me is that your tiles are ‘piling’ up. If you’re doing any sort of culling (IE- only drawing tiles when they’re on the screen) then I’d look at that code.)
  2. Are you making sure to clear the screen before you draw?
#12

Phew! You scared me there :smiley:

This is my method for drawing tiles. I tried quoting out the if-statements, which are responsible for limiting the game to only draw tiles that are visible, or about to be (the +40 and +80). The playerRenderOffset is the translation everything goes through, to be moved to the right portion of the screen.


    public void drawTiles(Graphics2D g, int roundedPlayerPosX, int roundedPlayerPosY) {
    	int tiles = 0;
    	for( int i=0; i < currentMap.getHeight(); i++){
            // Only draw the tile if it is in range
    		if(roundedPlayerPosY-((height/5)*4)-80 < i*40 && roundedPlayerPosY+(height/5)+80 > i*40){
    			for (int j = 0; j < currentMap.getWidth(); j++) {
    	            // Only draw the tile if it is in range
    				if(roundedPlayerPosX-width-40 < j*40 && roundedPlayerPosX+width+40 > j*40){
    					if(!currentMap.getGround()[i][j].equals("00")){
    						g.drawImage(control.rh.tileList.getTileList().get(currentMap.getGround()[i][j]).getImg(), j*40+playerRenderOffsetX, i*40+playerRenderOffsetY, null);
    						tiles++;
    					}
    				}
    			}
    		}
    	}
    }

I do this before every draw:


g.setColor(Color.black);
g.fillRect(0, 0, width, height);
#13

Hmm, did commenting out the ifs result in a different behavior for the edges? Hmm, as a test to see what’s happening, could you edit your tiles so that they have a border? Like, just a single pixel red box around them, and see what happens at the edges?

As an aside, just because I’m odd and picky… I would honestly attempt to compute your ‘view’ square first, then do the iteration, rather than the other way around.


int startX = Math.min(0, (roundedPlayerPosX - width) / 40  - 1);
int endX = Math.max(currentMap.getHeight() -1, (roundedPlayerPosX + width) / 40 + 1);
int startY = Math.min(0, (roundedPlayerPosY-((height/5)*4) / 40 - 2);
int endY =  Math.max(currentMap.getHeight() -1, (roundedPlayerPosY+(height/5) / 40 + 2);
for(int i = startY; i < endY; i++) {
    for(int j = startX; j < endX; j++) {
        //Paint code.
    }
}

Sort of a micro optimization in a way, however I feel that one’s more readable than the way you’re doing it (Gets a little nesting heavy).

#14

Here’s the gameLoop if someone cares:


	public void run() {
		
		curTime = System.nanoTime(); // FPS counter timer-variable
		currentUpdateTime = System.nanoTime(); // game-loop timing variable
		
		while (running) {
			startTimeOfGameloop = System.nanoTime();

			lastUpdateTime = currentUpdateTime;
			currentUpdateTime = System.nanoTime();

			// I've separated the FPS-calculations for readability purposes.
			updateTimersForFPScounter();
			
			// do whatever the controls command 
			actuateControls();

			//Update any sprite or other graphical objects
			updateGameLogic();
			
			do{
                do{
                	//Handle Drawing
        			Graphics2D g = (Graphics2D)bufferStrategy.getDrawGraphics();
        			draw(g); // draws whatever you'd like

        			//Dispose of graphics context
        			g.dispose();
                }while(bufferStrategy.contentsRestored());
                
                bufferStrategy.show();
                
            }while(bufferStrategy.contentsLost());
			
			// Find out the time it took to render, and deduct it from 1000000000ns/60 = 16666667,
			// to get the amount of time we should sleep after this update, to hit 60fps.
			endLoopTime = System.nanoTime();
			setSleepTime(16666667L - (endLoopTime - startTimeOfGameloop));

			long diff;
				while((diff = System.nanoTime()-endLoopTime) < getSleepTime()) {
				if(diff < getSleepTime()*0.8)
					try { Thread.sleep(1); } catch(Exception exc) {}
				else
					Thread.yield();
			}
		}
		
		s.restoreScreen();
		System.exit(-1);
	}
#15

Wow, thanks for writing that out :slight_smile: And you’re absolutely right. It’s terribly nesty ^^

I’m busy stuffing my face atm, but in about 15 min I should be able to post a new version with a red border at the edges of the tiles.

#16

New version with magnificent colors on the edges of the tile-images. The problem is very apparent now.

Download

#17

I think that the issue might actually be more of with the way our eyes work than anything else. Try it with another tile design and see if it looks nearly so bad?

#18

Really? Or maybe the little LEDs in the screens can’t update fast enough. You really think that’s it?
I have another tileset here. Give me a moment

#19

So I looked at the new jar and now it runs fine but every time I jump the pink lines flicker. Some tiles have red and some blue but where some mix it is pink and those lines flicker when I jump.

I see no other problems what so ever. I really like the particle effects with the blood and ground…I REALLY like the ground.

#20

I think the different borders are used to denote different tile types. Like the grass tops are blue, the ‘edge’ tops are pink, the others are red.