Jump to content

Aemony

Administrator
  • Content Count

    201
  • Joined

  • Last visited

  • Days Won

    28

Aemony last won the day on May 24

Aemony had the most liked content!

1 Follower

About Aemony

  • Rank
    Supporter

Profile Information

  • Gender
    Undisclosed

Recent Profile Visitors

1,513 profile views
  1. Differences between editions themselves are usually listed under the "Version differences" header below the Availability category, see e.g. https://www.pcgamingwiki.com/wiki/Doom_Eternal#Version_differences. The reason why availability rows list editions are to highlight the different ones available for purchase on each storefront. Beyond that, game code-wise PCGW does not really keep track of versions of the game per se (v1.0, v1.1, v1.2 etc) as the article is meant to (unless stated otherwise) target the latest available version of each game.
  2. You're out in uncharted waters with too many unknown factors -- there's almost no guarantees that can be made. The general gist of it though, if even possible, is to convert the Win7 iso to a USB stick (Google for instructions on how to do so) and then boot using the USB stick and install Windows 7 on a separate partition/drive through there.
  3. Well, my strongest recommendation would be to, well, not install Windows 7 at all. But if you really have to, I imagine installing it after Windows 10 should hopefully do the trick. Although be mindful that something might go wrong and you might have to reinstall both OSes to fix it in the worst case scenario.
  4. https://social.technet.microsoft.com/wiki/contents/articles/14286.converting-windows-bios-installation-to-uefi.aspx But it's not something I'd recommend undertaking -- especially not before your new system arrives as the action can (and most likely will) make the disk unbootable on your existing system.
  5. Because of the lack of that row, I'm assuming the OS is installed in legacy BIOS mode.
  6. Is there no more rows below that? That row you've highlighted is the "SMBIOS Version" shown on the page I linked to. The actual row "BIOS Mode" you need to look for is two (or possibly more) rows below that one.
  7. Not necessarily as it could very well be that your motherboard is configured to use legacy/BIOS/compatible boot and not UEFI boot. The legacy option was often the default on older machines as well as on components sold separately. It was mostly only pre-built machines that had UEFI boot enabled by default. See this for how you can determine whether Windows 7 is booting in UEFI or legacy BIOS mode: https://docs.microsoft.com/en-us/archive/blogs/home_is_where_i_lay_my_head/how-to-check-in-windows-if-you-are-using-uefi
  8. According to the FAQ, at least 3 edits to existing pages and an account life of at least 6 hours is required before a new page or file can be created.
  9. Please clarify whether this file is from the unpatched, original ToCA2 from the CD-ROM or the patched 4.1 version.
  10. Not necessarily -- it all depends on which boot manager is being invoked, and whether that boot manager recognizes the other OS automatically or not. If it does not, you should be able to create the missing entry from the booting OS by using bootrec. There's also a possibility that your new OS is configured to use UEFI to boot, while your Windows 7 is configured and installed as legacy/"BIOS". If that's the case you might not be able to boot Windows 7 until you put the BIOS/UEFI in legacy/compatibility mode, and might or might not have to once again recreate the boot entry using https://neosmart.net/wiki/fix-uefi-boot/. So... it depends? 😄 Windows 8.x and newer uses a new boot manager (blue interface with mouse support) while Windows 7 uses the legacy boot manager (black interface without mouse support). The two can function alongside one another but I've never done so with a migrated Windows 7 install. When I dual-booted Windows 7 and 10 (as well as 8.x) I always did so by first installing Windows 7 in UEFI mode and then after that installing Windows 10 (8.x). This ensured that both OSes had full boot support while my system was running in UEFI mode and not the legacy "BIOS"/compatibility mode.
  11. We have a tiny search bar on the front page? I never use that one.
  12. This only applies to games running in classic exclusive fullscreen mode, where the fullscreen optimizations of Windows 10 aren't being used nor is the game running in (borderless) window mode. This is, to be honest, a bit of a hit or miss. HDR support is still in its infancy with various alternative methods available which affects how or whether a game will enter HDR mode automatically or not. For example, Nvidia exposes HDR through their NVAPI that some games utilizes, yet there's also the native built-in support in Windows as well. I still haven't really fully grasped which method automatically swaps the monitor to HDR mode or not, but... meh... it's too cumbersome at the moment where some games requires you to manually enable HDR in Windows before the in-game HDR option is made available. None, whatsoever. Windows 10 has, since v1803, a built-in tonemapper that basically maps the SDR signal of the game over to a HDR appropriate range. You can control the brightness of this under Display Settings > Windows HD Color settings > HDR/SDR brightness balance. You'll find that SDR games running in SDR while HDR is enabled and active will have their brightness adjusted in real-time when/if you play around with that slider with the game running in the background. On another entirely separate note, the modding utility Special K allows for HDR "retrofits" into DirectX 11 titles. It isn't perfect, but for SDR titles that already does their lighting calculations in the higher range (the "old" type of HDR -- aka "HDR rendering") the difference can be worth the hassle of using Special K. If you want a beta key for Special K, you only need to request one in this thread: Beta Invite Correspondence
  13. We actually had a SwiftShader page back in 2012 but it was removed due to lack of content, and honestly I sorta don't see it go any different this time around. From the looks of things, SwiftShader is essentially turning graphics APIs and calls into software rendering -- that is, being rendered and executed on a CPU and not the GPU. It is intended for enabling 3D rendering on systems that otherwise can't fully support hardware-accelerated rendering, and was developed by Google to allow 3D web content to be available even to those users without proper GPU capabilities. It makes it... I mean... Its use-cases becomes extremely specific. For example, the Crysis video highlights the fact that even with the game running at the lowest settings in 720p, on a Ryzen 2700x (8 cores, 16 threads) released in 2018, it is a stuttering mess and barely playable. And the game would almost certainly perform much faster on any integrated GPU of any CPU -- something that is the standard, I think(?), for CPUs nowadays. We can still create the page, of course, to allow new users to add information to it, but unless someone really steps in and takes responsibility of filling the page out I would imagine any page would essentially just be a few sentences at most.
  14. After extensive discussion, I think we're close to finalize the details of how we would cover it best. The way I see right now is a multi-parameter approach like the DualShock 4 parameters under input, where we both track support (native, hackable, etc) separately from the mode supported itself (DirectSound3D, Windows Spatial, etc). Inputting e.g. "EAX" into the mode field would interpret it as DirectSound3D and show it as such.
  15. As for FF8, I was about to say that it looks to be the Steam version but the support page mentions how up to 3 machines can be activated simultenously: https://support.jp.square-enix.com/faqarticle.php?kid=70429&id=9221&la=0&ret=faq&pv=20&page=0&c=0&sc=0&so=0 Basically it sounds as a non-Steam SecuROM PA protected title, same as Square Enix had available for FF7.
×
×
  • Create New...