Recommended Posts

Mozilla is an example of broken Windows developer mentality: "Why change when old ways still work?"

 

Anyway, if you are complaining about the memory requirement, I have news for you, you are not the target audience for the game, PC gamers are.

 

 

 

Mozilla is an example of broken Windows developer mentality: "Why change when old ways still work?"

 

Anyway, if you are complaining about the memory requirement, I have news for you, you are not the target audience for the game, PC gamers are.

 

Many PC gamers only have 4GB of RAM... I guess they aren't the target audience either.

Many PC gamers only have 4GB of RAM... I guess they aren't the target audience either.

This is true, I meant active PC gamers that actually update their rigs. A single stick of RAM is 8 GB.

 

If you don't want to upgrade, too bad, modern games require modern hardware. Being too poor to afford a newer PC is not an argument for 32 bit.

Well, Mozilla could do a 32bit plugin with a 64bit browser host, but it's hard (Unlike OS X, you can't have 2 different architectures in a single binary) and even then it's only a compatibility shim (The proper solution to 32bit plugins with a 64bit host is to replace them with 64bit plugins)

And yes, there are stability issues, for the longest time 64bit Firefox didn't have a crash reporter due to differences in the 64bit API, so people using the 64bit nightly just didn't report crashes, the printing code used 32bit pointers instead of the right length ones, etc.

Edit: IE runs in 32bit mode by default, that'd be a big reason why people don't make 64bit plugins for it. Same as WMP and codecs.

 

IE11 on 8.1 runs 64-bit by default now I believe, or at the very least it used to due to EPM being on by default.

 

Many PC gamers only have 4GB of RAM... I guess they aren't the target audience either.

 

21% vs 26% according to Steam's hardware survey for 4GB and 8GB respectively. Surprisingly large number of people with 3GB and 6GB too. (16% & 6%)

21% vs 26% according to Steam's hardware survey for 4GB and 8GB respectively. Surprisingly large number of people with 3GB and 6GB too. (16% & 6%)

 

I'd imagine the 6GBers are primarily laptops. That appears to be a pretty common default configuration these days. But, yeah the steam statistics show something like ~40% of users are 4GB or lower. That's actually more than I expected to be honest.

This is true, I meant active PC gamers that actually update their rigs. A single stick of RAM is 8 GB.

 

If you don't want to upgrade, too bad, modern games require modern hardware. Being too poor to afford a newer PC is not an argument for 32 bit.

 

I don't think so, look at the statistics Athernar posted. Most people (including gamers) don't upgrade their rigs every year. Also, I don't think anyone has ever made the argument I bolded.

Many PC gamers only have 4GB of RAM... I guess they aren't the target audience either.

Most serious PC gamers nowadays have between 8-16 GB. An El Cheapo 'puter that you get from any retailer has at least 4 GB.

 

Personally, I have 32 GB but I run a small vSphere lab for work purposes. 

As was so perfectly stated by _Alexander, choosing not to upgrade is not a valid argument.

I'd imagine the 6GBers are primarily laptops. That appears to be a pretty common default configuration these days. But, yeah the steam statistics show something like ~40% of users are 4GB or lower. That's actually more than I expected to be honest.

 

Those Tri-channel Intel configurations that were a mini-fad a while back might be a big contributor too.

 

:/ Not for me, the checkbox was unchecked and hitting "Restore defaults" didn't check it.

 

In yet another dumb move they reverted EPM to off by default because apparently having it on by default for a couple of months post-RTM had worked to "push plugin developers to update".

 

It's still on for me however, and I've not altered the setting.

  • Like 1

Most serious PC gamers nowadays have between 8-16 GB. An El Cheapo 'puter that you get from any retailer has at least 4 GB.

 

Personally, I have 32 GB but I run a small vSphere lab for work purposes. 

As was so perfectly stated by _Alexander, choosing not to upgrade is not a valid argument.

 

I'm restating a bit, but your reply is (1) ignoring that ~62% of the market has less than 8GB and (2) no-one in this thread has ever made the argument that being unable to afford a new computer is a good argument for staying with 32-bit executables.

