Re: [9front] proposal: move common code from md, nes, snes, gb, gba, c64 to a libemu

[qwx <qwx@sciops.net>]

> > - (?) added toggling fullspeed emulation when audio is enabled
> by dropping samples?
> 
> i don't like that this is enabled with space.
> i would prefer some more remote key, like `.
> 
> personally i think this is a misfeature. in other emulators i always find 
> myself using it too much.

I agree, ` is better.  I'd like to keep this just because it lets me
blaze through some extremely annoying unskippable sequences in many
games (for convenience rather than a hack).  Final verdict?


> > - (?) dynamic rescaling from x1 to x16 for larger screens;
> >  removed -2, -3
> i think i've stated before i don't like this very much.
> but i'll accept it begrudgingly, i think :).

Thank you :)


> > - emalloc, as often reproduced in the emulators;
> >  might be better off in libc or nowhere
> moving emalloc to libc has been discussed many times and vetoed every
> time.
> not sure what you mean by 'nowhere'.

I recall the debates;  I just wasn't sure if it was worth placing in the
library anyway, or to just leave it in the emulators that need it.  I'm
leaning towards just removing it from libemu, it's a bit extraneous.


> > - the signed typedefs might be better placed in /$objtype/include/u.h
> yes i would like that.
> we've postponed doing this too many times already.

So, can we?  I don't remember why it was never done.  What objections
were there?


> > - clumsy; input bit vectors are semi-arbitrary and adaptation in some
> >  emulators is fairly bad; worse examples: snes and md
> > - regkeyfn is not very useful as is
> i would like this to be fixed.
> why not just register all keys?
> something like
>  	regkey("left", Kleft, 1);
> to register it as bit 1 in the input bitvector.

True, this makes more sense.  I'll do it.


> > - can we merge 2600 even if it's buggy?
> yes.

I will then do it after all is said and done for libemu.


Thanks!

qwx