11–20 of 62 posts
As a day-to-day C# developer, I'm curious about a few things: - Do you ever find that the Garbage Collector causes noticeable pausing in the emulator? - Did you do this with 100% managed memory, or do you need to use unsafe code / real pointers? (Apologies that I didn't read the source code.)
This is great. It would be almost perfect if it didn't rely on WinForms (1) and was built on .NET core from the ground up. Anyway, great project I will keep checking out. (1) instead it could be a runtime that just gives you an interface to the frame buffer somehow and it's up to the integrator to use WinForms/WPF/Qt etc.
I think SDL2-CS[0] would be an awesome candidate for a platform-independent implmentation. Gives you a ton of low-level control. [0] https://github.com/flibitijibibo/SDL2-CS
> ProjectPSX dosn't use any external dependency and uses rather simplistic C# code.
And for a learning project I think the ability to download the code and get it to run immediately without hunting for dependencies, is a very important property. More important I'd say than complicating the code to make it run everywhere.
As a day-to-day C# developer, I'm curious about a few things: - Do you ever find that the Garbage Collector causes noticeable pausing in the emulator? - Did you do this with 100% managed memory, or do you need to use unsafe code / real pointers? (Apologies that I didn't read the source code.)
I haven't read the code, but you usually don't let the garbage collector get a chance to do anything with projects where it matters.
However, for an ancient platform on modern hardware I guess the per-frame budget is plentiful even for an emulator.
Earlier quoted context omitted.
I think SDL2-CS[0] would be an awesome candidate for a platform-independent implmentation. Gives you a ton of low-level control. [0] https://github.com/flibitijibibo/SDL2-CS
It would conflict with this, though: > ProjectPSX dosn't use any external dependency and uses rather simplistic C# code. And for a learning project I think the ability to download the code and get it to run immediately without hunting for dependencies, is a very important property. More important I'd say than complicating the code to make it run everywhere.
As a day-to-day C# developer, I'm curious about a few things: - Do you ever find that the Garbage Collector causes noticeable pausing in the emulator? - Did you do this with 100% managed memory, or do you need to use unsafe code / real pointers? (Apologies that I didn't read the source code.)
Otherwise, everything looks statically allocated. So there should be no GC collections at all.
Earlier quoted context omitted.
It would conflict with this, though: > ProjectPSX dosn't use any external dependency and uses rather simplistic C# code. And for a learning project I think the ability to download the code and get it to run immediately without hunting for dependencies, is a very important property. More important I'd say than complicating the code to make it run everywhere.
A platform independent desktop UI framework really is the biggest gap in the .NET platform right now, and I think Microsoft knows it. We'll probably see something new on that front soon, I'd wager.
Earlier quoted context omitted.
I haven't read the code, but you usually don't let the garbage collector get a chance to do anything with projects where it matters.
In fact, the techniques for C# here would be pretty much the same as for C++ or C: Don't do dynamic allocation in the hot path. And if you must, keep the lifetime short so it gets cleaned up predictably (usually in gen0). However, for an ancient platform on modern hardware I guess the per-frame budget is plentiful even for an emulator.
Earlier quoted context omitted.
It would conflict with this, though: > ProjectPSX dosn't use any external dependency and uses rather simplistic C# code. And for a learning project I think the ability to download the code and get it to run immediately without hunting for dependencies, is a very important property. More important I'd say than complicating the code to make it run everywhere.
A platform independent desktop UI framework really is the biggest gap in the .NET platform right now, and I think Microsoft knows it. We'll probably see something new on that front soon, I'd wager.
MS has no interest in this space [0]. Your best bet at this moment is Electron or other open source alternates like eto forms.
[0] - Scott hunter's .net rocks podcast. The related commentary is past 30 mins from beginning of the show - https://www.dotnetrocks.com/?show=1634
Earlier quoted context omitted.
In fact, the techniques for C# here would be pretty much the same as for C++ or C: Don't do dynamic allocation in the hot path. And if you must, keep the lifetime short so it gets cleaned up predictably (usually in gen0). However, for an ancient platform on modern hardware I guess the per-frame budget is plentiful even for an emulator.
Yeah, which is the problem with GC'd languages because it isn't always obvious where allocation will occur.