legit

Anarkis Gaming Forums

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: What happens when the game is loading after start (i.e. slow start for me)?  (Read 1890 times)

joeyeti

  • Lieutenant
  • **
  • Karma: 0
  • Posts: 28
    • View Profile

I mean, I presume I do have quite a slow machine (a notebook with an Intel i5 processor and onboard graphics), but what exactly is the game engine doing when I start the EXE file?

Is it decompressing stuff to run, or loading things into memory? Not that I know what I speak about (much), so just wanted to know if the "slowness" for me (a minute of loading or so usually) just means a slow machine on my end, or if it can still be optimized somehow?
Logged

EsKa

  • Administrator
  • Vice Admiral
  • *****
  • Karma: 112
  • Posts: 262
    • View Profile
    • Anarkis Gaming

The initial loading time is slow for multiple reasons, some good, some not so much. I hope you wanted the long technical, but hopefully readable, answer, because you're going to get it  ;D
(also I may point other people to this topic if the question arise again so I am going to be thorough)

There was one thing I wanted to avoid at all cost: in game loading times. I hate those. I don't remember if you're a X2/3 player or not (i think you are), but for me the loading in between sectors was extremely annoying, especially in X3 and + where they removed the warp animation and put a static loading screen instead (heresy). To avoid that, everything is loaded in memory first. A few hints and menu related text aside, the game never read or write from the disk once it's launched.

So anyway,

First the game loads its data. As with any simulation (in the true sense of the genre) there's a lot of data. All the ships, docks, weapons, shields, wares, factions .... Lots of data. It's single threaded (one core) because we are reading from the disk and disks don't like getting 2 orders at the same time. So your CPU won't change a thing here, but a fast hard drive will.

Secondly it generates from thin air -well, from a math formula- the sky, nebulae and clouds. This one doesn't use the hard drive and it's multi-threaded, the more cores the faster it goes. If you run a cpu monitor, you'll see a spike at 100% cpu usage from my game at that point. Reducing the new "Background Texture" setting in the options helps but that will save you a few seconds at best (that will save a decent amount of RAM. Also battery each time you move between sectors).

Then, there's the infamous "building sprites" phase which takes ages. As you have probably noticed, UG is freaking small (140Mb) compared to what it does. There's a good reason for that. Instead of saving all possible rotations for each ship and bullet in a file, I only have the sprites facing up. I rotate each sprite for all possible angles and save all of that in memory. That's basically 120 sprites x 180 angles (rotate by 2 degrees) images to build. It already takes a while but that's not all it does. Remember the colored icons on the sector map ? they rotate too ! And they are colored as well ! In their case it's "faction count" x "amount of icons" x "amount of rotations".

"Why not do the rotations in real time ?" you may ask. Well, if it was a basic shooter with a few dozen people on screen at best and with mostly circular bullets that would work. But we have 100 vs 100 battles all the time with thousands of bullets being fired. Even with a copious amount of optimization, rotation is still a fairly slow process (also the graphical library I am using isn't exactly the fastest thing on earth) and it would make the game a slideshow in even medium sized fleet battles.

The problem with this phase is that it only uses one core when it could use all of them. That would double its speed on your computer or x4 on a quad core. There are very technical reasons as why it doesn't do that currently and i won't go into it. Hopefully, soon enough I will overcome this hurdle using my own code to rotate stuff instead on relying on what i am provided with.

The last (noticeable) part is the "sound loading". Basically loading all sound effects and putting them in a way the PC can play quickly. No idea how long it takes for you, but it's 3-4 seconds for me. And there I can't do anything about it, it's the sound library (based on OpenAL) which does its thing. And I assume it does it well enough given it's widely used.

Long story short, some parts can be optimized (building sprites) and others already are (everything else).

Also, I wanted to put the option in 1.05 but i hadn't the time to do so. But I can add another graphical option to reduce how smooth ship/bullet rotations are. It would reduce loading times and memory consumption by a lot. Obviously, rotations would look like they are missing a few frames (because they would be :p)
Logged
Anarkis Gaming

joeyeti

  • Lieutenant
  • **
  • Karma: 0
  • Posts: 28
    • View Profile

Thx for the explanation EsKa! That is what I wanted exactly :) And I understand what you are talking about as well... (pat on my shoulder).

