Jump to content

PCGamingWiki will use a Single Sign On (SSO) system to bridge wiki and forum accounts which is ready for testing. You may login using the 'Login with PCGamingWiki' button on both the wiki and the forum, which will soon be the only option. If you have any issues please message Andytizer on Discord.

Marioysikax

120hz, Unreal games and SmoothedFramerate

Recommended Posts

Those who has >60hz monitors want information does game support their display. One thing that has been bothering me is that many Unreal games like to use bSmoothFrameRate with value of 62 which gives best quality with regular 60hz monitor but caps the fps. 

Problem is that all the games that use it has fix in article but they are all said in differend ways and on differend sections! Here's only few examples: 

http://pcgamingwiki.com/wiki/Mass_Effect#120Hz

http://pcgamingwiki.com/wiki/Sanctum_2#Essential_improvements

http://pcgamingwiki.com/wiki/Batman:_Arkham_City#120Hz

 

I was thinking as they all seem to be solutions to exact same problem with exact same engine should we just make generig fix to 120hz page and just link to it instead of re-writing solution differendly again as it's games config directory, Xengine.ini with X replaced with games ID and same values.

Share this post


Link to post
Share on other sites

I was thinking as they all seem to be solutions to exact same problem with exact same engine should we just make generig fix to 120hz page and just link to it instead of re-writing solution differendly again as it's games config directory, Xengine.ini with X replaced with games ID and same values.

I think it would be better to leave them in game's specific pages, even if this means a lot of copy-pasting of exactly the same solutions (asuming people test them, first). Some Unreal games encrypt their config files and I could almost bet there are some Unreal games where going beyond 62fps is going to break some elements of physics, AI behaviour or whatever. Forcing something from graphics driver panel is pretty much the only exception, I'd like to see so far. But this (frame smoothing), DxWnd and similar, I'd prefer having properly described for each game separately - especially if the solution takes only like 3 lines.

 

That's my opinion about it so far - I have not bumped into any issues with a page describing 120Hz and how to disable framerate limit. My biggest common problem so far is modifications section and how often they make getting to video settings section difficult via scrolling.

Share this post


Link to post
Share on other sites

I think it would be better to leave them in game's specific pages, even if this means a lot of copy-pasting of exactly the same solutions (asuming people test them, first). Some Unreal games encrypt their config files and I could almost bet there are some Unreal games where going beyond 62fps is going to break some elements of physics, AI behaviour or whatever. Forcing something from graphics driver panel is pretty much the only exception, I'd like to see so far. But this (frame smoothing), DxWnd and similar, I'd prefer having properly described for each game separately - especially if the solution takes only like 3 lines.

 

That's my opinion about it so far - I have not bumped into any issues with a page describing 120Hz and how to disable framerate limit. My biggest common problem so far is modifications section and how often they make getting to video settings section difficult via scrolling.

I agree. Also some games (e.g. Deadpool) have hardcoded frame rate cap. And this method does not work with them.

Share this post


Link to post
Share on other sites

That's my opinion about it so far - I have not bumped into any issues with a page describing 120Hz and how to disable framerate limit. My biggest common problem so far is modifications section and how often they make getting to video settings section difficult via scrolling.

I think we may want to discuss moving modifications to the "Other information" section, especially since they seem to get very large very often. Although, that's somewhat irrelevant to this thread.

 

What I'd recommend doing is adding a section to the Engine:Unreal article which has a general overview of this. Keep the separate versions for each page, but also leave a note on each of those sections that says "For more information, see the Unreal Engine article." or something similar. This is what I do with Source engine games.

Share this post


Link to post
Share on other sites

I think it would be better to leave them in game's specific pages, even if this means a lot of copy-pasting of exactly the same solutions (asuming people test them, first). Some Unreal games encrypt their config files and I could almost bet there are some Unreal games where going beyond 62fps is going to break some elements of physics, AI behaviour or whatever. Forcing something from graphics driver panel is pretty much the only exception, I'd like to see so far. But this (frame smoothing), DxWnd and similar, I'd prefer having properly described for each game separately - especially if the solution takes only like 3 lines.

 

