Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Oppugno (Alpha 261a released!)  (Read 3312 times)
0 Members and 1 Guest are viewing this topic.
Online tinfoilboy
« Posted 2014-08-28 00:51:09 »

Oppugno is a game where you kill endless amounts of enemies in an arena. I'm planning on adding a lot to this, one of the features being multiplayer (that's going to be so much fun *sarcasm*).

Download the current version, Alpha 261a!

Controls (Can be changed in assets/config.txt!):

W, S, A, and D to move.

Shift to Sprint.

Tab to go to shop

Left Click to swing/shoot

Right Click to open chests





Changelog:

Oppugno Alpha 260a Changes
--------------------------

• Massive performance improvements.
• Rotation!
• Semi-working lighting!
• Added a bow fire texture and sound.
• Better GUI (Less text, more visual).
• Preparations for Multiplayer.
• New pause menu (plus new GUI stuff)!
• Projectiles are now completely abstract (what projectiles do on collision with an object is determined by a callback, as opposed to hardcoded)!
• Rebindable keys (found inside of assets/config.txt)!
• Generation improvements.
• Lots of bug fixes.
• New enemy sprite (courtesy of 0Creds)
• Sensitivity option.
• Fixed texture bugs.
• Toggleable HUD showing (use F10 to show and hide the HUD)!
• Fixed the out of memory exceptions people were getting.

Oppugno Alpha 261a Changes
---------------------------------

• Fixed a bug where purchasing an upgrade could put you in negative money.

Offline jrenner
« Reply #1 - Posted 2014-08-28 10:47:03 »

looks neat. some problems on linux:

1. grass and weapon(?) sprites failed to loaded, replaced by a purple texture.
2. couldn't get any controls working except WASD and left-click
Offline EgonOlsen
« Reply #2 - Posted 2014-08-28 13:35:55 »

Why does it require 3gb of RAM? It can't run on a 32bit OS this way. I tried it anyway with a max heap of 1gb and it crashed with an OOM.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Gibbo3771
« Reply #3 - Posted 2014-08-28 14:54:01 »

Runs shockingly bad.

10FPS

Uses 2.5GB of RAM

Disk usage hits 100%


Sounds like you got a massive memory leak, as well as continous I/O operations going in the loop.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Online tinfoilboy
« Reply #4 - Posted 2014-08-28 15:44:40 »

Runs shockingly bad.

10FPS

Uses 2.5GB of RAM

Disk usage hits 100%


Sounds like you got a massive memory leak, as well as continous I/O operations going in the loop.

I don't even do any disk I/O, other than loading the assets, which is done before I even generate the arena.

Online tinfoilboy
« Reply #5 - Posted 2014-08-28 15:46:16 »

Why does it require 3gb of RAM? It can't run on a 32bit OS this way. I tried it anyway with a max heap of 1gb and it crashed with an OOM.

The only reason I can think of that it requires 3 gigs/2 gigs of RAM is that the generation takes up most of it, but when it's allocated, the data is never deleted, for some reason. Also, it doesn't require exactly 3 gigabytes, it requires more like 2 gigs, the generation was way faster when I set it to three. I also have a theory that what is using most of the memory is the buffer that stores the vertices, texture coordinates, and normals for the world VBO, as it is just a static object.

Online tinfoilboy
« Reply #6 - Posted 2014-08-28 18:05:50 »

looks neat. some problems on linux:

1. grass and weapon(?) sprites failed to loaded, replaced by a purple texture.
2. couldn't get any controls working except WASD and left-click

The sprite problem was me being an idiot, and forgetting to add the new assets *facepalm*.

I need to do more testing on Linux, I've mainly been testing on Windows.

Online tinfoilboy
« Reply #7 - Posted 2014-08-28 19:06:19 »

I've lowered the memory requirement a bit, now it is only a little above 1 gigabyte, no downloadable version yet because I had to rip apart most of the mechanics to get that increase.

