Messages

16

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 02, 2016, 11:50:34 pm »

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.

17

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 02, 2016, 03:27:24 pm »

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.

18

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 02, 2016, 02:53:25 pm »

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?

19

OpenXcom Extended / Re: Meridian's resources and mods for X-PirateZ

« on: May 01, 2016, 06:08:17 pm »

The game only runs on one core as it is. Would you mind trying at 30 or 40 just to test the performance?

20

OpenXcom Extended / Re: Meridian's resources and mods for X-PirateZ

« on: May 01, 2016, 12:59:11 pm »

I just realized that using the clear inventory button or load template button on a gal with pre-primed grenades drops the grenades live on the floor for a bit of a surprise a turn later... Due to the number of inventory items in a typical equip screen this can be a bit hard to catch manually, so I made a tiny fix and attached it to this post. Prime-able items are now reset when either of these buttons drops the item.

New request: Add # of gals wounded to the debriefing state, shown before # of gals killed, with the possibility of deducing score for that.

The number of days they'll be injured would be really useful for such a screen too. Though perhaps that part is better for the skill screen, then again that screen is fairly busy as it is.

21

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: May 01, 2016, 02:06:56 am »

Ah, change from

Code: [Select]

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

Code: [Select]

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

22

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« 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.

23

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

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

24

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: April 29, 2016, 10:40:25 pm »

That's actually pretty close to how I'm updating FOV at the moment. I imagine a circle around the event (with some clearance) then place lines tangent to the circle as viewed from the unit and update units and/or tiles within that area. For tiles it's a little more complicated due to the nature of the bresenham lines used to reveal terrain, but it appears to work well now.

As for the doors I just haven't updated the function call from the code handling the doors yet, as I've been busy testing the basic functionality. With it using the old function call convention certain parameters are set to default values causing the algorithm to ignore the arc handling part of the update. Should be an easy fix as long as I remember that doors can have different sizes and scale the event accordingly.

25

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: April 29, 2016, 08:30:47 pm »

Glad you're still finding it useful!

I should have a new version with greatly improved performance for you fairly soon. I just need to update a few more places where the new FOV calculation is initiated, then run a couple more battles to look for the most obvious bugs.

how performance look after your changes? How much far you can now push visibility to see problems?

Attached is a graph of my latest test on movement-related calculations. The "original" bars is the current OXCE build. The newFOV2 bars is my current build. (not the executable from the original post). The graph tracks a single unit running to a craft door, then a second unit running into the craft and opening a second door. Each step along the X-axis is one step for the unit with a FOV calculation for every unit in range (34 units in range total). The Y-axis plots the time used per step for both algorithms. The view distance was set to 30. The median time used per calculation was 58.41ms and 5.782ms. The two slow newFOV2 bars are the doors opening, as that part of the code hasn't been updated to use the new features yet, which causes the algorithm to default to a semi-original behaviour.

I've tried playing with view distances up to 60, but the reactionfire gets really crazy when everyone can see across the map....

26

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: April 23, 2016, 05:51:21 pm »

I'm planning some additional changes to how and when the FOV calculation is used. Here's a rundown for movement-related FOV calculations:

For every step of movement:
what it was:

• Every unit in range of the moving unit clears and updates their visible units.
• All player units in range clears and updates their visible tiles.

what the new version does:

• Every unit in range of the moving unit clears and updates their visible units (in a faster manner).
• Only the moving character clears and updates its tiles (if a player unit).

What I'm planning to change next:

• Only units which saw the moving unit before its move needs to check for new visible units. (In case the moving unit blocked sight to someone behind it.)
• Every unit in range needs to check if it can see the moving unit after the step.
• Only the moving character clears and updates its tiles (if a player unit).

So thats my todo-list for movement-related FOV calculations. I may also update the projectile hit code for explosive projectiles to use the optimizations I added for the non-explosive ones (basically don't recalculate the entire maps' worth of sun and other lighting, as well as the FOV of all units in range, unless something has actually changed as a result of the hit)

I see there's a bit of back and forth in my commits, so I'll make a new branch when I've updated the source with the new features.

27

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: April 23, 2016, 01:29:55 am »

Oops, you're quite right. Mixed windows and linux line endings. I reverted the latest commit and uploaded it again with slightly better consistency. BTW: Would it be better if I recreated the branch with all changes in one commit?

28

XPiratez / Re: [MAIN] XPiratez - 0.98D - 21 Apr - Bugfixes

« on: April 22, 2016, 10:15:53 pm »

Thanks for the new version!

why when I made one shot from the laser gun for example, at the end of the battle cage disappears (Not enough equipment to fully re-equip squad)?

That's how the game works. It tallies all shots remaning in all the clips of a single type, then re-creates a number of ammo clips. Thing is, it always rounds the number of remaining clips down.

There's an approximation of saving all rounds available in the bullet saving patch on the dev subforum. Might encourage greater weapon diversity as players don't have to be as careful with what they use to save clips.

29

OXCE Suggestions DONE / Re: Help test new FOV calculation executable (playable long view distances)

« on: April 22, 2016, 10:06:20 pm »

Not quite. It had two modes. One updating per unit and one updating around a set position on the map. The per unit is decently fast, but uses a method of fetching visible units which doesn't scale well with view distance. The around position function uses the unit one internally and triggers it for every unit within a given range of the point.

The stuttering was mostly to do with the latter function as every moved tile every unit in range had to check if it saw new units (which is fine, as otherwise you wouldn't get reaction fire or aborted movement), but since the function is also responsible for revealing tiles this lead to a lot of busywork.

30

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

« on: April 22, 2016, 09:42:11 pm »

I've had some problems with stuttering gameplay with long view distances and noticed that it is apparently a quite common problem. Hence I decided to take a look at the way the game handles Field of View (FOV) calculations and made a significant improvement in calculation speed. You may download this new version and help test the changes below.

What does faster FOV calculations mean for you as a player:
Greatly reduced delay after each movement step for all units. This leads to smoother gameplay, faster AI turns and playable long view distances. The handling of post hit and post explosion vision calculations also benefit which leads to less delay after each shot. This in turn means faster auto fire and reduced delay whenever the terrain changes.

Download and source
Windows executable (My own additions built on Meridian's v2016-04-28) The runtime libraries normally compiled into the executable, are not, hence you need to download some additional .dll files and put the ones from "deps\lib\Win32" within your game folder with the executable. Now included in Meridian's executable.
Source code
Should you find something amiss, let me know.

PS: To get increased view distance you have to change the "maxViewDistance: 20" line in Piratez.rul.