That's my opinion about it so far - I have not bumped into any issues with a page describing 120Hz and how to disable framerate limit. My biggest common problem so far is modifications section and how often they make getting to video settings section difficult via scrolling.

Well then we should at least have some kind of source/example to copy-paste from? Some pages have it as "essential improvement", some tell you to disable the option completely, some tell you to raise the value to 120 which isn't working with 144hz monitors and so forth. 

Should I just manually go, edit one page perfect and then just copy paste that to every single game that uses this fix?

 

I agree. Also some games (e.g. Deadpool) have hardcoded frame rate cap. And this method does not work with them.

I was specifically talking about unreal games that has smoothed framerate enabled with value of 62 and plain text ini files as there are tons of those and they all have literally same solution. 

 

E:

I think we may want to discuss moving modifications to the "Other information" section, especially since they seem to get very large very often. Although, that's somewhat irrelevant to this thread.

 

What I'd recommend doing is adding a section to the Engine:Unreal article which has a general overview of this. Keep the separate versions for each page, but also leave a note on each of those sections that says "For more information, see the Unreal Engine article." or something similar. This is what I do with Source engine games.

Well that sounds just perfect solution! BUT we still need some example to copy-paste that solution from as now everyone seems to be making their own versions of the solutions which may not work as intended for everyone.

Share this post


Link to post
Share on other sites

Well that sounds just perfect solution! BUT we still need some example to copy-paste that solution from as now everyone seems to be making their own versions of the solutions which may not work as intended for everyone.

 

I'm tired and have been editing Wikipedia lately (everyone there is a horrible person, we weren't even testing for that) so I may be mistaken, but is that sarcasm or do you legitimately like the idea?

 

Anyway, I think if we made an "Issued fixed" or what-have-you section on the Unreal Engine article as I suggested, we should be able to copy-paste it from there and then modify it on a per-game basis.

Share this post


Link to post
Share on other sites

Well then we should at least have some kind of source/example to copy-paste from? Some pages have it as "essential improvement", some tell you to disable the option completely, some tell you to raise the value to 120 which isn't working with 144hz monitors and so forth. 

Should I just manually go, edit one page perfect and then just copy paste that to every single game that uses this fix?

I'm assuming a lot of the pages which list this under essential improvements, are pages that were written before we had 120Hz solutions. I'd actually be with the idea of having one fix and copying it other pages, to be honest - especially, that I'm not native English speaker, so having a text ready on the page related to engine, which requires to copy the text and only change paths a bit would actually be extremely helpful.

 

 

 

I think we may want to discuss moving modifications to the "Other information" section, especially since they seem to get very large very often. Although, that's somewhat irrelevant to this thread.

Yes, that's what I've been thinking as well and I even did that for like 2 pages. But obviously - the discussion will require additional thread.

Share this post


Link to post
Share on other sites

I'm tired and have been editing Wikipedia lately (everyone there is a horrible person, we weren't even testing for that) so I may be mistaken, but is that sarcasm or do you legitimately like the idea?

 

Anyway, I think if we made an "Issued fixed" or what-have-you section on the Unreal Engine article as I suggested, we should be able to copy-paste it from there and then modify it on a per-game basis.

That's seriously best idea, sorry if I sounded sarcastic as I'm not native english speaker >_> (also lol @ portal joke)

So we (or I or someone) just make perfect version of fix to engine page and then manually copy-paste it to game pages with link to engine page. 

 

E: One thing I haven't found perfect answer is that if you actually raise smoothing value should you put it exactly the same as refresh value or 2 higher like it defaults with 60hz monitors in mind? 

Share this post


Link to post
Share on other sites

Having a sample on the Engine: page is a good idea but it should only be copied onto game pages where it is already present or is known to work since there exceptions to this as already mentioned.

 

The section definitely needs some standard name and position. I've been thinking about renaming 120Hz to encompass 144Hz and also be a standardised section name for uncapping, maybe something like "High frame rate (120Hz/144Hz)". Unacceptably low default caps (anything below 60 FPS) would still be a key point as always.

