| f205v |
|
Dumper
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 193
|
|
Loc: Switzerland
|
|
|
|
Send PM
|
|
|
MAME on Native Client
#272003 - 01/02/12 11:56 AM
|
|
|
|
|
|
Re: MAME on Native Client
[Re: f205v]
#272005 - 01/02/12 12:59 PM
|
|
|
> Just read this article straight from a SlashDot.com comment:
> https://developers.google.com/native-client/community/porting/MAME
>
> Some Google developers portet MAME 0.143 to Native Client.
> They describe the full process, with pros and cons.
> DIFF and builts are included at the bottom of the article.
It was on the news submission board here months ago. Slashdot is only useful for lulz - news there is never recent.
|
|
|
| f205v |
|
Dumper
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 193
|
|
Loc: Switzerland
|
|
|
|
Send PM
|
|
|
Re: MAME on Native Client
[Re: Vas Crabb]
#272016 - 01/02/12 05:17 PM
|
|
|
Sorry, I thought it was something of a novelty.
|
Ciao
f205v
|
|
|
The explanation is new...
[Re: f205v]
#272795 - 01/12/12 12:17 PM
|
|
|
isn't it? I don't recall/didn't see anyone providing that in the 'MAME in your browser' thread, here.
Quite interesting, even for me who does no coding. Intriguing was (seemingly to me) how little code resulted and how little time it took them.
Some questions (possibly for Arby) arose:
- how does the lack of CPU emulation based on the UDR affect emulation accuracy?
- how does their enabling of SDL (or does it?) parallel SDLMAME?
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: The explanation is new...
[Re: mogli]
#272823 - 01/12/12 09:01 PM
|
|
|
> isn't it? I don't recall/didn't see anyone providing that in the 'MAME in your
> browser' thread, here.
I linked it when it was announced.
> Quite interesting, even for me who does no coding. Intriguing was (seemingly to me)
> how little code resulted and how little time it took them.
As the portability guy, I'm vaguely insulted that you'd find that remarkable. MAME compiles out of the box on every major OS/environment shipping today and a few that aren't. If you have GCC and SDL available, the rest is negotiable.
> - how does the lack of CPU emulation based on the UDR affect emulation accuracy?
They removed all of the drivers that relied on the UML subsystem. That wasn't actually necessary since there is a pure C backend which does conventional interpretive emulation on the intermediate UML bytecode. You lose all the speed of the recompiler plus some doing that of course, but the accuracy is just as good as in the conventional case.
> - how does their enabling of SDL (or does it?) parallel SDLMAME?
They used the existing SDL backend largely unmodified (but with OpenGL disabled). The SDL backend is intended to work on pretty much anything SDL can be ported to.
|
|
|
|
Re: The explanation is new...
[Re: R. Belmont]
#273146 - 01/15/12 09:19 PM
|
|
|
> > isn't it? I don't recall/didn't see anyone providing that in the 'MAME in your
> > browser' thread, here.
>
> I linked it when it was announced.
>
> > Quite interesting, even for me who does no coding. Intriguing was (seemingly to me)
> > how little code resulted and how little time it took them.
>
> As the portability guy, I'm vaguely insulted that you'd find that remarkable. MAME
> compiles out of the box on every major OS/environment shipping today and a few that
> aren't. If you have GCC and SDL available, the rest is negotiable.
>
> > - how does the lack of CPU emulation based on the UDR affect emulation accuracy?
>
> They removed all of the drivers that relied on the UML subsystem. That wasn't
> actually necessary since there is a pure C backend which does conventional
> interpretive emulation on the intermediate UML bytecode. You lose all the speed of
> the recompiler plus some doing that of course, but the accuracy is just as good as in
> the conventional case.
>
> > - how does their enabling of SDL (or does it?) parallel SDLMAME?
>
> They used the existing SDL backend largely unmodified (but with OpenGL disabled). The
> SDL backend is intended to work on pretty much anything SDL can be ported to.
Hah hah hah hah. Nothing about you, but about my lack of understanding the content and use of things. I want to be clear on one part: one loses the speed of the recompiler by removing the drivers, or by using the C backend?
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: The explanation is new...
[Re: mogli]
#273158 - 01/16/12 12:22 AM
|
|
|
> Hah hah hah hah. Nothing about you, but about my lack of understanding the content
> and use of things. I want to be clear on one part: one loses the speed of the
> recompiler by removing the drivers, or by using the C backend?
The latter. You could make a philosophical case that removing the drivers mean you lose 100% of any potential speed, but I'm not going there ;-)
|
|
|
Previous 
Index 
Next 
Threaded 
MAME on Native Client
Reply
[Re: 