OpenXcom Forum
OpenXcom => Suggestions => Topic started by: moriarty on September 04, 2012, 07:13:55 pm
-
with the game growing and growing, writing a savegame takes more and more time... we have reached a point where the game actually takes an amount of time for writing a savegame to disk that users might start to get worried if the game is actually doing something or just crashed.
considering that this will get worse, maybe it's time to find some kind of "busy" signal that tells the user that the game is actually doing something.
1) does anybody agree?
2) if so, does anybody have an idea what it should look like? (small window with progress bar? animated "busy" cursor? small window with some kind of animation? whatever it is, it should be very "xcomish". something iconic that everybody instantly recognises from the game.)
-
The black screen or window with centrally animated person... sectoid? :D
Animation for looooong loading... :P
https://img.1gif.pl/wedkarstwo/wedkarstwo-44.gif
-
Project just need to get rid of sluggish yaml-cpp library.
Or probably something like this. https://code.google.com/p/yaml-cpp/issues/detail?id=7
Getting busy indicators used because of non optimal code is very bad idea.
-
Face it, Volutar, there's always going to be idle times, no matter how good the code is. Between geoscape and battlescape, when loading or saving a game...
if we find some really good way of handling and bridging these idle times, we will make the game a little bit better again.
A spinning geoscape globe would be very recognizable, although I don't know how it will look in 320x200 resolution.
-
kind of like this, maybe?:
-
Face it, Volutar, there's always going to be idle times, no matter how good the code is. Between geoscape and battlescape, when loading or saving a game...
Why should I face it? There's no even a second of idling time in original game, so why would openxcom have idle time?
The only moment when you have to wait - is a "hidden movements screen". Anything else is a lame.
-
It has been a while since I loaded a game in a release build, but the slow saving/loading is only in the battlescape right, or is it the geoscape too?
Because in the battlescape currently every tile of the map is saved as a seperate YAML object, which is a lot of overhead, where as one base64 encoded blob would be more efficient. It's somewhere on my todolist.
-
Daiky, base64-encoded binary in yaml text config is a kind of perversion. Why don't you want to write binary files? They are not for edit anyways.
I'd better be using yaml only for config files. By going weird way as now we may put sprites into yaml - pixel-by-pixel info. Actually if that happen I'll ask to delete my name from the credits.
-
Actually if that happen I'll ask to delete my name from the credits.
"WEBSITE UPDATE : NAME HAS BEEN SUCCESSFULLY REMOVED FROM THE CREDITS ... HAVE A NICE DAY"
Only kidding , i have no idea what the hell you guys are discussing "Base64 Encoding" :P
-
Daiky, base64-encoded binary in yaml text config is a kind of perversion. Why don't you want to write binary files? They are not for edit anyways.
One thing to consider with either approach is that if you want to transfer saves between machines of different endians.
-
Is always possible to "fix" endians in cost of slower loading.
-
What about endians? if you will read binary file byte-by-byte there will be no such thing as "endian"
-
What about endians? if you will read binary file byte-by-byte there will be no such thing as "endian"
No, that is exactly when endianness matters. If you would read bit by bit then it would not matter.
But if you read bytes it is the difference between 1 and 256(or -128 depending on byte format).
Anyway, I dont think a binary format is a good idea.
-
LCSand, you're mistaken.
Big/Small endian is BYTE order, not a BIT order.
https://en.wikipedia.org/wiki/Endianness
And binary files are okay. Every developer trying to compress data for project: a) not to occupy too much of place, b) to maintain high load speed (smaller files loaded faster).
-
If you have any values that are larger than a single byte, it will matter, because you'll need to reverse the order after you read it, whether read byte-by-byte or by reading a 16bit word.
I never meant that it was a "problem", just something to be considered if implementing any sort of binary reading
-
Ugh let's not get into the file format arguments again. I couldn't care less if OpenXcom saved in text, binary or maple syrup. I've seen games that load/save from text files with dozens of MBs in a matter of seconds, and I've seen games taking half an hour loading binary. I've seen formats made out of just memcpy'ing the whole game or out of ZIP files containing mixes of XML and binary files. It's all about meeting its needs.
My stance is this: Binary is all well and good when you have a solid structure and a fixed set of requirements, which is not the case with pre-v1.0 OpenXcom. The code is ever-changing and ever-developing, and binary would just make it a nightmare to maintain, while YAML lets us throw in and remove stuff with little care. After 1.0 we can look into all the optimization and perfomance needs and come up with the best possible format ever if necessary. If you wanna do that for us be our guest. As for endianness, SDL has you covered (https://www.libsdl.org/intro.en/usingendian.html).
For now I think it's OK to at least have "loading..." and "saving..." indicators as most games do.