Guide/home/mini-dash/slide-in Bar

[Tiptup300]

I was just inquiring if any sort of guide was planned at all. I'm not totally ignorant to the process of programming, but I never knew how exactly the guide of the xbox 360 works. I know it runs on another thread checking for the guide button and once pressed it appears, but I don't quite get how it's ran. Like if it's a thread that starts when the 360 boots and it just runs over top all the other games. Could something like this be possible on the Pandora?

I made a mockup here:

Let me explain the mockup:
- Make sure it tells the time/date, my favorite thing about the guide in the Wii/PS3/Xbox 360
- Make sure it's expandable so that users can customize it
- Allow room for TINXL information, I know it's not complete, (not sure if it's started at all), but if the idea takes off, need to be ready for it. (Friends online, invites)
- Custom music would have to be on an application by application basis for the fact that it's a handheld, so some games could not have enough juice for gaming and music. I'm also not a big linux guy, so I don't know how feasible this is.
- Have the home button available, so you touch/choose it and it goes to the dashboard.

From what I know, it will run Linux, therefore the guide could just be an application ran during the other games, that would be simple, although the problem would be making sure all the developers use the guide when making their games/applications.

Well, I suppose all should just view the image and post your views.

Also, my experience with programming is small, but so far I've done a lot of web site designing with php/mysql. I'm also certified in Oracle SQL. I went through a 3 year course for business computing (COBOL, RPG2, SQL.) Currently I just make games using C# and xna, although I enjoy making mockups more than programming.

 

[MarcelP102]

Looks great, but did you know that some apps can shutdown the os to get full cpu and ram access So it should work but not with all apps/games.

 

[benjymous]

Basically it would just be a custom Task Manager like app - assuming the emulators / games are running under X, rather than talking to the gfx hardware directly, it'd be a dead simple thing to implement.

Otherwise, someone would just need to build the code library that handles the guide screen, and the developers of pandora apps would just need to link in the library for a consistent UI across apps. This again would be pretty straighforward, but would require all the developers to stick to some form of guidelines, rather than just hitting the metal to get every bit of performance

 

[plopperz]

Looks great, but did you know that some apps can shutdown the os to get full cpu and ram access So it should work but not with all apps/games.

Just an idea, but what if, for the games that needed it, when pressing the button (or whatever you would do) it would boot the OS in the background, then display the slider. Though that would only work if the OS booted quickly.

 

[slygamer]

From the experience with the GP2X, yes you could shutdown the OS and have the device to yourself, but hardly anyone did.

In my other life, I work as a game developer on the Xbox 360, and the blades (as they are called) are very useful, not only from the perspective of the user but for the developer as well.

On the Xbox 360, the kernel is always running, and it is what detects the Guide button being pressed. On a device such as the Pandora, it would be a background task spawned during the boot process that performs the job of checking for the button and drawing the window. However, the drawing may be difficult without a single API used to access the display. On the Xbox 360 all applications must call Direct3DDevice9:resent() at least 15 times per second, and it is during this call that the kernel renders the blade. There is a similar API on the PS3 where it renders the XMB. On the Wii, the application must render the Home Button Menu with art assets supplied by Nintendo.

So it is definitely possible, but it may be a difficult task with such an open system. You may have seen just how difficult it was trying to get a group of people to agree on standard button functionality on the GP2X. I can imagine it will be just as difficult to get people to agree on how things will be rendered.

 

[sindbad]

If everyone is nice and makes sure their games work in X11, there shouldn't be a problem.

 

[JayFoxRox]

I m pretty sure there is always a way to inject such overlays. This is definatly someting I will look at =) (Seeing that I also plan to write my own XMB)

 

[mindlord]

I for one am not an X11 programmer, and wouldn't be inclined to learn it just for this. I'm pretty sure there are other non-X11 devs out there too who aren't going to concern themselves with it either, even on the Pandora. The reason things like this work well on consoles like Xbox, Wii, and such is because the devs are forced by the manufacturers to use certain rules and APIs. While good for developers on those platforms, it's not exactly parallel to the Pandora ideal as I understand it. Don't get me wrong, I like standards, but imposing a standard of "You must make sure your app runs in X11" or "It must obey the SDK or you'll break the world" isn't cool, IMO.

SDL makes it easy to go fullscreen even in X. But, what happens if the SDL app is running at 320x240, upscaled by the DSP and someone hits the magic button? Only the upper-left corner of the window could be seen, and the buttons couldn't be clicked. Even worse the window might steal focus, but because the SDL app is beating on the framebuffer you'll get a garbled mess. Just because an application is running on top of X doesn't mean it will play nice at all. It will then become each dev's responsibility to watch for this event and jump a bunch of hoops to accommodate it. I know it seems easy in concept, but it's simply not as easy as stopping the threads and waiting for the widget to finish. There are timers, and display resolutions, and the framebuffer to consider.

But the question needs to be begged. Why bother putting another GUI app on top if you're already running some other type of window manager to launch your game in the first place? Why not just "ALT-TAB" out and do whatever you need to do with the fully functional WM? Instead of this simplified, but pretty group of buttons. Now, if your app was the window manager this would be a different argument, but a side-bar, or guide doesn't fulfill the needs of the UMPC aspect of the Pandora. It's a good idea, and I kinda like where it could possibly go, but it will be unbelievably difficult to get compliance from all the devs, and there are huge technical hurdles to overcome. If all you were using a Pandora for was X11 (and well behaved SDL) games this would work a treat.

