Announcement

Collapse
No announcement yet.

GCW Zero: Another Linux Game Console Attempt

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

  • #16
    Originally posted by crazycheese View Post
    VGA was 320x200 (aka 13h, aka ModeY), 320x240 is so-called ModeX, its a hack and never seen a game using it.
    VGA was capable of 640x480 although only @ 16 colors and extremely slow.
    Thank you crazycheese and Bridgman.

    I'm a bit confused now but it seems I was wrong somehow.

    Comment


    • #17
      why MIPS ....
      not compatible with arm :/

      screen resolution is really bad, psp 9year ago was 480*272 ! (and 4.3")


      but it's a great idea to release an "open source Game console" !
      Last edited by mum1989; 01-13-2013, 04:23 PM.

      Comment


      • #18
        Originally posted by zear View Post
        Hello. I'm a developer involved in the GCW Zero project and I have a prototype unit.
        First, thanks for the coverage. It means a lot to us that we are mentioned in Linux related news services. If anybody has any questions about this handheld, I'll be happy to answer them.
        I have the same question that most other people here have - why limit resolution to 320x240? 640x480 or 800x600 would be much better. Also, is there any USB port or bluetooth, so a keyboard, mouse or joystick might be used with the device? 256 MB RAM is also quite limiting, atleast 512 MB would be better.

        Regarding the software, how many of the drivers are open source? Are you planning to use the recently announced etnaviv open source driver, or a proprietary driver for the Vivante GPU?

        Comment


        • #19
          Originally posted by sandy8925 View Post
          I have the same question that most other people here have - why limit resolution to 320x240? 640x480 or 800x600 would be much better. Also, is there any USB port or bluetooth, so a keyboard, mouse or joystick might be used with the device? 256 MB RAM is also quite limiting, atleast 512 MB would be better.

          Regarding the software, how many of the drivers are open source? Are you planning to use the recently announced etnaviv open source driver, or a proprietary driver for the Vivante GPU?
          Some anwers on thier website :
          Why did you choose a 3.5″ LCD over 5″ LCD any why a resolution of 320x240?

          A bigger screen on the GCW Zero = less battery life / more work on the
          CPU / less fps in emulation / blurry, rescaled graphics and a higher
          manufacturing cost...

          The reason behind choosing a 320x240 display isn't just monetary. Of
          course, a larger display would have raised the final price of the
          device, but it also has many other cons for a device aimed at retro
          gaming. First of all, a higher resolution is not needed because most
          retro games we support run at 320x240 at most. A larger screen would
          require everything to be rescaled, so the CPU would have an extra load
          of work and this would result in worse gaming performance and less
          battery life.
          Why did you choose mini-USB over micro-USB?

          Mini-USB allows you to plug extra peripherals much better than
          micro-USB. With micro-USB, we were afraid that the port would not
          survive a heavy weight attached to it.

          GCW Zero was designed so you can attach extra peripherals such as game
          controllers or keyboard/mouse combo of your choice and use them
          together with HDMI/analog video out.

          Here is an example in this link with a USB Bluetooth dongle:
          http://www.kickstarter.com/projects/...CommOrClosSour

          Comment


          • #20
            Originally posted by sandy8925 View Post
            Regarding the software, how many of the drivers are open source? Are you planning to use the recently announced etnaviv open source driver, or a proprietary driver for the Vivante GPU?
            Is also answered:
            Another thing that we are still working on is the OpenGL driver. Unfortunately, we will not be able to release this as open source. People who only want a fully open source system can simply leave out the OpenGL driver though; the 2D graphics system (Linux framebuffer) works fine without it.

            The Wi-Fi module itself uses binary firmware, but the driver that runs on the MIPS CPU is open source. Every other driver we are using is fully open source and that source will be published on github as soon as the first unitís ship.

            Comment


            • #21
              Originally posted by TAXI View Post
              Is also answered:
              Another thing that we are still working on is the OpenGL driver. Unfortunately, we will not be able to release this as open source. People who only want a fully open source system can simply leave out the OpenGL driver though; the 2D graphics system (Linux framebuffer) works fine without it.
              This is ultra-stupid.
              Its like saying "opensource console", yet its GFX system is proprietary and even wifi hardware needs a blobby driver.
              You could find a blob-free hardware.
              And what the problem with MESA?

              So now, by supporting the project, people will pay for closed source blob to wifi provider and to your closed source opengl provider/license issuer.
              Which is basically supporting closed source companies.

              By the way you were running closed-source games (no problem here, but you false advertised - "opensource games")

              Corrected this for developer:
              People who only want a fully open source system can simply leave out the project.

              With such attitude, its no different than Android projects and this will shift into fight with them. You killed one part of uniquess, compact size is still here.
              Last edited by crazycheese; 01-14-2013, 11:42 AM.

              Comment


              • #22
                I'm hoping for a game console that doesn't try to do special software.
                It breaks compatibility and often is detrimental to the experience anyway.
                (If you want to have a custom GUI it's better to be using a default desktop environment and develop a theme for that.)

                I want software with as little modifications from upstream as possible. GCW Zero developers. Please work with upstream, when done right it's more efficient and allows the maintenance of everything to be shared along you and upstream.

                The 320x240 resolution of the display is on the low side, even for a console like this.

                Comment


                • #23
                  Originally posted by sandy8925 View Post
                  I have the same question that most other people here have - why limit resolution to 320x240? 640x480 or 800x600 would be much better. Also, is there any USB port or bluetooth, so a keyboard, mouse or joystick might be used with the device? 256 MB RAM is also quite limiting, atleast 512 MB would be better.
                  320x240 is a good fit for retro gaming. Of course 640x480 would be good too since even if the application outputs 320x240 you can just scale up the image, but that would have made the unit more expensive.

                  The USB port supports USB OTG, so it should be possible to attach USB input devices via a USB hub. We don't have support for this in the kernel yet though, so I cannot say how well it works.

                  Since we run a pretty light embedded Linux, 256 MB total memory means about 240 MB available for applications. I haven't seen any application get near that kind of memory use; I think we could run everything in 64 MB if we had to. Most of the memory is used for caching data from the SD because it is not in use by anything else.

                  Originally posted by sandy8925 View Post
                  Regarding the software, how many of the drivers are open source? Are you planning to use the recently announced etnaviv open source driver, or a proprietary driver for the Vivante GPU?
                  Everything in our current kernel is open source; you can find the source at github: https://github.com/gcwnow/linux. The current kernel doesn't do GL ES yet, only framebuffer graphics, which is handled by just the LCD controller and doesn't use the GPU.

                  As for the GPU, for the short term we're trying to get the proprietary driver working. We prefer open source for everything though, so for the long term we're certainly going to look at etnaviv.

                  Another piece that we don't have source code for is the WiFi firmware that runs on the WiFi module itself (this is an internal USB device). This firmware does not run on the MIPS CPU and does not have access to main memory, so in my opinion it doesn't matter that it's not open source, but some people have stricter demands than I do so I thought I should mention it.

                  Comment


                  • #24
                    Originally posted by crazycheese View Post
                    This is ultra-stupid.
                    Its like saying "opensource console", yet its GFX system is proprietary and even wifi hardware needs a blobby driver.
                    You could find a blob-free hardware.
                    And what the problem with MESA?
                    About WiFi: the part that runs in the kernel is open source, it's only the part that runs on the WiFi module's microcontroller that is a blob.

                    The console is perfectly usable without any blobs in the kernel, but it won't have accelerated rendering then (and no WiFi if you consider uploaded firmware blobs taboo). Since 320x240 is not that many pixels, software rendering will go a long way, so most applications will run smoothly even without hardware accelerated rendering.

                    Originally posted by crazycheese View Post
                    So now, by supporting the project, people will pay for closed source blob to wifi provider and to your closed source opengl provider/license issuer.
                    Which is basically supporting closed source companies.
                    We don't pay specifically for the blobs, they are included in the cost of the hardware. In the case of embedded graphics, I'm not aware of any company that offers open source drivers for their GPU. In the case of WiFi, there might be some that are fully open, but by far the most common arrangement is an open driver with a blob running on the WiFi card itself. As I said before all the WiFi code that runs as part of the kernel is already open, which is the most important aspect: no mystery blobs that could cause instability, nothing to prevent us from upgrading our kernel even if the internal kernel interfaces change.

                    Originally posted by crazycheese View Post
                    By the way you were running closed-source games (no problem here, but you false advertised - "opensource games")
                    Yes, this was a mistake in the script for the video. We corrected it in the FAQ on Kickstarter.

                    Originally posted by crazycheese View Post
                    Corrected this for developer:
                    People who only want a fully open source system can simply leave out the project.

                    With such attitude, its no different than Android projects and this will shift into fight with them. You killed one part of uniquess, compact size is still here.
                    I too would love to see a mobile system with fully open source GPU drivers, but if we want to deliver that, we'd either have to design our own hardware or wait with releasing the console until we have fully reverse engineered the GPU. I think the former is not realistic and the latter is not an improvement over our current plan.

                    What I wanted to express with the original "People who only want a fully open source system can simply leave out the OpenGL driver though" line is that the console is not crippled without the GPU driver; in fact every GCW Zero video you can find on YouTube was done without using the GPU. A certain popular embedded Linux board won't even boot without the proprietary GPU driver

                    Comment


                    • #25
                      Originally posted by plonoma View Post
                      I want software with as little modifications from upstream as possible. GCW Zero developers. Please work with upstream, when done right it's more efficient and allows the maintenance of everything to be shared along you and upstream.
                      This is one of our goals: to use standard interfaces and stay close to upstream.

                      Our preferred way for applications to interact with the hardware is through SDL, which is highly portable. We already submitted a few patches to SDL, for example to fix wait-for-vsync and an option to not wipe the framebuffer when an application exits (so our loading screen remains visible until the application takes over).

                      On the kernel side, I'm removing a lot of the custom interfaces that Ingenic used in their kernel, to replace them with standard Linux interfaces. Also, in the drivers we try to use generic in-kernel mechanisms as much as possible, for example we use the generic gpio-keys driver and the new generic pwm framework.

                      As I wrote in the original mail to Michael, we keep up with upstream releases, which is unfortunately rare in the embedded world. This allows us to reduce the amount of customizations we need, when upstream accepts either our patches or other people's solutions to the same problem.

                      Comment


                      • #26
                        Originally posted by zear View Post
                        So you are asking whether it will be possible to compile natively on the device instead of resorting to cross-compilation from x86 Linux?
                        We have not thought of it. The device has no keyboard, so coding on it is a bit pointless. On the other hand, you could always plug it into the tv and connect a keyboard via usb-otg. Or you could just log into the device via SSH/Telnet and try to invoke the compiler. So perhaps this isn't such a stupid idea. We will think of it
                        Yes, my idea was precisely that, connect a keyboard to it via USB-OTG and connect console to TV....if the dev tools are buildin, then we could dev directly in the device....it will not only be a console but a full blown dev tool

                        Comment


                        • #27
                          Originally posted by mthuurne View Post
                          About WiFi: the part that runs in the kernel is open source, it's only the part that runs on the WiFi module's microcontroller that is a blob.

                          The console is perfectly usable without any blobs in the kernel, but it won't have accelerated rendering then (and no WiFi if you consider uploaded firmware blobs taboo). Since 320x240 is not that many pixels, software rendering will go a long way, so most applications will run smoothly even without hardware accelerated rendering.
                          Thanks for the answers!
                          No, I do not consider firmware to be taboo, except this firmware takes on more functions than firmware should do.
                          I bet WiFi needs government approved backdoors.

                          Shame about GPU :/

                          Sorry, didn't mean to scare you off guys... Btw, regarding Commander Keen. Its source code has been lost. Yeah, proprietary as usual.

                          Comment


                          • #28
                            Originally posted by crazycheese View Post
                            Thanks for the answers!
                            Btw, regarding Commander Keen. Its source code has been lost. Yeah, proprietary as usual.
                            For Commander Keen we are using an engine reimplementation called Commander Genius. So CK in the video is running natively.
                            Unfortunatelly the person shooting the video messed with the settings and triggered a glitch where a 320x240 output would be software-"stretched" to a smaller window, which resulted in high frame drop. So you will have to believe me that in reality Commander Genius on GCW Zero runs on full 60fps on 320x240

                            Comment


                            • #29
                              I dunno, but 320x240 is bit too retro for my liking.

                              Why should one prefer it over an android phone + gamepad for example? How much more expensive would at least a 640x480 screen be? Why packing a GLES2 GPU and 512MB RAM into it, if price and battery life are such an issue?

                              Sorry if I sound too negative. I am sure it will find its buyers.

                              Comment


                              • #30
                                Originally posted by log0 View Post
                                Why packing a GLES2 GPU and 512MB RAM into it, if price and battery life are such an issue?
                                The GPU is part of the jz4770 SoC we are using. We had a 256 -> 512MB RAM upgrade mainly because that was largely requested by people ever since our KS project starter. Personally I think 256MB RAM is enough, but I guess it's the today world where bigger numbers == more sales.
                                Originally posted by log0 View Post
                                Why should one prefer it over an android phone + gamepad for example?
                                This is solely a personal preference, so I won't comment on that.

                                Comment

                                Working...
                                X