Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.97a is out! (02/02/24); New blog post: Simulator Enhancements (03/13/24)

Pages: 1 [2]

Author Topic: A Small Change to the Installer that Could Help Your Game.  (Read 4436 times)

Dark.Revenant

  • Admiral
  • *****
  • Posts: 2806
    • View Profile
    • Sc2Mafia
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #15 on: July 05, 2019, 03:37:48 PM »

On the subject of VRAM...

This game shouldn't be using much VRAM for textures, unless people are behaving insanely in mods.  Seriously, the graphics folder is 68MB; even if we presume that every single image is using 3X that much VRAM when it's decompressed... there should be lots and lots of room.  I'm having a lot of trouble understanding why VRAM might be a real issue here.

If somehow textures are actually the issue (which doesn't make any sense unless, again, people are doing insane things) then fine, the game's specs need to be higher or the graphics need to be in DDS to use texture compression properly on modern GPUs.

I think that VRAM usage, if it's a real problem for 1GB cards, must have roots somewhere else (storage of geometry, etc.) that mods can't control very easily.  I'd think that most end-users on a potato like that are hitting walls with general RAM use and CPUs that can't take the hit well before that is a real problem, however.

You're making a number of incorrect assumptions about game textures.

Firstly, let's use the onslaught as an example.  It's 196 KB in the manner that it's packaged on the file system, in .png format, which is a lossless compressed image format.  Based on the source image dimensions of 288 x 384, with mipmapping enabled, and 24-bit color depth and an 8-bit alpha channel, we're talking 512x512 pixels with 4 bytes per pixel and an overall 4/3 increase in size due to the mipmapping.  Overall, the texture will take up at least 1365 KB on a graphics device -- uncompressed.  This isn't even close to the disk-stored file size.  A far cry from your estimate of 3X, even.  We're talking 7X.  This gets even worse if the PNG images are compressed with a better algorithm.  I was able to get the onslaught sprite down to 150 KB.

Lossless compression is extremely computationally expensive, so it's not an option for real-time graphics.  Alex could implement lossy compression (for maybe perhaps a 4X VRAM reduction), but the really advanced types that might produce an acceptable visual result are not available to old GPUs or some integrated graphics devices, and those are the devices that are having trouble in the first place.  Remember, the universally-supported DXT3/5 S3 texture compression methodology will have significant visual artifacts when we're talking about the detailed, 1:1 2D textures that Starsector uses.

Here are my figures for VRAM usage:

    Starsector 0.9.1a: 413.5 MiB (approximately)
    GraphicsLib 1.2.1:  267.4 MiB (not including ~97.5 MiB for various shader buffers, depending on settings & resolution)
        small ripple:   207.4 MiB
        no distortions: 182.1 MiB
        no shader maps:  85.4 MiB
        fully disabled:   0.1 MiB
    Tyrador Safeguard Coalition 1.6.1c: 259.0 MiB
        no shader maps:                 186.9 MiB
    Ship and Weapon Pack 1.10.2: 200.4 MiB
        no shader maps:           56.5 MiB
    Shadowyards 0.8.7 RC2: 161.2 MiB
        no shader maps:    106.7 MiB
    Interstellar Imperium 2.0.0: 158.8 MiB (not including Unknown Skies shared textures)
        no shader maps:           61.3 MiB
    Blackrock Drive Yards 0.9.5: 119.5 MiB
        no shader maps:           62.4 MiB
    Unknown Skies 0.42: 117.5 MiB
    Dassault-Mikoyan Engineering 1.0: 115.3 MiB
        no shader maps:                52.2 MiB
    Junk Pirates / PACK / ASP 3.10: 102.0 MiB
        no shader maps:              56.2 MiB
    Scy Nation 1.55:    82.1 MiB (not including Unknown Skies shared textures)
        no shader maps: 55.8 MiB
    Underworld 1.3.2:   44.4 MiB
        no shader maps: 13.3 MiB
    Outer Rim Alliance 0.85: 32.1 MiB (not including Unknown Skies shared textures)
        no shader maps:      21.7 MiB
    Diable Avionics 2.04: 24.4 MiB
        no shader maps:   22.4 MiB
    Upgraded Rotary Weapons 1.41: 7.5 MiB
        no shader maps:           4.5 MiB
« Last Edit: July 05, 2019, 03:45:09 PM by Dark.Revenant »
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #16 on: July 06, 2019, 04:28:01 AM »

OK, thanks for the refresher on just how bad lossless formats like PNG transported straight into OpenGL are, memory-wise.  Not to mention the load-time spent uncompressing them.

That said... I agree that going to DDS is kind of a dire option, if for no other reason than I'd have to teach yet-another community some basic tricks with DDS.  I actually like DDS; it's fine if you know what you're doing.  But... yeah, I can see the massive moaning and groaning we'd get here.

Probably a  better one would be to atlas stuff at runtime so that it's not wasting VRAM on sprite padding.  Just based on the example Onslaughts... we can get nearly 11 of them in the same space 8 are using now, if they were on a 4096 atlas; that'd help quite a lot, I'd think.  Especially for all of the narrow boxes.  Perhaps Alex ought to implement this?

Anyhow, I concede that this is an actual problem; based on what you've shared here, the game's real footprint is roughly 7X vs. compressed-PNG and some mods are using rather egregious amounts of VRAM all by themselves.  How, that's still kind of a mystery; are people doing giant frame animations or something?  That just seems weird.

I wasn't aware this was a real problem; I don't really remember anybody crashing their potato trying out Vacuum, which had a lot more ships, guns, etc. in it than most of the released faction mods combined did at the time.  But yeah, I can see how if you add in some crazy things and then try making normalmaps to work with GraphicsLib, it goes downhill fast.

Presuming that atlases cut that down by 20%, that'd help, but not by a lot. 

So, perhaps the best answer's to load up the textures into RAM, pass to GPU only when it's really necessary; it shouldn't be terrifically hard to build  a loader / unloader when entering a battle / refit scene, I'd think, that would just load up what's actually going to get used.  I think that the main thing we'd be giving up there would be some tiny lag while the textures pass from RAM-->VRAM.

So... the game would load up, for example the graphics for the ships, but only the ships listed in the CampaignFleetAPI, weapons, etc.; if modders wanted something loaded (say, a SpriteAPI) then they'd have to call for it to get loaded and return a pointer in init or something. 

Dunno, this is probably more work than Alex wants to do on this part of the game at this point, just to support mods, really; probably just not worth it in terms of payoff.
« Last Edit: July 06, 2019, 04:32:27 AM by xenoargh »
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Midnight Kitsune

  • Admiral
  • *****
  • Posts: 2846
  • Your Friendly Forum Friend
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #17 on: July 06, 2019, 07:12:55 AM »

Basically vanilla SS can run on just about anything. IIRC Lazy Wizard got it to run on a Pi. (Although it was at like 2 FPS and there was major hackory involved.) It is only once you get into ship mods when you start running into issues.
Also, I played Vacuum back in the day of .54.1 and I remember it was a TC. IE you couldn't add any other mods to it that weren't utility mods. Also that was back before Shader/ Graphics Lib was even a thing.
Logged
Help out MesoTroniK, a modder in need

2021 is 2020 won
2022 is 2020 too

Hrothgar

  • Captain
  • ****
  • Posts: 327
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #18 on: July 06, 2019, 07:28:23 AM »

We need Stonehenge version of Starsector.
Logged

Midnight Kitsune

  • Admiral
  • *****
  • Posts: 2846
  • Your Friendly Forum Friend
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #19 on: July 06, 2019, 08:50:26 AM »

We need Stonehenge version of Starsector.
Hmmm?
Logged
Help out MesoTroniK, a modder in need

2021 is 2020 won
2022 is 2020 too

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #20 on: July 06, 2019, 11:20:40 AM »

Yeah, I definitely don't see it being made to run on Pis well, lol. 

Anyhow, sorry for the distraction re: VRAM; I've never really considered this game limited by anything on the GPU, period, and just never pay any attention to this stuff; I haven't worked with an engine that statically loads all of its bitmaps at runtime in like, ever, either.  There are a few things I've seen in terms of optimization (in particular, order-of-operations stuff with glBindTexture() on ATi) but I hadn't considered newbies trying to run 15 mods at once on a potato and crashing. 

Short of major under-the-hood work, the game might want to do a test of what's being loaded from /graphics, do a rough multiplication (let's say a rule of 8X, for safety's sake) and if it's pushing the limits (say, 65% of VRAM, because the OS / browsers etc. might be using it too) it'd give a polite warning to the end-user, rather than just crashing out because of allocation issues.

The game could also print the graphics load (memory-wise) to the console logs, so that modders could immediately find out the impact of their latest crazy idea.  I don't think most modders will care, though, honestly; they're hard-pressed enough just finding time to make Cool Stuff.
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Dark.Revenant

  • Admiral
  • *****
  • Posts: 2806
    • View Profile
    • Sc2Mafia
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #21 on: July 06, 2019, 12:07:54 PM »

Atlasing would be a lot of work on Alex due to the fact that the texture mapping coefficients all throughout the code would need to be redone.  A 20% decrease ~42% decrease (I calculated - for an even distribution of sprite sizes - not including padding pixels) is probably not worth it for the level of effort involved.  But it's something he could do with basically no performance cost or impact to visual fidelity.

A texture loader is probably less risky because, in the worst case, it still logically behaves like the old interface of grabbing a SpriteAPI where needed - it just performs like *** if you do it wrong.  So in the end, the game probably wouldn't glitch out, it would just run suboptimally if Alex messed up.  Unless he's doing something crazy with retained texture IDs or something.  Long-term, I've always thought Alex should implement something like this, but ultimately it's up to him.

Short of major under-the-hood work, the game might want to do a test of what's being loaded from /graphics, do a rough multiplication (let's say a rule of 8X, for safety's sake) and if it's pushing the limits (say, 65% of VRAM, because the OS / browsers etc. might be using it too) it'd give a polite warning to the end-user, rather than just crashing out because of allocation issues.

This is a good idea, but the game doesn't need to estimate based on file size; it can make a much more accurate estimate by multiplying width by height and then multiplying by 16/3 bytes.
« Last Edit: July 06, 2019, 12:24:54 PM by Dark.Revenant »
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #22 on: July 06, 2019, 01:29:49 PM »

LIBGDX has explicit support for various texture-loading concepts that look pretty straightforward. 

In fact, it could probably be written to interpret a call to a SpriteAPI as a call to Pixmap, maybe? 

That looks on paper like it largely deals with the use case, although probably there'd (realistically) have to be a lazy-loader transferring from there to a list of currently-loaded, ready-to-bind textures when called for, which is, I presume, basically what there is now, except they're already loaded right now and just need glBindTexture() to happen.

This seems like it might be the least-disruptive way to do this; then SpriteAPI is largely left intact, just the internals change.
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23987
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #23 on: July 07, 2019, 08:15:53 AM »

Atlasing would be a lot of work on Alex due to the fact that the texture mapping coefficients all throughout the code would need to be redone.  A 20% decrease ~42% decrease (I calculated - for an even distribution of sprite sizes - not including padding pixels) is probably not worth it for the level of effort involved.  But it's something he could do with basically no performance cost or impact to visual fidelity.

Yeah, the "amount-of-work to payoff" ratio on this isn't the best.

Another point about that approach, actually! Binding a larger texture takes longer than binding a small one (or, at least, it definitely can; I don't know if this is the case with all graphics cards/drivers, though it'd make sense if it was). So if you've got a couple of atlases but are swapping between them very frequently, that's a performance issue. And trying to minimize the amount of swapping would basically be ... well, probably impossible, for many reasons.


A texture loader is probably less risky because, in the worst case, it still logically behaves like the old interface of grabbing a SpriteAPI where needed - it just performs like *** if you do it wrong.  So in the end, the game probably wouldn't glitch out, it would just run suboptimally if Alex messed up.  Unless he's doing something crazy with retained texture IDs or something.  Long-term, I've always thought Alex should implement something like this, but ultimately it's up to him.

Hmm. This reminds me of doing something similar when I was trying rendering to FBOs for some effects. I don't know if it was a driver issue or a bug in my code (though I'd gone over the latter many times), but it seemed like glDeleteTextures() - while freeing up the texture id - wasn't releasing the actual memory, at least not in any timely fashion. After a bit, that game would start stuttering badly and eventually crash; I don't remember if it crashed the OS as well, it might have. I spent a *while* trying to debug that and eventually settled on allocating a few textures and reusing them, i.e. doing the memory management on my end instead of on the video card.

