Add YOUR System Specs to the Wiki!

[z929669]

We encourage all mod testers to hop onto the Wiki and log in using your forum credentials (HINT: check the 'Remember' box). 

 

Enter in your system specs.

 

Also notice the bug-ticket generator button that will be useful for opening mod tickets pending resolution during testing for future releases.

[stoppingby4now]

I admit I wasn't aware of Enhost. Based on the limited information I've been able to gather, it seems like it's doing something good (there's that compelling reason). Though, I'm surprised that the Skyrim process would reach 4GB based on the speculation of what Enhost is doing. Guess I'll have to get a setup going and do some testing.

 

The only problem currently is that all we have right now is speculation on what Enhost is doing. I have trouble believing that Enhost is extending DirectX management on top of what Skyrim is doing, as that would add an additional layer of latency. I feel like something else must be going, akin to Enhost taking over DirectX management somehow.

 

That said, we can add a field for System RAM. We'll still need compelling evidence to show that amount of System RAM plays a significant role for cards with less VRAM, when using Enhost.

[MontyMM]

Whatever ENBhost is up to, it won't improve matters for limited VRAM. lt Can only improve the efficiency of the DX mirroring behaviour, allowing greater VRAM to be utilised before Skyrim hits its 32 bit limit.

 

As i understand it, DX9 must maintain a copy of video data in system memory, because prior to DX 10 the CPU could not directly address data held in VRAM; it had to maintain a copy in system memory in order to perform the CPU bound part of its operations. ENhost seems to work around this by moving part of the data caching to a separate process.

[phazer11]

I still don't get what the big deal is. Why not just go ahead and add it and be done with it? It'll make any analysis down the road easier if we can determine who is having problems and then be able to tell more about whether or not it's the amount of RAM they have that is the issue.

[MontyMM]

I still don't get what the big deal is. Why not just go ahead and add it and be done with it? It'll make any analysis down the road easier if we can determine who is having problems and then be able to tell more about whether or not it's the amount of RAM they have that is the issue.

 

I would go along with that. Short of a full understanding, the results are good enough to warrant at least testing. We can at least learn about it empirically, by having as much of the team and community gaining experience with it.

[stoppingby4now]

I still don't get what the big deal is. Why not just go ahead and add it and be done with it? It'll make any analysis down the road easier if we can determine who is having problems and then be able to tell more about whether or not it's the amount of RAM they have that is the issue.

I don't have a problem with adding it, as I've stated. The initial response was to explain why it wasn't added initially and why it currently isn't a key point for the intended purpose of the Specs.

[Uhuru]

For some reason the newly added 1440x900 resolution appears at the bottom. Not sure how that can be fixed so I'll leave that to you.

 

I was also going to suggest adding the >2560x1600 option up.

 

Also, I'd definitely get rid of the uncommon resolutions which 99% of people out there won't be using. There are too many variations to even list and some resolutions don't even exist as native screen resolutions.

 

I'd say a standard list would have:

 

1024x768 (4:3)

1280x720 (16:9)

1280x1024 (5:4)

1366x768 (16:9)

1440x900 (16:10)

1600x900 (16:9)

1680x1050 (16:10)

1600x1200 (4:3)

1920x1080 (16:9)

1920x1200 (16:10)

2560x1440 (16:9)

2560x1600 (16:10)

Eyefinity/NV Surround (varies)

 

Anything else is REALLY uncommon. Unless I missed something obvious.

The resolutions that were initially added were based on what was available in the selection. There are going to be some additional choices based on monitor selection (as evident by the missing 1440x900 for example).

 

Point is, if it's available for selection, it needs to be there, regardless of how uncommon it is. The one exception is multi-monitor. That is in the realm of high-end and it's less important to capture actual resolution (not to mention the choices would make the list much larger than is necessary).

As a muti-monitor user I disagree, I don't know if you know this (you probably do), with a utility called Widescreen Fixer, Skyrim can be played with multi-monitor setup and Modded with SkyUI as well.

As for making the list longer that all depends what is done to collect the information, for instance:

• Multi monitor question had a multi choice dropbox, with answer giving number of monitors from say 2 to 5

• Most setups will have all same size monitors, so single choice bullet selector on existing list would cover most setups
• To include variable size setups, you could add a new bullet column for each monitor or just a single variable size bullet for them all

This would cover muti-monitor setups with at most one extra row or 4 extra columns, neither option increases list length much

 

For my setup I'd select 3 monitors and the 2560x1440 bullet and job done.

 

Thats the view from realm of high-end and my resolution 3 × 2560×1440=7680×1440 is very important to me, I hate small screens these are 27 inch.

 

Never mind, I've just been to page and it's all drop boxes. I was sure I'd done this, but that looks different to what I remember. This is on Semantic Wiki I assume.

[z929669]

Agree that we should have a field for RAM. I have noticed that my RAM utilization has tripled with use of fixed ugrids by Artimor and enbboost. 8 gigs is good in my case (with 3 GB VRAM)

 

Sent from my SPH-L720 using Tapatalk