If you can squeeze any further optimization out of the engine (or, as you said, replace some code structures with your own), it will definitely help us "slow notebook users" :) Even that "choppy rotation" option, I would not mind it much anyway - the more options, the better, I can always switch to full shiny'!

Or go buy an SSD :)
Logged

Paul

  • Pilot
  • *
  • Karma: 2
  • Posts: 17
    • View Profile

Kind of uninformed suggestion (never worked with this sort of code before) but couldn't you have a fast load option where it generates the rotated sprites in a temp directory inside the game folder and re-uses it on subsequent loads? It could be set in the launcher.

It could just look for a temp directory inside the folder when it goes to the building sprites part, and if the files are present just use those. If not, build sprites and dump the results in that folder as it puts them into memory. It would increase the program's footprint a bit, but for most folks a few hundred mb is a drop in the bucket on their hard drives.
Logged

EsKa

  • Administrator
  • Vice Admiral
  • *****
  • Karma: 112
  • Posts: 262
    • View Profile
    • Anarkis Gaming

It's not a bad suggestion and I already thought about it for a while.

Practically, in total that would be roughly 30k+ PNG files to load. Very small files, sure, but 30k nonetheless. Loading this amount of files on a non SSD drive that's likely to be fragmented for ~95% of the user-base would take longer than just doing the rotation during the load time.

A possible solution would be to merge all those auto-generated files into one 'archive' to save the costly open/close file operations and search loop. Load the big file in memory then extract the png from it. That would be RAM hungry for a while, but it would definitively work. It even has a name, "virtual file system". It's what does Civilization, X3, or any Bethesda rpg game ever made. But comparatively to making my own multithread compatible "rotate" function, it would take way more coding time. Especially with the mod thingy: It needs to take into account what mods are loaded or not and act accordingly (generate new files or don't load parts of the archive).

The advantage with what I want to do is that I know the benefits already. 2x loading time on dual core, 4x on quad core and so on. The archive file option, not so much, and it would vary widely based on the hard drive's type (old/standard/ssd) and maintenance (fragmentation).

Also, don't get me wrong it's possible to cut the initial loading time, and even the game save/load operations (to a lesser extend) by quite a bit even after this optimization. Heck, we still get single threaded AAA games nowadays (which, in itself, is so puzzling to me) that are loading more data than me and they do it faster. Problem is, they have the manpower to dedicate one or two coders to this task and this task alone while i don't have this luxury.



Logged
Anarkis Gaming

Paul

  • Pilot
  • *
  • Karma: 2
  • Posts: 17
    • View Profile

Couldn't it generate sprite rotation images in a single composite per image? That way it's still the same number of files as loading them from the base files, and it would solve the mod issue - just have a folder for core files and a folder for each mod, loading them in based on which mods are active.

But I can definitely see the benefit of doing it on the fly, doing 2 degree rotations would add a lot to the game's footprint. I think most games only do like 9 degree.
« Last Edit: July 17, 2015, 10:02:26 PM by Paul »
Logged

EsKa

  • Administrator
  • Vice Admiral
  • *****
  • Karma: 112
  • Posts: 262
    • View Profile
    • Anarkis Gaming

Yes, that's very similar to what i explained replacing the big archive/zip by a image. It would be faster in execution time. That said a 64x32 sprite once it's rotated to let's say 45° isn't 64x32 anymore, so i would either need to store a table with the top-left and bottom-right points for each rotated sprite in the image or to find a way to do it automatically. It's not difficult, but I am still favoring the 'on the fly' option.

Quote
doing 2 degree rotations would add a lot to the game's footprint. I think most games only do like 9 degree.

Yeah it does. The debug build runs with 18 degree increments so i don't get mad each time I need to test something :p. In any case, I will add a setting to choose how "smooth" rotations are in the gfx options next version. Depending on how fast the other things I want to add for 1.1 are progressing, I may give a shot at writing the new rotate function too.

Logged
Anarkis Gaming
 

Bad Behavior has blocked 231 access attempts in the last 7 days.