By using this site, you agree to our Privacy Policy and our Terms of Use. Close

Forums - Microsoft - XBOX ONE BC: Here's how backward compatibility works:

Tagged games:

According to them it should run exactly as if it were running on an xbox 360 with being able to use xb1 features on it.

We'll see forsure when it launches.

I ran mass effect on my xbox one and it didnt give me any issues at all



Around the Network
exdeath said:
Some Quake 3 era shooters, some N64 games, and a bunch of puzzle and party games. Eg: nothing huge or demanding.

It's pretty clear to anyone who knows anything about hardware and software that emulating a system as powerful and bleeding edge on their launch like PS3 or 360 on a PS4 or XBone is extremely improbable. JIT cross compilers from PPC to IA64 and HLE of DX API calls will make it somewhat easier but still.

It's no surprise that none of the games in that list are outstanding in any technical capacity. A couple puzzle games and N64 platformers aren't exactly Bioshock Infinite or GTAV. Anyone thinking their favorite AAA games from 360 are eventually going to be supported on XBone through BC are going to be sorely mistaken.These big titles are going to require you to keep your 360 or rely on native XBone HD remasters.

This is the beta. Obviously more games are coming.



kontrary said:

According to them it should run exactly as if it were running on an xbox 360 with being able to use xb1 features on it.

We'll see forsure when it launches.

I ran mass effect on my xbox one and it didnt give me any issues at all


This would be a very impressive feat if it doesn't require patching or tweaking of games on a case by case basis AND it performed identical to native 360.

Sony learned the hard lesson when they tried to emulate the PS2 on the PS3 at the machine level.  Like PS3, PS2 was a radically different architecture, and had much machine level custom programming in assembly language and multiple processors and instruction sets.  When you don't have APIs and excellent first party API/SDK support, you're pretty much stuck at emulating at the instruction by instruction level which absolutely cannot happen with 7th gen to 8th gen.

Writing a DrawPrimative wrapper around another version of DirectX or whatever you wanted really is a far far more sane approach.

Microsoft has a clear advantage here in that they have been providing and supporting APIs/SDKs for DECADES, so if 360 is purely API/OS system call oriented to do everything, it really wouldn't be near as difficult as I described earlier as you're just writing API wrappers at a much higher level.  I was refering to machine level instruction by instruction emulation in my first post.  As in look up a byte, parse the opcode, look up the parameters, check load/store ranges for special memory addresses for hardware I/O, etc.



exdeath said:
kontrary said:

According to them it should run exactly as if it were running on an xbox 360 with being able to use xb1 features on it.

We'll see forsure when it launches.

I ran mass effect on my xbox one and it didnt give me any issues at all


This would be a very impressive feat if it doesn't require patching or tweaking of games on a case by case basis AND it performed identical to native 360.

Sony learned the hard lesson when they tried to emulate the PS2 on the PS3 at the machine level.  Like PS3, PS2 was a radically different architecture, and had much machine level custom programming in assembly language and multiple processors and instruction sets.  When you don't have APIs and excellent first party API/SDK support, you're pretty much stuck at emulating at the instruction by instruction level which absolutely cannot happen with 7th gen to 8th gen.

Writing a DrawPrimative wrapper around another version of DirectX or whatever you wanted really is a far far more sane approach.

Microsoft has the advantage here that have been providing and supporting APIs for decades.


Id love to see a video explaining how they did it and what difficulties they had haha, in mass effect i didnt notice the texture popins that were prevalent in the 360 version.

Its very exciting for me cause I have a backlog of games I didnt finish and I dont want to replug my 360 to get through them



Now I have to question if they have an easy time provided backward compatibility with high level API redirection "emulation" then why the hell didn't this come about much much sooner?