Maybe this isn't an issue anymore, I don't know. I guess this is just a general "there could be unexpected problems" point... the experience certainly didn't leave me keen on doing anything relying on freeing up texture memory, that's for sure.
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #24 on: July 07, 2019, 05:02:03 PM »

Quote
So if you've got a couple of atlases but are swapping between them very frequently, that's a performance issue. And trying to minimize the amount of swapping would basically be ... well, probably impossible, for many reasons.
You're totally right, on the first point.

On the second point... call me over-optimistic, but there should be a way to skin that cat: 
Spoiler
I think that you're maybe a little over-pessimistic.  First off, the CPU cost of glBindTexture() is fairly high, regardless of the GPU and the size of the texture.

Let's look at the rendering process for the game (insofar as I understand it:

1.  Background
2.  Back-most elements (PlanetAPIs etc.)
3.  First round of JitterUnder elements for ShipAPIs
4.  First round of ShipAPIs
5.  First round of damage decals
6.  First round of WeaponAPIs
7.  First round of JitterOver for ShipAPIs
8.  First round of Jitter for WeaponAPIs (I presume Glows are also drawn during that pass)

...keep going...

So, yeah, there are a lot of rendering processes.  But a lot of them would involve just one atlas; a 4096 texture could easily hold every weapon, barrel and projectile graphic for every weapon in the game (and frankly, also hold most of the particles, damage masks, etc.).

