[DONE] Help test new FOV calculation executable (playable long view distances)

[Yankes]

Great, I will looking forward for final version.

[Meridian]

Great, I will looking forward for final version.

Me too.

[Stian]

Updated the first post with the new source code and an executable built on top of Meridian's v2016-04-28.

Should I make some kind of illustration explaining how it works?

[Hazard]

Yay, now I can upgrade to 98E. Thank you very much Stian.

[Stian]

Discovered a bug with doors opening. (so much for the easy part, right?) If an AI opens a craft door your units will not reveal tiles within the craft. They will still reactionfire at units standing on the tiles which should've been revealed though. I know when it bugs out and have a dirty fix for it, but I'd rather try to fix it properly so that units don't slow down on doors. Sorry about this.

Edit: ...and I know exactly what I did wrong. I did a last minute fix of a bug relating to explosions at the edge of unit visibility. That is the centre of the explotion was outside of range, but the effect wasn't. This fix had a small oversight (forgot to square the range...) and stopped most positionupdates from working properly. Executable will be updated shortly, just need to remove the debug info.
Edit2: Updated the executable and the source.

[Meridian]

I've cherry-picked the two commits, but it doesn't compile for me...

[Stian]

Ah, change from

Code: [Select]

(*j)->getVisibleTiles()->clear(); to

Code: [Select]

(*j)->clearVisibleTiles(); (My Git upload tool hates me.)

[new_civilian]

Just wanted to thank everyone involved in this, the gain of performance is incredible. It feels like my computer had a major hardware upgrade. I am using a viewrange of 40 fwiw.

[Dioxine]

There was also discussion about 2 further possible upgrades to performance:

1. Why the game is so slow on high-res? (I can play OK in 480px, even 640px, but my native res - 1680px - slows the game down to a crawl, even with the new FOV calculations).

2. Why the pre-battle slows down so much if you have much stuff on your craft?

Investigating these 2 strange cases might bring us even more speed...

[Stian]

Just wanted to thank everyone involved in this, the gain of performance is incredible. It feels like my computer had a major hardware upgrade. I am using a viewrange of 40 fwiw.

I'm so glad that it is working and providing such a benefit for people! Thanks.

There was also discussion about 2 further possible upgrades to performance:

1. Why the game is so slow on high-res? (I can play OK in 480px, even 640px, but my native res - 1680px - slows the game down to a crawl, even with the new FOV calculations).

I'm getting this if I have OpenGL turned on. Basicly if I turn on an OpenGL filter my CPU immediately jumps to full load on that core regardless of resolution. With any of the non-OpenGL filters 1920x1080 is working well for me. So something is obviously wrong with the hardware acceleration code, or device selection, as it shouldn't be slower than software.

2. Why the pre-battle slows down so much if you have much stuff on your craft?

I had a look at this earlier in the week. It appears to be caused by the inventory packing code. Sadly I've managed to overwrite my basedefence savegame where this issue was most prevalent for me, and using the battle generator doesn't give me the same slowdown that save had for some reason. Do you happen to have a save handy?

[legionof1]

If we are still using the same inventory code as the original game i'm not surprised. It had a hard limit for number of items in loadout screen to prevent memory issues. To my recollection openxcom just took off the limit. Most the time you would never notice the bad code since modern machines have orders of magnitude more memory.

[Meridian]

I had a look at this earlier in the week. It appears to be caused by the inventory packing code. Sadly I've managed to overwrite my basedefence savegame where this issue was most prevalent for me, and using the battle generator doesn't give me the same slowdown that save had for some reason. Do you happen to have a save handy?

I have a good save.
Will upload later today... I haven't looked at it yet, but I feel it must be the arrangeGround() method... probably arranging each item separately instead of arranging stacks, so 1000+ credit chips on the ground will give it a hard time. Just guessing tho.

[Stian]

Yes, I seem to remember that's pretty much how it went. Start from the beginning for each item, add one to the stack, etc. A quick fix would be to add as many as possible each step. A good bit of the extra busywork could also be reduced if it kept track of free slots, just like those imagestacking algorithms do, rather than scan through the inventory with each new item. I'll take a look later.

[Meridian]

Save attached (0.98e, no other mods)

[Stian]

With that save there are 2563 items to be processed into 185 stacks. Turning the inventory page takes 621ms with the current algorithm on my machine. I introduced some changes, and while I still need to clean up the code a bit, it's looking good so far with pages turning in 8ms. With pre-sorting of items from large to small it completes in 5ms, but that also alters the display order.