Share this post


Link to post
Share on other sites

That's seriously best idea, sorry if I sounded sarcastic as I'm not native english speaker >_> (also lol @ portal joke)

So we (or I or someone) just make perfect version of fix to engine page and then manually copy-paste it to game pages with link to engine page. 

 

E: One thing I haven't found perfect answer is that if you actually raise smoothing value should you put it exactly the same as refresh value or 2 higher like it defaults with 60hz monitors in mind? 

In my opinion the default fix would be to completely disable it.

Then, if a game use some weird physic engine -which screws gravity if simulation run above 60 FPS- we could note that. But those would be exception (goddamn you, Dead Space)

 

Actually, the correct row name should be "frame cap" instead of "120hz". Since 100% of times, I haven't seen issues with the refresh rate itself, but rather with the limiter

If I had a 120hz then (provided that the game is high-framerate friendly) I would still keep off the framerate limiter.. why should I enable it?

 

And I would also like further references about the "reports of game crashing" (in the Mass Effect article)

 

Also, I really dislike who use frame limiting as vertical sync, and who use vertical sync as frame limiting

Share this post


Link to post
Share on other sites

Having a sample on the Engine: page is a good idea but it should only be copied onto game pages where it is already present or is known to work since there exceptions to this as already mentioned.

 

The section definitely needs some standard name and position. I've been thinking about renaming 120Hz to encompass 144Hz and also be a standardised section name for uncapping, maybe something like "High frame rate (120Hz/144Hz)". Unacceptably low default caps (anything below 60 FPS) would still be a key point as always.

Well of course it would be applied only the games that the fix works. Thing was there's many of those games ::)

Yeah, 120hz is most common used but 144hz seems to be new standard and there's even 240hz monitors available. Then you have games like Payday which allows cap to be increased up to 135 which works with 120 but is under 144... Maybe just "High frame rate" would be good enough and comment is it limited to certain amount (many games also use 91 especially with online play) or is game completely uncapped.

 

In my opinion the default fix would be to completely disable it.

Then, if a game use some weird physic engine -which screws gravity if simulation run above 60 FPS- we could note that. But those would be exception (goddamn you, Dead Space)

 

Actually, the correct row name should be "frame cap" instead of "120hz". Since 100% of times, I haven't seen issues with the refresh rate itself, but rather with the limiter

If I had a 120hz then (provided that the game is high-framerate friendly) I would still keep off the framerate limiter.. why should I enable it?

 

And I would also like further references about the "reports of game crashing" (in the Mass Effect article)

 

Also, I really dislike who use frame limiting as vertical sync, and who use vertical sync as frame limiting

That may be the main problem as people don't seem to know which is actually better: completely disabling the smoothing or just raise it to match closer to monitors refresh rate? Some even suggest just raising cap to 999! :D

What I usually seem to find is that solid number on fps counter is far better than jumping uncapped one. That may also be the reason why so many devs but that "cap" in there in first place! Uncapped fps may sound like wonderful idea but usually it's actually worse. Also smoothing isn't cap as cap only locks framerate to certain number where smoothing tries to minimize spikes and smooth out gameplay overall. 

What I would do is to place smoothing value raising as main fix included in game specific pages and then linking to engine: page which also includes more depth explanation (if even needed) and disabling cap fix.

 

Most data on internet is inaccurate and said by random guys who got it working by editing config file and there's no solid data on which actually is the best. I guess that's just the case as higher framerate monitors aren't that usual.

 

As with Mass Effect page that crashing was edited by Tmpltd and then just carried over with edits. He's also the one that made the value 120 for some reason and added note about mod clipping audio and longer loading times so it may have been just him messing his computer. I can't find any evidence game actually crashing just because of this. 

 

I made first version of the fix. I would would love if someone ironed out spelling errors as said I'm not native english speaker <3

Share this post


Link to post
Share on other sites

I agree with changing 120Hz to High frame rate (HFR). It should not be for 120/144Hz users only, there are some users who hate playing with v-sync/frame-rate cap.

