News & Rumors: Xbox One (codename Durango)

[Shifty Geezer]

The system OS has to have access to the game's front buffer to composite it with the system UI elements. Oh, I suppose conceptually the game content could be going to the composition chip and the system just sends instructions to that chip to scale and position the game content, without accessing the game's video buffer. So you'd have two buffers, OS and game, and the only place they meet is during composition for final output.

As for DRM, even if in principle they exist, no-one enforces them. You can screen capture on every device under the sun, from PC to tablets to PS4. I can't believe any dev releasing a game would then want to stifle viral marketing by not allowing people to share screens! Especially when they can share videos. The only reason for that is to inhibit pixel counters, and they don't necessarily need screenshots for that (DF captures HDMI out).

 

[Dave Baumann]

See my point a few posts up.

 

[Deleted member 11852]

The system OS has to have access to the game's front buffer to composite it with the system UI elements.

What is the system OS?

Which OS do you think is ultimately in control? 1) Game OS. 2) App OS. 3) Hypervisor ? I.e. what's managing the dashboard and what relationship does it have with the other two OSs?

 

[Shifty Geezer]

What is the system OS?

The 'app OS' as you call it. That's the OS that users interface with and decide what the console is going to do (as I understand it).

 

[function]

The game os and the dash os pass stuff between each other through an API. Might require work on both sides, and might also not work for old games baked onto a game os with out there API changes.

 

[Deleted member 11852]

The 'app OS' as you call it. That's the OS that users interface with and decide what the console is going to do (as I understand it).

Users also directly interface with the game OS as well, or does gamepad input go through the app OS with the game OS basically being subordinate?

Anyway it doesn't matter, this is likely the problem. The hypervisor - the only software layer with complete access to the video hardware and frame buffers - is likely doing the final compositing and the app OS likely has no way of access this for screen dumps.

Design-wise it doesn't need too, it only needs to know things in abstract like a game is running, whether it's full screen or not, and that x, y and z UI elements are on screen.

Adding screen capture probably means modifying the compositor to have an output for App OS software (the screen capture) to tap into and APIs for both to communicate.

 

[Shifty Geezer]

Users also directly interface with the game OS as well, or does gamepad input go through the app OS with the game OS basically being subordinate?

The users launch the 'game OS' from the 'system OS'. Tey also launch apps from the 'system OS'. They can't launch the system OS from the game OS, or launch apps from the game OS. Hence there's clearly a hierarchy if even both system OS and game OS are on the same tier regards the hypervisor (not sure if my choice of words are apt here).

Anyway it doesn't matter, this is likely the problem. The hypervisor - the only software layer with complete access to the video hardware and frame buffers - is likely doing the final compositing and the app OS likely has no way of access this for screen dumps.

That's fair. I wasn't factoring in the hypervisor properly and it's HW extraction, forgetting that the system OS is a VM.

Adding screen capture probably means modifying the compositor to have an output for App OS software (the screen capture) to tap into and APIs for both to communicate.

Yes. You'd want an output from the hypervisor to a file and for that file to be passed to the system OS. I don't think a game API would be necessary as the hypervisor will have access to the video buffer. So updating my original theory, where I'm wrong about the 'System OS' (app OS) having access to the FB and being able to copy the data to a file, there is still an OS somewhere with access to the FB that should have no trouble turning it into an image.

 

[Deleted member 11852]

The users launch the 'game OS' from the 'system OS'. Tey also launch apps from the 'system OS'. They can't launch the system OS from the game OS, or launch apps from the game OS. Hence there's clearly a hierarchy if even both system OS and game OS are on the same tier regards the hypervisor (not sure if my choice of words are apt here).

This sounds incredibly messy and overly complicated, borderline insane. So the hypervisor sits on the hardware and abstracts and arbitrates hardware access between two VMs but one VM (game OS) is subordinate to the other (app OS) VM yet has - by virtue of necessary - higher priority to most of the hardware.

How do you even architect a meta hypervisor in this way? I really wish Microsoft would talk more about this.

Yes. You'd want an output from the hypervisor to a file and for that file to be passed to the system OS.

Probably not a file as you really don't need (or want) the hypervisor mucking around with VM's filesystems, an API call with a big data packet would work as well without the I/O overhead. Then the image could be made available to both VMs and we have no idea how the sandboxing of data works in the app OS VM.

Anyway, O/T

 

[mrcorbo]

This sounds incredibly messy and overly complicated, borderline insane. So the hypervisor sits on the hardware and abstracts and arbitrates hardware access between two VMs but one VM (game OS) is subordinate to the other (app OS) VM yet has - by virtue of necessary - higher priority to most of the hardware.

How do you even architect a meta hypervisor in this way? I really wish Microsoft would talk more about this.

