OpenXcom Forum
Modding => Released Mods => XPiratez => Topic started by: Ninawindia on June 03, 2018, 10:09:21 am
-
I tried to install it on my tablet that has an actual keyboard, but every time I try to run it, it crashes.. It can run the normal xcom on OXCE+ but not pirates...
-
2 GB RAM minimum, 3 GB recommended.
-
^^ >o :o
so much? ?
i thought tha XPiratez (as whole UFO-XCOM at all) is mainly, basically, (almost) DOS -game, designed to run under ms-dos
(.. /and those very early Windows.. (3.11 - Win 95++, amybe...)
-
Back then the game was about 11mb and did a lot less.
-
You can run vanilla with less than 100 MB... just PirateZ needs that much.
-
OXC was never designed to run under DOS, it's a modern engine written in C.
-
Funny that modern engine is more memory intensive than the DOS one.
-
Back then you had to look out for every kb, there is just no reason to go that extra mile anymore i guess.
-
Funny that modern engine is more memory intensive than the DOS one.
Not all that funny - since we know more RAM is available, we can do things that speed up the running of the game at the cost of more memory use. Reading from/writing to disk can take a while compared to accessing something in RAM.
-
The real fun is when you eat shitloads of RAM while doing things much slower. :--DDD
-
Wirth's Law.
-
OXC was never designed to run under DOS, it's a modern engine written in C.
Blasphemy!! C++
And for more serious answers, folder of pirates contains 200MiB of compressed pictures, when you decompress them you get around 10 times more data == 2GiB.
Another thing is that engine is fully modable than increase requirements (hardcoding everything could made game smaller and faster).
Theoretically game could use less resources and loading things only on demand but you will need wait another 2 years for basic gameplay because game would be not finished yet.
-
I tried to install it on my tablet that has an actual keyboard, but every time I try to run it, it crashes.. It can run the normal xcom on OXCE+ but not pirates...
I run X-Piratez on my mobile device (a Galaxy S6 Edge+) with little to no problems whatsoever, what device are you using, by chance?
-
the game starts chugging on the bigger maps on my full desktop. Its a potatoe, but damn does it chug.
-
the game starts chugging on the bigger maps on my full desktop. Its a potatoe, but damn does it chug.
The engine is not built for such big (especially tall) maps and for such long visibility distances.
Modders are aware of it, but willingly decided to use it in spite of suboptimal user experience.
1/ vanilla maps have height = 4, piratez maps can go up to height = 30... which is roughly linearly (8-times) slower
2/ vanilla maps have visibility limit = 20, piratez has limit = 40... which is much worse than linearly slower... I don't have exact numbers, but it can bring any CPU to its knees
3/ also tons of new features in OXCE+ (e.g. indicators, night vision, LOS checks, etc.) are slowing down rendering quite significantly... again I don't have exact numbers, but I would say it's about 50-100% slower in worst cases
All in all a tall map in piratez can easily render and animate 50x slower than a normal vanilla map.
PS: also, if you have FPS counter enabled, don't believe what you see... even if the game barely manages 5 fps, it will still show a lot more
-
The engine is not built for such big (especially tall) maps and for such long visibility distances.
Modders are aware of it, but willingly decided to use it in spite of suboptimal user experience.
1/ vanilla maps have height = 4, piratez maps can go up to height = 30... which is roughly linearly (8-times) slower
2/ vanilla maps have visibility limit = 20, piratez has limit = 40... which is much worse than linearly slower... I don't have exact numbers, but it can bring any CPU to its knees
3/ also tons of new features in OXCE+ (e.g. indicators, night vision, LOS checks, etc.) are slowing down rendering quite significantly... again I don't have exact numbers, but I would say it's about 50-100% slower in worst cases
All in all a tall map in piratez can easily render and animate 50x slower than a normal vanilla map.
PS: also, if you have FPS counter enabled, don't believe what you see... even if the game barely manages 5 fps, it will still show a lot more
No No, I mean, quite literally my computer chugs. My new laptop thats two cenimeters high when closed runs the game better than my PC.
-
And what do you want to say by that? I understand even less now...
-
Running mostly ok using almost all 2GB of ram on my low-power Atom laptop with a 1024x600 screen. Must close my browser and any other memory intensive applications before starting xcom.
Linux gentoo 4.11.3 #10 SMP PREEMPT Mon Jun 5 00:24:27 EEST 2017 x86_64 Intel(R) Atom(TM) CPU N450 @ 1.66GHz GenuineIntel GNU/Linux
During base defence and some large maps I need to change video to show only 1/2 or 1/3 in order for moving soldiers not to be too slow.
Compiling oxce+ took about 2hours, and starting the game takes a few minutes 2min 15 sec of loading on the black "MS/DOS" screen before presented with the first main menu.
-
This question not matter: even about ten years old configuration tolerate @mod@. Such ancient garbage still enough to run. Slower PCs already on the dump long years ago or scattered to dust in pantry.
4gb old slowest ddr2 ram/dual 1.8ghz cpu - about 30 fps
Other question is - how this trash make his own olympic-grade jump MUCH HIGHER than a pretty memely FOnline, that eat ram and cpu x20 times. Full cpu usage, memory consumption on a win-process-limit - even Crysis cannot do this. Very bad optimized projects, old and modern(unity-based "games", visual novels and its ports, flash browser online games, self-made mmorpg's and roguelikes) still can't show such apocalyptic result(200mb of old, even worse than VGA-quality graphics, early 90's level, even not a 1/3 of CD-disk capacity...). I think, this is a trolling, 90% memory rewrites with random numbers, and infinite recursion cycles loading 90% CPU.
-
Do you actually want to hear the answer or are you just trolling?
-
My only gripe (as a coder) is how "bandit cave" and base defence missions are much slower than usual maps only due to the spawn point/most of the combat being up on the 3rd/4th level. I guess the engine draws the lower layers regardless of 99% of them being completely covered by completely opaque tiles on the layers above.
But I guess there is no information about a tile, or even its floor, being completely opaque, and thus the graphics drawing engine can't skip drawing tiles that are fully hidden by a upper level.
-
My only gripe (as a coder) is how "bandit cave" and base defence missions are much slower than usual maps only due to the spawn point/most of the combat being up on the 3rd/4th level. I guess the engine draws the lower layers regardless of 99% of them being completely covered by completely opaque tiles on the layers above.
But I guess there is no information about a tile, or even its floor, being completely opaque, and thus the graphics drawing engine can't skip drawing tiles that are fully hidden by a upper level.
That's basically it. I once tried to speed this up, but.. it started approaching a complete renderer rewrite, which would have zero chances to be merged. And, therefore, pointless.
-
That's basically it. I once tried to speed this up, but.. it started approaching a complete renderer rewrite, which would have zero chances to be merged. And, therefore, pointless.
Did you benchmark what have biggest cost in map rendering?
-
Did you benchmark what have biggest cost in map rendering?
Terrain tile blits. This dominates everything.
Now, the problem is not only in that the renderer renders every single tile visible, although that's the proverbial 80% of the problem.
Noticeable time is wasted because the data is all over the address space, not organized into tidy texture albums, this just kills caches.
EDIT: I prototyped an OpenGL ES renderer that uses hw zbuffer to sort out visibility and vram-resident texture albums so that drawing every single last tile has no noticeable effect on framerate. But I decided that that patch won't ever be accepted.
-
Terrain tile blits. This dominates everything.
Now, the problem is not only in that the renderer renders every single tile visible, although that's the proverbial 80% of the problem.
Noticeable time is wasted because the data is all over the address space, not organized into tidy texture albums, this just kills caches.
EDIT: I prototyped an OpenGL ES renderer that uses hw zbuffer to sort out visibility and vram-resident texture albums so that drawing every single last tile is not noticeable. But I decided that patch won't ever be accepted.
Probably mass killing cache is biggest crime of OXC, like this line:
_objects[part]->getDataset()->getSurfaceset()->getFrame(_objects[part]->getSprite(_currentFrame[part]));
each `->` is candidate for cache miss, this could be simplified to `_objectsSurface[part]` but this will made `Tile` more fat and reduce performance in other places. Probably better would be something like I did with `VisibilityBlockCache`.
Another place where we could improve cache is position of surfaces, right now 99% of them once they are loaded will be never changed. This could allow us to bach allocate memory for them.
Question how much it will improve performance. Interesting thing is that I get 50% boost only for using OpenGL filter (XPiratez base defense, 1600x800 , 1:1 pixel scale, whole map visible).
-
Probably mass killing cache is biggest crime of OXC, like this line:
_objects[part]->getDataset()->getSurfaceset()->getFrame(_objects[part]->getSprite(_currentFrame[part]));
each `->` is candidate for cache miss, this could be simplified to `_objectsSurface[part]` but this will made `Tile` more fat and reduce performance in other places. Probably better would be something like I did with `VisibilityBlockCache`.
Obviously the pointer spaghetti mess isn't helping anything, but just the nonlocality of the bitmaps is enough to trash any cache, every frame.
Another place where we could improve cache is position of surfaces, right now 99% of them once they are loaded will be never changed. This could allow us to bach allocate memory for them.
Best solution would be to get the surfaces off the CPU caches entirely - that is, hand them off to the GPU.
This being not quite possible, second candidate is a tiled surface store/allocator, just like the GPUs manage their texture memory.
Interestingly such an allocator/storage manager is half of the way of entirely offloading the blitter to the GPU.
Question how much it will improve performance.
Just getting rid of some pointers? I doubt it'll be much if the surface data stays where it is and in SDL_Surfaces the size of original spritesheets.
Interesting thing is that I get 50% boost only for using OpenGL filter (XPiratez base defense, 1600x800 , 1:1 pixel scale, whole map visible).
Curious. What's your hardware?
-
Intel i5 4670K 3.40GHz
I did again my test and I see that I miss one important thing, there still difference between software and OpenGL (40 vs 60) but I do not check CPU usage that increase when OpenGL is enabled, this mean my "boost" is not real one, only caused by fixed fps by OpenGL.
-
Okay then. I'll play until a base is raided and then try to revive the tile/sprite texalbum code. Maybe it'll help noticeably.
-
Okay then. I'll play until a base is raided and then try to revive the tile/sprite texalbum code. Maybe it'll help noticeably.
Right now I do some refactors that flatten memory of surfaces and tiles. Current result is around 25% to 40% speed up.
Probably lot of speed grain was from caching
_objects[i]->getDataset()->getSurfaceset()->getFrame(_objects[i]->getSprite(_currentFrame[i]));Overall I think that we could grain more when we could avoid using `_objects` in map drawing. Another place I see where we could grain some FPS is compressing `Tile` data (like replacing `bool` with bit field that in extreme cases could cause 8 time speedup if work was memory bound) or splinting tile in half to move less used data to other place in memory.
My WIP branch where test are done: https://github.com/Yankes/OpenXcom/tree/stash/workInProgress (commit 5358df2340c1ab14d9a36027d65b980caaede70d)