Also I would like to note that there are several methods for capping the frame rate. Or for vertical sync. Personally I use adaptive v-sync by NVIDIA whenever possible. If v-sync has some issues with a particular game then I active framerate limiter on NVIDIA Inspector.

Share this post


Link to post
Share on other sites

Thanks nicereddy for grammar correction! :3

There seems to be 27 games which has listed this as fix and I'm sure there's more. What I have researched that smoothed value should be little over refresh rate rather than exact number as it's smoothing instead of hard cap, games "capped" with this method to 30fps also has value of 32 in smoothing so this strengthen the fact. If screen tearing is visible games vsync should work or just force vsync/cap other way as smoothing is there to just - well - smooth instead of syncing or capping. As for crashing issue mentioned in Mass Effect page seems to be related to making config "read only" mode and it's also mentioned in Lost Planet 3 but then Warp seems to need it because of Origin file syncing. References are missing with all the cases so it's really hard to investigate especially when I do not own all of those games. I'm not sure why people put it in "read only" as games usually won't change that value unless you completely remove config file when game regenerates/copies new one. 

 

I'll just add note about "read only" crashing with {{CN}} but otherwise at least for me fixbox seems pretty fine now.

Share this post


Link to post
Share on other sites
That may be the main problem as people don't seem to know which is actually better: completely disabling the smoothing or just raise it to match closer to monitors refresh rate? Some even suggest just raising cap to 999! :D

What I usually seem to find is that solid number on fps counter is far better than jumping uncapped one. That may also be the reason why so many devs but that "cap" in there in first place! Uncapped fps may sound like wonderful idea but usually it's actually worse. Also smoothing isn't cap as cap only locks framerate to certain number where smoothing tries to minimize spikes and smooth out gameplay overall. 

What I would do is to place smoothing value raising as main fix included in game specific pages and then linking to engine: page which also includes more depth explanation (if even needed) and disabling cap fix.

 

Most data on internet is inaccurate and said by random guys who got it working by editing config file and there's no solid data on which actually is the best. I guess that's just the case as higher framerate monitors aren't that usual.

 

Well, I must have done the limiting FPS and forcing v-sync page for something!

And I would like to underline another time that's very stupid to use v-sync when you want to limit FPS and viceversa.. Because you are achieving the worst of both worlds

Limiting= Tearing can still be seen, but you have no delays, no additional stuttering

V-sync= Fix tearing. Framerate is choppy most of times if you don't enable triple buffering. Input lag

 

Btw, I think I could say it's a common opinion that framerate cap/smoothing reduce stuttering.. but how you said: what are the technical proofs?

My understanding says that w/o those things, GPU renders images as fast as it can.. If everything goes well, this should be the baseline and less complex situation possible.

Still, I would be pleased to be corrected..

 

EDIT: ok, the idea just comes to my mind. What if when you limit framerate, your computer has more time to prepare the following? It's against the KISS principle.. but do you know if somebody use this in their game engines?

 

EDIT2: are there any games which doesn't allow 120hz screen refresh rate?(≠frame per second)

This would be the only case when 120hz row name would still be accurate I suppose..

Edited by Mirh
added triple buffering link

Share this post


Link to post
Share on other sites

Well, I must have done the limiting FPS and forcing v-sync page for something!

And I would like to underline another time that's very stupid to use v-sync when you want to limit FPS and viceversa.. Because you are achieving the worst of both worlds

Limiting= Tearing can still be seen, but you have no delays, no additional stuttering

V-sync= Fix tearing. Framerate is choppy most of times if you don't enable triple buffering. Input lag

 

Btw, I think I could say it's a common opinion that framerate cap/smoothing reduce stuttering.. but how you said: what are the technical proofs?

My understanding says that w/o those things, GPU renders images as fast as it can.. If everything goes well, this should be the baseline and less complex situation possible.

Still, I would be pleased to be corrected..

 

EDIT: ok, the idea just comes to my mind. What if when you limit framerate, your computer has more time to prepare the following? It's against the KISS principle.. but do you know if somebody use this in their game engines?

 

