New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Milestone: v0.2 planning #1318

Open
RadWolfie opened this Issue Jun 28, 2018 · 16 comments

Comments

Projects
None yet
4 participants
@RadWolfie
Member

RadWolfie commented Jun 28, 2018

@Cxbx-Reloaded/developers You have permission to edit OP post for any updates or take assignment.
Contributors are welcome to send pull request to origin progress branch to get the job done quicker. 馃槈

Here's the plan for future v0.2 release.

  • CPU Emulation (general improvements if any bugs found)
    • LLE GPU improvements [Graphic devs]
    • LLE APU feature [Audio devs]
    • LLE USB feature [ergo720] - doesn't work yet because of kernel issues
  • Improving our HLE kernel [LukeUsher]
  • Use open source API to move registry data into ini file. [RadWolfie]
  • HLE DirectSound, audio, improvements [RadWolfie]
    • See issue #1132 (Must be done first before proceed fix remaining bugs)
  • Create list of patches than search in symbol address list. [RadWolfie]
    • See progress in #1416 task
    • Then we do not need LLE flags in HLE cache file. (We will need to rename it to Symbol cache or the like.)
    • Plus start removing all FUNC_EXPORTS (except for kernel APIs?).
  • HLE Selection renderer/audio support. (all feature may not be complete at release as they are more of a proof of concept what could be done in HLE)
    • [G] DirectX9 feature [Graphic devs]
  • Log filtering support [ergo720]
    • Useful to only filter specific library sections to a log file plus some other miscs.
    • Log specific level, such as debug, info, warning, errors.
  • GUI log indication [RadWolfie]

What other tasks we should do?

Postpone:

  • CPU Emulation [LukeUsher, v1.0 milestone]
  • GUI v2.0 [v1.0 milestone] (by using QT to support cross-platform)
    • Will be working with several various contributors.
    • See issue #677
  • HLE OpenGL feature
  • Loading and running a REAL Xbox kernel/bios [LukeUsher]
  • HLE OpenAL Soft feature

Scrap from plan:

  • Split kernel and GUI codes into 2 executable (again)
    • By doing this method will allow kernel to load all settings without GUI set it up.
    • Once separation is done, we can finally start switch to GUI v2.0 development
@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jun 28, 2018

Split kernel and GUI into two executables is wrong :P What will most likely end up happening is the GUI and Emulator will remain one executable, but there won't be any process relaunching. The virtual xbox will be able to start/stop/pause at any time! (With CPU emulation & LLE we could even support save states, etc).

This will also mean multi-xbe titles won't cause weird issues: We'll just reboot the emulated Xbox with no process relaunch

CPU emulation also means a debugger can be part of the main emulator instead of a separate program: And with LLE it will be able to peek/poke hardware registers/state, as well as step through code execution one instruction at a time, view all registers, etc. The current debugger is pretty limited in this regard.

@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jun 28, 2018

Oh another thing:

We NEED a CMake build system, Cxbx-Reloaded should be able to be compiled with at least MSVC and GCC.

A single CMake project can generate MSVC solutions and GCC makefiles, alternatively, we could maintain the MSVC solution and a Makefile manually. Either way, we need to take steps towards working cross platform.

From this point forward, Windows specific code will not be allowed either, unless it is a bug fix or minor tweak to existing Windows specific code.

The effort to being cross-platform starts now.

HLE code can remain Windows specific for now but it will be migrated to cross platform over time. Even if we keep the existing DSOUND/D3D HLE, there must be cross platform alternatives made available.

LLE must be completely cross platform going forward, no dependencies on any specific operating system

@ghost ghost added the informational label Jun 28, 2018

@RadWolfie

This comment has been minimized.

Member

RadWolfie commented Jun 28, 2018

True, we do need a CMake build system. Though, I don't think we can completely remove Windows' functions before v0.2 release. Since it will not be able to build other platform within 6 months yet. Might be possible in v0.3 release plan.

It's my prediction theory, though. If we do get a lot of work done quickly, then sure.

EDIT:

Even if we keep the existing DSOUND/D3D HLE, there must be cross platform alternatives made available.

Updated the list for selection options in HLE.

@ghost

This comment has been minimized.

ghost commented Jun 30, 2018

Just a suggestion: if a release implements all the features of above, you could very well call it version 1.0 in my opinion

@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jun 30, 2018

That may well happen, v0.2 is just a tentative release version number: A more suitable verison number will be chosen closer to completion.

@RadWolfie

This comment has been minimized.

Member

RadWolfie commented Jul 2, 2018