Offline Gibbo3771
« Reply #8 - Posted 2014-08-28 19:15:26 »

Runs shockingly bad.

10FPS

Uses 2.5GB of RAM

Disk usage hits 100%


Sounds like you got a massive memory leak, as well as continous I/O operations going in the loop.

I don't even do any disk I/O, other than loading the assets, which is done before I even generate the arena.

Odd, for some reason it makes max's out my disc write and read. Also memory sort of ranged between 2.4-2.5 for me. I presume you are loading the entire level into memory? Rather than chunks? If so then the memory amount makes sense.

Perhaps implementing chunk loading before anything else is a good first step. It will make life easier down the line.

"This code works flawlessly first time and exactly how I wanted it"
Said no programmer ever
Online tinfoilboy
« Reply #9 - Posted 2014-08-28 19:18:55 »

Runs shockingly bad.

10FPS

Uses 2.5GB of RAM

Disk usage hits 100%


Sounds like you got a massive memory leak, as well as continous I/O operations going in the loop.

I don't even do any disk I/O, other than loading the assets, which is done before I even generate the arena.

Odd, for some reason it makes max's out my disc write and read. Also memory sort of ranged between 2.4-2.5 for me. I presume you are loading the entire level into memory? Rather than chunks? If so then the memory amount makes sense.

Perhaps implementing chunk loading before anything else is a good first step. It will make life easier down the line.

Yeah, it's just one massive VBO, I remove all of the data after generation, but you would run out of memory before you would be able to generate it fully. So I am going to have to do chunked rendering, which sucks because I wanted to avoid that, but, you gotta do what you gotta do.

Also if you are on Windows 8/8.1 the disk maxes out for no reason at anytime, not just when playing my game, for me at least.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline trollwarrior1
« Reply #10 - Posted 2014-08-28 19:21:31 »

When I ran the game, my PC completely froze for a few minutes. Then, the game crashed and all my applications took another minute or so to restore their memory o-o

I don't understand, what the hell are you doing that is consuming 2gigs or ram? Could you explain that more or did I miss something?
Online tinfoilboy
« Reply #11 - Posted 2014-08-28 19:26:12 »

When I ran the game, my PC completely froze for a few minutes. Then, the game crashed and all my applications took another minute or so to restore their memory o-o

I don't understand, what the hell are you doing that is consuming 2gigs or ram? Could you explain that more or did I miss something?

I'm generating an arena. I generate the border, pillars, chests, and grass separately for organization, I just generate the vertices, texture coordinates, and normals for the iterations that certain piece and add it to a static VBO, then once that is done I bind, fill, and clear the buffers for the VBO, and then draw it. That is where the memory is filled, and probably where your computer slows down.

Offline BurntPizza
« Reply #12 - Posted 2014-08-28 19:27:26 »

That doesn't sound like anything that would take more than a second or two and certainly not something that would lock the machine.
Online tinfoilboy
« Reply #13 - Posted 2014-08-28 19:30:04 »

That doesn't sound like anything that would take more than a second or two and certainly not something that would lock the machine.

That does seem like the problem, due to it taking up 80% CPU on my PC during that process...

Offline trollwarrior1
« Reply #14 - Posted 2014-08-28 19:33:14 »

How many vertices do you have?
Maybe you are creating your VBO each frame?
Online tinfoilboy
« Reply #15 - Posted 2014-08-28 19:49:46 »

How many vertices do you have?
Maybe you are creating your VBO each frame?

I am not recreating my VBO every frame, I assure you XD

The size of buffer itself (which contains all of the vertices, texture coordinates, and normals) is 96640032.

Offline BurntPizza
« Reply #16 - Posted 2014-08-28 19:55:12 »