EDIT2: are there any games which doesn't allow 120hz screen refresh rate?(≠frame per second)

This would be the only case when 120hz row name would still be accurate I suppose..

There are some games yeah. Usually if a game supports 120Hz it also support 120 fps as well. But some games do not. You can easily see it by using FRAPS. It shows refresh rate as 120, but frame rate is capped around 60 fps.

Besides triple buffering there is also an adaptive v-sync option for NVIDIA cards. Personally I like it more than triple buffering.

Share this post


Link to post
Share on other sites

There are some games yeah. Usually if a game supports 120Hz it also support 120 fps as well. But some games do not. You can easily see it by using FRAPS. It shows refresh rate as 120, but frame rate is capped around 60 fps.

Besides triple buffering there is also an adaptive v-sync option for NVIDIA cards. Personally I like it more than triple buffering.

AMD users have something similar too (via RadeonPro) :p

Anyway, I think I don't care about v-sync cause my monitor is quite quick refreshing pixel (2ms GtG) (shitty colors though)

 

When I connect the computer to the 32" TV, tearing is terrible

Share this post


Link to post
Share on other sites

There are some games yeah. Usually if a game supports 120Hz it also support 120 fps as well. But some games do not. You can easily see it by using FRAPS. It shows refresh rate as 120, but frame rate is capped around 60 fps.

Besides triple buffering there is also an adaptive v-sync option for NVIDIA cards. Personally I like it more than triple buffering.

Actually Hz and fps gets mixed up a lot as they usually mean same thing with you seeing 120fps so it means 120 frames per second which means it's shown with 120Hz monitor. 

Only game I actually needed vsync was Dead Space as it had massive screen tearing in areas with blinking lights even with 144Hz monitor but vsync messed everything up. Adaptive vsync actually worked and there wasn't any problems that were related to vsync. 

 

As for main problem I think it's now pretty much solved as it clearly states how to get the game working and there's alternative solution and extra info linked. 

E: What I noticed that many pages actually re-write games config path to fix itself instead of linking it. Isn't this bad especially with games that have mac version or goty edition?

Share this post


Link to post
Share on other sites

Actually Hz and fps gets mixed up a lot as they usually mean same thing with you seeing 120fps so it means 120 frames per second which means it's shown with 120Hz monitor. 

Only game I actually needed vsync was Dead Space as it had massive screen tearing in areas with blinking lights even with 144Hz monitor but vsync messed everything up. Adaptive vsync actually worked and there wasn't any problems that were related to vsync. 

 

As for main problem I think it's now pretty much solved as it clearly states how to get the game working and there's alternative solution and extra info linked. 

E: What I noticed that many pages actually re-write games config path to fix itself instead of linking it. Isn't this bad especially with games that have mac version or goty edition?

Even if they got usually mixed up, we shouldn't confuse the steady monitor refresh rate with the variable number of frame for second. (what you are saying is true only with v-sync though)

And btw I feel weird the actual implementation we took (with UE games at least). We should only tell how to disable the cap there. Claiming to raise it is secondary imo, it's the v-sync that should handle the tearing.

 

And wtf? Are you claiming you hadn't any hassle with Dead Space running at more than 100 FPS ??

As soon as I exceeded the 60, game view control became a shit. And when I say this, I mean the worst ever created. Something like I had to move the mouse through the entire mousepad TWO times to turn 90° right

V-sync in that games is bugged and locks framerate at 30FPS then

 

and could you make an example of config path fixing/linking?

Share this post


Link to post
Share on other sites

Even if they got usually mixed up, we shouldn't confuse the steady monitor refresh rate with the variable number of frame for second. (what you are saying is true only with v-sync though)

And btw I feel weird the actual implementation we took (with UE games at least). We should only tell how to disable the cap there. Claiming to raise it is secondary imo, it's the v-sync that should handle the tearing.

 

And wtf? Are you claiming you hadn't any hassle with Dead Space running at more than 100 FPS ??