For more info on what I mean, look up the N64 emulator Ultra HLE (HLE stands for High Level Emulation). It was a revolutionary new type of emulation at the time if I'm not mistaken that was based on recognizing that as modern systems became more like PCs with first party provided operating systems and SDKs that forced you to go through API.  Most performance critical work would passed into the SDK by well documented function calls eg glVertex4f(float x, float y, float z, float w ); that the first party had optimised library code written for and that all you had to do to emulate was translate the function calls with a simple wrapper (Facade and Decorator design patterns for the C++ OOP crowd). What non API specific user CPU code that remained was just basic non performance critical management and main loop code that made API and syscalls that could be easily interpreted or cross assembled and cached in native machine code on the host VM with a runtime JIT recompiler.

It's a very different paradigm for emulation compared to fetching and fast switching bytes at opcode level and writing a clock accurate fully simulated CPU.  This latter is very resource intensive and inefficient and mostly unnecessary on systems that adhere to very strong OS and API models to do the majority of the high performance work.

Graphics is my specialty, not emulation (I was writing an OpenGL mini port in assembly language on the PS2 with full asynchronous DMAC chaining/VIF/VU1/GS even with multiple dynamically uploaded VU1 vertex programs based on the OpenGL state changes before other things came up in life.)  

So I could be wrong, but I believe Ultra HLE was the first widely successful experiment in this type of high level emulation, and this HAS to be what 360->XBO is doing if it actually ends up being good.  There is just no way these relatively slow AMD APUs are going to be performaning instruction level emulation of Xenon with any resemblence to native 360 performance.



Around the Network
kowenicki said:
walsufnir said:
Entered the thread in hope for technical bits, saw only things we know (well, those who are interested, at least).


what do you want?

it tells you everything.

A full emulator is installed on your xbox one.  the end.

Except it isn't. A full emulator would allow you to play your game directly off the disc (Like the PS2 emulator in the PS3 did - after Sony removed the emotion chip and went for software based b/c), or install directly off your disc, it would also not be confined to just a handful of games. So it being not a full emulator those who are interested are interested in knowing the technical ins and outs of how Xb 360 games get converted into being playable using the not-quite-full emulator.

Somehow I doubt MS will ever be that forthcoming though, so we are left to rely on educated deductions from those who know about the techhie stuff.



“The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt.” - Bertrand Russell

"When the power of love overcomes the love of power, the world will know peace."

Jimi Hendrix

 

exdeath said:
kontrary said:

According to them it should run exactly as if it were running on an xbox 360 with being able to use xb1 features on it.

We'll see forsure when it launches.

I ran mass effect on my xbox one and it didnt give me any issues at all


This would be a very impressive feat if it doesn't require patching or tweaking of games on a case by case basis AND it performed identical to native 360.

Sony learned the hard lesson when they tried to emulate the PS2 on the PS3 at the machine level.  Like PS3, PS2 was a radically different architecture, and had much machine level custom programming in assembly language and multiple processors and instruction sets.  When you don't have APIs and excellent first party API/SDK support, you're pretty much stuck at emulating at the instruction by instruction level which absolutely cannot happen with 7th gen to 8th gen.

Writing a DrawPrimative wrapper around another version of DirectX or whatever you wanted really is a far far more sane approach.

Microsoft has a clear advantage here in that they have been providing and supporting APIs/SDKs for DECADES, so if 360 is purely API/OS system call oriented to do everything, it really wouldn't be near as difficult as I described earlier as you're just writing API wrappers at a much higher level.  I was refering to machine level instruction by instruction emulation in my first post.  As in look up a byte, parse the opcode, look up the parameters, check load/store ranges for special memory addresses for hardware I/O, etc.

It does, for every game that gets put into the b/c list. It's why you can't just play a 360 game directly from your 360 disc. People with a better understanding of what tweaks are needed have explained what sort of modifications are likely to be undertaken to make a game Xb one ready. It's much less than actual porting, but it's not nothing.



“The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt.” - Bertrand Russell

"When the power of love overcomes the love of power, the world will know peace."

Jimi Hendrix