Skip Navigation

User banner
Posts
0
Comments
180
Joined
2 yr. ago

  • to learn vulkan every time they want to use a GUI for their job

    Not every time, just the first time. But yes. Devs should stop being so lazy

    compiler design whenever they wanna use java for their job

    Every dev should at least know the basics of language design and compiler design, yes. Again, you also only have to learn it once

  • Nah you should learn

  • I agree with the last point tbh

    At the bare minimum, if you aren't capable of contributing to the library you use, then you don't deserve to use it.

  • I would really prefer native if there is the opportunity

    I prefer native apps too, but I'll still use websites and some electron apps, and I'll still use applications built in C#, Java, Python, etc. None of those are really native either. Proton is analogous to a virtual environment for running an interpreter. Potentially, it's slower and has issues a la Python, but if the program can work, then I don't care about the theoretical problems; it works despite them. So I think it's fine.

    If it means more games for Linux and a standard that developers can target, encouraging them to "support Linux," then that's a win I think. Like I said in another comment, a studio can buy a steam deck, throw the same Windows export on it, and then have someone run through the same set of tests they'd normally go through. If it works there, it'll work on most Linux machines. Having a standard API is not a bad thing imo

  • The way I like to think about it is that Proton essentially provides a standard, stable API across both Windows and Linux for gaming (Win32). We typically talk about it as a translation layer, and it is, but also to some degree it's also "here's an implementation of Win32 for Linux."

    If game devs can, say, buy a steam deck and know their game works on it, that means it's gonna work on other steam decks and probably most Linux machines. It's making it easy for devs to test and develop for Linux, even if it's not really "on Linux." Copy the Windows files to the steam deck, run your release checklist, and you're good to go.

  • Here's how I think it works

    In formal language, what it means to accept a verification means does the result fall into the list of acceptable values.

    Consider adding two 2-bit numbers:

    • Alphabet: { 0, 1}
    • Language: { x | x consists of four binary digits representing two 2-bit binary numbers where the result of adding these two numbers is a valid 2-bit binary number (i.e. falls between 00 and 11) }
    • Then you have an automata that will:
      • Start from the rightmost bit
      • Add the corresponding bits (+ carry from any previous iterations)
      • Carry over to the left if needed
      • Repeat for both bits
      • Check for acceptance
    • Machine as a whole simply checks did the inputs produce a valid 2-bit number, so it just accepts or rejects

    The machine itself simply holds this automata and language, so all it does is take input and reject/accept end state. I think you're just getting caught up in definitions

    A sum of a list of numbers I think would be something like

    • Alphabet: digits 0-9 and ','
    • Language: a single string of digits or a single string of digits followed by a comma and another valid string
    • Automata:
      • Are we a single string of digits? If yes, accept
      • Sum the last number into the first and remove the comma
      • Repeat
    • Machine: Does the some operation result in a valid string?

    Machines accept a valid state or hit an error state (accept/reject). The computation happens between the input and accept/reject.

    But maybe I don't understand it either. It's been a while since I poked around at this stuff.

  • I have been for the past month now. All of my games are now working.

    Previously no and the reason was bc of Nvidia issues, but they all seem resolved now for the most part

  • I wonder if you could get a any benefit by introducing two more MCUs.

    Dedicate one MCU to simply reading and refreshing the RAM as fast as possible which can act as an abstraction layer for another MCU that it can talk to over I2C or SPI.

    Then use a second MCU to act as the MMU and talk to the RAM MCU.

    Finally, run Linux on the third MCU which talks to the MMU MCU.

  • I can't even wrap my mind around people who use 60% keyboards and use a bunch of extra function keys let alone anything more drastic

  • In VR, you are able to place windows anywhere. You have infinite amounts of screen. Look at something like Simula

  • Bc they're about to release a VR headset PC that allows just that. It will likely inspire other companies to do so as well

  • Move to VR and infinite screen space. We're so close. No doubt once Apple joins the fray it'll be time

  • What I said:

    You could mull over and discuss a million different ways to get started. The most important thing is to be decisive and just do

    We could go on for hours debating what the best beginner language, environment, project, etc is, but the important thing is that they pick something and do it.

    I gave them a specific thing to get started on. That's the important thing.

    Learning programming is gonna be hard. They're gonna face issues no matter what, so like I said:

    Is it the best way? Who cares just get started

    That's why I said you missed the point. I don't think you read my reply at all and just stopped at the first word lol

  • Rust is renowned for being hard and frustrating to onboard onto. I don’t think this is a wise suggestion.

    You missed the point

  • Pick Rust, learn Bevy, and make a Flappy Bird clone. Is it the best way? Who cares just get started.

    You could mull over and discuss a million different ways to get started. The most important thing is to be decisive and just do