412 réponses à ce sujet

[MichaelFinnegan]

100RenegadePoints wrote...

So more and more people are investigating this which is good. I think I have noticed differences in the AI's ability to flank the player at lower frame rates. Also the speed at which they advance to the players position. Anyone else noticed these differences? or am I seeing things ?

I'm not sure whether this is relevant, but I've noticed (let's say in hunter mode) out of the line of sight, enemies always move at increased speed to try to converge on the players position (from, say, their spawn point), and as soon as they get into the line of sights of the players, their movement speed goes back to "normal." You can sometimes see this sudden change in speed as they start nearing.

There are however times when I can plainly see that they are moving and reacting much faster. This could be attributed to an increased frame rate.

[Commander_Rafael]

It looks like developing with the console frame stability in mind and portin into the pc just can't cease to amaze me on how much trouble it gives.

[BACON4BREAKFAST]

As someone with extensive playtime on xbox and PC this thread is very interesting. (I haven't read all of it and am probably repeating stuff but IDC)

The xbox's abysmal frame rate is one of the major contributing factors that led me to purchasing the game for PC.

I knew something was strange with the PC version, It seemed like I was taking way more damage than I should be while I was doing the same tactics. However after reading this I'm still sticking to 60 FPS. Precision aim is a lot easier on higher frame-rates and that far outweighs taking some extra damage (enemies can't kill you if they're dead). I still believe that the problems for the console version make it "harder" than the PC version.

1. Controllers cannot be as accurate. (don't need to explain why)
2. Auto-aim. While this is a HUGE benefit in almost every console game (try playing without it) and even in ME3 it makes aiming/sniping so much easier (except when it aims you at the wrong target, which is about 25% of the time)
3. Can't rotate camera while sprinting. Even if you can do the claw method (index finger on "A" button and thumb on stick) the game won't let you rotate the camera while sprinting. This makes it impossible to check corners while playing aggressive. (this was the single most frustrating factor for me)
4. low sensitivity. Even at "High" it feels so sluggish and it can be very frustrating to switch between multiple targets or to engage something behind you quickly.
5. Low frame-rate. While the benefits have been shown, low frame-rates lead to low accuracy.

So I don't think console players have it "easier", I get way faster times and perform much better on PC overall. Stick to 60 FPS if you're a PC player, you're gimping your offensive capabilities too much by capping your frame rate.

Modifié par BACON4BREAKFAST, 16 février 2013 - 07:49 .

[FatalionPanic]

BACON4BREAKFAST wrote...
[...]

So I don't think console players have it "easier", I get way faster times and perform much better on PC overall. Stick to 60 FPS if you're a PC player, you're gimping your offensive capabilities too much by capping your frame rate.

I'm confident that ~30 FPS is how the game was meant to be played.
While 60 FPS might work pretty good for the host it can be hell for the clients connecting to that lobby.

I've been a client to 60+ FPS hosts and the game will become buggier with every wave.
Not everyones PC/Laptop can get above 30 FPS. My Laptop can barely keep it at 25-30.

Unless you don't mind carrying your clients 60 FPS are all fine. 

[CmnDwnWrkn]

Feneckus wrote...

Caratinoid wrote...

Here a short video showing how to take advantage of 30 FPS mode on gold with no shield boost gear and no cyclonic or adrenaline mods:

Video

Does that mean you can do that on xbox ? Or is it because the game is running at half the FPS it's supposed to ?

Because if you can do that on xbox, well, that kind of put things in perspective.

I don't know about XBox, but I can tell you with certainty the PS3 version does NOT play that way.  I'm looking at this 30 fps PC video, and it looks completely foreign to me.  You can't just run by enemies like that on Gold and have them miss like that.  It just doesn't work that way.  I've seen enough and read enough on here describing the PC version at 30 fps to conclude that 30 fps PC is not the same as 30 fps PS3.  Nobody actually knows the other differences between the PC and console version.  They might have very well intended for the game to run at 60 fps on PC, but then scaled the enemy AI for console so that the two versions retain a similar difficulty. 

[Adamziomal]

On Goddes I have 18-30 FPS. People don't complain and 20-30 FPS is comfortable for me.

[TheKillerAngel]

Before I built my own computer I'd regularly play games at 20-30 FPS and think that was smooth. Now I've been spoiled by my SLI GTX 560's.

[novalotus]

This is by far the most interesting thread I was fortunate enough to stumble upon. Since the FPS has been confirmed to affect shield recharge, I wonder how many other PC only issues it is possibly the cause of.

[Arppis]

Even so, it's pretty annoying on consoles too. You do get hit from smallest of cracks and enemies are pretty much dead on with their guns, rolling doesn't help either, even on waist-high objects, they will still hit you.

If they are even more accurate than that on PC, and I do mean they pull headshots 100% all the time. It must suck to play there.

[hawkera_prime]

i always play at steady 60fps

[Dorryn]

mi6o wrote...

i always play at steady 60fps

Cool for you bro !

[Deerber]

TheKillerAngel wrote...

Before I built my own computer I'd regularly play games at 20-30 FPS and think that was smooth. Now I've been spoiled by my SLI GTX 560's.

Oh my. I bet I could run Skyrim pretty good with that...

[Caratinoid]

Ok, I just took a quick peek at the source code, there are rounding errors all over the place. Most variables are floating point numbers but the programmers are working with functions like Max, Min, Clamp etc which can only work with integers. When passing float parameters to those functions, they are automatically typecasted to integer (rounded down). If you don't want this you should use the FMin, FMax, FClamp ... functions instead which they still don't use even in last DLC.
So if you write something like "Clamp(factor, 0.5, 1.0)" the result will always be 0.

What's affected? So far found these things:

Shield recharge times (see OP)
Some aspects of schield gates are affected (for example it was not intended for asari's dodge to remove shield gate if you use up all your shields)
Enemy spawn penalty calculations (yeah, I said it)
Projectile movement (direction change)
Player position tracking is probably due to this as well

This can not be fixed with a patch because those functions are used everywhere, you would need to replace almost all files to fix it, no wonder there have been no response. If basic functions like this are used incorrectly then I'm afraid to dig any further.

The only chance to fix those bugs would be to make a custom patcher to replace those function calls in all files with the correct ones by manipulation uscript byte codes.

Now that I can read the source code (the process is not perfect yet) I can probably answer questions about other aspects of the game mechanics without having to do memory tests.

[burr beer]

If true, sounds crazy that Bioware's coders did such a sloppy job with the coding, especially regarding the functions-isn't that a part of any basic programming class?

(Not doubting you, just have no time or interest in the matter to verify for myself.)

We're not going to get a dev response regarding this issue, there's literally nothing they can do at this point but keep quiet and hopefully hire some better coders for future projects.

Modifié par burr beer, 24 février 2013 - 12:55 .

[BridgeBurner]

Ahhh, once again, PC players get the short end of the stick due to problematic porting.

[Caratinoid]

burr beer wrote...

If true, sounds crazy that Bioware's coders did such a sloppy job with the coding, especially regarding the functions-isn't that a part of any basic programming class?

(Not doubting you, just have no time or interest in the matter to verify for myself.)

We're not going to get a dev response regarding this issue, there's literally nothing they can do at this point but keep quiet and hopefully hire some better coders for future projects.

Yeah I thought I was reading it wrong or something but I just tested some of those things in the game and it looks like someone needs to go write his first "Hello world" program.

This is why it takes so long to fix bugs, it all makes sense now.

Modifié par Caratinoid, 24 février 2013 - 01:03 .

[HolyAvenger]

Damn. I wonder why there are such basic issues with the code.

[LorelynF]

120 Fps <3

Lower than 60fps is a bit laggy, imo.

[Yosuke]

Just thought I'd do a little experiment; perhaps it has been done already, but if so, here it is again. Cerberus, goddess, gold. Ran around in wobbly circles in the same area as OP. Died roughly thirty seconds after first contact.

Observations: While impossible to prove with anecdotal evidence, enemy targeting at 30 FPS does not appear equal to on consoles. Additionally, the inability to turn the camera while running means you cannot sustain your sprint through extended turns or observe the enemy, which is a significant limitation or handicap in both mobility and awareness; so much so that the PC experiment cannot even be properly reproduced on console.

Conclusion (which one should not even need this experiment to reach): While useful for comparing FPS settings between PCs, this data does not prove much on the PC vs console debate, even ignoring the plethora of other factors involved. While the possibility remains that enemy targeting abilities are equal between PCs and consoles at the same FPS, the limitations of console controls as a handicap appear to outweigh any benefit from poor targeting when forced to evade in a circular course.

Recommend further tests using maneuvers that are possible on console (i.e. not running in a circle).

Modifié par Yosuke, 24 février 2013 - 03:22 .

[kratos301]

All this story it's really ridiculus. i always have played at 60 fps, and for me the phantoms killing you with 3 palm's cannon shots in 0.75 seconds and the prime starting to shoot even before I went around the corner, with his shots that can not be outrun even with +35% movement speed, were normal, and cheap, things.

after reading this thread, having companions of dubious skill in a platinum PUG hosted by me, I have set my fps to 30, and heck if it was easier to carry than any of my gold games at 60 fps. phantoms were a piece of cake and i was outrunning prime's cannons with just the +20% mov.speed by annihilation field. i even done half of the wave 8 alone, and i am really terribad at doing solo games.

this game has some serious problems. now i understand why in all the xbox/PS3 videos all, excepts the movements, seems so easy and the enemy miss you, when at 60 fps a pack of marauder is more terrifying than 2 banshees, at least for a non warlord-juggernaut.

screen (white/cerb/plat):

Modifié par kratos301, 02 mars 2013 - 02:48 .

[Deerber]

Caratinoid wrote...

Ok, I just took a quick peek at the source code, there are rounding errors all over the place. Most variables are floating point numbers but the programmers are working with functions like Max, Min, Clamp etc which can only work with integers. When passing float parameters to those functions, they are automatically typecasted to integer (rounded down). If you don't want this you should use the FMin, FMax, FClamp ... functions instead which they still don't use even in last DLC.
So if you write something like "Clamp(factor, 0.5, 1.0)" the result will always be 0.

What's affected? So far found these things:

Shield recharge times (see OP)
Some aspects of schield gates are affected (for example it was not intended for asari's dodge to remove shield gate if you use up all your shields)
Enemy spawn penalty calculations (yeah, I said it)
Projectile movement (direction change)
Player position tracking is probably due to this as well

This can not be fixed with a patch because those functions are used everywhere, you would need to replace almost all files to fix it, no wonder there have been no response. If basic functions like this are used incorrectly then I'm afraid to dig any further.

The only chance to fix those bugs would be to make a custom patcher to replace those function calls in all files with the correct ones by manipulation uscript byte codes.

Now that I can read the source code (the process is not perfect yet) I can probably answer questions about other aspects of the game mechanics without having to do memory tests.

Damn! I didn't see this before. Looks like you nailed it. You mentioned pretty much 90% of the so-called "bull****" that this game offers. Looks like there's a readon behind it, then.

Well, I don't want to beharsh on Bioware as the game is really amazing anyway. But, in all honesty, it would be much much better if they put a little bit more effort in this part. And I'm pretty sure, by what you say, that the effort wouldn't have been very big.

So, I can just say... Bioware guys, what about putting in a bit more effort in this part for ME4? It might help the game development a lot 

[ElementL09]

Lord_Sirian wrote...

Yet console players keep insisting that the AI on their lolbox 360s with their framerates capped at 30 is more accurate/aggressive than the AI on your standard 60 FPS PC.

This is well documented, but thanks for putting it all in simple terms for people to understand.

Who the heck said that?

[Shampoohorn]

Caratinoid wrote...

Ok, I just took a quick peek at the source code, there are rounding errors all over the place. Most variables are floating point numbers but the programmers are working with functions like Max, Min, Clamp etc which can only work with integers. When passing float parameters to those functions, they are automatically typecasted to integer (rounded down). If you don't want this you should use the FMin, FMax, FClamp ... functions instead which they still don't use even in last DLC.
So if you write something like "Clamp(factor, 0.5, 1.0)" the result will always be 0.

What's affected? So far found these things:

Shield recharge times (see OP)
Some aspects of schield gates are affected (for example it was not intended for asari's dodge to remove shield gate if you use up all your shields)
Enemy spawn penalty calculations (yeah, I said it)
Projectile movement (direction change)
Player position tracking is probably due to this as well

This can not be fixed with a patch because those functions are used everywhere, you would need to replace almost all files to fix it, no wonder there have been no response. If basic functions like this are used incorrectly then I'm afraid to dig any further.

The only chance to fix those bugs would be to make a custom patcher to replace those function calls in all files with the correct ones by manipulation uscript byte codes.

Now that I can read the source code (the process is not perfect yet) I can probably answer questions about other aspects of the game mechanics without having to do memory tests.

Quite surprising.

Do you think this is a result of the game's origin as an SP RPG?  This forums Experts have picked apart the microscale actions and outcomes of MP in ways that were never worth doing in any of the single player campaigns.  Multiplayer has been an amazing experience this past year, and if anything I'm more impressed that Bioware made a game worth playing (and playing) -- despite all of its fundamental flaws.

[Dunvi]

Caratinoid wrote...

Ok, I just took a quick peek at the source code, there are rounding errors all over the place. Most variables are floating point numbers but the programmers are working with functions like Max, Min, Clamp etc which can only work with integers. When passing float parameters to those functions, they are automatically typecasted to integer (rounded down). If you don't want this you should use the FMin, FMax, FClamp ... functions instead which they still don't use even in last DLC.
So if you write something like "Clamp(factor, 0.5, 1.0)" the result will always be 0.

What's affected? So far found these things:

Shield recharge times (see OP)
Some aspects of schield gates are affected (for example it was not intended for asari's dodge to remove shield gate if you use up all your shields)
Enemy spawn penalty calculations (yeah, I said it)
Projectile movement (direction change)
Player position tracking is probably due to this as well

This can not be fixed with a patch because those functions are used everywhere, you would need to replace almost all files to fix it, no wonder there have been no response. If basic functions like this are used incorrectly then I'm afraid to dig any further.

The only chance to fix those bugs would be to make a custom patcher to replace those function calls in all files with the correct ones by manipulation uscript byte codes.

Now that I can read the source code (the process is not perfect yet) I can probably answer questions about other aspects of the game mechanics without having to do memory tests.

I just saw this.









(Also, just out of curiosity as I am a computer science student but have mostly worked with unix systems so far, how did you look at the source code? I assume you're decompiling, but what program do you use to decompile?)

Modifié par Dunvi, 04 mars 2013 - 11:01 .