Source update or updated plugin API?

[DerekTurtleRoe]

Could you guys update the source code in the repository to the latest version?

If you want to wait until the next version comes out, that would be fine, I just want the updated source if possible. This code appears to be quite older than I thought.

Also, if somebody wants to make a plugin for DEmul, the plugin API seems out of date as well. If you could update that that would be great.

Thanks.

[p1pkin]

plugin 'API' header available for developers per request. on practice, during many years there was no single side person who whish to develop something for Demul, or collaborate, or anything else.

[fuel-pcbox]

@p1pkin That's absolutely no excuse for keeping the source closed, you fucking parasite.

[fuel-pcbox]

@vgturtle127 Says the guy who tried to ask nVidia upfront for docs like some kind of clueless idiot.

[fuel-pcbox]

@vgturtle127 I highly doubt that. nVidia has been known to be extremely cloak-and-dagger about their hardware. Everyone knows that.

[p1pkin]

is it really true ? I'm tend to think you are lying, it seems you are just a sources collector, not real developer but if KrossX needed it for his plugin - feel free to contact me/us.

2015-12-31 5:04 GMT+02:00 vgturtle127 notifications@github.com:

Could I have the API? I am looking into making some plugins...

— Reply to this email directly or view it on GitHub https://github.com/p1pkin/demul/issues/356#issuecomment-168113714.

[p1pkin]

its not excuses, this is my/our fucking sources, it is result of our fucking work, and we do with them whatever we fucking want, without single excuses to anyone.

2015-12-31 6:43 GMT+02:00 MoochMcGee notifications@github.com:

@p1pkin https://github.com/p1pkin That's absolutely no excuse for keeping the source closed, you fucking parasite.

— Reply to this email directly or view it on GitHub https://github.com/p1pkin/demul/issues/356#issuecomment-168124588.

[p1pkin]

the truth is - we are shared and sharing results of our work, like API, documentation, or whole plugin sources, or other emulator parts, BUT not to emukiddies like you guys, but to real developers.

[fuel-pcbox]

@p1pkin You should be sharing it with everybody. Not doing so makes you a parasite, leeching off of other people's work without returning anything.

[fuel-pcbox]

Also, I've actually developed semi-functional emulators, so do yourself a favor and shut the fuck up.

[p1pkin]

leeching off other people's work ? what are you talking about ? if there is some info or results of my/our work / researches (or some research done in collaboration with authors of other closed-source emulators like Makaron) I/we want to share - this is done through MAME and its sources (since I'm a mamedev as well) and btw, as a MAMEdev I see there is very little benefits of being OS, besides getting tons of various shitty forks like 'No Nag' and other crap. with almost zero 3rd-party contributions back to main project's repo.

so, please, get lost and go leech NY ;)

[fuel-pcbox]

And yet, MAME is still one of the worst Dreamcast emulators... Mkay.

[p1pkin]

hey, but its open source right ? so, in theory, any developer can contribute anything Dreamcast or whatever emulation-related. but on practice this doesn't happens. and also there is nullDC/Reicast, and new dreamvm, with (unsurprisingly) exactly the same "benefits" from being OS, I.e. zero emulation-related contributions.

and what's why I so skeptic about opening sources.

[fuel-pcbox]

@p1pkin You do realize that Squarepusher has been fixing bugs in Reicast for his libretro port, right?

[p1pkin]

Square-troll able to fix emulation related bugs ? really ? I can believe he can fix something in backend, but not in emulation core(s), it seems out of his league.

[MooglyGuy]

Would just like to point out that MoochMcGee is better known as Alegend45, and is something of a laughing stock among a large portion of the emulation community. Mainly for the fact that he rather enjoys talking about all of the different things he wants to work on on various emulators, but enjoys doing the actual work much less so.

[fuel-pcbox]

Says the guy who allegedly split his dick for some stupid reason.

[ghost]

@MooglyGuy now now, I cannot go unpunished you know either. I after-all insult people randomly every full moon or something, whiles other moments being completely rational and sane. I am also responsible for code crimes, which are far far worse than Mooch's dealings.

[CalmCodeC]

@p1pkin

Please ignore these guys ;) , not sure why you're getting emotional against these trolls. it's your work and you deserve to have it as closed source. moving to open source is really a good idea but don't do it for these ungrateful guys but only if you personally think so. just my personal opinion ;)

[inactive123]

