Announcement

Collapse
No announcement yet.

Lars Knoll Shares His Technical Vision For The Qt 6 Tool-Kit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by uid313 View Post

    No, you don't need it. You could write everything from scratch, but many developers prefer to use libraries that provide functionality rather than writing code to implement things that are not their core focus, and that will never be as good as something established, mature and well-proven with a large user base and dedicated developers.
    Yeah, but you're only using like 5% of the library.
    For computer terminal simulation that can be easily done with the game/graphics engine itself, and same for the options widgets.

    Edit: I do not accept losing to the bloat/incompat/anti-KDE team!!!!! Who gave these guys a like?
    Did you read the post before this one? Using Qt for a game is overkill! This is why our games have sizes that exceed 100GB. We could optimize a few GB out, but because we want to look cool by using other libs we don't.
    Last edited by tildearrow; 14 August 2019, 02:30 PM.

    Comment


    • #22
      Originally posted by Knoll
      While we had to base Qt 5.0 on C++98, we can now rely on C++17
      To me, that explains everything. Before move semantics, I got constant headaches for thinking about unnecessary copy operations. C++ became a language with C++11.
      Last edited by andreano; 09 August 2019, 11:46 AM.

      Comment


      • #23
        Originally posted by tildearrow View Post

        Yeah, but you're only using like 5% of the library.
        For computer terminal simulation that can be easily done with the game/graphics engine itself, and same for the options widgets.
        Almost everything only use a small percentage of the library. That's not an issue, you get a commercial license and statically link and only the parts used will end up in the final binary.

        For games though, it seems Qt is much more commonly used for launchers and installers. For me it seems half the time a game has a launcher app that launches the main app, that launcer is written in Qt.

        Of course if you wrote the main menu in Qt, you wouldn't need a launcher as the main menu could effectively be the launcher.

        Comment


        • #24
          Originally posted by carewolf View Post

          Almost everything only use a small percentage of the library. That's not an issue, you get a commercial license and statically link and only the parts used will end up in the final binary.

          For games though, it seems Qt is much more commonly used for launchers and installers. For me it seems half the time a game has a launcher app that launches the main app, that launcer is written in Qt.

          Of course if you wrote the main menu in Qt, you wouldn't need a launcher as the main menu could effectively be the launcher.
          Qt is not optimized for the kinds of tasks games do, so you'll wind up using it in addition to a game engine, and it's not designed for embedding in game engines the way things like CEGUI are, so using it for a game means that you'll be having a lot of duplicated stuff loaded even if you statically link.

          As for launchers, they exist for various reasons, but it tends to come down to "the game engine can't change certain settings without quitting and restarting".

          The current launcher-game split isn't ideal, but it at least means that, once the game has been configured, it's usually possible to set your game manager to bypass the launcher and launch directly into the game, producing a 100% gamepad-compatible interaction flow for things like the Steam Link.

          Comment


          • #25
            Originally posted by ssokolow View Post

            Qt is not optimized for the kinds of tasks games do, so you'll wind up using it in addition to a game engine, and it's not designed for embedding in game engines the way things like CEGUI are, so using it for a game means that you'll be having a lot of duplicated stuff loaded even if you statically link.

            As for launchers, they exist for various reasons, but it tends to come down to "the game engine can't change certain settings without quitting and restarting".

            The current launcher-game split isn't ideal, but it at least means that, once the game has been configured, it's usually possible to set your game manager to bypass the launcher and launch directly into the game, producing a 100% gamepad-compatible interaction flow for things like the Steam Link.
            My idea would be to have a full screen launcher serve as the main menu, and launch or preload the main game engine in the background. So it would be no more duplication than already there. Using Qt for game menus would be a better choice than some of the other 3rdparty game UI frameworks out there like Coherent.

            Comment

            Working...
            X