Next Generation Emulation banner

101 - 120 of 134 Posts

·
Registered
Joined
·
423 Posts
Well, I must admit that I haven't looked into how the enlargement of the display window is being handled exactly. We let DirectX handle it, so it could either stretch the surface (duplicating pixels) or it could draw more pixels, I really don't know what's happening (yet).

All we had to do, was to mention the viewport size and DirectX does the rest. (I did found out that using a window-inside-a-window doesn't give the same enlarging behaviour, so we're sticking to the current drawing method until we find something even better)

And yes, fullscreen is supported too (and the Alt+Enter shortcut actually works) in any available resolution you'd want to configure. All this is inherited from Cxbx however, so it's nothing new (except the stretching in windowed mode - Cxbx doesn't allow resizing while we do).
 

·
Registered
Joined
·
45 Posts
Dxbx indeed stretches the viewport to fit the window, but we don't (yet) support resizing during emulation, so you'll have to size the window to your liking *before* starting a game. But at least it's possible ;)
Letting the players set the resolution will likely cause problems with some games. The game must support higher resolutions in order to work properly because a few things might be hardcoded. For example: Panzer Dragoon Orta will look strange - the UI elements have their positions hardcoded, not to mention the game uses a 512x384 texture as a render target for the world, voiding any advantages of a higher resolution. That's just one example... many other games might not work properly if you force the resolution.

And yes, fullscreen is supported too (and the Alt+Enter shortcut actually works) in any available resolution you'd want to configure. All this is inherited from Cxbx however, so it's nothing new (except the stretching in windowed mode - Cxbx doesn't allow resizing while we do).
Actually, Cxbx does let you resize the window. At least my version does.
 

·
Registered
Joined
·
376 Posts
Letting the players set the resolution will likely cause problems with some games. The game must support higher resolutions in order to work properly because a few things might be hardcoded.
Which is why N64, PlayStation 1/2, DreamCast, GameCube, and Wii games have so many problems rendering at hi-res.

Oh wait, they don't.

(Note that Dolphin in particular even includes an option for rendering at native resolution just in case)
 

·
Registered
Joined
·
423 Posts
Halo 2 is build using link-time-optimized libraries, making it near impossible to automatically & generically detect symbols. As a result, Dxbx will not support those type of titles. Your best chance would be with Xenoborg (the low-level Xbox1 emulator, being worked on by Blueshogun96, albeit at a slow pace), I'm afraid...
 

·
Registered
Joined
·
96 Posts
Halo 2 is build using link-time-optimized libraries, making it near impossible to automatically & generically detect symbols. As a result, Dxbx will not support those type of titles. Your best chance would be with Xenoborg (the low-level Xbox1 emulator, being worked on by Blueshogun96, albeit at a slow pace), I'm afraid...

Even if one day DXBX will be "successful" as PCSX2 or Dolphin? :(
I don't except the emulator to be Compatibility as those emulators,any time soon,but what IF you will get highest Compatibility some day?
will you consider to support the "Hardest" titles?

ho,and I think Xenoborg project,is dead,or am I wrong?
 

·
Registered
Joined
·
423 Posts
Well, in order to support link-time-optimized titles, we need be able to patch functions at their right addresses. Our symbol-detection algorithm will probably still find a lot of symbols, but I suspect that many important functions won't be detected. So these titles need to be manually investigated to pin-point all important functions. Apart from that, our patching relies on very specific function signatures (arguments & calling convention)... and link-time optimization could well disturb that too, probably resulting in stack-corruption, crashes, etc.

So yeah, if Dxbx ever becomes immensly popular, there's still a *slight* possibility that we *could* run these kind of titles, but I wouldn't bet on it...
 

·
Registered
Joined
·
376 Posts
Though, I would imagine Xbox games with PC ports would be low on the priority list anyway...
 

·
Registered
Joined
·
376 Posts
Well, there is one thing C/Dxbx should have going for it - native x86 code execution. This should make C/Dxbx THE emulator to use for multi-platform games due to much better performance.
 

·
Registered
Joined
·
18 Posts
so umm... whens the next release??.... just asking.. dont flame me please... I'm only human. For the love of all things.. no... dont... no... please ......stop... noooooo.............

:dead:
 

·
Registered
Joined
·
376 Posts
Usually these kind of projects don't really follow a development schedule which means they don't get developed consistently, which therefore means you can't really give an accurate date.
 

·
Registered
Joined
·
423 Posts
Nintendo Maniac is right; We don't follow a predetermined schedule. At the moment I'm a bit tired & having the flu, so I'm not commiting as much as I used to do, although we still work regularly on Dxbx (look here for our progress : SourceForge.net: dxbx - Develop).

Anyway, I'm still working on the symbol detection code - as I've said before, this new design is better in many ways, but is not yet on an acceptable compatibility level. As soon as I've got all SDK samples working again (and maybe a game or two), we'll release a new build.

Apart from the symbol detection, we're also fixing, improving & extending Dxbx regularly - there's all kinds of bugs and oversights we inherited from Cxbx (or introduced ourselves during our translation efforts).

So all I can say is : stay tuned, we're still working on it.


On a personal note, I'm more and more convinced that High Level emulation (using hundreds of patches) is not the best way to go in the long run. That's why I'm also looking into a hybrid approach, in which we could try to run with less patching and more hardware emulation (but going completely low-level is also too much I think). Maybe I'll write more on this later.
 

·
Registered
Joined
·
376 Posts
Yeah, LLE-ing an x86 CPU when you're already running on an x86 CPU is just silly. :p (not to mention x86 emulation is apparently hard and SLOW - see DosBox)

And isn't LLE typically always the better option in then long run?
 

·
Registered
Joined
·
423 Posts
Yes, dynarec could indeed work on x86 (and even on other CPU's), but there's another method which blueshogun is trying in Xenoborg : Native code execution, using a page fault handler on specific guard pages to support emulation of absent hardware addresses. The fault handler can identify the address and operation being executed, and emulate it in some way. The hard part is of course to identify the behaviour of all hardware addresses, and working out a decent enough emulation. The renouveau project can be a great help for the NV2X graphics chip, but that's 'just' the graphics side; There's lots more to it, so that approach has probably bigger potential for full emulation, but is also much more work.
 
101 - 120 of 134 Posts
Top