Since I was dragged into this conversation, guess I might as well respond :) It is also going to be my first and only response in here, since I don't care much for getting drawn into childish flamewars anymore with people whom I have never even said anything bad to or don't even know who they are. Been there, done that. It's a new year, new resolutions and all that. It's time we all mature a little.

p1pkin said:

"Square-troll able to fix emulation related bugs ? really ? I can believe he can fix something in backend, but not in emulation core(s), it seems out of his league."

Hmm, I didn't even know who you were before you made this comment. What possible reason do you have for disliking me anyway? I never had any dealings with you, I never talked to you, in fact I didn't even know who you were until today or so. Don't think I ever talked bad about you since, well, I don't even know who you are/were before these comments were made.

This is getting really tiring, I see so many people in emudevland creating supposed 'issues' with me when honestly, I don't even know or have ever talked to any of you in person. So what is it with all this pent-up frustration and misgrievances you have? Seems extremely irrational if you ask me and just an attempt to drag my character through the mud when I just stick to my own IRC channels and my own forums.

OK, so here I am about to put my two cents in: I did indeed fix a couple of bugs in Reicast libretro so far, being able to look at the plugin sources of Demul for reference would sure be helpful even if it's just D3D code.

Lxdream is a dead project, that DreaVM stuff is obviously too experimental to really look at as a reference, MAME/MESS is what I have compared things to so far in order to improve stuff but honestly in most cases there is the same omissions as you'd find elsewhere (no bump mapping emulation, etc). And Reicast/nulldc honestly has been going nowhere all these years. I find it incredible that 5 years has gone by without anybody really caring about improving the nuts and bolts of DC emulation. More time was spent on experimental dynarecs and experimental PVR/TA threading strategies than honestly improving DC emulation. There are so many instances where people pointed out emulation issues in NullDC for years that still have been largely neglected and still exist to this day in Reicast. The core emulation was just barely improved, in fact most of the graphics features in Reicast are still completely stubbed out in upstream and it seems so deliberately for speed reasons? (RTT, clipping, volume modifier shadows, etc). I turned on some of these features and honestly I don't get how this could cause such a big speed hit. Maybe on some prehistoric Cortex A8 tablet it does or whatever but honestly, why just sacrifice all these features for some ancient outdated mobile SoCs?

And as for you questioning why people didn't pick up Nulldc/Reicast and drastically improve it on their own, well honestly, what do you expect? The source code is a total mess and it has stayed in this mess since at least 2010 with no discernable effort to improve it or revise it. How can you or anybody else expect contributors when you leave it in a state like that? Furthermore, it seems plenty of regressions were made in NullDC and no effort was taken to get to the bottom of those regressions, instead we moved onto another fork (Reicast being nulldcE) where once again plenty of regressions were made during the initial porting of this to PSP, and so on and on the ride goes. AGAIN (just to preface), I am not blaming anybody here, but honestly, people need to be more honest with themselves. You know why you are not getting all these contributions in opensource land yourself.

People are not just innately stupid or anything. It isn't like there are only 3/4 guys in the whole world that could do DC emulation and the rest are all a bunch of stupid bumpkins who couldn't get stuff done. It isn't like the hardware is even that complex to warrant that kind of snobbism, There are plenty of talented engineers who could contribute to emulator projects if they wanted to. People with impressive resumes even working at impressive companies who likely did stuff in their own spare time dwarfing the efforts of any emudev. I asked one of those to look into reicast briefly when I was wrestling with a bug. Know the response I got back though? I had to literally try pushing this person to keep looking at the source since honestly there were plenty of times where he just went 'meh, source is awful, won't look at it further'. And this is indicative of why you don't see all this 'help' that you so desire beyond just legal fears.

There are PLENTY of good coders, working for all sorts of Fortune 500 companies, literally dying to help you. What they are NOT going to do, though, is muck through sourcecode that is obviously so messy out of sheer neglect and/or plain indifference that it just would take an extreme time effort on their part to even try to make sense of it. If people stopped with this unprofessional outlook that 'this is just my hobby, meh' and instead just made a serious commitment to actually improve DC emulation for posterity reasons, everything could progress, all sorts of highly talented coders all over the world would send pull requests (even anonymously) and we wouldn't have this situation right now where you have three or so DC emulators all in various states of disarray and with the authors having extremely unprofessional attitudes as to their desire to want to really improve it. DC emulation quite honestly deserves better than to be kept hostage by a bunch of guys like this who just regard their own emulators as their own 'personal toybox'. This whole 'personal toybox' perspective on things really is to the project's own undoing. You cannot expect good contributions from good engineers then. If you take a professional outlook on things, you get professionalism back. It is very plain and simple. I am not deriding anyone here with regards to what they think about their own personal emulator, it is your own choice and you have the right to that choice. But honestly, don't then complain that you are not getting back the kind of 'help' and 'collaboration' that you expected. Because you know yourself why you are not getting this back: because this codebase is your 'personal toybox' and all that. Such an outlook on things really shuts out and kills off any kind of collaborative development overnight.