I'm restating a bit, but your reply is (1) ignoring that ~62% of the market has less than 8GB and (2) no-one in this thread has ever made the argument that being unable to afford a new computer is a good argument for staying with 32-bit executables.

1. So? Should we continue developing for XP while at it? This is a video game, it will require more resources than most everything else.

2. That is the only argument in favor of 32-bit.

1. So? Should we continue developing for XP while at it? This is a video game, it will require more resources than most everything else.

2. That is the only argument in favor of 32-bit.

 

If it made business sense to develop for XP still, yes absolutely. However, XP is a niche market now and the return doesn't match the investment required.

 

In the same vein, cutting large swaths of your market out just so some armchair wannabe-programmers can feel good about using the latest tech "just cuz", is not economically viable or particularly sensible/intelligent.

  • Like 1

1. So? Should we continue developing for XP while at it? This is a video game, it will require more resources than most everything else.

2. That is the only argument in favor of 32-bit.

 

XP has about ~6% of the market so the comparison isn't relevant. Targeting a game for where the largest segment of the market is at is certainly a valid reason for distributing 32-bit executables (and a smart marketing decision).

 

EDIT: I was too slow. Refer to what Athernar wrote. It makes the same points.

:/ Not for me, the checkbox was unchecked and hitting "Restore defaults" didn't check it.

They disabled Enhanced Protected Mode as default after a while, claiming it was only for 'information gathering' (wot)

 

I had 6GB.  Would still be running that if this crappy ass mobo didn't decide it hated it.

Targeting a game for where the largest segment of the market is at is certainly a valid reason for distributing 32-bit executables (and a smart marketing decision).

But the largest segment of the market is 64-bit by far, about 75% from a quick look at the Steam Hardware Survey. I don't think the 64-bit executable will be much of an issue; the RAM requirement will be. But that's a good thing I think. It's time games pushed the technological envelope.

But the largest segment of the market is 64-bit by far, about 75% from a quick look at the Steam Hardware Survey. I don't think the 64-bit executable will be much of an issue; the RAM requirement will be. But that's a good thing I think. It's time games pushed the technological envelope.

 

That is true, it's definitely not the OS choice holding the market back. But there's no good reason to a force a 64-bit build if your requirements are less than 4GB RAM though, you'd just be cutting out ~10% of the market for no real reason.

:huh: Where are you getting that a quad core without HT can't handle 8 threads? That's the entire point of a preemptive scheduling. You'd quite literally pin 2 threads: 1 core if you needed 8 threads. Also, I think you are misunderstanding the point of HT. HT doesn't give you 8 cores or more resources, it gives you the means by which to better utilize the resources of the 4 cores you do have; i.e. to do a better job scheduling those 4 cores. So you will never see 2x the performance gains and in some workloads you may only see a modest increase of 5-15% in some cases. It all depends on how well the scheduling is done on a single core.

 

Take look at this. Notice, how the i7 is not double the performance than the i5 when pegging all cores:

http://cpuboss.com/cpus/Intel-Core-i7-3770K-vs-Intel-Core-i5-3570K

 

 

Here's a more fair comparison for an 8 core AMD vs a i5. Take note, this 8120 is clocked about 2 times of that of the PS4, yet even with that advantage and 8 cores it still gets worse overall performance when using all cores compared to an i5 with half has many cores:

http://cpuboss.com/cpus/Intel-Core-i5-2500K-vs-AMD-FX-8120

 

Basically if we were going to generalizing this, what this says is that you can do essentially the same workload faster and more efficiently using an i5 than you can with a PS4 processor that has 2x the amount of cores. Or if we were looking at this on a single core bases, you can finish the same work more than 2x faster on an single core of an i5 than you can on a PS4 core (check the passmark scores for the AMD i linked and consider that it is clocked 2x faster than a PS4 core).

 

I think that about sums up this, you need 8-core for future games thing. 

