Refactor sdirectsound to allow multiple implementations

Question

Refactor sdirectsound to allow multiple implementations

Closed this issue a year ago · 5 comments

When the SDL implementation would still "push" audio to SDL and I was adding the "pull"-based CoreAudio support, I deliberately tried to stay within the structure of the SDL code and #ifdef'ed my way around.

Now that the SDL implementation is also "pull"-based, we should be able to define a suitable base class and split up the implementations for cleanliness. Right now there are 19 #ifdefs in my version of sdirectsound.cpp which is quite ugly.

If you have some time to sketch out where you'd like a new base class to live (common?) I can attempt to write up a PR.

sh95014#41

sh95014 commented a year ago

ref: #124

Answer 1 · 2023-06-16T07:41:56.000Z

There is not a well defined interface for different frontends.

Some of it is virtual in the Frame
some of it is link-time like https://github.com/audetto/AppleWin/blob/master/source/linux/linuxinterface.h
and some via static https://github.com/audetto/AppleWin/blob/master/source/linux/paddle.h#L27

1 has its own issues (we need to revisit the Frame hierarchy), but probably if well done would be the best.

I think that if we fix the hierarchy, then we have a path for this too.

Answer 2 · 2023-12-10T20:14:53.000Z

Looks like #115 basically fulfills this?

I've split the CoreAudio implementation out of sdirectsound.cpp now.

Answer 3 · 2023-12-11T11:52:52.000Z

I am pleased it made your life easier.
I still think the hierarchy of Frames should be revisited.

If you have other immediate suggestions, do comment here, or close it.

Answer 4 · 2023-12-12T15:14:48.000Z

Agreed that sdlframe should probably be refactored, as that's my only remaining dependency on the SDL port. I'll take another look at it when I get some time.