As a personal aside, I have to say, most of the sourcecode I have seen so far in MAME/MESS, Demul and Reicast/nulldc all seems to borrow from one another. Reicast/nulldc's AICA DSP code was obviously based on MAME's, the ARM AICA code in Reicast/demul/lxdream all seems to pretty much come down to the same VBA ARM code, the ('leaked' ?) sourcecode of DEmul doesn't seem to take any big divergences compared to what Reicast/nulldc does. I don't get all this duplication of effort honestly. Seems like another example where the plugin system did more bad than good by allowing people to close up their own renderers behind a closed source wall instead of the fruits of their efforts going back into the individual emulator projects where everybody could benefit from them.

[p1pkin]

@twinaphex speaking of docs - there is internal Sega's docs on everything (DCDBSysArc990907E.doc). it explains every aspect of how it works. I see no any reason to look at someone's interpretation/approximation attempts instead of original reference. well, except AICA, there is not much details about it.

about AICA, in addition to Sega/Yamaha docs I can recommend only Neil Corlet's doc http://pastebin.com/9TbKLGPs at the end you can see detailed DSP explanation, afaik every AICA or SCSP DSP emulations was made based on Neil's researches, so again - why to look at someone's else understanding of this thing and implementation in C (which can be wrong here or where) instead of original docs from person who did all researches and really understand how such devices works ? as well as his C implementation https://github.com/kode54/Highly_Theoretical (revert repo back to about ~02.2012, before wrong crap from MAME was copy/pasted there, except https://github.com/kode54/Highly_Theoretical/commit/a1b482e0070112b08d6bd45842e5a3a9b061deba this is only good fix) this is only close to "reference quality" AICA and its DSP emulation core I know. it may contain some errors, but it is made in right way and correct in general. do not look at MAME's AICA, it is in state "this bad/wrong crap must be wiped completely and redone almost from scratch", so it was really bad idea to take something from there and/or use as reference.

[inactive123]

Alright, thanks for pointing me in the right direction, that is appreciated.

And yeah, skmp seems to be in similar agreement with you over the accuracy of MAME's AICA code, that is honestly poor show on their part that we cant even look at anything from MAME and consider it a reference implementation no matter how slow. I think they previously said that it was supposed to be pretty accurate and that AICA was almost the same as Saturns SCSP save for some extras like ADPCM, so I guess they came back from that and/or that statement simply was not true.

Makes me wonder what the purpose is of having DC/NAOMI emulation in there altogether if they are not going to bother making it accurate to begin with. I saw similar hack jobs being done on the N64 MESS side where DPC freeze bit were simply 'stubbed out' instead of being correctly implemented and that just made me shake my head since I know that will cause issues with specific games.

[kode54]

kode54/Highly_Theoretical@a1b482e is a necessary fix, because it prevents clipping by performing a correct soft saturation. So pull that fix, and drop the MAME crap, and move it to another branch? Feel free to fix all the bugs while you're at it.

[arkov]

Since the last release of Demul some time has passed and I am very appreciative of the work that has been done already. But I think things have changed a bit in the last 2+ years. We see crowds working on big emulators like RPCS3 and Citra, which both are very impressive. So open sourcing it would be nice.

[p1pkin]

I think it was explained already - Demul is product of work of several people, EVERYONE of them have to agree going to open source. but few developers (not me) against this. and as was already said - there already enough FOSS Dreamcast/NAOMI emulators - NullDC, Reicast, Redream, lxdream, but - I see no people working on them, except single person in each project in best case.

if you gonna say: people cannot understand "NullDC/Reicast/etc" code, it is total mess! - believe me, current Demul code is even much bigger mess either.

[ghost]

Damn fucking straight.

[arkov]

Sorry p1pkin, you are right, I didn't realize the aspect of the devs' code.