For most things in this game, especially all of the stuff that gets drawn to the screen in many places per frame- everything from weapon sprites to projectiles and particle effects... it's almost certainly a huge win to use atlases. 

Five machine-guns on a ship, for example, is at least five glBindTexture() calls, if it's brute-forced every time (which of course, I don't know how that's being done; I presume it's a little slicker than that).  Each time that gets called, there's a delay as the GL state is changed.  So just avoiding that by doing one binding per frame for every one of these things, or at most two, is a big optimization.

Where is an atlas approach maybe a bad idea?

The unfortunate answer is that ships themselves might be the no-go.  Hard to say without actually trying it out, though.

There's no point in binding a 4096 to render one ship on the screen, when one 128X128 would suffice. 

It's almost impossible to predict how many ships would require how many atlases, either. 

However, how many 4096's do you need, to fit all of the ships in the game into one glBindTexture operation?  At a guess, maybe 2 for all of the current ships in the game, at most.  Especially if the ships are atlased using their collision borders with a padding around that, although then we're getting into some fairly advanced atlas-construction techniques.

If the ships are sorted by the texture they need before passing to rendering, then it should be fine.

Anyhow... ultimately, atlases are one of the answers; if implemented as described above, the biggest issue would be that SpriteAPI calls from mod-side code would harken back to the atlases; there's where things would get a little ugly, since we'd need the UVs, etc., if we're doing anything like what I'm doing (getting texture ids, binding them, etc.) but that's not the end of the Earth (I figure anybody doing something crazy like that probably knows a thing or three).
[close]

As a final note:  you could have some quick fun, comparing the above (let's call it, "20 glBindTexture calls per render frame", which is probably reasonable) with your current calls (start a counter, increment it every time you call glBindTexture, get the average during a busy bit of gameplay).  I'm guessing you come out waaaaaay ahead. 

Then, for funsies, just write some code that binds a 4096 and writes part of it to, IDK, 1500 quads / frame. 

I can tell you, from over here, that my preliminary tests kind of indicate that I should build an atlas for my particle system, if I want it completely optimized; instead, because I'm still vaguely hopeful that others might want to try using it (and will not want to have to tinker with some Master Atlas built by hand, for obvious reasons), I'm settling on mini-atlases of 3 "choices" to again, reduce the number of calls to glBindTexture per frame.
« Last Edit: July 07, 2019, 05:30:34 PM by xenoargh »
Logged
Please check out my SS projects :)
Xeno's Mod Pack

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 23987
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #25 on: July 07, 2019, 06:31:11 PM »

On the second point... call me over-optimistic,

You're over-optimistic :)

First off, the CPU cost of glBindTexture() is fairly high, regardless of the GPU and the size of the texture.

Where are you getting that? As far as I know, that's not true, the CPU cost is absolutely minimal since it doesn't need to wait for a round-trip from the graphics card and it doesn't have much data to send. What's really expensive is if you need to query the state for any reason, which requires waiting for the graphics card to send back data before the method returns.
Logged

xenoargh

  • Admiral
  • *****
  • Posts: 5078
  • naively breaking things!
    • View Profile
Re: A Small Change to the Installer that Could Help Your Game.
« Reply #26 on: July 08, 2019, 02:11:49 AM »

That was the results on the hot-spots on ATi two years ago, roughly.  Unless miracles have occurred in Driver Land, I'd expect roughly the same thing on common Intel chipsets (at least, that was the result the few times I profiled my stuff on a cruddy laptop).

Let's not get sidetracked with that, anyhow.  This has been enough of a derail, lol.

Anyhow, honestly, after looking at the options, I thought load-when-needed solution looked the least awful.  Best balance between sheer speed, flexibility, not having to reinvent wheels, etc.  It'd cost end-users more RAM, though, so we're right back to the OP's feature request.
Logged
Please check out my SS projects :)
Xeno's Mod Pack
Pages: 1 [2]