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?

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.

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

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.

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?

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?

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.

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.

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

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.

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

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

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.

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.

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org