Keith, I am very sorry if the way I said this the first time was very unclear. I will
try to work on saying things more precisely.
Part of the problem in this case was thread cross over, but that is no excuse. Each
thread must stand on its own. I had not
intended to be allusive - just took it for granted that people knew. Also, I made
some basic assumptions based on what I observed
that could seem confusing if you're not observing the same things.
But my goal is to be as constructive as possible. Just to reiterate because it's
important, I am only saying things in this
newsgroup to try to provide constructive, usable feedback towards change. On that
note, I appreciate your feedback to my email, so
that I can write in a clearer manner.
Let me redo this and try to be clearer in explaining the problem I'm observing. It's
under Windows 98SE.
> What's wrong with sound emulation?
I did make several direct emails reporting the sound problem, but again, a different
thread.
Ok, the particular problem I was referring to with sound was using SndDoCmd in a non
blocking mode (sndCmdFrqOn, sndCmdNoteOn).
Under the windows emulator, every sound you play is queued up one after the other to
play at full duration, as opposed to one sound
interrupting the next as on the real device.
So for example, if I played 1000 notes, each with a duration of 1 second given to the
SndDoCmd, but I executed the SndDoCmd's one
millisecond after the other, on a real device, I'd hear an interesting sound effect, a
one second note, then silence (each call to
SndDoCmd interrupts the previous). On the emulator, the program would run, be done,
and back into the launcher. But the sounds
would play out, all queued up, at one second intervals, until all the sounds were all
played out at full duration.
When I was discussing this sound thread someone else mentioned that maybe this was
because sound was not being emulated at the
hardware level. I figured it was just dumping the sounds into the windows sound
buffers. But this is the type of extrapolation can
cause confusion.
> What do you mean by the emulating missing when it needs to update the screen?
Under Windows 98SE, it sometimes does not update the screen image at all when the
image changes, or updates scattered parts of the
image, when the background changes. I honestly couldn't tell you a pattern, because I
haven't really found one. For example, if I
simply turn the power on and off, usually it works fully, sometimes it redraws part of
the screen, and sometimes it misses it. But
you can always see what's really on the screen by dragging the entire emulator off the
desktop and then back on, forcing a WM_PAINT
message. What this says to me is that the emulator is always updating its internal 2x
image buffer (could be updating it very, very
fast), but is not always telling windows to update the buffer to the
screen....[extrapolation again, but I add it to help visualize
the problem I'm describing]
> I don't view this as a reason for adding an FPS throttle.
As for your interpretations below, I really must have been unclear, as I was not
asking for a FPS throttle, although I alluded to
that as a nice side benefit. An actual FPS throttle would be nice too, but should be
its own feature. What I was suggesting was to
redraw 100% of the current Palm screen memory onto the Windows screen so many times
per second, so that I can see what's going on at
a higher frame rate. Based on my observations, I was assuming that (1) since the
whole screen wasn't always updated, that the
emulator was attempting some kind of delta screen update, and (2) since the whole
screen doesn't update very often, that maybe
Windows updates happen on a very low priority in the Emulator. [Extrapolation]
The effect I see is that although the emulation is running at 500% normal speed, the
visual update of the display is only about 2-3
fps. I actually saw this same effect under windows 95 and with older emulators, so I
assumed it was done to conserve processing
power. So my suggestion was aimed at upping the visual update rate now that the
computation power is there. Your suprise may be
related to the other problem I observed, i.e., maybe the internal graphics buffer of
the emulator IS updating very fast, but Windows
is getting very few draw commands.
>From your response, I assume that the emulator IS trying to update it's screen image
>continually and quickly. But for some reason
it's not all getting through, so I just manually force redraws on the window.
But whatever the extrapolated reasons, I would love to see on my emulator the palm
screen updating at least 20 fps. The faster the
Palm emulates under the hood, the faster the screen refresh I need to see what's
happening before it's all over.
OK, Keith - you be the judge. Was I any better this time, or was I still not specific
enough?
- Jeff
[EMAIL PROTECTED] wrote:
> > This is a cosmetic request and should be lower in priority than issues
> > like sound emulation.
>
> What's wrong with sound emulation?
>
> > At least under windows, updating the emulator screen is given VERY low
> > priority. So on modern PCs, we have the ironic situation that our code
> > runs 5 times faster than normal, yet we didn't see what happened. Also,
> > the emulator often misses when it needs to update the screen.
>
> Jeff, you really have this unhelpful habit of throwing out comments without
> explaining yourself. What do you mean by the emulating missing when it needs to
> update the screen? I know of no problems here. If you are seeing problems,
> then you really should report them instead of making allusive remarks about
> them.
>
> > When I
> > try it on a real device, the whole process runs much slower, but the
> > screen update speed is so fast it makes the device looks like a
> > supercomputer.
> >
> > I propose the following "15 minute" solution: Let the user specify a
> > frame rate in which the Emulator will update it's current screen
> > continuously whether it needs to or not. If you set this to 2 fps, you
> > solve the problem of the screen thinking it doesn't need to update.
>
> *If* there is a problem here, then your suggestion is not the right solution for
> it, so I don't view this as a reason for adding an FPS throttle.
>
> > If
> > you set this to 60 fps and your PC is fast enough, you get Palm-speed
> > graphics, along with the bonus of slowing the execution speed itself
> > down to closer to real world speeds.
>
> *If* running faster than an actual device is a problem, then your suggestion is
> not the right solution for it. So again I don't view this as a reason for
> adding an FPS throttle.
>
> -- Keith Rollin
> -- Palm OS Emulator engineer
>
> --
> For information on using the Palm Developer Forums, or to unsubscribe, please see
>http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