@slygamer - Almost every app I ever tried on the GP2X killed the menu process on launch and reloaded it when it finished, usually by way of a launching shell script. Some of the heavier GP2X apps like GPE loaded a custom kernel. I don't expect many games to run on the bare metal, but I am willing to bet that a fair number of them kick the machine into runlevel 2 and return to 5 when finished.

 

[sindbad]

If it's upscaled by the DSP before being actually rendered to the window, the effective resolution is 800x480. I think the screen resolution is not supposed to be changed.

SDL has an X11 backend and OSDs work just fine. Hold alt-tab and you'll see the popup, same for the dash. If X is used and the app is a fullscreen window, everything will work as expected. Anything that kills X or otherwise messes with the framebuffer is alone in the dark.

 

[Parkydr]

@slygamer - Almost every app I ever tried on the GP2X killed the menu process on launch and reloaded it when it finished, usually by way of a launching shell script. Some of the heavier GP2X apps like GPE loaded a custom kernel. I don't expect many games to run on the bare metal, but I am willing to bet that a fair number of them kick the machine into runlevel 2 and return to 5 when finished.

GP2X apps don't kill the menu, the menu kills itself by running the .gpe/.gpu with exec() which replaces the menu process with new one. You then have to call exec in your app or launch script to rerun the menu.

I don't think there are many, if any, apps that change the run level, there are no significant processes running anyway.

 

[Orkie]

GPE doesn't boot a custom kernel :S.

 

[mindlord]

@slygamer - Almost every app I ever tried on the GP2X killed the menu process on launch and reloaded it when it finished, usually by way of a launching shell script. Some of the heavier GP2X apps like GPE loaded a custom kernel. I don't expect many games to run on the bare metal, but I am willing to bet that a fair number of them kick the machine into runlevel 2 and return to 5 when finished.

GP2X apps don't kill the menu, the menu kills itself by running the .gpe/.gpu with exec() which replaces the menu process with new one. You then have to call exec in your app or launch script to rerun the menu.

I don't think there are many, if any, apps that change the run level, there are no significant processes running anyway.


There were a few odd occasions when experimenting on the GP2X the menu failed to exit and the program I ran and the menu both attempted to display on the screen and accepted user input. The result was an ugly slow mess. I don't quite recall how or why it happened, but it did. I was under the impression that the script or the app explicitly killed the menu. It's been too many months since my GP2X actually worked and I coded on it.

@Orkie - I thought it started a loopback that loaded another kernel with a different file system like cramfs or some such, or maybe that was the specific case where it had an included swap file.

 

[redstar1949]

Why wouldn't we just have a mode in the OS that kills the overwhelming majority of all of the "bloat" and runs very light when in a game, and when a user brings up this menu, they have the option of loading back into the full bloated OS or whatever?

 

[sindbad]

That's called runlevels. The only conceivable bloat would be the X and a window manager, which are very light. I don't get all this concern about X eating resources, it just hugs a bit of ram.

 

[cb88]

.... whenever i want to run a 3d game (i has a pretty limited GPU nvidia mx 400 ... ) i kill X and restart with TWM... in some games notably fretsonfire stemania and quake3 FPSs are noticably higher....

the lighter Xlib only wms rock for low resource usage twm jwm and i think pwm (not sure ) ... just to name a few i haven't bothered to check in fluxbox but IMO it is not nearly as light...

 

[multiplex]

Having a light-weight process that reacts on a menu button should be easy, since it's running a multitasking OS.
As far as I understand the video hardware, it shouldn't be too hard to draw your own overlay somewhat robustly either, even if it's fullscreen or non-X.
What might be hard is reliably getting the currently running game to pause, and stop drawing to the screen.
They'll probably have to handle some signals if they want robust handling of things like closing the lid, anyway, though. Actually, it might be as easy as identifying the foreground process and sending a SIGSTOP.

 

[slygamer]

What might be hard is reliably getting the currently running game to pause, and stop drawing to the screen.
They'll probably have to handle some signals if they want robust handling of things like closing the lid, anyway, though.

With the Xbox, the application receives an event via a handler function that it registers with the system at startup. The game can enter the pause state if desired. Also, the game doesn't stop drawing. The blade draws over the top of a darkened game screen.

 

[sindbad]

Processes can be paused with SIGSTOP and later resumed with SIGCONT. This works for every single process in a linux computer and it will also stop drawing.

It's also possible to just draw over with libosd or something similar, without stopping the process.

 

[logokas]

Since apparently, window managers are bloated and resource greedy, perhaps the better way of solving such issues would be to put effort into making a completely optimized window manager for the Pandora instead, make it lightweight and assign all the necessary programs for whatever purpose, while keeping it small enough to remove the need to kill it for games that need more.

The idea of pausing the game is not good. For instance, if you're playing a game of online Quake 2 on the Pandora, pausing it will most likely kill the connection it has, or at least result in something annoying. Thus, it would be recommended to keep the game running while using the 'guide'.

 

[Parkydr]

Not all window managers are bloated. e.g. Evilwm. The statically linked executable on the gp2x is only about 1 MB, twm isn't much larger.