Tile images are doing weird things

[Ultroman]

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?

[UprightPath]

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.

[Ultroman]

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

Thanks for trying it out, though!

Games published by our own members! Check 'em out!

[StumpyStrust]

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.

[UprightPath]

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...

[Ultroman]

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.

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.

[Ultroman]

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...

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 ).
Are you by any chance on a computer with an onboard gfx-chipset or something?

[UprightPath]

Narp.

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

[Ultroman]

Narp.

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

Hmm, mine are both Intel dualcores and Geforces...my game must not like AMD

[UprightPath]

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.

Games published by our own members! Check 'em out!

[UprightPath]

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?

[Ultroman]

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?

Phew! You scared me there

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.

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17

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:

1   2

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

[UprightPath]

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.

1   2   3   4   5   6   7   8   9

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).

[Ultroman]

Here's the gameLoop if someone cares:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21   22   23   24   25   26   27   28   29   30   31   32   33   34   35   36   37   38   39   40   41   42   43   44   45   46   47   48   49   50   51

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);    }

[Ultroman]

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.

1   2   3   4   5   6   7   8   9

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).

Wow, thanks for writing that out 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.

[Ultroman]

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

Download

[UprightPath]

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?

[Ultroman]

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

[StumpyStrust]

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.

[UprightPath]

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.

[Ultroman]

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.

Thank you! I spent a lot of time on that ground. That little particlespray took me about an hour. It's exceedingly simple, but I think it does the job well. It's just ovals (too small to get a regular shape) and 1px lines ^^

Here's a new version with another almost finished tileset (I have to educate my artist on how to make seamless tiles   )
Download

I think the problem is, that in my original ground tileset, I used a lot of thin black lines, which made it very obvious that it takes time to change a LED from off (black) to a color, or from one extreme color to another. And yes, you're right about the pink. The red does it a bit for me , too.

Note: CBA to change the color of the particles flying from the ground right now.

Thank you both SO much for helping me find out, that I really didn't have much of a problem here after all

[UprightPath]

Sure! I'd noticed before that that happened. I had fun like that happening in my game (The Perils of Alchemy one in the showcase thinger.)

[StumpyStrust]

Ehh here is some quick seamless dirt.



 

[Ultroman]

Sure! I'd noticed before that that happened. I had fun like that happening in my game (The Perils of Alchemy one in the showcase thinger.)

Did you fix it? Or is it still apparent? I'm gonna take a look, if I can

Ehh here is some quick seamless dirt.



 

Funny ^^
Although that looks just fine, I'm going for a more cartoony feel. I hope the artist won't feel too bad about having to redo most of his work. It is a trade of the business he's in after all, heheh

[Ultroman]

Wow, I see what you mean. Bricks are gonna be a nightmare in my game, too. MAN those are some hard controls!!

[matheus23]

I just downloaded your jar, and noticed something about how you store your files.
This is not really about your problem here, it's more about the problem in another thread you startet. That thread was (in the offtopic part) about the loading time for all your images.

I see you are having a different Image for every tile you have. Don't do this. Put everything in one or more .pngs, and split them at runtime, so you call BufferedImage.getSubimg() for every tile. That should greatly reduce file loading.

[UprightPath]

Heee~ Yeah, my controls are vaguely based off of the original Sonic game with lots of physics in the actual controls beyond just jumping/falling. I'm redoing a lot of the engine though, so... anyway.

I think I fixed it pretty well (The issue is to do with repetition of small patterns, I think.)

[Ultroman]

Heee~ Yeah, my controls are vaguely based off of the original Sonic game with lots of physics in the actual controls beyond just jumping/falling. I'm redoing a lot of the engine though, so... anyway.

I think I fixed it pretty well (The issue is to do with repetition of small patterns, I think.)

Yeah. I think you're right.

I see you are having a different Image for every tile you have. Don't do this. Put everything in one or more .pngs, and split them at runtime, so you call BufferedImage.getSubimg() for every tile. That should greatly reduce file loading.

Thanks. I'll do that

[Vladiedoo]

This is really off topic but I ran the first running example and wanted to say that you should use

1	g.drawString(String.format("%.2f",movementSpeed), x , y);

to view the movement speed rounded to two decimals, unless you're trying to see the exact value that the movement speed is at. Also I'm on a 1920 x 1200 screen and the bullets don't reach to the edge of the screen so it looks odd with them stopping in mid-air. Other than that I really like what you've done with the game so far (movement is smooth), good luck and hope this helps.

[Ultroman]

This is really off topic but I ran the first running example and wanted to say that you should use

1	g.drawString(String.format("%.2f",movementSpeed), x , y);

to view the movement speed rounded to two decimals, unless you're trying to see the exact value that the movement speed is at. Also I'm on a 1920 x 1200 screen and the bullets don't reach to the edge of the screen so it looks odd with them stopping in mid-air. Other than that I really like what you've done with the game so far (movement is smooth), good luck and hope this helps.

Thanks for the nice words Yes, well, all the HUD was made in a hurry to check for problems while debugging. I usually use DecimalFormat to format to fewer decimals, but this is a much less intrusive and performance-saving way. Thanks for that.

As for the length of the bullet-travel, this is going to be a variable per each type of ammunition, so it is just set to a random travel-length for now. Also, some will penetrate multiple enemies and such. It's gonna be rad! Thanks for the note, though. I'm happy to hear it is running fine, even in HD
When the menus are being done, you'll be able to choose between all resolutions available for your gfx-card. For now, I just have a list of a few standard ones.