Author Topic: [DONE] Help test new FOV calculation executable (playable long view distances)  (Read 27304 times)

Offline Yankes

  • Commander
  • *****
  • Posts: 3323
    • View Profile
Re: Help test new FOV calculation executable (playable long view distances)
« Reply #15 on: April 29, 2016, 11:16:20 pm »
Great, I will looking forward for final version.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9047
    • View Profile
Re: Help test new FOV calculation executable (playable long view distances)
« Reply #16 on: April 29, 2016, 11:18:29 pm »
Great, I will looking forward for final version.

Me too.

Offline Stian

  • Sergeant
  • **
  • Posts: 30
    • View Profile
Re: Help test new FOV calculation executable (playable long view distances)
« Reply #17 on: April 30, 2016, 07:39:46 pm »
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?

Offline Hazard

  • Captain
  • ***
  • Posts: 60
    • View Profile
Re: Help test new FOV calculation executable (playable long view distances)
« Reply #18 on: April 30, 2016, 08:39:36 pm »
Yay, now I can upgrade to 98E. Thank you very much Stian. :)

Offline Stian

  • Sergeant
  • **
  • Posts: 30
    • View Profile
Re: Help test new FOV calculation executable (playable long view distances)
« Reply #19 on: April 30, 2016, 10:48:21 pm »
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.
« Last Edit: April 30, 2016, 11:24:51 pm by Stian »

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9047
    • View Profile
I've cherry-picked the two commits, but it doesn't compile for me...
« Last Edit: May 01, 2016, 01:53:00 am by Meridian »

Offline Stian

  • Sergeant
  • **
  • Posts: 30
    • View Profile
Ah, change from
Code: [Select]
(*j)->getVisibleTiles()->clear(); to
Code: [Select]
(*j)->clearVisibleTiles(); (My Git upload tool hates me.)

Offline new_civilian

  • Commander
  • *****
  • Posts: 725
    • View Profile
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.

Offline Dioxine

  • Commander
  • *****
  • Posts: 5455
  • punk not dead
    • View Profile
    • Nocturnal Productions
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... :)

Offline Stian

  • Sergeant
  • **
  • Posts: 30
    • View Profile
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.

Quote
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?

Offline legionof1

  • Commander
  • *****
  • Posts: 1900
  • Bullets go that way. Money comes this way.
    • View Profile
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.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9047
    • View Profile
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.

Offline Stian

  • Sergeant
  • **
  • Posts: 30
    • View Profile
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.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9047
    • View Profile
Save attached (0.98e, no other mods)

Offline Stian

  • Sergeant
  • **
  • Posts: 30
    • View Profile
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.