1

To clarify, I know why my game is running slow. I have a lot of different objects in the current area and it has to tick and render all of those objects. I just don't know how to fix the problem without just making less objects.

The answer I am looking for is more of a concept of how I can go about fixing this problem rather than just making a bunch of code for me to paste into my game.

I am designing my games based off of tutorials by RealTutsGML. There where some issues I had to work around with his method of building games, but I figured them out.

So every tick in my game, I have to look through all of the objects that currently exist. The more objects that exist, the longer it takes to process all of them. I need to find a way to help free up memory if those objects are currently not in view, for example. I know games like Minecraft use chunks to free up unused memory. (Blocks outside of the view distance are not generated) What can I do to allow for an environment with many objects without causing so much lag? I want to be able to have a big level without having so much lag from all the objects that have to be ticked and rendered.

Another thing that I will clarify is that all of the objects loaded into the levels are held in a LinkedList so that I can easily create and destroy objects. Every tick, I run a for loop through those linked lists to process every objects behavior and how they are rendered.

[EDIT APRIL 28]

The objects in the game I was working on are organized in a very grid-like format. So that includes the tiles, the player, and all of the other game objects.

  • 1
    You need to profile your code and find those areas which are consuming the most amount of time. Some games use a form of ray tracing to determine of an object is visible or not (drawing lines from the camera to the object to test for collision for example) – MadProgrammer Mar 16 '16 at 06:30
  • I already create a rectangle to represent the current screen. If an object is not intersecting it, it will not be processed or rendered. This didn't work though. –  Mar 16 '16 at 06:36
  • What about those objects which are behind/hidden by other objects on the screen – MadProgrammer Mar 16 '16 at 06:36
  • That doesn't matter. As long as they are in visible view of the camera. –  Mar 16 '16 at 06:44
  • This is too vague. You must explain your data structure & algorithms using it & implementing it in sufficient (but no more) detail that we could *rearrange* it to a different data structure & algorithms--because that's the only way a "why" can be expressed. (Ideally, the data structures are common abstract data types so we already know their specs & implementations and the using algorithms would be already clearly expressed by your code.) PS Your comments are too terse, they are not clear. – philipxy Dec 08 '17 at 08:24
  • I'm having the same problem. All that happens is the cursor lags. (I'm on a system with virtual desktops) If I'm looking at the desktop that the game is not on, then there is no lag. There is only cursor lag on the virtual desktop that the game window is also no. I've looked at System Resources and there is no change; the game isn't filling memory or using all CPU %. – 9716278 Jul 18 '19 at 14:10
  • @9716278 Hey did you try making chunks? That worked for me. Are you using a VM? That could be another problem. –  Aug 11 '19 at 22:48
  • @pebble225 No VM. I'm using Gnome3 just for clarification. I think it has something to do with the way render is called. I commented it out, and it started working fine. https://pastebin.com/MqiFvg8y I've since looked into libgdx.badlogicgames.com – 9716278 Aug 12 '19 at 00:12

2 Answers2

1

You haven't given too much information about your game (I'm not going to look through the tutorial either). You may want to give more background information, and maybe some code snippets.

I know one thing about your code with certainty: you are using linked lists. Linked lists, especially when you add and remove things from the middle, are slow. The reason for this is memory (or cache) locality. When they say computers are growing exponentially faster, they meant the processor is. Your data needs to be transported from its home in memory to another location to a place where it can be used. When data is needed, it is transported by a bus, which also brings neighboring data. (Note that "bus" is actually the technical name for the component.) Linked lists, especially how you're using them, manipulate data in a way that destroys neighborhoods of data. As a result, the bus essentially becomes a "taxi", getting data one at a time. And the bus, according to the graph, is a stunning 10x faster than the computers of the 1980's (remember, the graph has an exponential scale).

Your bus is slow

Also, it seems to me like you probably don't need to tick EVERY object EVERY frame. Yes some objects, like mobs, will need to tick every frame (if they are close enough to be active). From what I assume your game looks like, you have each block of grass being its own object and ticking every frame. Stop watching the grass grow.

MineCraft, for example, will only tick sand blocks when a neighboring block changes (which is why sand generated in the air will only fall when disturbed).

You may want to check these pages out:

Question about memory locality.

Question about linked lists and memory locality

Site explaining cache locality, and source of picture.

Question about slow graphics loop.

Code Review is a good place to get feedback on your code.

Game Development will give more game-based answers.

Community
  • 1
  • 1
Laurel
  • 5,965
  • 14
  • 31
  • 57
0

In an organized environment like such, I think it would be very obvious that making chunks(holds tiles/game objects) and mega-chunks(holds chunks, chunks were still running slow) would be a clear solution especially in an organized environment like this. Like someone on here said, clearly not everything needs to be processed at once and not even exist all at once.

Here is how I see chunks being useful.

I tried this, but didn't see much of a difference, so I am going to try making chunks to hold chunks and hopefully that will help.