As soon as I exceeded the 60, game view control became a shit. And when I say this, I mean the worst ever created. Something like I had to move the mouse through the entire mousepad TWO times to turn 90° right

V-sync in that games is bugged and locks framerate at 30FPS then

 

and could you make an example of config path fixing/linking?

I was just thinking it from perpective of regular user but you are right at that one.

 

I still don't see smoothing as cap. Smoothings job isn't to cap or vsync but to smooth out jumping framerate, you can still cap and vsync after smoothing if you want to. I usually put game settings that they run minimum of 60fps so it may go anywhere over 60fps. If I disable smoothing it's clear when game fps goes down fast where with smoothing on you actually have to look at fps meter to see it. So when you are playing the game you won't focus on how framerate goes. To summarize smoothing is actually even more vital with over 60Hz monitors if your computer doesn't have power to output every frame to monitor. For those with 4x Titan rigs it's fine either way but for regular gaming PC it's usually better to go with smoothing instead of lowering settings to look like console game. 

This is also why smoothing removing fix was listed under engine page so if someone want's to remove there's tutorial for it and if same person runs into same problem at another game (s)he already knows how to do it then. Of course this is just what I have tested and googled, I linked best source I found as reference on engine page. It's still pretty easy to just change the fix and I won't update it to games I do not own. 

 

Dead space worked fine with disabling vsync entirely and then turning mouse speed to 2.00 from config. With vsync mouse was unusable and loading times were huge. Like said only problem was flashing lights so I turned on adaptive vsync and everything still worked. It has been some time but I can test it again just out of curiosity. 

E: Yeap. Perfectly playable with adaptive vsync and 144fps.

 

OK most recent example coming to mind is Batman Arkham Asylum, which has Windows and Mac versions available. There doesn't appear to be much Mac gamers though as config directory for mac is missing. Still point is that there's config file listed at the top of the page. When you scroll down every fixbox tells user to "Go to %USERPROFILE%..." even if user used Mac. I don't know how steamworks conversion effected config files but at least there were non-GOTY edition purchareable and Mac still has. For me it sounds fix should link to top of the page instead of rewriting config path over and over again especially when it doesn't apply to every version of the game.

Share this post


Link to post
Share on other sites

OK, I think I found. some. references for our debating

I see your points. My simple opinion would be more in-line with this man, but i understand how game developers seems to have invented this weird thing called frame render ahead.

 

But I have never experienced such "spike lags" like those tweakguides talks of btw

An agreement on both fronts could be this (quote from HARDOCP article)

 

[...] graph is quite clear, with the bSmoothFrameRate option enabled framerates are smoother, but it can hardly be called an improvement in overall framerate performance. The whole point of such frame-limiting features is to keep CPU time available for other tasks, such as audio, network, input, and physics. If we were limited in such tasks by our CPU, we may consider this option useful, but we are not so limited

 

Advising to raise the framerate 2+ more than your refresh rate for example..... and so on is too longwinded for the common, noob user

A link to the detailed UE3 smoothing explanation would be better

 

btw my testing with dead space revealed that mouse speed never changes under 60FPS.. then, the double the framerate the half the sensitivity

Yes, you can hack the configuration file, but as the framerate flutter, you'll have you'll have different mouse feedbacks..

 

And you are right, linking to #configuration files should always be preferred

 

 

EDIT: Look at Mass Effect page. Do you think this could be a nice compromise?

Share this post


Link to post
Share on other sites

OK, I think I found. some. references for our debating

I see your points. My simple opinion would be more in-line with this man, but i understand how game developers seems to have invented this weird thing called frame render ahead.

 

But I have never experienced such "spike lags" like those tweakguides talks of btw

An agreement on both fronts could be this (quote from HARDOCP article)

 

Advising to raise the framerate 2+ more than your refresh rate for example..... and so on is too longwinded for the common, noob user

A link to the detailed UE3 smoothing explanation would be better

 

btw my testing with dead space revealed that mouse speed never changes under 60FPS.. then, the double the framerate the half the sensitivity