Quick investigation (haven't run the code or profiled it, just looking):

Your memory issues are most likely from (profile to verify this) the fact that you store all the vertices and texcoords of each cube in the map, in each cube in the map. Look up the flyweight pattern. Vertices can be easily computed from a single Vec3 world coordinate, and instead of storing all the texcoords just store which texture region that cube renders with.

Things like Sprite.getRandomSpriteFromSheet() shouldn't be creating a new Random object at every invocation. Re-use the Random object.

Also various instances of high time-complexity like large triple nested loops.


There is no reason a program like this should use multiple Gb of memory. That's insane.
Online tinfoilboy
« Reply #17 - Posted 2014-08-28 20:06:32 »

Quick investigation (haven't run the code or profiled it, just looking):

Your memory issues are most likely from (profile to verify this) the fact that you store all the vertices and texcoords of each cube in the map, in each cube in the map. Look up the flyweight pattern. Vertices can be easily computed from a single Vec3 world coordinate, and instead of storing all the texcoords just store which texture region that cube renders with.

Things like Sprite.getRandomSpriteFromSheet() shouldn't be creating a new Random object at every invocation. Re-use the Random object.

Also various instances of high time-complexity like large triple nested loops.


There is no reason a program like this should use multiple Gb of memory. That's insane.

Wait, let me see if I get this correct. I get the nested loops and the random thing, but the storing vertices part is the one I don't really get.
First of all, with the texture coordinates thing, should I keep separate static VBO's for each cube with a specific texture? Also with the flyweight pattern, wouldn't I still be generating the same amount of vertices?

Offline BurntPizza
« Reply #18 - Posted 2014-08-28 20:10:39 »

You're not separating your object representation from how it is rendered.

A Cube, logically, is
Position, Sprite

Even size isn't needed if every Cube is the same size. (static field)

The VBO stores everything else, as it is render specific. All of it's information is derived from that fundamental definition of a Cube. Storing render information in the Cube is redundant.

I'm not the most fluent in conveying ogl-specific stuff, maybe someone else has a better explanation.
Online tinfoilboy
« Reply #19 - Posted 2014-08-28 20:14:03 »

You're not separating your object representation from how it is rendered.

A Cube, logically, is
Position, Sprite

Even size isn't needed if every Cube is the same size. (static field)

The VBO stores everything else, as it is render specific. All of it's information is derived from that fundamental definition of a Cube. Storing render information in the Cube is redundant.

I'm not the most fluent in conveying ogl-specific stuff, maybe someone else has a better explanation.

Wait, for the texture coordinate thing, are you saying to reuse the same texture coordinate batch, so that if there is a sprite that is the same as another, use those texture coordinates instead of generating new ones?

Offline BurntPizza
« Reply #20 - Posted 2014-08-28 20:15:03 »

That is flyweight, yes.
Online tinfoilboy
« Reply #21 - Posted 2014-08-28 20:15:32 »

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.

Offline BurntPizza
« Reply #22 - Posted 2014-08-28 20:49:02 »

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.
Online tinfoilboy
« Reply #23 - Posted 2014-08-28 20:51:05 »

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.

Offline BurntPizza
« Reply #24 - Posted 2014-08-28 20:55:22 »

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.
Online tinfoilboy
« Reply #25 - Posted 2014-08-28 21:03:06 »

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


Offline BurntPizza
« Reply #26 - Posted 2014-08-28 21:05:07 »

Looks better, although you cropped a lot of good information.
Online tinfoilboy
« Reply #27 - Posted 2014-08-28 21:10:07 »

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.


Offline BurntPizza
« Reply #28 - Posted 2014-08-28 21:12:41 »

I feel like I'm continuously derailing your thread, but I meant the overall info and such.

BTW, if images are too large: [img width=800][/img]
Online tinfoilboy
« Reply #29 - Posted 2014-08-28 21:13:48 »

I feel like I'm continuously derailing your thread, but I meant the overall info and such.

BTW, if images are too large: [img width=800][/img]

Ah okay, thanks! And no you aren't, it's helping me out a bit.

Pages: [1] 2
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (67 views)
2014-10-14 00:35:47

TehJavaDev (60 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (86 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!