If you're trying to keep the GameOS as thin as possible, it makes perfect sense to have another external system manage it since this allows you to leave those management functions out of the GameOS itself.

What is it about this model that bothers you exactly?

 

[Deleted member 11852]

If you're trying to keep the GameOS as thin as possible, it makes perfect sense to have another external system manage it since this allows you to leave those management functions out of the GameOS itself.

If you want the game OS to be as thin as possible don't layer it two levels below the hardware.

I'm not convinced this is actually how the OS layers are organised, a straight hierachial implemented barely needs a hypervisor at all, just a smart kernel arbitration. Unless the hypervisor is intended for forward-compatible abstraction, i.e. Xbox Two. But then Microsoft are shaving off performance today to make backwards compatible easier tomorrow. It's a valid choice, though.

 

[Shifty Geezer]

This sounds incredibly messy and overly complicated, borderline insane. So the hypervisor sits on the hardware and abstracts and arbitrates hardware access between two VMs but one VM (game OS) is subordinate to the other (app OS) VM yet has - by virtue of necessary - higher priority to most of the hardware.

How do you even architect a meta hypervisor in this way? I really wish Microsoft would talk more about this.

That was talking about the 'system OS' from the user perspective (what's the 'System OS'? The one the users interact with to launch stuff). Basically getting in a tangle with the naming of the OSes. I see them as Game OS, System OS, and hypervisor.

Probably not a file as you really don't need (or want) the hypervisor mucking around with VM's filesystems...

Okay, image buffer then, Mr. Pedantic. Send that to the System OS to turn into a file.

 

[AlNom]

How about modifying the home button behaviour? Maybe a quick tap for screenshot and a slighting longer tap for normal behaviour. Or single tap vs. double tap.

Maybe. However, they've already got double tap for swapping two apps (I think?), so it might confuse people. Also, how long does a person wait until taking a second screenshot etc.

I was thinking maybe having folks hit both bumpers, both sticks, and both triggers all at once (*finger crunch* >_<) - all buttons that the hand is already naturally placed upon, but I'm not so sure the new bumpers make that easy (vs 360). Don't know if there are any games that have ever assigned a function as such (not too sure how the Rock Band/Guitar Hero instruments assigned the extra functions in SW).

edit:

I just remembered that the button is at the very top of the controller now, which would make it a bit inconvenient because I imagine a number of folks want to take the screenshot while the action is going and their hands are possibly occupied or just plain out of reach (need to be fast). If they had it like the 360 controller, the guide button would at least have been a fair bit closer to the right stick (easier stretch).

edit2:

Maybe they'll be thinking about having additional buttons on the wired headset controller attachment.

 

[Deleted member 11852]

Maybe they'll be thinking about having additional buttons on the wired headset controller attachment.

Retrofitting a standard function into an existing control scheme not designed for it is always tricky. They could just provide the function for games and let games decide how screen shots will be taken. Much like 'photo mode' which is beginning to creep into more and more games.

 

[AlNom]

They could just provide the function for games and let games decide how screen shots will be taken.

Yeah, that might be for the best in terms of implementating a button, but it still means more work for every game developer on just one platform.

 

[mrcorbo]

If you want the game OS to be as thin as possible don't layer it two levels below the hardware.

I don't believe it is two layers below. I think the SystemOS VM has the ability to manage/support the GameOS VM (starting it, stopping it, providing services for it). That doesn't mean that the SystemOS VM sits between the GameOS VM and the hypervisor

 

[BRiT]

Better yet, maybe the question is how do you want screenshot to work? If you're running a game and have an app snap mode, what does the screenshot contain? What do you want it to contain? Do you screen shot the game? Do you screenshot the app? Do you screenshot the composite of game and app?

 

[dobwal]

Even if could, how would you go about snapping screen shots during a game. The Xbox button is already tied to bringing up the UI and Snap. Is triple pressing the Xbox button to screenshot a viable option? I guess you could snap and have a screen shot app. But thats seems like a convoluted procedure just to do a screenshot.

I don't think its a technical reason as the xb1 when bringing up the UI during the game basically minimizes the game and displays the last frame in the main screen space. Also my xb1 and TV don't get along sometimes and won't handshake properly so I get a few seconds of the last TV frame before the xb1 error "we lost the signal" screen.

 

[AlNom]

Too many presses to capture the moment you want.

Maybe they should just take them from the video recording.

 

[dobwal]

Too many presses to capture the moment you want.

Maybe they should just take them from the video recording.

I guess they don't want to do that because its not native or upscaled 1080.

 

[BRiT]

Even if could, how would you go about snapping screen shots during a game. The Xbox button is already tied to bringing up the UI and Snap.

Double-tap + Y = Screenshot That.

Since Double-tap + X = Record That.

That's the natural progression I would use.