Yes, you can hack the configuration file, but as the framerate flutter, you'll have you'll have different mouse feedbacks..

 

And you are right, linking to #configuration files should always be preferred

 

 

EDIT: Look at Mass Effect page. Do you think this could be a nice compromise?

Well this definitely turned out to be tougher thing that it looked. You may be right about the longwinded thing too. 

I'm still in favor of smoothing. I was watching that HARDOCP article image about smoothing that 30fps difference just can't be right when I got something like 1-2fps avarage difference before noticing article was from 2007. I would bet if someone owns monitor with high refresh rate they would at least have medium gaming PC which shouldn't have that much difference in frame rate. BUT that just proofs there may be someone with lower end PC and regular monitor would like to turn smoothing off and so many games default it on! 

AND that proofs that maybe we shouldn't just put one fix and link to another one so I was wrong with that. Mass effect page may be little too summed up for someone and I think link should be clearer. This way person can fix issue simply reading that box and not having to go to perfect explanation to engine page. I adjusted Mass Effect page a little with those things in mind.

 

As for Dead Space I played it like that, didn't have massive problems and was glad that second part wasn't that poor PC job :P

Share this post


Link to post
Share on other sites

OK, i made other searches today.

Nvidia cards seem never had this problem, while ATI/AMD ones have addressed their "frame pacing" issues in February

If you are really interested I even found an in-depth review of the problem

 

Would be a nice thing to understand if all those problems they had in the past were linked to this thing. This would mean finally frame smoothing is useless :p

Because like I previously said, my mind has an hard time trying to figure that waiting = faster

Share this post


Link to post
Share on other sites

  • Similar Content

    • By SirYodaJedi
      This icon is a replacement for the original 4-bit icon for Unreal Gold and Unreal 227. It uses the 24-bit Unreal Emblem.jpg from the GOG version's bonus avatars.
      Comparison: https://community.pcgamingwiki.com/gallery/album/138-unreal-gold-icon-comparison/
      Scroll to zoom Note that the original file was a 150x150 jpeg, so there will be aliasing when viewed in "Extra Large Icons" mode.
    • By Kenji Kusanagi
      This is a bundle created for the sake of playing Unreal Tournament on Linux system.
       
      It is based on Flibitijibibo's UT Linux Steam Install pack, but implemented the unofficial 451 Patch.
       
      Be sure to read the README-KayX291.txt first!
       
      The only thing you are required are the game assets which can be found by buying the game from Steam, GOG.com, Retail etc.
       
      NOTE: If you encounter any issue regarding connecting to servers that rely on UTPG's patch (Such as Multiplay ones), you have no choice but to use the Flibitijibibo's UT Linux Steam Install pack.
       
      Non-Steam users can just copy and paste the content of his pack into main game folder, but if you wish to use some of the content I've made for this patch, I have uploaded the Extras for that.
    • By Kenji Kusanagi
      This is a pack of goodies that were used for my UT Native Linux 451 Patched.
       
      It basically contains all the content from the Goodies such as:
      * Chris Donhal's OpenGLDrv
      * Loki Compatibility Libs
      * Server Creation Wiki page in text form
      * NPLoader files
       
      It also includes the "ut-fps" script and the Troubleshooting text file in case if you encounter any issues.
       
      This was made due to the fact that there is an issue regarding difficulties to connecting server which use 451 version from UTPG's. However, the mentioned version is backwards compatible with 436, which Flibitijibibo's back was made on.
    • By ThatOneReaper
      Original file: http://www.gamefront.com/files/1540908/
       
      This is the Unreal Fusion Map Pack. It is the only official map pack for the game and it is free to download.
       
      To install the maps, copy/paste the contents of download into the game installation folder.
       
      Here are the list of maps added:
      DM-Cybrosis
      DM-Twilight
      DM-Mojo
      DM-Letting
      DM-Shrapnel
      DM-Loxi

  • Who's Online   1 Member, 0 Anonymous, 78 Guests (See full list)

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Forum Statistics

    1,181
    Total Topics
    6,663
    Total Posts
×