• 0 Posts
  • 34 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle




  • There are several small differences between the Xbox 360 and the Xbox Series X gamepad. No single point by itself would be a very big difference, but overall it sums up. I have both gamepads in front of me, and will try to make a comparison:

    • The material of the Xbox 360 gamepad feels “better”. I can’t exactly say why, but I think it’s because of its smooth material on the bottom.
    • The Xbox 360 gamepad has bigger analogue sticks, with stronger springs.
    • Similarly, the triggers of the Xbox Series X gamepad are “weaker” than of the Xbox 360 gamepad.
    • I would have sworn that the Xbox Series X controller is a lot lighter too, but turns out, after weighing them both, that the Xbox 360 controller is slightly lighter. It does not feel this way though, with the Xbox 360 gamepad feeling way sturdier and heavier (but, as said, it’s actually lighter?!?).
    • The buttons on the Xbox 360 gamepad feel a lot smoother. They don’t make a “cheap, broken device” noise when being pressed.
      • This also applies to the D-Pad.

    I think the last point - the feeling when using the buttons and especially the D-Pad - is the most important one for me. On the Xbox 360 gamepad the buttons feel like actual buttons. On the Xbox Series X gamepad they sound and feel like a fidget toy. Using the D-Pad on the Xbox Series X gamepad is really annoying, because of the noise it makes.




  • Gamedev here: For non-indie projects it’s not up to the devs to decide which platforms get a native build. That decision is made by the publisher, and usually depends strongly on the estimated amount of extra work needed to make a native version. I agree with your statement, that if devs use ARM development PCs, they get a strong argument to convince publishers to pay for a native version, because porting costs will drop to near-zero.

    However (there always is a “however”): Many devs cannot switch away from Windows. If one develops for PC only, it’s possible. If one targets other platforms too (think: game consoles), one is stuck with whatever development environment the manufacturers of those platforms support - what is typically Windows and Visual Studio. It is kind of a chicken-and-egg problem. Platform SDKs will be made available for other operating systems or processor architectures once enough gamedevs are using those. Gamedevs cannot yet use those because platform SDKs aren’t available for them…

    It’s, to be honest, a frustrating experience… I personally would switch away from MSVC and Windows the moment I get an opportunity to. However, there never was an opportunity up to now… Our previous tech-director was pushing for Linux on dev machines - or rather: “let the devs use whatever they want, as long as it works” - but there never was an opportunity to switch, due to our games’ target platforms allowing only Windows for development…









  • Two things to add regarding question 1:

    The Steam Deck GPU is optimized for the built-in screen, which has 1280x800 pixels. FullHD is more than twice the number of pixels. The GPUs fragment fill rate will therefore not be sufficient to play many games at FullHD native. The Steam Deck has built-in FSR upscaling though, so if you are not sitting directly in front of the screen, it will look OK-ish…

    The second thing is refresh rate. On the deck itself you can set the screen refresh rate to 40 Hz. For many, many games the built-in GPU will not manage 60 FPS even at 1280x800, but it quite often manages to do 40, which still feels OK-ish.

    Most external screens don’t support 40Hz though, so you will be stuck with either limiting your framerate to 30 FPS, or you will have to live with either tearing or unsteady framerate.