Jump to content

Marioysikax

Editor
  • Content Count

    301
  • Joined

  • Last visited

  • Days Won

    35

Posts posted by Marioysikax

  1. Job of the code tag has been to show paths, filenames, config files flag, etc. so most important part of it is to be visible to user once user opens windows explorer, opens up notepad++, changes something, etc. and gets back to webpage to look for next step. Having background color that differendiates slightly from background is almost essential if you ask me. It's basically the same as having table where every other line is slightly differend background color, so you can easily focus on what line you are on.

    Of course other possibility is to bold the text, but that would look silly when text is bolded inside black box. 

     

    Not trying to sound too harsh, but is it necessary to open up new topic on every astetic thing you have already fixed for yourself with custom CSS? Just have single topic for all the subjective matters about wikis graphical style and people can input their own opinions on the matter. Because seeing several topics dealing with graphical style with opening of "please change this" feels really negative and that you would like wiki to look just like your custom CSS. 

  2. Few problems. 

     

    First: games with settings menu seperated into many parts. 

    Best example I can think out of my head is Osu!. Graphics settings would've taken three screenshots alone and would've included my personal game information and other settings in other settings screenshots. Would've been total mess without cropping and combining. Screenshots in Metal Gear Rising: Revengeance were replaced (png with png, and replaced, not updated original file like it should be done, my files are still there and aren't even tagged for deletion) and now audio and input settings basically containg 99% of the same settings and can't be viewed directly from game article. 

     

    Second: games with tiny setting screens. 

    There can be games which have 90% of space which doesn't containg anything useful, but is there to increase image size SIGNIFICANTLY. This means you can't see anything from pages thumbnail and opening up the image will take ages. 

    One good example I can think of this is Mitsurugi Kamui Hikae

     

    You can compare yourself, cropped image found in article (37 KB) vs uncropped image (2.52 MB). 

    Now that whole main menu would repeat with all the images and glutter whole damn page! 

     

    So basically, I'm againts posting uncropped settings images if it's simply stupid, especially if only counterargument is "Cropped images look really ugly". Cropped images are usually directly viewable without opening in articles, they are much smaller to open if necessary and they focus on only the thing that's important. Especially when many games have super stylized options menus these days. And we have only talked about cropping and combining, there's no mention of altering content of the images, so even if images are cropped on pages, they should contain everything that settings menu have to offer.

     

    I will say though that some form of cropping does definitely look ugly, thus I have tried to maintain astetic beauty and possibly some visible thing to show that everything is shown in the screenshot when cropping (e.g. including settings menu borders, showing right side scroll bar, etc.). One good example is Transistor, Here's soebs original screenshot vs my screenshot when I updated all the screens in the article. They are pretty visible on article, all I did was remove complete black space around it and kept vertical resolution same so they look consistant when viewing article. Soebs screenshots did do their job of course, but must admit they looked really ugly for such beautiful game. 

     

    Of course when it comes to configuration tools, it's usually better to have whole thing, because it's in theory already cropped without anything extra and having window border does tell everything is there. And for something like Hyperdimension Neptunia Re;Birth 2: Sisters Generation where cropping would save vertical space only and not by much, of course it's not smart to crop it and whole screenshots are better. 

  3. It does make much more sense to cover third party solutions in dedicated page instead of outdated information on game pages.

     

    Speaking of first party clouds and going offtopic, when is Xbox Live Cloud going to be on the table? My solitaire already said that my data from Windows 8 has been merged and all the games are always synced to Xbox Live Cloud. The power of advertisement and microtransactions. 

  4. The only thing that I guess would extremely annoy me are 45 FPS caps (that is: a frame has 16.6ms and another 33.3ms duration).

    But hey, thanks god nobody ever use that value as a cap :p

    Ummmm.... 

    *Looks into the direction of God Mode and Spoiler Alert*

     

    Summed up. Imo.

     

    That's pretty good summ up. Even more summing up is that it's better to have 60 FPS value with "true" or "false" value than frame rate cap with wrong information or nothing at all. 

     

    And that summs up that current thing is basically the best, even if it were rushed decision which made it feel like unwanted change. 

  5. As pointed out by Mairo, we should even take into account there exists game that use vsync to lock framerate

    And that nobody forces us to use a true/false value, so we could just insert the exact maximum value and live happy.

    I also stated that they shouldn't exist, as those games are then be automatically broken with over 60Hz displays, most notable examples are Skyrim and Stealth Inc. 2. With Skyrim I can't even advance the first minute of the game because of kilometer long horses and carts rolling hundred times a second - which should be on rails and shouldn't fail. With Stealth Inc. 2 everything runs over double the speed making game much harder. (Sine Mora had this issue, then they introduced cap which broke speedup mechanic of the game and never fixed it nor gave possibility to downgrade to earlier version of the game, so thank you devs!) And with all of the cases I have linked to FPS capping section of FPS article to guide the capping process instead of writing it over and over again. Also been removing changing monitor to 60Hz because of side effects it produces, especially on cheaper end of displays and it's also mentioned in FPS capping.

    Then there are tons of similar issues, but other way around, where game enables cap only if vsync gets disabled. Many Unity games do this and they still work just fine with higher frame rates but require vsync to be enabled from the game. (THIS is why I don't like people with 60Hz monitors editing this part when they can't fully test it and only see 60 FPS value with and without vsync)

     

    Problem with "exact maximum value" is that if game indeed has vsync forced on, that maximum value for most would be 60 FPS. Of course it can be disabled from GPU control panel, but I'm sure most will not do that to find out will the game run faster than their monitor can show it. If game is new, almost nobody has powerful enough rig to actually get to that maximum value, with some cases it's unlimited, but with some it may be something like 200 or 1000 (yes, I have gotten to few 1000 FPS capped games). At this point I will argue that current system works for now, because it's really easy for anyone to check does the game get to 60 FPS mark and that will be more useful to some that high frame rate value was. After that, it's easy for those with high refresh rate monitors and powerful rigs to see how far does the frame rate get, so 120+FPS field will firstly give guideline to does the game support over 60 FPS values at all and then notes section can be filled with extra info if/when something like frame rate cap field is introduced. 

     

    EDIT: I'm still in favor of having input lag and/or frame rate cap field instead, but it would limit significantly who would be able to edit that field and most likely have false information all the time. I remember HFR field being unknown most of the time. It would be neater looking though if 60 FPS field was hidden if 120+FPS was true and 120+FPS would be hidden if 60 FPS were false. 

     

    EDIT2: If you meant "vsync to lock framerate" games that have forced vsync? Then it's vsync value, if it's false it means there's no option to toggle vsync and I have always written "Always enabled." if it's forcifully always on. I just remembered that because with vsync, some games do get really irritatingly high input lags when I play with my 60Hz plasma. This is why I was in favor of soebs idea of having input lag field but again, I'm sure there aren't many to be willing to measure such things. BUT with those cases they are simply forcing vsync, not capping the frame rate with vsync. And we do have vsync as part of graphics table. 

    Also would like to point out your example of person owning 144Hz monitor, I'm just fine with whatever frame rate game plays, though usually opt to use my plasma with 30 FPS games. It just means I get far less tearing. With Gsync/Freesync even 120 FPS cap is usually fine. 

  6. Was the new design never tested on anything else other than Chrome and Mac? The font rendering looks completely different on Windows. Some elements are pretty much broken on Firefox.

    Well, it was publicly available to be tested by anyone for good month. Font rendering does look bit differend, but not worse. Maybe pixel or two larger font would've been nicer though. 

     

    The main page isn't being rendered correctly for me at all though, or at the tables not supposed to be aligned?

     

    This is what it looks like without my fixes.

    There should be ads placed there if you aren't logged in. (and according to screenshot you aren't)

  7. Also for simple byte replacement, creating a program which does just that should not be a problem. 

    I though so as well, but some (most) cases there aren't automatic patchers available and sometimes it's indeed red flagged (Burnout case, Personally had false flag with only Microsoft Windows games autopatcher). 

     

    What I'm aiming for is basically some unified way for these kind of cases, where executable needs to be modified. If sharing executables is fine, then it makes matters much simplier for many users, but I feel like simply telling to hex edit stuff may be too much for some. I though that xdelta would be pretty viable solution as 1. any user can do them 2. they all work same way and also with Unix based systems 3. we can then have one article for instructions and automatic script which could be easily modified for any game and bundled with the patch. 

     

     

    This thread is in some sense a duplicate of this

    Somewhat, yes, as I already brought xdelta up there. 

     

    And password protected archives should be banned by law. 

  8. There was discussion at IRC about sharing modified game executables, it basically got started with Batman Arkham Asylum, here's the edit.

     

    I don't have logs about the discussion, but basically it boiled down that it's far better to simply instruct that to user instead of sharing automatic patchers which are almost always falsely flagged with AV softwares or sharing directly modified executable which basically contains copyrighted material - even if DRM is intact and user can't do anything with it alone, it's better to play safe. 

     

    Because of this I though that using xdelta would be great way to bypass this. No executables are shared, no false AV alarms. I did make xdelta patch with (supposedly) working windows batch file for Batman and uploaded it into files section, though it's still not approved. I've been using xdelta few times as translation patches for console games use this quite often. 

     

    ~couple weeks ago, this happened. It's link to modified executable with those hex values edited. 

     

    So basically, what is official stance on sharing modified game executables here? Of course hex editing should be more than OK, but I'm sure there are some users preferring far easier methods, see killer is dead article earlier. 

  9. If game doesn't require keyboard or mouse to play fully, then it automatically supports big picture, so I guess it's good addition to keep there. 

    Though if game requires big picture to be fully controller with controller (outside inviting friend to game which opens steam overlay on steamworks titles) then it should be false. Though haven't bumped into that kind of game yet. 

  10. ...but is controller sensitivity a thing? I can't think of any games that offer me any options there. I'm guessing this refers to triggers/sticks?

    It most definitely is! If it wasn't some games would be painful to play, Splatoon is one example where I had to set sensitivity to max or else motion controls and stick speed would've been too slow for someone accustomed to mouse. It's mostly for first/third person games, so that's why it may be bit obscure thing to PC gamers as you would play those games with mouse. 

    I can count many console games, but on PC I'm sure at least CODs and CS:GO offer this, later one even has seperate sensitivy for X and Y. 

     

    With other games bigger issue is usually deadzone. Most games are just fine if user has decently working controller without wonky sticks (glad we have come far from N64 controller sticks on that front), but some games have zero deadzone or too large deadzone making game bit nightmare'sh. I have stumbled to few games which slowly started to move camera and reason was that plugged XInput controllers right stick was under millimeter off from center position. 

  11. I can agree on the part that adding keypoints of the game not working under Windows 10 pretty stupid. 

     

    Problem is that those "patched executables" are basically No-CD patches, which remove DRM completely. Distributing regular untouched game executables is already pretty bad idea, sharing those executables with DRM removed becomes really bad idea. I was talking about xdelta possibility on IRC channel while back about this, but it would still be xdelta patch with info for removing DRM from untouched executable so it would still fall under super gray area. I though this would be neat idea as translation and undub patches on consoles use this, but difference is that those patches only contain changed game data, while this is for removing DRM. 

     

    I'm still thinking about making and sharing xdelta patches for games that require minor hex editing (Killer is dead, Batman: Arkham Asylum, Microsoft Windows games) as automatic patchers are usually red flagged instantly with antivirus software (like seen in Burnout Paradise case) so xdelta would be super easy solution for this that won't require user to use hex editor or download and install extra software. 

     

    This is indeed really stupid thing that some games would work without any problems under Windows 10 if DRM is removed. As No-CD patch basically makes the game work it should be at least mentioned on game article though... 

  12. I still would like if it was optional when used on the blog or on any pcgamingwiki.com pages.

    Don't see much of a point of it being optional. Also it's only and overlay on the edge of the image, so it shouldn't ruin anything. 

    I would almost say that it should be bit bigger as I didn't even notice that at first glance! 

  13. - rebrand to PCGamingWiki for anytone to create their own fullscreen/embeddable comparison slider, e.g. compare.pcgamingwiki.com

    Oh yes! I have been using screenshotcomparison up to this point because it's easy to use, but it's supposed to be used with movies. 

     

    A zoom-lens like feature, I did it myself anyway manually. Just scroll to the last images. I think it would probably get a bit too wonky anyway, I'll just manually edit this in. (kinda sleepy right now, sorry for repeating myself so often)

    That would be neat for harder to spot graphical differences. Some checkbox to enable magnifying glass for cursor would be most ideal.

  14. ​This isn't about improving the source code yourself, someone else can and will develop software for others to use. For example the screen capture tool FRAPS would greatly benefit from going to FOSS, the program hasn't been updated in two and a half years but the base is strong.

    Also, open source software rarely contains malware, ads or tracking because people can and will built the program from the source after checking it's validity and remove unwanted components if they so desire.

    At that point, I would say bigger point would be that program isn't updated in years, instead of it not being foss. They are still selling the product, so in their eyes of course open sourcing it would seem bad at least at the moment. Also that if program isn't updated in long time, userbase will slowly move away when there's newer, better and more modern alternatives available. Just shame with many cases it seems to be bandicam for some bloody reason... 

     

    I would say that if there are several similar programs available, where one is open source, It's good to be noted. That's the reason why I use 7zip over winrar personally, rar is awful format in that front. But having negative note on every proprietary program would simply be insane. I would also say that programs like steam are in state they basically can't be open sourced and there can't be alternatives. 

  15. I would say yes, but blackbird is right that end user simply doesn't care. For them it's question of is it free or paid software. But that can't be negative point either as paid version can offer more or something else than free does, e.g. most games are for windows, even if it is proprietary software, it makes playing games easier even if linux would othervice be better option for the user. I'm also fairly sure that people are aware that something like steam isn't exactly open source either. 

     

    BTW it's proprietary not Propriety or propietary :P

    English is haaard language. I can't even pronounce that word without help. 

  16. Most people do not even know that they can hover on the CN template to get more information, and the CN template is for refs for the most part anyway.

    Well, if something needs checking, then I would argue that it's good to have some sort of reference, either external site or who has tested it, when and with what, so there won't be situation where someone simply removes CN tag and question is left hanging in the air. Even if CN comment isn't visible in the page, it still says "reference needed" which should already be really informative and when editing comment should be more than visible even without hovering. 

     

    I would say it would be better to have some kind of "tested by nickname" in editing mode templates, so it would be easier to click something to get reference inserted with your name and date. For some reason mediawikis basic ~~~~ works in page, inserting editors name and date, but refuses to work within ref tag leaving it as ~~~~.

  17. You don't get this when you search for the page? The red link.

    unyaSvV.png

    New users need to wait for awhile and do few edits before they can create pages. 

    I have created the page with basic layout and steam ID in place: http://pcgamingwiki.com/wiki/Cold_Fear

     

    E: oh, MOJ has already been editing a lot. Anyway, that article is now created. Searching and clicking red link is the easiest way. I have also been using enhanced steam linking trough steam. 

  18. DInput dates back to DX8 so it's pretty much uncommon and mostly dead. Sony did a bad thing by making DS4 DInput only. Shows how much out of touch they are sadly.

    Yes we did and I still disagree it's useful for anything, but niche input devices.

    So what is the point? Why bother mentioning DInput when barely any users need it unless they cling to their ancient controllers for no reason. DS4 users will use XInput wrapper anyway unless they want to play only few games that support it natively.

    PS3 accepts all and every DirectInput controller you put into it. That's why e.g. logitech controllers still have that switch instead of being fully XInput. I actually have Xinput-to-DInput converter there just because of that. Then most of the converters for older controllers like Dualshock 2 and Gamecube are usually DirectInput, so it's still used in places where XInput can't be used (missing buttons or having more buttons and features). 

    I'm guessing reason was because XInput is basically Xbox standard which microsoft simply ported over to PC and for same reason they "buried" DirectInput. 

     

    Lately I have been abandoning my wired 360 controller because Dualshock 4 works surprisingly well 99% of the time without any extra software or wrappers. Steam nowdays wraps the inputs if game doesn't support it. To me it feels more like because XInputs control bindings don't vary that it has been simply easy way to implement controller compatibility for games and it does seem like DS4 has become second standard for controllers, not just DirectInput. 

     

    Only problem with DirectInput I have seen is that button mappings aren't standardized so devs use XInput as excuse to be lazy. 

     

    Xpadder/Joy2Key are evil. Analog axis become a mere 0/1 this way.

    Everybody should try to avoid them as much as possible.

     

    Then I'm not really caring whether one or the other API is more used. I'm beating for everything to be supported.

    And I'm very sad when I read about "niches" being snubbed.

    Tbh I don't actually see any handicap in playing with DI controllers.. You'll have to configure them perhaps, but that's it.

    I have been saying the same thing on so many steam game community forums I'm almost done with it. Other one is that people are still suggesting MotionInJoy to use with Dualshock 3. 

     

    That's also pretty well said, as with PC gaming there are and will be those niche setups. That's why there isn't WiiUGamingWiki. 

  19. ...and since DirectInput has been depreciated for years, naturally nearly every new controller has a XInput driver. Which kind of leads me to a question: do we have a centralized page for XInput? I searched the past few days and didn't find much other than a page with workarounds for the R2/L2 thing, but it was deeply buried in the search results. I'm assuming just an XInput page andhave a near-noob-proof statement to start it out.

     

    Also, as a point: right now basically we state the API support under the controller support field as a note right? I'm not sure what the best practice is for that - either that or an ii above the table. Thanks for the testing link BTW.

    After Dualshock 4 got released, more and more games are supporting it directly and adding support for generic DirectInput as well. Even if it's depreciated it's still alive and kicking. Actually looking at XInput limitations compared to DirectInput, it's impossible for XInput controller to have any more or less buttons than regular 360 controller and windows always states the controller as 360 controller despite the model. So I would say simply use 360 controller article for XInput related stuff, then link to it from third party XInput controllets. 

     

    I was unsure where to put the info about API, after I put it into API tables input field, someone corrected me to put it into input sections controller note. 

     

    When I put up "controller recommended" key note, I always explain the stuff in Input section of the page and link to it. One really good example is Fairy Bloom Freesia article, which states obvious things and then it's up to user do they want to use controller or not. Game only showing controller button prompts isn't good enough reason and I always put it as negative point in input section. 

  20. Ratchet is right that earlier thing was working as it also basically stated 60 FPS, only problem was that there wasn't easy way to collect this information if I'm correct. But now that it's 60 FPS field then other field becomes significally more pointless but still required. So I'm still in favor of turning it into FPS cap field which is hidden by default as majority has 60Hz monitors so they most likely only care about 60 FPS, those wanting unlimited frames or have 144Hz monitor want to know about FPS caps in the game have the other field. This would also make it easier to state e.g. physics, character or camera being locked to certain frame rate as then it has it's own note field. 

     

    It's almost like with resolution there's widescreen and 4K. 

  21. Input/Frame delay would be super sweet, but I can imagine that being super hard to measure(?) 

    Frame rate capping does sound like more proper thing now that 60 FPS is a thing. After all if there is some kind of hard cap, then usually HFR is false as well and most HFR fixes are for raising or disabling FPS capping. So HFR kinda already was frame rate capping option to some degree. It would be also bit more describeable for wider range of people and not only for 120/144Hz monitor owners at that point. 

     

    Hard cap = false, optional cap = true and mention how large cap, hard cap which can be manually changed = hackable. 

    At this point partial value would be nice again, if game forces the cap and only give certain amount of caps which are under 120 FPS. 

     

    Sigh. With this recent change the FPS part of the video setttings in a lot of articles now make no sense

    How so? I see almost every page have 60 FPS as unknown right now. 

  22. So I think I found the list from the see games with high frame rate support link on the http://pcgamingwiki.com/wiki/Glossary:Frame_rate_%28FPS%29 page and changed it from 'true or hackable' to 'false'. Is there a way to also show the High Frame Rate Notes field in that list too?

    Was just asking about this, because right now HFR tag means game is locked to lower than 120 FPS and if it's other than 60 FPS then it's noted and if it's lower it's keynoted as well. 

×
×
  • Create New...