On Thu, Mar 30, 2006 at 05:54:37PM +0100, Chris Young wrote:
> On Thu, 30 Mar 2006 11:49:16 +0100, Peter Howkins wibbled on for an age:
>
> > OK, hope this helps
> >
> > - DisplayKbd_InitHost()
> > Called once on program startup, this is where you should put your host
> > specific stuff including.
> > - Opening a GUI window of some sort
> > - Creating an 800x600 RGB buffer of some sort [1]
> > - Plugging that buffer into the window
>
> A bitmap is created and attached to Intuition windows when the window
> is opened, so that should make things a bit easier.
>
> > - DisplayKbd_PollHost(ARMul_State *state)
> >
> > Probably not strictly needed for display, it's a function that's called
> > back 'every so often' that platforms use to read in keyboard and mouse
> > events from the host operating system. You *might* need to use it to
> > 'flush' the display, if the writes in the RefreshDiplay_* calls didn't do
> > it automatically. This isn't ideal and I don't think you'll need it.
>
> It looks like I'm going to have to rewrite all the signal-related code
> to be Amiga-friendly, I would suggest waiting for messages, but that
> would stop the emulation. I might need this function to poll for
> messages.
>
> While on the subject of signals, It looks like there are only a few
> lines in dagstandalone.c relating these. I notice they are #ifdef'd
> out for Windows (presumably Windows also doesn't support UNIX
> signals), and relevant code seems to be in win/win.c - but I can't see
> where these functions are called from. Is there any other signal code
> I need to worry about? Is the best idea to #ifdef out the signal code
> and use DisplayKbd_PollHost to poll for messages?
>
Yes, having had a look at it, the signal stuff in dagstandalone isn't
soemthing you should need. #ifdefing it out along with the windows
versions will do fine for you (I'll see if something more tidy can be come
up with later). DisplayKbd_PollHost() is the ideal place for host and
emulator message passing.
> At this stage I will only need it to monitor messages to detect when
> the window has been closed.
>
That should be doable in DisplayKbd_PollHost() (I hope)
>
> > [1] The X platform supports sizes up to VeryLarge by VeryLarge and resizes
> > the graphics buffer on mode changes in the resizeWindow() callback from
> > VIDC_PutVal() instead of being limited to 800x600. This is the ideal
> > solution but to get started with you don't need to worry about it.
>
> What I would like to do is open a screen of the same resolution and
> depth as the emulated machine when the mode changes. I could even set
> the palette the same if I can get that sort of information out of
> ArcEm, and then plot pixels directly to the window/screen.
Red Squirrel/Vitual Acorn has a 'full screen' mode in a similar way to
what you describe, but they also do a windowed mode (this is probably a
side effect of using Direct X
> Anyway,
> that's for later. I'm not sure of the format of my bitmap structure
> at the moment, it may be easier and possibly quicker to do this rather
> than playing with the bitmap.
>
There's another bit of code that I forgot earlier that probably needs to
be in there before display will work. There's code to setup [1] colourmaps
at the top of each RefreshDisplay_Xbpp() function that you'll also
hopefully be able to nick from another platform, I'm not entirely sure how
these work though. Called DoPixelMap_Standard() and DoPixelMap_256() in
the Windows and Mac OS X, Called set_video_4bpp_colourmap() and
set_video_8bpp_colourmap() in X, called DoColourMap_2(), DoColourMap_4(),
DoColourMap_16() and DoColourMap_256() on RISC OS and GP2x (mmm,
consistant :) ).
Peter
[1] Yet another refactoring opertunity, these 'redo the colourmap' calls
are only done when a pallette is marked as dirty on the 'X' platform, yet
they are done every single screen refresh on the Windows, RISC OS, gp2x [2]
and Mac OS X build, there's a speed up to be had there, but I'd rather
roll the logic into shared code, so each platform gets it at once rather
than each doing it in different way. [3]
[2] GP2x confusingly calls it's 'plot to screen' func from inside it's
'redo the colourmap' calls. Not to tricky to split out again to get this
speed boost though.
[3] At the moment, a struct with lot of function pointers in to do the
following seems a good idea (as opposed to just having functions of
specific names for each platform), as this would allow X to have it's
Pseudo/True colour support (and risc os direct/windowed) in one file just
by changing the function pointers.
/* something along the lines of this */
struct DispKbdFunctions {
void (*RefreshDisplay_1bpp)(void *viddata (1), unsigned width, unsigned
height)
void (*RefreshDisplay_2bpp)(void *viddata, unsigned width, unsigned
height)
void (*RefreshDisplay_4bpp)(void *viddata, unsigned width, unsigned
height)
void (*RefreshDisplay_8bpp)(void *viddata, unsigned width, unsigned
height)
void (*RefreshDisplay_16bpp)(void *viddata, unsigned width, unsigned
height) (1)
void (*RefreshDisplay_24bpp)(void *viddata, unsigned width, unsigned
height) (1)
void (*DoColourMap_1bpp)()
void (*DoColourMap_2bpp)()
void (*DoColourMap_4bpp)()
void (*DoColourMap_8bpp)()
void (*DoColourMap_16bpp)()
void (*DoColourMap_24bpp)()
void (*DoColourMap_Cursor)()
vpod (*ResizeWindow)(unsigned width, unisgned height)
}
This would allow us to share the current RefreshDisplay() func, move all
the calls to DoColourMap() to shared code, move VIDC_PutVal() to shared
code. And share the dirty pallette otimisation on all platforms.
Still doesn't even begin to scratch the surface of how much of the
Keyboard and mouse code is shared either.
(1) Might as well prep for vidc20 support now, even if the func pointer is
NULL on all platorms for the time being, also by not passing in
armul_state and passing in a pointer to video data directly, we won't have
to have a ...
if(vidc1) {
pointer = this
} else if(vidc20) {
pointer = that
}
... in every single RefreshDisplay func
HOWEVER, I don't think we should do this until we get a 1.5 (or whatever)
release out the door, as the potential for bustage is large.
I'll post another message about some release based things in a minute.
Peter
--
Peter Howkins
[EMAIL PROTECTED]
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
arcem-devel mailing list
arcem-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/arcem-devel