@ergo720 True. Though for 6 months, not all of us will have tons of free time. So, it's possible only half or 3/4 of the planning will be ready in 6 months. It's a lot of stuff to work on.

Also, I consider full ability to support cross-platform as 1.0 with complete features support mainly LLE stuff. 馃槈

P.S. Sorry for my late input.

As for having CMAKE generate MSVC solution and GCC makefiles sound pretty good to maintenance projects/makefiles without need to manually update both sides.

@ghost

This comment has been minimized.

ghost commented Jul 2, 2018

Another question: from the above features I see that OpenAL is being mentioned, so has that proposal been resurrected? According to #807, I thought it was decided not to implement it. I'm just asking by the way, I have nothing against it.

@RadWolfie

This comment has been minimized.

Member

RadWolfie commented Jul 2, 2018

Is HLE DirectSound implement cross-platform compatible? Answer: No, OpenAL do. Beside, both options will be provide as proof of concept. DSP binary will not be support in HLE environment. Except environment sound effects will be supportive in OpenAL-soft.

To emulate audio better is to use LLE for support DSP binary. It will be pain in the butt. We'll get there eventually.

Although for LLE audio emulation, we might find a better solution than to use OpenAL which only need to stream direct to audio hardware (with decoder requirement for XADPCM).

Is the comment clear enough for you to understand @ergo720?

@x1nixmzeng

This comment has been minimized.

Contributor

x1nixmzeng commented Jul 2, 2018

@LukeUsher I have a question about the state of the debugger for this next milestone

At the moment it handles the Cxbx process through the Windows debugging API. Depending how the CPU is to be emulated a GDB stub could be written instead to expose Xbox memory - allowing other third-party debuggers - such as the C# version - which could be updated. The alternative is to stip it out completely.

What are your ideas?

@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jul 2, 2018

With the real Xbox kernel, you could attach directly to the Kernel debugger via en emulated serial port, or XBDM over the network. You could connect IDA Pro to this directly, or even use official XDK tools if you have them, to debug software running under Cxbx-R.

@RadWolfie RadWolfie removed the enhancement label Jul 3, 2018

@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jul 26, 2018

Currently thinking I want a working/complete DirectX9 port for version 0.2 I also want it to be the default option.

The benefits for HLE are incredible:

  1. Better driver support/more stability
  2. Support for more texture and vertex data formats
  3. The biggest one: Support for shader models > 1.1 allowing for complex vertex and pixel shaders that are impossible to convert for DX8 to be converted accurately.

This has potential to dramatically improve compatibility and rendering accuracy: Specifically games with missing effects, T-pose models, corrupted vertices, etc will likely improve dramatically.

CPU emulation is still happening, but it's a big project, likely too much for v0.1 but it's a bigger project, more work, and likely reason enough to do a major 1.0.

I suggest scrapping CPU emulation, GUI 2.0 off this list: Because they are more suited for a major release such as 1.0 than minor releases, and they will likely take several months to complete, i'd rather not have to delay 0.2 if everything is complete except for these tasks.

@RadWolfie

This comment has been minimized.

Member

RadWolfie commented Jul 26, 2018

I agree. I made an update to the OP to reflect your suggestion.

Any time a feature/improvement is postpone from milestone, move them into postpone section. Or if really going to scrap anything from current plan and the future. Put them in scrap section.

P.S. LLE APU will be taking awhile. I'm thinking about postpone HLE OpenAL-soft to v0.3 plan or later.

@CakeLancelot

This comment has been minimized.

Member

CakeLancelot commented Jul 26, 2018

So would v1.0 be the more likely target for cross-platform/Cmake support or is it still an item on the list for v0.2?

@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jul 26, 2018

I'd say potentially further than that: cmake support could come in 1.0 but being fully cross platform requires the entirety of the emulator to be rebuilt, which is a long, gradual process.

Pretty soon (as in, within another release or two) there will be introduced a rule that windows specific code will no longer be accepted though: Any new development needs to be cross platform (eg: using std libraries instead of winapi)

@RadWolfie

This comment has been minimized.

Member

RadWolfie commented Jul 26, 2018

Correct, GUI system is still fixed for windows platform. Not all of std libraries has everything we need. There is more work require to bring cross-platform on the table.

@LukeUsher

This comment has been minimized.

Member

LukeUsher commented Jul 26, 2018

One thing I'd like to add to this: A vertex buffer cache is required for v0.2. It will improve performance in titles that use types that need conversion (quads, etc). This should be an enormous performance improvement for Metal Slug series, buffy the vampire slayer, and more.

@LukeUsher LukeUsher modified the milestone: v0.2 Jul 31, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment