Oppugno (Alpha 261a released!)

WIP games, tools & toy projects
#1

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.

#2

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
#3

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.

#4

Runs shockingly bad.

10FPS

[i]Uses 2.5GB of RAM

Disk usage hits 100%[/i]

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

#5

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

#6

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.

#7

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.

#8

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.

#9

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.

#10

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.

#11

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?

#12

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.

#13

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

#14

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

#15

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

#16

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.

#17

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.

#18

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?

#19

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

A Cube, logically, is [icode]Position, Sprite[/icode]
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.

#20

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?