I'd like to know where he's getting that no-HT=<8 threads, too.  I have Task Manager open in detail mode - simply to check that; Google Chrome (which is not an x64 browser) has three tabs open, and eighteen processes running.  That does NOT include the two crash handlers (Google has both x64 and x32 crash handlers -rather odd for an x32 browser).  And I'm not running on an i-series CPU of any sort, let alone one with HT; this is a Q6600 -- Kentsfield, the original Intel quad-core.  Chrome has the most processes of anything; even svchost (Services Host) uses just twelve processes - and that's a core process. (I picked svchost.exe because it uses the second-most process threads behind Chrome itself.  It's also an x32 application/executable. So, we have one application with eighteen threads, and another with twelve - and neither is 64-bit?  The OS is, but the executables are not. )

The amount of processes in use is not a measure of code efficiency by any stretch of anyone's imagination - despite Chrome's eighteen processes (and svchost's twelve) the CPU is still using less than thirty percent of available resources - in other words, despite the process load, it's basically "loafing".

That is true, it's definitely not the OS choice holding the market back. But there's no good reason to a force a 64-bit build if your requirements are less than 4GB RAM though, you'd just be cutting out ~10% of the market for no real reason.

 

Do you think, at this point, that 10% who are x32 with <4GB or RAM are going to buy Watch Dogs in any case? Even if some do, should developers continue to invest in developing for that segment in lieu of moving forward with mastering x64 development and giving them access to everything x64 may or may not offer?

I'd like to know where he's getting that no-HT=<8 threads, too.  I have Task Manager open in detail mode - simply to check that; Google Chrome (which is not an x64 browser) has three tabs open, and eighteen processes running.  That does NOT include the two crash handlers (Google has both x64 and x32 crash handlers -rather odd for an x32 browser).  And I'm not running on an i-series CPU of any sort, let alone one with HT; this is a Q6600 -- Kentsfield, the original Intel quad-core.  Chrome has the most processes of anything; even svchost (Services Host) uses just twelve processes - and that's a core process. (I picked svchost.exe because it uses the second-most process threads behind Chrome itself.  It's also an x32 application/executable. So, we have one application with eighteen threads, and another with twelve - and neither is 64-bit?  The OS is, but the executables are not. )

The amount of processes in use is not a measure of code efficiency by any stretch of anyone's imagination - despite Chrome's eighteen processes (and svchost's twelve) the CPU is still using less than thirty percent of available resources - in other words, despite the process load, it's basically "loafing".

 

It appeared to me that in subsequent posts that he thought that applications had to implement thread scheduling themselves as opposed to scheduling/thread-handling being an OS-service and preemption/interrupts being hardware supported. So, I think from there he had just assumed that it would be very difficult to do such a thing without taking massive performance hits. He had used an example of an video encoder only using the same number of threads as physical cores as evidence for what he was saying.

 

I don't think most people have the background to understand the nuances of processor utilization or scheduling and just assume more cores is better and that it would be impossible for a machine with less cores to do an equivalent amount of work in the same amount of time or less.

Do you think, at this point, that 10% who are x32 with <4GB or RAM are going to buy Watch Dogs in any case? Even if some do, should developers continue to invest in developing for that segment in lieu of moving forward with mastering x64 development and giving them access to everything x64 may or may not offer?

 

If crossplatform developers were capable of cramming games up till now onto PPC machines with 512MB of RAM, I think they should be able to manage supporting 2-4GB x86 machines without compromising 4GB+ x64.

  • Like 1

Do you think, at this point, that 10% who are x32 with <4GB or RAM are going to buy Watch Dogs in any case? Even if some do, should developers continue to invest in developing for that segment in lieu of moving forward with mastering x64 development and giving them access to everything x64 may or may not offer?

 

I don't think that the 10% who are using 32-bit Windows would have bought Watch Dogs. I don't see it as an issue of developers continuing to develop for the x32 segment, but as developers continuing to develop for the segment with <4GB of RAM, 32-bit executables just comes naturally if you are within that segment. Let's be honest, if you are aren't developing games for at-least the 4GB boundary as minimum then you probably aren't pushing the envelope anyway.

 

That being said, I don't take issue with the Watch Dogs requirements, moving forward, or pushing the envelope to x64. Most people are running x64 anyway. The only thing I am is skeptical of whether those requirements are truly valid or if they are just listing unneeded minimums.

They disabled Enhanced Protected Mode as default after a while, claiming it was only for 'information gathering' (wot)

 

I had 6GB.  Would still be running that if this crappy ass mobo didn't decide it hated it.

EPM is the equivalent of UAC for browsers - like Hyper-V, EPM comes from the server side of Microsoft (where it is still the default, as of Server 2012R2, which is the core of my Hyper-V test setup, due to no Extended Processor Table requirement in Windows Server).  Despite G41, it's the lack of DDR3 support (the MCH in this particular G41 mATX motherboard only supports DDR2 - there ARE G41 motherboards, even in mATX, that support DDR3 - one is the ASUS P5G41-M LX Plus - this very motherboard's otherwise-twin sister).

 

Current DDR3 pricing - I took a look at DDR3 pricing (an admitted snapshot), and I looked at dual-channel pricing for desktop DDR3 from my usual retail source - MicroCenter.  They have twenty DDR3 sets - the spread from cheapest to priciest runs from $74.99 at the bottom to $139.99 at the summit; all are 2x4GB.  The only reason DDR3 is as high as it is has to do with increased demand and constrained supply - less than six months ago, there was practically a DDR3 glut.  (I bought a 2x4GB set during the worst of the glut for just $39.99.)  2x8GB?  $139.99 to $239.99 - again, constrained supply.  Four such sticks has you bouncing off the motherboard RAM ceiling.

I don't the that the 10% who are x32 would have bought Watch Dogs. I don't see it as an issue of developers continuing to develop for the x32 segment, but as developers continuing to develop for the segment with <4GB of RAM, 32-bit executables just comes naturally if you are within that segment. Let's be honest, if you are aren't developing games for at-least the 4GB boundary as minimum then you probably aren't pushing the envelope anyway.

 

That being said, I don't take issue with the Watch Dogs requirements, moving forward, or pushing the envelope to x64. Most people are running x64 anyway. The only thing I am is skeptical of whether those requirements are truly valid or if they are just listing unneeded minimums.

I don't either - most of us that ARE so constrained aren't necessarily unwilling to upgrade, but we're constrained by our current motherboards (dead memory technology in my own case, for example).  Merely changing to a motherboard that supports DDR3 makes that issue moot - however, the (relative) sting in the tail is that a new CPU is also required.  However, outside of games such as Watch Dogs (BF4, for example, or NFS Rivals, or even Supreme Commander) and even with x64 applications (Office 2010/2013), the issue is more add-ons and/or plug-ins - not the core software (again, browsers and productivity software).  Niche software IS pushing the requirement (Photoshop went multicore-aware several years back, for example; same applies to AutoCAD and 3DS Max) - however, what about even the add-ons for the same software (Photoshop/AutoCAD/3DS Max) - how many of those are x64?  I wouldn't think that many folks are going to run AutoCAD on any PC with just 4 GB of system memory.

  • Like 1

It appeared to me that in subsequent posts that he thought that applications had to implement thread scheduling themselves as opposed to scheduling/thread-handling being an OS-service and preemption/interrupts being hardware supported. So, I think from there he had just assumed that it would be very difficult to do such a thing without taking massive performance hits. He had used an example of an video encoder only using the same number of threads as physical cores as evidence for what he was saying.

 

I don't think most people have the background to understand the nuances of processor utilization or scheduling and just assume more cores is better and that it would be impossible for a machine with less cores to do an equivalent amount of work in the same amount of time or less.

Yeah, games are one of those strange things where throwing more cores/threads at it might not help, unlike something like Excel or a video encoder.

The main difference being that excel or a video encoder don't care if a thread is 100ms late to reply, while having a subsystem in a game being 100ms out can make the entire thing break.

Stuff like map/model/texture loading is inherently asynchronous, while stuff like AI/physics are tightly coupled, the AI needs to know the physics state to make decisions, and the physics system will need to know the location of AI for collision, etc. So you end up with something resembling a real time operating system kernel where the majority is tightly coupled, and non-important tasks are thrown onto separate threads, which is rather hard to write (Meaning only people like John Carmack can do it justice), having everything handled as separate threads and leaving it up to the OS gets you into situations where you have your AI thread preempted to perform a texture load, not ideal.

GTX 460 and HD 5850 are fairly ancient now. The 6GB RAM requirement might be the biggest stumbling block for users though. A quick look at the latest Steam Survey shows more than 50% of users won't meet the requirement.

 

Well, thank god ram is cheap, haha.

This topic is now closed to further replies.
  • Posts

    • Flameshot 14.0 Final by Razvan Serea Flameshot is a free and open-source, cross-platform tool to take screenshots with many built-in features to save you time. Using Flameshot is as simple as launching, dragging the selection box to cover the area you want to capture, making annotations as needed in on-screen and saving the shot to your computer, all with a very simple and straightforward interface. Flameshot allows users to simply upload their screenshots directly to the cloud in order to easily share it with others. You can upload your image directly to Imgur with a single click and share the URL with others. In-app screenshot editing - You can choose to add an arrow mark, highlight text, blur a section (blur or pixelate an area), add a text, draw something, add a rectangular/circular shaped border, add an incrementing counter number, and add a solid color box with Flameshot's built-in editing tools. Command-line interface (CLI) - Flameshot has several commands you can use in the terminal without launching the GUI via a command line interface. The command line interface lets you script Flameshot and use it as the subject of key binds. Flameshot 14.0 release notes: This release brings major improvements to multi-monitor support, fractional scaling support, new capture workflows, and a long list of bug fixes across all platforms. Changelog: New Multi-Monitor Capture Workflow New monitor selection screen before capture for better multi-monitor and mixed-scaling support. Option to auto-capture the monitor under the cursor (X11 & Windows). Tray menu can directly select a monitor. Linux Improvements XDG Desktop Portal is now the primary screenshot method. Added legacy X11 fallback option for minimal window managers. New D-Bus capture API for scripting and automation. Windows Enhancements Global screenshot hotkeys now supported (not limited to Print Screen). New portable mode stores settings next to the executable. Clipboard now always uses PNG format for better compatibility. CLI & Platform Updates Redesigned flameshot screen command with per-monitor capture support. Added native Nix Flake support. More compact launcher UI and improved update notifications. Major Fixes Multiple Wayland stability fixes, including KDE Plasma crash fixes. Clipboard compatibility improvements for GNOME, Wayland, X11, Windows, and macOS. Fixed D-Bus hangs, capture crashes, and HiDPI region issues. Other Changes Dropped Ubuntu 20.04 (Focal) support. Updated translations and build infrastructure. Intel macOS builds are no longer provided. [full release notes] Download: Flameshot 14.0 | 18.1 MB (Open Source) Download: Flameshot Portable | 53.0 MB Links: Flameshot Home Page | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • Helium Browser 0.13.4.1 by Razvan Serea Helium is a private, fast, and honest Chromium-based web browser — built for people, with love. It offers the best privacy by default, unbiased ad-blocking, and a clean experience free from bloat and noise. Proudly based on Ungoogled-Chromium, Helium removes Google’s clutter while keeping a fast, efficient development pipeline. With thoughtful touches like native !bangs and split view, Helium is a people-first, fully open-source browser that puts control back in your hands. Privacy, security, and control come first. Ads, trackers, and third-party cookies are blocked automatically, HTTPS is enforced everywhere, and all Chromium extensions work seamlessly — while Google can’t track your activity. Helium’s 13,000+ offline-ready !bangs let you jump straight to sites or AI tools like ChatGPT instantly. Open-source, people-first, and unbiased, Helium delivers a browsing experience that’s fast, secure, and free from noise, ads, and compromises. Helium Browser key features: Performance Fast, efficient, and lightweight — built on Chromium’s optimized engine. Energy-saving and consistent — stays fast over time without slowing down. No bloat — stripped of unnecessary components for maximum speed. Minimalist interface — compact, clean, and distraction-free. Customizable toolbar — hide elements you don’t need. Smooth and stable — no flicker, lag, or animation glitches. Comfort-focused experience — intuitive and unobtrusive. Privacy & Security Best privacy by default — blocks ads, trackers, phishing, and third-party cookies. Unbiased ad-blocking — powered by community filters and uBlock Origin. No telemetry or analytics — zero background web requests on first launch. Strict HTTPS enforcement — warns for insecure sites. Passkeys supported — modern authentication made simple. No built-in password manager or cloud sync — your data stays yours. Extension Compatibility Full Chromium extension support — including MV2 extensions. Anonymized Chrome Web Store requests — Google can’t track extension installs. Extended MV2 support — maintained for as long as possible. Smart Features Native !bangs — browse faster using 13,000+ offline-ready shortcuts. AI integration — use !chatgpt and others directly from the address bar. Offline functionality — bangs work without an Internet connection. Philosophy People-first design — open source, transparent, and community-driven. No ads, no noise, no bias — privacy and honesty over profit. Helium Browser 0.13.4.1 changelog: 0a4f1149 revision: bump to 4 (#1969) 4848de1f helium/core: enable the chromium screenshot feature (#1968) e0dec3f5 onboarding: integrate strings to i18n system (#1948) 417fa5bc i18n: fix newline parsing for onboarding 7a339b39 i18n: add foraged translations for onboarding 4f090cff i18n/generate: add handling for onboarding strings bfe48d58 i18n_apply: manually override parent grd logic for onboarding strings ab214e3c onboarding: bump in deps, wire up grdp afa6a059 helium/core: disable pdf infobar feature (#1965) eba585e7 helium/ui/vertical: fix new tab button alignment and icon size (#1964) 6ecfc9e0 helium/ui/tabs: fix horizontal tab hover background color (#1963) 3db87dc0 helium/ui/tabs: fix new tab button hover/press colors (#1962) 6bbdcc3e helium/ui: improve tab group UI in all layouts (#1961) 53deb314 helium/ui/tabs: enable tab group hover cards e93aece7 helium/ui/vertical: fix tab group appearance, prevent line overlap 629f5495 helium/ui/tabs: restore solid group header colors, enable new colors 961c962e helium/ui/tabs: move horiz tab group underline to bottom, make it thick c96deab6 merge: update to chromium 149.0.7827.155 (#1959) 36db56b4 i18n: update source.gen.json 5ce006ae patches: refresh for chromium 149.0.7827.155 b4c1ea62 merge: update ungoogled-chromium to 149.0.7827.155 4e5e8671 Update to Chromium 149.0.7827.155 08a3e7da helium/ui/layout: disable mute on collapsed vertical tabs (#1778) a0a5bbaf helium/core: simplify context menu and prevent huge widths (#1951) c4732aac devutils/i18n: add forage command (#1944) 11d16986 devutils/i18n: add an option to translate using local CLI tools (#1942) d820c3a2 i18n/prompt: tighten translation rules to prevent common errors (#1940) cf827007 Update to Chromium 149.0.7827.114 6e3d5164 Update to Chromium 149.0.7827.102 Download: Helium 64-bit | Portable 64-bit |~100.0 MB (Open Source) Download: Helium ARM64 | Portable ARM64 Links: Helium Home Page | macOS | Linux | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
  • Recent Achievements

    • Reacting Well
      BizSAR earned a badge
      Reacting Well
    • First Post
      AndreaB earned a badge
      First Post
    • Week One Done
      Huge Trailer earned a badge
      Week One Done
    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
    • One Month Later
      eurospharma62 earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      579
    2. 2
      +Edouard
      183
    3. 3
      PsYcHoKiLLa
      75
    4. 4
      Michael Scrip
      73
    5. 5
      neufuse
      64
  • Tell a friend

    Love Neowin? Tell a friend!