That is flyweight, yes.
OH, okay I get that now, but the vertices I still partially don’t understand. Also, wouldn’t you still be allocating the same amount of texture coordinates to the buffer for the VBO, even if you did the sprite regions?
Also, if you think it will help, here is the github repo to the project.
Ok, so I can’t actually find any usages of RenderManager.getCube…() (don’t feel like importing everything into eclipse), but here is the top-16 types memory breakdown:
That’s a lot of instances of a lot of things.
Are there really 350,000+ "DungeonPiece"s?
If you want it to be playable, there’s some work to be done.
On that build, yes. I got rid of that in the new build, I didn’t put it up due to it breaking most of everything. Also, what profiler is that? I’ve been trying to find a good profiler, and that one looks nice. The RenderManager.getCube…() is in the MainDungeon class.
It’s visualVM, ships with the jdk.
I see lots of addCube…(), but no getCube…().
Either way, there’s way too many objects being created and kept around.
I will say that the newest version looks like this in VisualVM
Looks better, although you cropped a lot of good information.
Cropped? That was basically the whole memory profile results, it’s just a really big image.
Wait, I think I might have missed somethings, here is another image.
I feel like I’m continuously derailing your thread, but I meant the overall info and such.
BTW, if images are too large: [[b][/b]img width=800][/img]
Ah okay, thanks! And no you aren’t, it’s helping me out a bit.
I wonder, for the texture coordinate thingy. What if I made a class, named something like SpriteRegion, and when adding a cube instance, check if there is a SpriteRegion for the same sprite already, if so use that one again, if not, add a new one for that sprite.
Just got a major optimization done. Now when generating, the RAM usage only goes up to about 630 mb, and after generation, the RAM usage goes to around 400 mb. Also, now generating an arena only takes around 3742ms, give or take, it could be longer though, as the most I’ve personally seen is about 5000ms. There is no playable version yet, as I had to strip out most of the functionality of the game to get this boost, due to the most of the game depending on the class that took the most memory.
Added a loading screen, less RAM usage, better A.I., and a minimal chat.
Had to get rid of grass for now, as there was problems with it, the sprite and code is still there, just hidden away.
New version is in the link above.
Your file host seems to be down. I tried 12 hours ago, and now.
Ah! Sorry, fixed!
Finally got back around to working on this!
Totally implemented rotation, as well as better everything. Though, I did have to strip out most of everything. Most is re-implemented though.
I also got rid of lighting for the time being, as I plan on baking lighting, due to the lighting being hopefully static.
No download at the moment as I don’t think it is at a release point, kind of just wanted to write this to show that the project is still alive.
(Also might have improved performance drastically, but I really don’t know)
Still no downloadable version, but I improved performance drastically, as in my case, the game’s FPS went from around 350-400, to around 1000, overall really great boost from the fix of my really rookie mistake with the VBO, so now the game should run great, or decently. But, nothing can be exactly perfect, as with these improvements, it introduced a bug with enemies damaging you really quickly.
I’ve also now just added rebindable keys (sadly only for certain ones)! You can now rebind the forward, backward, left, right, sprint, and pause buttons. When the new version is released, the way you would do this is by editing the key. values in the config.txt file in assets/, this will also allow for options like “use keys instead of mouse for looking around”.
Lighting is going well, I guess, lol.
Edit: I’ve gotten lighting to work a bit better, all it really does is bake “lighting” values into the geometry, so therefore, light isn’t dynamic at the moment, I could probably do a sector type thing, where you make sectors that have certain light values, and check what sector you are currently in, and set the lighting of that sector, if the sector is null, don’t apply any lighting, but that is really all there is currently 
What’s happening with that lighting? Looks interesting though! If I could offer a suggestion, try to put some sort of distance limiter or use mipmaps so you don’t get the “checkerboard” effect when you are far away from the tiles in the distance.