Jump to content

Lord Crc

Member
  • Content count

    48
  • Joined

  • Last visited

About Lord Crc

  • Rank
    Fireteam Leader

Profile Information

  • Gender
    Male
  • Location
    Norway
  1. Unofficial SLI configuration for Squad

    IIRC I had issues like that with SLI in other games if I had Vertical Sync mode set to "On (smooth)". Try using just "On" or just "Off" if you have it set to smooth.
  2. Combat Loads (Ammo)

    In Joint Operations I must admit I quite enjoyed balancing movement speed vs ammo carried. If you rushed the next point by carrying just a couple of mags you were usually SOL if you got involved in a firefight before the point was captured.
  3. Still getting low FPS with the latest patch V4

    Joint Operations had 150 player servers, ran quite fine. It's always a trade-off though, between features and details vs player count.
  4. Gamma Settings

    I strongly disagree. Gamma 3.0 vs 2.2 makes a huge difference on my monitor, making it a lot easier to spot enemy movement at a distance.
  5. Gamma Settings

    If they don't have want to prioritize any fix for this issue, I agree with Nightingale that they should then simply remove night maps for now.
  6. New bugs and annoyances.

    Me too, though I was mostly playing against US.
  7. Gamma Settings

    Yes they definitely need to add something like this, though perhaps add a bit of noise in the black areas as well.
  8. WHERE IS EVERYBODY???

    Just to put this in perspective: If each backer plays Squad for 3 hours per weekend then to fully populate two 40-player servers through the weekend, you'd need 2 * 40 * 72 / 3 = 1920 players. Of course some will play more, some will play less, some will not play at all, player times will have peaks during the day etc etc. But I think my calculation shows the current server population level is roughly what one could expect given the number of potential players. Personally I'm trying to not get "game fatigue", so limit myself to about 3-4 hours per weekend. I also suspect a lot of backers are not playing at all because they dislike unfinished games, but gave their support at the kickstarter because they really want the finished game.
  9. FPS Problems (capped at 22fps)

    Well, multithreading is hard, that's why As far as I know, Unreal Engine has several tools for the developers to spread the load across more cpu cores, but I'm assuming the devs have turned most of them off for now. Turning them on will very likely lead to an increase in weird, hard to track bugs and crashes, which is not what they need right now.
  10. Shadows In Epic Flickering

    Ah I have that as well, though it's significantly worse on some maps. Thought it was the SLI though, 2x GTX 970. I should disable SLI and check again.
  11. Squad Closed Pre Alpha BUILD 1710 ( Week 2) playlist

    Still trying to get my bearings. Fortunately, so are other people
  12. Servers Constantly Crashing

    Nerd time: Imagine the memory as a chess board. Each square represents a piece of memory. When a program needs to allocate some memory, for example because the player fired a bullet and thus a "bullet object" needs to be created so the game can track where it's going and what it hits, the program needs to figure out which of the squares to use for this allocation. Obviously, it shouldn't use a square which has already been allocated and is thus used for something else. So the program needs to track which squares have been allocated, and then find a suitable square to use for this new allocation. Since this is such a basic and common task, it's delegated to a separate piece of code called the memory manager. So the program asks the memory manager: "please, find me an empty square". The memory manager then might look at each square in turn, to see if it's been marked as occupied. If a square is empty, it marks it as occupied and returns the address of it to the program which can then use it for whatever. Since the memory manager is a separate piece of code, the program has to explicitly tell it when a square is no longer in use. Otherwise it has no way to know that the square is not in use. Now, imagine that the bullet flied off, and after some time hit a wall. Ok, that's it for the bullet, no need to track it any more. But the programmer forgot to insert a call to tell the memory manager that the square used for the bullet object is not longer needed by the program. Next time the program asks for a square, the memory manager cannot consider this square, it's still marked as occupied as far as it's concerned. If this goes on then after a while the memory manager runs out of squares on the board, and it cannot return any when the program asks. In almost all cases, this is treated as a fatal error by the program and the program terminates (or crashes if the programmer simply ignored this possibility). There are other ways of leaking memory. For example, maybe the programmer tried to be smart and do "lazy loading", that is, not loading an image/texture into memory until it's needed. In that case, the programmer may forget to check if the image has already been loaded. Thus each time the program goes "oh, I need this image", the program would load it again into a new part of memory, until it runs out.
  13. HOW

    http://joinsquad.com/prepurchase Pay less and get access later, or pay more and get access sooner. In any case you'll have to wait 5-7 weeks or so. edit: we really could do with a more prominent sicky post for this...
  14. FPS Problems (capped at 22fps)

    Game is quite CPU heavy, but not yet optimized for multithreading, so that Phenom is going to suffer hard with its lacking single-thread performance.
  15. Grenade and explosion simulation

    Ah, I guess I explained it a bit poorly. I meant I wasn't sure if the Unreal Engine would easily allow for more advanced optimizations which could cut down the number of hit tests needed. As an illustration, one could consider each player as a sphere, and the grenade as another sphere which radius is determined by the maximum shrapnel travel distance. One could then for each player see if the player sphere intersects or is contained by the grenade sphere. If not, no hit tests are needed for that player. That boils down to a few subtractions and multiplications per player, so very fast (no need for expensive square roots, as one can simply compare the squared distance). Then one could take this a step further and only consider the shrapnel which is contained within the cone bounding the player sphere. This can be done with a bit of trig which is still quite cheap compared to a hit test. Then it might pay off to consider the player to be something less sphere-like and more tall box-like... Anyway, maybe the Unreal Engine has something for this already, or maybe it does not and it is quite hard to add. I don't know. Heck, maybe it's still too expensive for some reason I can't think of even after such optimizations. In any case I'm pretty sure the devs would do it if it was relatively easy and they didn't have to give up something better to get it in the game.
×