Re: [openMSX-devel] openMSX ChangeLog

[Maarten t. H. <mt...@st...>]

On Tuesday 26 February 2002 21:57, Wouter Vermaelen wrote:

(don't forget to reply to the list...)

> > I thought a bit about it, the difference from the current code is not
> > that dramatic. I am a bit worried about performance though, but I guess
> > I'll just have to try and see how it turns out.
>
> Can you elaborate on this please?

A typical update method in SDLHiiRenderer looks like this:

updateSomething(State newState, EmuTime &time)
{
  sync(time);
  // do something, if necessary
}

This is independent of the rendering accuracy.
But the current implementation of sync isn't:

template <class Pixel> inline void SDLHiRenderer<Pixel>::sync(
  const EmuTime &time)
{
  int line = (vdp->getTicksThisFrame(time) + VDP::TICKS_PER_LINE / 2)
    / VDP::TICKS_PER_LINE;
  renderUntil(line);
}

As you can see, the current sync rounds to the nearest whole line. This 
should change and the pixel conversion methods should be able to start and 
stop at any arbitrary pixel instead of always rendering a single line.

> > No problem once we have the new plugging architecture that Wouter
> > designed. The Connector is part of the emulated MSX and will be stored in
> > a save state, the Pluggable isn't. When you read from a mouse, the
> > JoystickPort (Connector) will read the current state of the Mouse
> > (Pluggable), store it internally and then return the first nibble. Upon
> > later reads, it will return the other nibbles. It's like the way the VDP
> > stores the first byte written to 0x99. Because the read from the
> > non-persistent Pluggable is atomic (entire state transferred without
> > EmuTime passing), the problem you describe cannot occur.
>
> This means the mouse protocol must be implemented in Joyport instead of the
> Mouse class. Currently the Joyport class does nothing more than passing
> signals to/from the device that is plugged in. I like to keep it that way.

Hmmm... This needs more thought. Some other time.

Bye,
		Maarten