Forum Index | FAQ | New User | Login | Search

Make a New PostPrevious ThreadView All ThreadsNext Thread*Show in Threaded Mode


SubjectMove/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/23/02 06:07 AM



Hi;

Some games in MameCE can be played with the stylus (like Starwars, Arkanoid, why not 1942 or 1943). Why don't try to emulate the mouse (I means to add the same mame32 option 'mouse support'.

More generally, most of the game can be played using stylus instead of the pad. This should be a great feature, and easier to play on (on ipaq 36xx where fire n move is not supported)

Finally, instead building a 'Large' build, mame should create some .DLL with the game and then we could use the DLL corresponding to game. This would produce look of binairies, but it will reduce the memory footprint.



Last thing, seems that mamece does not run in full screen but in a windowed GAPI mode. (We can see the task bar on the top ). Can you add an option to remove it ?

Best;







SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byfinaldave
Posted on05/23/02 12:38 PM



> Hi;
>
> Some games in MameCE can be played with the stylus (like Starwars, Arkanoid, why
> not 1942 or 1943). Why don't try to emulate the mouse (I means to add the same
> mame32 option 'mouse support'.
>
> More generally, most of the game can be played using stylus instead of the pad.
> This should be a great feature, and easier to play on (on ipaq 36xx where fire n
> move is not supported)
On iPAQ 36xx I'm finding I can't "swivel" from Up to say Left. If swivel the joypad from Up to Left or even to Down, Up seems to stay pressed.

Is this just The Way It Is (tm RunDMC)?

>
> Finally, instead building a 'Large' build, mame should create some .DLL with the
> game and then we could use the DLL corresponding to game. This would produce
> look of binairies, but it will reduce the memory footprint.

Sadly DLL is Microsoft specific. It's a good idea though, but would be tricky to be portable.

>
>
>
> Last thing, seems that mamece does not run in full screen but in a windowed GAPI
> mode. (We can see the task bar on the top ). Can you add an option to remove it
> ?

The way to do this is:
CreateWindow(...,WS_VISIBLE,0,0,240,320,NULL,NULL,wc.hInstance,NULL);
Don't ask me why! Seems to me a bad idea to do 240,320 hardcoded, but seems to be the only way...

>
> Best;
>





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/24/02 05:27 AM



>On iPAQ 36xx I'm finding I can't "swivel" from Up to say >Left. If swivel the joypad from Up to Left or even to >Down, Up seems to stay pressed. Is this just The Way It Is >(tm RunDMC)?

Yes, What I want it's to play with the stylus. Period.


> Sadly DLL is Microsoft specific. It's a good idea though, > but would be tricky to be portable.

It's not specific. MacOS, Linux, BeOS supports dynamic libraries. (DLL = dynamic libraries) so it would be portable. In fact It would be

Main executable -> spawn the game (for example 1943.dll or 1943.emu) -> calling mame.dll (which contains all the code for emulation).

In fact mame gets bigger and bigger, and one day, the authors will rally need to separate each game from the main code.

> The way to do this is:
> CreateWindow(...,WS_VISIBLE,0,0,240,320,NULL,NULL,wc.hInstance,NULL);
> Don't ask me why! Seems to me a bad idea to do 240,320 hardcoded, but seems to
> be the only way...

This is wrong: You must write (see gapi manual)

#define MENU_HEIGHT 26
HWND g_hWnd; // Window APP
RECT rc;
SHFullScreen(g_hWnd, SHFS_HIDESTARTICON | SHFS_HIDETASKBAR |
SHFS_HIDESIPBUTTON);
GetWindowRect(g_hWnd, &rc);
MoveWindow(m_hWnd, rc.left, rc.top-MENU_HEIGHT, rc.right, rc.bottom+MENU_HEIGHT, TRUE);
GXOpenDisplay(g_hWnd, GX_FULLSCREEN);






SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byfinaldave
Posted on05/24/02 06:52 AM



> > Sadly DLL is Microsoft specific. It's a good idea though, > but would be
> tricky to be portable.
>
> It's not specific. MacOS, Linux, BeOS supports dynamic libraries. (DLL = dynamic
> libraries) so it would be portable.

No they don't. Each has their own version. e.g. Linux has shared libraries (.ao files I think). Microsoft Win32 has DLL (.dll)

It wouldn't be portable. If if was don't you think we would have done it a LONG time ago?
Basically you'd have to write a wrapper for each platform...


> > The way to do this is:
> > CreateWindow(...,WS_VISIBLE,0,0,240,320,NULL,NULL,wc.hInstance,NULL);
> > Don't ask me why! Seems to me a bad idea to do 240,320 hardcoded, but seems to
> > be the only way...
>
> This is wrong: You must write (see gapi manual)
>
> #define MENU_HEIGHT 26
> HWND g_hWnd; // Window APP
> RECT rc;
> SHFullScreen(g_hWnd, SHFS_HIDESTARTICON | SHFS_HIDETASKBAR |
> SHFS_HIDESIPBUTTON);
> GetWindowRect(g_hWnd, &rc);
> MoveWindow(m_hWnd, rc.left, rc.top-MENU_HEIGHT, rc.right, rc.bottom MENU_HEIGHT,
> TRUE);
> GXOpenDisplay(g_hWnd, GX_FULLSCREEN);

Thanks for the tip!
Where's the GAPI manual by the way - I couldn't see one, only examples?

*update* - are you sure about SHFullScreen? I searched for it at MSDN and strangely even though it appears in other articles it's not in MSDN itself? Seems weird...





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/24/02 09:13 AM



> No they don't. Each has their own version. e.g. Linux has > shared libraries (.ao files I think). Microsoft Win32 has > DLL (.dll)
> It wouldn't be portable. If if was don't you think we
> would have done it a LONG time ago?

Yes, but I didn't find any discution about this features. Now I know. But i'm sure that this is possible.
Btw: The DLLs should be build on each platform of course.

This would produce a lot of file and makefile, I think this is the real reason

> Thanks for the tip!
> Where's the GAPI manual by the way - I couldn't see one, only examples?

see http://www.gapidraw.com


> *update* - are you sure about SHFullScreen? I searched for it at MSDN and strangely even though it appears in other articles it's not in MSDN itself?

See:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q266244





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/24/02 09:36 AM



Pff !

I've downloaded the latest source code, and found in Cgapi.cpp that the SHFullscreen code was missing ...

Please update !

This will fix also the random flickering and improve speed (no taskbar redraw for example).

I will try to recompile the source code (not the week end sorry) with my modifications to fix that fullscreen issue.

I will also try to add the stylus support in game. if it works, it would be great. Playing arkanoid for example, there is some existing 'break out' games available on pocket pc, and every uses the stylus and it rocks


Also the GXSuspend() / Resume() are never called !

Ok, look this code, they should be modified but this always better application switching and stylus support. for all games if option is enabled..

**********************
// playgame.c
int xRaw, yRaw, buttonsRaw;

int getPenPosition(int *x, int *y)
{
*x = xRaw;
*y = yRaw;
}

int isPenDown()
{
return buttonsRaw;
}

LRESULT CALLBACK MAMECE3_MessageProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
LRESULT Result = 0;
switch(Msg)
{
case WM_SETFOCUS:
GAPI_Resume();
break;
case WM_KILLFOCUS:
GAPI_Suspend();
break;

case WM_LBUTTONDOWN:
buttonsRaw|= 1;
xRaw = isLandscape ? 320 - HIWORD(lParam) : LOWORD(lParam);
yRaw = isLandscape ? LOWORD(lParam) : HIWORD(lParam);
break;
case WM_LBUTTONUP:
buttonsRaw&=~1;
break;
case
}
}


// input.c
void osd_trak_read(int player,int *deltax,int *deltay)
{
if (player != 0 || use_mouse == 0)
*deltax = *deltay = 0;
else
{
static int x0, y0;
int x, y;
getPenPosition(&x, &y);
if (isPenDown())
{
*deltax = x - x0;
*deltay = y - y0;
}
else
{
x0 = x;
y0 = y;

}
}
}





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byTekhmaster
Posted on05/24/02 03:59 PM



-snip-
> > > The way to do this is:
> > > CreateWindow(...,WS_VISIBLE,0,0,240,320,NULL,NULL,wc.hInstance,NULL);
> > > Don't ask me why! Seems to me a bad idea to do 240,320 hardcoded, but seems
> to
> > > be the only way...
> >
> > This is wrong: You must write (see gapi manual)
> >
> > #define MENU_HEIGHT 26
> > HWND g_hWnd; // Window APP
> > RECT rc;
> > SHFullScreen(g_hWnd, SHFS_HIDESTARTICON | SHFS_HIDETASKBAR |
> > SHFS_HIDESIPBUTTON);
> > GetWindowRect(g_hWnd, &rc);
> > MoveWindow(m_hWnd, rc.left, rc.top-MENU_HEIGHT, rc.right, rc.bottom
> MENU_HEIGHT,
> > TRUE);
> > GXOpenDisplay(g_hWnd, GX_FULLSCREEN);
>
> Thanks for the tip!
> Where's the GAPI manual by the way - I couldn't see one, only examples?
>
> *update* - are you sure about SHFullScreen? I searched for it at MSDN and
> strangely even though it appears in other articles it's not in MSDN itself?
> Seems weird...
>
Thats exactly why I didn't use it either, I had no idea you could.
All the sample apps using Gapi (that I used right after it came out) use the CreateWindow() function.

I'll take a look at it and rewrite it to use that function a soon as I get a chance.

FYI, My first attempt at rewriting this had the full screen blacked out, however it would never refresh the menu bar and clock when I exited MameCE3. I always assumed it was becuase we were blitting to the screen directly and the OS didn't know that we overwrote the menubar. I also couldn't figure out how to tell it that I had written on the menu at the time.
Also, (becuase of this)my blit routine in display.c does not reblit the menubar. It start its blit at the screenframe+=26.

Perhaps we will get a few more frames per second after this change :)


Cheers,
-Techmaster


SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byfinaldave
Posted on05/25/02 07:19 AM



> > No they don't. Each has their own version. e.g. Linux has > shared libraries
> (.ao files I think). Microsoft Win32 has > DLL (.dll)
> > It wouldn't be portable. If if was don't you think we
> > would have done it a LONG time ago?
>
> Yes, but I didn't find any discution about this features. Now I know. But i'm
> sure that this is possible.
> Btw: The DLLs should be build on each platform of course.

Er yes, thus "not portable".


> This would produce a lot of file and makefile, I think this is the real reason
>
> > Thanks for the tip!
> > Where's the GAPI manual by the way - I couldn't see one, only examples?
>
> see http://www.gapidraw.com

Unfortunatley that's a manual for 'GapiDraw', not GAPI itself. GapiDraw is a wrapper for GAPI, apparently made by someone in Sweden. Very nice, but hardly the official word on things.
Microsoft's Pocket PC site has some examples.


> > *update* - are you sure about SHFullScreen? I searched for it at MSDN and
> strangely even though it appears in other articles it's not in MSDN itself?
>
> See:
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;q266244

Yes, as I said: even though it appears in other articles it's not in MSDN itself, which is strange.
In fact none of the SH* function appear in MSDN, very very strange.





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byfinaldave
Posted on05/25/02 08:27 AM



> Pff !
>
> I've downloaded the latest source code, and found in Cgapi.cpp that the
> SHFullscreen code was missing ...


I don't think it's needed: here's a clip out of the first GAPI example on Microsoft (the nearest thing to docs):


hWnd = CreateWindow(szWindowClass, szTitle, WS_VISIBLE,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL);
if (!hWnd)
{
return FALSE;
}
//When the main window is created using CW_USEDEFAULT the height of the menubar (if one
// is created is not taken into account). So we resize the window after creating it
// if a menubar is present
{
RECT rc;
GetWindowRect(hWnd, &rc);
rc.bottom -= MENU_HEIGHT;
if (hwndCB)
MoveWindow(hWnd, rc.left, rc.top, rc.right, rc.bottom, FALSE);
}



As you can see, the only magical thing which happens here is that it makes a window the size of the screen! Not very magical at all. The MENU_HEIGHT=26 looks to be a bit hacky even. I think I'd be happier with this code:


int cx=0,cy=0;
// Get desktop size
cx=GetSystemMetrics(SM_CXSCREEN);
cy=GetSystemMetrics(SM_CYSCREEN);

hWnd=CreateWindow(L"WindowClass","My Win",WS_VISIBLE,0,0,cx,cy,NULL,NULL,wc.hInstance,NULL);


I've tried this on iPaq and Jornada and it works fine - fullscreen display. No need for any SH* stuff.
Tekhmaster, have you had any troubles with fullscreen?
execom_rt - you said you had fullscreen troubles, which pocket pc model do you have?





SubjectSHfullscreen new Reply to this message
Posted byexecom_rt
Posted on05/27/02 07:32 AM



I've got a Ipaq 3630 with Pocket PC 2002.

Well the documentation come from Microsoft web site.

Using the latest version of MameCE, the upper bar with time is still visible and clicking on the lower part strongly flicker the rendering.

Also the application is not multitask friendly (the GAPI Resume and Suspend functions are never called which is no good).

I suggest to enable the new code, exactly as Microsoft said. Generally some developers want to skip some microsoft recommendation and when the hardware or operating system changes, the implementation does work anymore:

It might works on your pocket PC, but may not one newest hardware : Best example look the WhatsnewCE.txt from MameCE release 9.3:
I quote:

"Implemented the Ipaq 3800 display workaround: The Ipaq 3800 has a bug(*) which causes GAPI screen access to be delayed (creating a severe display redraw penalty)"


No offense, but this hack was performed by the author because some initialisation was missing (like shfullscreen for example).

I have no IPAQ 3800 but I'm sure at 99% that if the author had followed the Microsoft specs (Shfullscreen, etc..) the mamece will runs perfectly under GAPI and would run faster ...

In my optinion, the redraw penalty is due to the fact that the taskbars and other UI stuffs was still renderered ...

If you see the Gapidraw.com, Trust me I know a lot of developers doing that under DirectX and when the hardware changes, the program flaws because they did not respect Microsoft recommendations and need to patch their programs because they did removed some initialisation thinking the code was not necessary.

Finally the 'move' of the window is necessary for the mouse input for example, else the 0,0 would be physically at 0,26.



> I don't think it's needed: here's a clip out of the first GAPI example on Microsoft (the nearest thing to docs):
>
>
> hWnd = CreateWindow(szWindowClass, szTitle, WS_VISIBLE,
> CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL,
> hInstance, NULL);
> if (!hWnd)
> {
> return FALSE;
> }
> //When the main window is created using CW_USEDEFAULT the height of the menubar
> (if one
> // is created is not taken into account). So we resize the window after
> creating it
> // if a menubar is present
> {
> RECT rc;
> GetWindowRect(hWnd, &rc);
> rc.bottom -= MENU_HEIGHT;
> if (hwndCB)
> MoveWindow(hWnd, rc.left, rc.top, rc.right, rc.bottom, FALSE);
> }
>
>
>
> As you can see, the only magical thing which happens here is that it makes a
> window the size of the screen! Not very magical at all. The MENU_HEIGHT=26 looks
> to be a bit hacky even. I think I'd be happier with this code:
>
>
> int cx=0,cy=0;
> // Get desktop size
> cx=GetSystemMetrics(SM_CXSCREEN);
> cy=GetSystemMetrics(SM_CYSCREEN);
>
> hWnd=CreateWindow(L"WindowClass","My
> Win",WS_VISIBLE,0,0,cx,cy,NULL,NULL,wc.hInstance,NULL);
>
>
> I've tried this on iPaq and Jornada and it works fine - fullscreen display. No
> need for any SH* stuff.
> Tekhmaster, have you had any troubles with fullscreen?
> execom_rt - you said you had fullscreen troubles, which pocket pc model do you
> have?
>





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/27/02 10:55 AM



Also, the landscape mode is faster than the regular mode because you can blit the screen with a single memcpy (it's +10 % faster). This is something to investigate further (needs to rotate the paddle keys too ...).

Actually the rotate option left/right option does not work ( flips the display of 180 degrees instead of 90 degrees, I mean, on my Ipaq ).

To refresh the clock and bar at exit, here my tip I use: (which should be also performed when changing of task WM_FOCUSLOST (not sure for the exact name))

Grab the memory buffer (with GXBeginDraw(), copy it into a a 320x240x2 byte buffer ( but you can compress it with a rle routine to reduce memory footprint )

When returning to the GUI, copy back this buffer, and voila, everything will be restored.

Last thing again, allow an 'safe mode option' using DIB instead of GAPI. Can be convenient ..



> Thats exactly why I didn't use it either, I had no idea you could.
> All the sample apps using Gapi (that I used right after it came out) use the
> CreateWindow() function.
>
> I'll take a look at it and rewrite it to use that function a soon as I get a
> chance.
>
> FYI, My first attempt at rewriting this had the full screen blacked out, however
> it would never refresh the menu bar and clock when I exited MameCE3. I always
> assumed it was becuase we were blitting to the screen directly and the OS didn't
> know that we overwrote the menubar. I also couldn't figure out how to tell it
> that I had written on the menu at the time.
> Also, (becuase of this)my blit routine in display.c does not reblit the menubar.
> It start its blit at the screenframe+=26.
>
> Perhaps we will get a few more frames per second after this change :)
>
>
> Cheers,
> -Techmaster
>





SubjectRe: SHfullscreen new Reply to this message
Posted byfinaldave
Posted on05/27/02 11:34 AM



Had a quick look at the MAMECE code

hWnd = CreateWindow( _T("MAMECE_PLAYWINDOW"),
_T(""),
WS_POPUP,
0,
0,
GetSystemMetrics(SM_CXSCREEN),
GetSystemMetrics(SM_CYSCREEN) ,
MAMECE3App.m_hwndUI,
NULL,
hInstance,
NULL);

ShowWindow(hWnd, SW_SHOWNORMAL);
UpdateWindow(hWnd);



As far as I can see there are some things to try before trying the SHFullscreen call. The WS_POPUP and the ShowWindow(hWnd,SW_SHOWNORMAL) call (I just used WS_VISIBLE). Maybe give that a try?





SubjectRe: SHfullscreen new Reply to this message
Posted byexecom_rt
Posted on05/27/02 11:56 AM



In the code the window position (0,0) is relative 0,26 physically to the main bar.

SM_CXSCREEN, SM_CYSCREEN would returns the workable space (so something like 320x214). So this code does not provide a full screen.

Anyway the window size does not matter really, because in GAPI mode, it's returning the display memory address from 0,0

Better, you can define a 1x1 window, this should work, and you will reduce memory footprint again .. of course, if you call the SHFullscreen functions.

Also, no need to the GUI manager to clip the taskbars with your window (again, speed would be increased).


> Had a quick look at the MAMECE code
>
> hWnd = CreateWindow( _T("MAMECE_PLAYWINDOW"),
> _T(""),
> WS_POPUP,
> 0,
> 0,
> GetSystemMetrics(SM_CXSCREEN),
> GetSystemMetrics(SM_CYSCREEN) ,
> MAMECE3App.m_hwndUI,
> NULL,
> hInstance,
> NULL);
>
> ShowWindow(hWnd, SW_SHOWNORMAL);
> UpdateWindow(hWnd);
>
>
>
> As far as I can see there are some things to try before trying the SHFullscreen
> call. The WS_POPUP and the ShowWindow(hWnd,SW_SHOWNORMAL) call (I just used
> WS_VISIBLE). Maybe give that a try?
>





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/27/02 12:02 PM



> Unfortunatley that's a manual for 'GapiDraw', not GAPI
> itself. GapiDraw is a wrapper for GAPI, apparently made
> by someone in Sweden. Very nice, but hardly the official > word on things. Microsoft's Pocket PC site has some
> examples.

Yes, it's just a C++ wrapper and adding some new function, but in all samples, the initialisation uses GAPI and seem to be very documented. And uses SHFullscreen. I've seen other pocket PC programs and everyone (but MameCE) uses SHfullscreen

It is documented on my MSDN offical DVD version .. but not on the online version ( guess why .. )


> Yes, as I said: even though it appears in other articles it's not in MSDN
> itself, which is strange.
> In fact none of the SH* function appear in MSDN, very very strange.
>





SubjectRe: SHfullscreen Reply to this message
Posted byTekhmaster
Posted on05/28/02 06:45 PM



> Also the application is not multitask friendly (the GAPI Resume and Suspend
> functions are never called which is no good).
They are never called becuase while doing emulation their is technically no way to get to any other apps. The Emulation is in full control drawing directly to the screen. Didn't wan't to waste any resources to check for other activity becuase no other activity can really happen At least that was the theory. I could add them for complete code but I just never did.

> It might works on your pocket PC, but may not one newest hardware : Best example
> look the WhatsnewCE.txt from MameCE release 9.3:
> I quote:
>
> "Implemented the Ipaq 3800 display workaround: The Ipaq 3800 has a bug(*) which
> causes GAPI screen access to be delayed (creating a severe display redraw
> penalty)"
>
>
> No offense, but this hack was performed by the author because some
> initialisation was missing (like shfullscreen for example).
Wrong. This hack was used becuase myself and many others including the developers of PocketTV and Rocket Elite to name a few, detected an obvious bug in the 3800 series. I am not sure of the details of whyu or how this bug works (Check the Brighthand Boards thats were I saw the explanation). All I know is that something to do with the lookup of the frame buffer takes a whole lot longer on the 3800 than it did on the 3600 series. Therefore the Developers of PocketTV came up with this hack to speed things up (which it does significantly). When I get time I will be testing your comments on the SHFull and I will test it with both the default settings and the hack, but I suspec the hack will still be needed.
>
> I have no IPAQ 3800 but I'm sure at 99% that if the author had followed the
> Microsoft specs (Shfullscreen, etc..) the mamece will runs perfectly under GAPI
See my last comment.

-snip-



Cheers,
-Techmaster


SubjectRe: SHfullscreen new Reply to this message
Posted byfinaldave
Posted on05/29/02 05:58 AM



> > Also the application is not multitask friendly (the GAPI Resume and Suspend
> > functions are never called which is no good).
> They are never called becuase while doing emulation their is technically no way
> to get to any other apps. The Emulation is in full control drawing directly to
> the screen. Didn't wan't to waste any resources to check for other activity
> becuase no other activity can really happen At least that was the theory. I
> could add them for complete code but I just never did.

Try setting an alarm and then playing - it will pop up the alarm on top of you application. If you don't call GXSuspend, I don't know, it might mess up the screen because you are drawing over another window? Try it - let me know...

> > It might works on your pocket PC, but may not one newest hardware : Best
> example
> > look the WhatsnewCE.txt from MameCE release 9.3:
> > I quote:
> >
> > "Implemented the Ipaq 3800 display workaround: The Ipaq 3800 has a bug(*)
> which
> > causes GAPI screen access to be delayed (creating a severe display redraw
> > penalty)"
> >
> >
> > No offense, but this hack was performed by the author because some
> > initialisation was missing (like shfullscreen for example).
> Wrong. This hack was used becuase myself and many others including the
> developers of PocketTV and Rocket Elite to name a few, detected an obvious bug
> in the 3800 series. I am not sure of the details of whyu or how this bug works
> (Check the Brighthand Boards thats were I saw the explanation).

3800 has the screen inverted. Because some old demented games hardcoded the line pitch, Compaq (not Microsoft) chose to expose a RAM buffer and then copy it pixel by pixel to the real screen. I hate them, they managed to ruin GAPI within the first year, morons. They also used the slowest copy known to man, it takes about 20ms each frame, killing performance. The only way around is to ignore the GAPi info for this model and use:
iPaq 38xx 240x320 -640 2 Addr=0xac0755a0 (maybe abfd0020 is real start?)

> All I know is
> that something to do with the lookup of the frame buffer takes a whole lot
> longer on the 3800 than it did on the 3600 series. Therefore the Developers of
> PocketTV came up with this hack to speed things up (which it does
> significantly). When I get time I will be testing your comments on the SHFull
> and I will test it with both the default settings and the hack, but I suspec the
> hack will still be needed.
> >
> > I have no IPAQ 3800 but I'm sure at 99% that if the author had followed the
> > Microsoft specs (Shfullscreen, etc..) the mamece will runs perfectly under
> GAPI
> See my last comment.

You are sure at 99% with zero technical knowledge and no iPaq 3800. Interesting...





Subjectconclusion new Reply to this message
Posted byexecom_rt
Posted on05/29/02 07:48 AM



>All I know is that something to do with the lookup of the >frame buffer takes a whole lot longer on the 3800 than it >did on the 3600 series.

You mean, trying to read the frame buffer takes a whole lot longer ? Probably this now the video memory is non longer cached (this is the same problem with directdraw, reading backbuffer takes ages). Anyway proposing Gapi or DIB should be a fine thing and easy doable.

You could think of an intermediate implementation : using a memory buffer, working on it and copy the memory buffer into the GAPI backbuffer.

Also, during the copy blit, you could only render the odd lines, to simulate the scanline interleaved mode, ( game would run faster, but less readable of course)

To conclude all this whole discussion, I will check with the 9.4 version for my own, trying to do some tests (SHFullscreen, doing a real 90 rotation option and trackball emulation using the pen) and reports to you of my differents tests.

If the modifications works better, perhaps they could be merged in next release.

Thanks you for your time.





SubjectIs it NOTHING to do with reading video memory new Reply to this message
Posted byfinaldave
Posted on05/29/02 01:33 PM



> >All I know is that something to do with the lookup of the >frame buffer takes a
> whole lot longer on the 3800 than it >did on the 3600 series.
>
> You mean, trying to read the frame buffer takes a whole lot longer ? Probably
> this now the video memory is non longer cached (this is the same problem with
> directdraw, reading backbuffer takes ages). Anyway proposing Gapi or DIB should
> be a fine thing and easy doable.
>
> You could think of an intermediate implementation : using a memory buffer,
> working on it and copy the memory buffer into the GAPI backbuffer.

Err "execom_rt" - HELLOOOO? Can you actually hear me?

Is it NOTHING to do with reading video memory, it is to do with the copy from the memory buffer to the physical screen - this is COMMON knowledge for WinCE programmers... why do you insist on
A) Offering technical advice when you have ZERO technical knowledge
B) Ignoring technical advice from people who do actually know what they are talking about
C) Trolling this board repeating the same incorrect technical advice
D) Bugging Tekmaster and confusing him with your incorrect information

Are you trying to sabotage MameCE, because you are doing a very good job?



SubjectRe: SHfullscreen new Reply to this message
Posted byTekhmaster
Posted on05/29/02 06:38 PM



> > becuase no other activity can really happen At least that was the theory. I
> > could add them for complete code but I just never did.
>
> Try setting an alarm and then playing - it will pop up the alarm on top of you
> application. If you don't call GXSuspend, I don't know, it might mess up the
> screen because you are drawing over another window? Try it - let me know...
As I said it was the theory :) It pops up, but the EMU rewrites over the top so the game continues with just a little garbage to the left and/or right sometimes.
Good point however. It would be nice to be able to tell the system to not interrupt no matter what.

> > (Check the Brighthand Boards thats were I saw the explanation).
>
> 3800 has the screen inverted. Because some old demented games hardcoded the line
> pitch, Compaq (not Microsoft) chose to expose a RAM buffer and then copy it
> pixel by pixel to the real screen. I hate them, they managed to ruin GAPI within
> the first year, morons. They also used the slowest copy known to man, it takes
> about 20ms each frame, killing performance. The only way around is to ignore the
> GAPi info for this model and use:
> iPaq 38xx 240x320 -640 2 Addr=0xac0755a0 (maybe
> abfd0020 is real start?)
Ok I remember now.
Seems typical of Compaq, they fix one thing and break another ie. the gamepad fix and then the screwed up design of the new Oval shaped pad. Makes playing almost as difficult as on the ipaq3600.


Cheers,
-Techmaster


SubjectRe: SHfullscreen new Reply to this message
Posted byfinaldave
Posted on05/29/02 07:33 PM



> > > becuase no other activity can really happen At least that was the theory. I
> > > could add them for complete code but I just never did.
> >
> > Try setting an alarm and then playing - it will pop up the alarm on top of you
> > application. If you don't call GXSuspend, I don't know, it might mess up the
> > screen because you are drawing over another window? Try it - let me know...
> As I said it was the theory :) It pops up, but the EMU rewrites over the top so
> the game continues with just a little garbage to the left and/or right
> sometimes.
> Good point however. It would be nice to be able to tell the system to not
> interrupt no matter what.

That's not really the way to think about it - with a new operating system like Windows CE, which is going to run on mobile phones, the user needs to have the power to interrupt any application. For example with a phone call or an urgent reminder.
A game can be paused, but a phone call can't - I think a game should pause itself if it gets a WM_KILLFOCUS message.

Not like good old DOS days I admit - but quite exciting in a different way I think!

> > > (Check the Brighthand Boards thats were I saw the explanation).
> >
> > 3800 has the screen inverted. Because some old demented games hardcoded the
> line
> > pitch, Compaq (not Microsoft) chose to expose a RAM buffer and then copy it
> > pixel by pixel to the real screen. I hate them, they managed to ruin GAPI
> within
> > the first year, morons. They also used the slowest copy known to man, it takes
> > about 20ms each frame, killing performance. The only way around is to ignore
> the
> > GAPi info for this model and use:
> > iPaq 38xx 240x320 -640 2 Addr=0xac0755a0 (maybe
> > abfd0020 is real start?)
> Ok I remember now.
> Seems typical of Compaq, they fix one thing and break another ie. the gamepad
> fix and then the screwed up design of the new Oval shaped pad. Makes playing
> almost as difficult as on the ipaq3600.

Absolutely! Let's hop the new HP iPaq fix the problem. I hate the joypad on the Jornada, it's so crappy and clicky!
On the 38xx I don't understand why they had to flip the screen at all: aren't the cases the same?





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byrjr
Posted on05/29/02 09:23 PM



> > Btw: The DLLs should be build on each platform of course.
>
> Er yes, thus "not portable".

But the binaries are never portable, of course. The source code still could be - I have done this before.

It is potentially as portable as the current system.

BTW, with respect to the button issue on the Ipaqs (which is a really stupid hardware design), there is a solution used in the game Rayman which is rather clever. Two 'soft' buttons are shown on screen, and they are pressed instead of the real buttons. Thus, the movement and button pressing can be done at the same time.

- Rob



SubjectModified MameCE version available new Reply to this message
Posted byexecom_rt
Posted on05/30/02 06:00 AM



Ok, since you prefers seeing things by yourself, upload this

ftp://ftp2.v3x.net/vx/mame/mamece-mod.zip ( 500 Kb )

This is the modified version of mamece 9.4 using the SHFullscreen + source.

You will be surprise than an zero knowledge technical did remove the annoying task bar, and increased mamece of +3 fps by using the shfullscreen.

Try it, the binary is provided + source modified, so I don't have anything than a ipaq 3630, perhaps you should try this version on your prefered PDA, give me comments on this (provide ARM binary only)

If you have doubt about my zero technical knowledge, i suggest to look on my site http://www.realtech-vr.com and http://www.v3x.net and also see how a zero technical can do since 1995. Ah, I'm now working on this game btw : http://www.tombraider.com (I've done the Ipaq version - If you want, my email is stephane@core-design.com


Best

PS: Since i've got the source now, I'm now much more understanding the problems, thanks you for your info for the Ipaq 3800 however...



> Is it NOTHING to do with reading video memory, it is to do with the copy from
> the memory buffer to the physical screen - this is COMMON knowledge for WinCE
> programmers... why do you insist on
> A) Offering technical advice when you have ZERO technical knowledge
> B) Ignoring technical advice from people who do actually know what they are
> talking about
> C) Trolling this board repeating the same incorrect technical advice
> D) Bugging Tekmaster and confusing him with your incorrect information
>
> Are you trying to sabotage MameCE, because you are doing a very good job?
>





SubjectRe: SHfullscreen new Reply to this message
Posted byexecom_rt
Posted on05/30/02 06:03 AM



Thanks for the ipaq trick, I will try this.
As I said, you can upload the modified version of the Mame CE 9.4 with the task bar removed. There is also some performance gain.
I've tested on Ipaq 3630 but should works on other models. It's fixing the bug when the user was tempted to click on the (X) button when playing (badly behave).

Since no more taskbar, I've got +3 fps gained on some game. Also looks nicer in full screen.

Best;


> Absolutely! Let's hop the new HP iPaq fix the problem. I hate the joypad on the
> Jornada, it's so crappy and clicky!
> On the 38xx I don't understand why they had to flip the screen at all: aren't
> the cases the same?
>





SubjectRe: Modified MameCE version available new Reply to this message
Posted byfinaldave
Posted on05/30/02 07:23 AM



> Ok, since you prefers seeing things by yourself, upload this
>
> ftp://ftp2.v3x.net/vx/mame/mamece-mod.zip ( 500 Kb )
>
> This is the modified version of mamece 9.4 using the SHFullscreen source.
>
> You will be surprise than an zero knowledge technical did remove the annoying
> task bar, and increased mamece of 3 fps by using the shfullscreen.

I don't believe that you increased the performance of MameCE by using SHFullscreen - that to me would make no sense. You are saying your SHFullscreen call turns the video memory into "special fast" memory? It alters the memory map to allow more speed?

I will reiterate, I have no task bar and no SHFullscreen call. Maybe a PocketPC 2002 thing? (I haven't got that to test on.)

> Try it, the binary is provided source modified, so I don't have anything than
> a ipaq 3630, perhaps you should try this version on your prefered PDA, give me
> comments on this (provide ARM binary only)
>
> If you have doubt about my zero technical knowledge, i suggest to look on my
> site http://www.realtech-vr.com and http://www.v3x.net and also see how a zero
> technical can do since 1995. Ah, I'm now working on this game btw :
> http://www.tombraider.com (I've done the Ipaq version - If you want, my email is
> stephane@core-design.com

Well if you know what you are talking about why are you saying stuff which isn't true?!
"it's probably reading from video memory which is slowing iPaq 38xx": not true - it's the rotation blit.
"DLLs are portable across all platforms": not true.
"It would be straightforward to put drivers in different DLLs": not true.
"SHFullscreen is the only way to get fullscreen": not true. I've got fullscreen without it - I mean this is just basic logic surely?

0/4 seems a bit bad to me.
The only way we can combine what both of us are seeing is maybe Pocket PC 2000 doesn't need a SHFullscreen command and Pocket PC 2002 does, but that would just be speculation. Don't jump to conclusions!

> Best
>
> PS: Since i've got the source now, I'm now much more understanding the problems,
> thanks you for your info for the Ipaq 3800 however...

No problem.





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byfinaldave
Posted on05/30/02 07:31 AM



> > > Btw: The DLLs should be build on each platform of course.
> >
> > Er yes, thus "not portable".
>
> But the binaries are never portable, of course. The source code still could be -
> I have done this before.
>
> It is potentially as portable as the current system.

How? Please enlighten me?

And how exactly would you handle the DOS port? Or the Kodak port?
Or the Dreamcast port? Or the EPOC version?

And who would voluteer to rewrite the entire MAME source code (all 2000 drivers). Yourself?




SubjectRe: Modified MameCE version available new Reply to this message
Posted byexecom_rt
Posted on05/30/02 08:46 AM




Seems indeed you don't have PocketPC 2002 and did not seen the problem I've got. Perhaps next time we should expose exactly the hardware we've got.

My configuration:
Ipaq 3830 + PocketPC 2002.

My problem :
- Task bar (the upper bar with Start and the clock) was visible during play game.
- You can close the game during play ( but in fact the Ipaq goes mad when doing this ...)
- Notice performance issues compared to PocketPC 2000

I solved this by:

- by adding the missing SHFullscreen code
- by modifying the GAPI initialisation
- improve performance on PocketPC 2002/Ipaq
- modification should be compatible on Pocket PC 2000 ( the earlier version, maybe as fast and why not faster than the previous version (in fact the OS don't need to update it (for example, the clock minutes))

My question : Why nobody reported this problem ? especially Ipaq 3800 users should see the task bar. So this update will also improve for them.

> I don't believe that you increased the performance of
> MameCE by using SHFullscreen - that to me would make no sense.

Probably I would said that I had a performance issue and now it's working as fast as it was with a Pocket PC 2000 (like yours).
So you will never know. unless you upgrade your pocket PC, see the problem by yourself and then use the updated version.


> I will reiterate, I have no task bar and no SHFullscreen call. Maybe a PocketPC 2002 thing? (I haven't got that to test on.)
Yes ! Finally !

> Well if you know what you are talking about why are you saying stuff which isn't true?!
> "it's probably reading from video memory which is slowing iPaq 38xx": not true - it's the rotation blit.

There was an issue on ipaq 38xx. Ipaq 38xx are Pocket PC 2002.

The performance issue was due to the fact that the code didn't perform some initialisation, but luckily did work on Pocket PC 2000.

On Pocket PC 2002, we used to see the upper bar when playing which of course reducing performance.

Then the author told it was a performance issue when accessing the frame buffer - strange, but did not said that on PocketPC 2002, the task bar is now visible .. ?

I asked : "When reading from frame buffer ? - I wasn't aware that the game used temporary buffer and copy it to the main frame buffer -

So my assumption was wrong, because I lacked of information. Having the source code, I understand now.

> "DLLs are portable across all platforms": not true.
> "It would be straightforward to put drivers in different DLLs": not true.

Again, incorrect, I've suggested in fact to create a main executable and generate DLLs for each games in order to reduce memory footprint. When requesting a game, the program load the matching DLL.

This concept of 'modules' could be adapted on each platform but actually everyone want to create a single executable with everything inside.

Also this proposal of 'extracting the driver from the main executable' is doable and is platform independant ( Because you understood a DLL which can be used on every plaform, no of course, it's a DLL for 1 platform)

> "SHFullscreen is the only way to get fullscreen": not true. I've got fullscreen without it - I mean this is just basic logic surely?

No I said that Microsoft suggested that SHFullScreen should be performed in order to get full screen.

It seems that on earlier PocketPC version, this wasn't needed, but under PocketPC 2002, this must be done.

>Pocket PC 2002 does, but that would just be speculation.
>Don't jump to conclusions!

Yes, just try in your own PDA, see it's still working. Then the modifications would work for both of us and everyone would be happy, so you will be agree that SHFullScreen is needed but tolerated on Pocket PC 2000.


Best;




SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on05/30/02 09:03 AM



>How? Please enlighten me?

>And how exactly would you handle the DOS port? Or the >Kodak port Or the Dreamcast port? Or the EPOC version?

>And who would voluteer to rewrite the entire MAME source >code (all 2000 drivers). Yourself?

the idea is you write a makefile that produces a main executable and a series of libraries for each game (which can be dynamic if the platform support dynamic libraries).

Ex:
1942 uses processor zx80 + processor audio zx123 + other processor
so we create a 1942.dll which uses zx80.dll and audiosx123.dll

The main program need 1942 to run, it load the 1942.dll, ask for the a struct GameDriver, automatically, the 1942.dll will load the requested dll needed ...

You see the point ? Also it's perfect to extend the roms forever and no need of 2 Mame version, needs to run a new game, just recompile the module and upload on your ipaq.

Of course, this would need the current mame code to be revised .. I won't but i'm sure that the developer thinked about that.

But with our PC with 1Gb of memory, who cares, but on PocketPC where memory is limited, this is something which would be needed.

Of course, on platform with no dynamic loading support (like DOS, but in fact, it's still possible, but hacky), the dll are .lib which are statically linked.




SubjectRe: SHfullscreen new Reply to this message
Posted byexecom_rt
Posted on05/30/02 09:06 AM



Yes, that's why we should introduce the stylus support for mamece, there is a lot of game when we can play with it.

Best;

> Ok I remember now.
> Seems typical of Compaq, they fix one thing and break another ie. the gamepad
> fix and then the screwed up design of the new Oval shaped pad. Makes playing
> almost as difficult as on the ipaq3600.
>
>
> Cheers,
> -Techmaster
>





SubjectRe: Modified MameCE version available new Reply to this message
Posted byfinaldave
Posted on05/31/02 06:09 AM



>
> Seems indeed you don't have PocketPC 2002 and did not seen the problem I've got.
> Perhaps next time we should expose exactly the hardware we've got.
>
> My configuration:
> Ipaq 3830 + PocketPC 2002.
>
> My problem :
> - Task bar (the upper bar with Start and the clock) was visible during play
> game.
> - You can close the game during play ( but in fact the Ipaq goes mad when doing
> this ...)
> - Notice performance issues compared to PocketPC 2000
>
> I solved this by:
>
> - by adding the missing SHFullscreen code

Actually I've just realised: I have Ipaq 3630 and Pocket PC 2002, not 2000 as I thought. So you are definitely wrong.





SubjectIs there a developer here ? new Reply to this message
Posted byexecom_rt
Posted on05/31/02 08:48 AM



> Actually I've just realised: I have Ipaq 3630 and Pocket PC 2002, not 2000 as I thought

You are a funny guy, you even don't know the brand and the OS version of your own Pocket PC .. and you claim to be a developer ? Or do you use an emulator ?

Btw who's the f**k are you ? You even not a MameCE developer, me neither, but as the source compile.txt said:

"If you make any special enhancements or fix any substantial bugs, please submit them to me to be included in the Official MameCE3 Release."

That's I'm trying to do ( I wanted that to be concluded but here, I'm losing my time now )

Anyway all modifications I suggest should be validated by Techmaster not by you.

So you an just say "Well I don't have this issue on my ipaq, so maybe you should ask to more people about this", instead of being so rude.

Sorry dude, you are just an user like me here.










SubjectRe: Is there a developer here ? new Reply to this message
Posted byTekhmaster
Posted on05/31/02 02:57 PM



All right guys, settle down.

I think you both presented valid information and I will take both into consideration when I get a chance to do some more work on this project.

-snip-
> "If you make any special enhancements or fix any substantial bugs, please submit
> them to me to be included in the Official MameCE3 Release."
>
> That's I'm trying to do ( I wanted that to be concluded >but here,

Thank you, that is what I like to see here, more discussion on how to make it better.
Good, bad, and off the wall suggestions are all appropriate and none is discarded without at least a little thought.


Cheers,
-Techmaster


SubjectRe: SHfullscreen new Reply to this message
Posted byTekhmaster
Posted on05/31/02 03:04 PM



> Had a quick look at the MAMECE code
>
> hWnd = CreateWindow( _T("MAMECE_PLAYWINDOW"),
> _T(""),
> WS_POPUP,
> 0,
> 0,
> GetSystemMetrics(SM_CXSCREEN),
> GetSystemMetrics(SM_CYSCREEN) ,
> MAMECE3App.m_hwndUI,
> NULL,
> hInstance,
> NULL);
>
> ShowWindow(hWnd, SW_SHOWNORMAL);
> UpdateWindow(hWnd);
>
>
>
> As far as I can see there are some things to try before trying the SHFullscreen
> call. The WS_POPUP and the ShowWindow(hWnd,SW_SHOWNORMAL) call (I just used
> WS_VISIBLE). Maybe give that a try?
>

Would that really change much? After all, this routine is run once, when the window initializes. I always thought the WS_popup was wrong but it was from the original Mame Code so I left it in.


Cheers,
-Techmaster


SubjectRe: SHfullscreen new Reply to this message
Posted byTekhmaster
Posted on05/31/02 03:11 PM




-snip-
> > Good point however. It would be nice to be able to tell the system to not
> > interrupt no matter what.
>
> That's not really the way to think about it - with a new operating system like
> Windows CE, which is going to run on mobile phones, the user needs to have the
> power to interrupt any application. For example with a phone call or an urgent
> reminder.
> A game can be paused, but a phone call can't - I think a game should pause
> itself if it gets a WM_KILLFOCUS message.
>
> Not like good old DOS days I admit - but quite exciting in a different way I
> think!
You are right of course.

-snip-
> > Ok I remember now.
> > Seems typical of Compaq, they fix one thing and break another ie. the gamepad
> > fix and then the screwed up design of the new Oval shaped pad. Makes playing
> > almost as difficult as on the ipaq3600.
>
> Absolutely! Let's hop the new HP iPaq fix the problem. I hate the joypad on the
> Jornada, it's so crappy and clicky!
I agree somewhat I have the Jornada as well and the pad is a bit 'loose'. However it's a tad better than the iPaq because you can actually move diagnally without guessing that you are.

> On the 38xx I don't understand why they had to flip the screen at all: aren't
> the cases the same?
One can only wonder why Compaq made such a change. Only one think is probably absolute, we will never be told the real reason. :\



Cheers,
-Techmaster


SubjectRe: SHfullscreen new Reply to this message
Posted bythekINGpIN
Posted on06/01/02 08:31 AM



first of all, sorry for the interruption. Just want to say...your posts are really interesting, I´ve been reading all of them since the first one...and keep up the good work!!! you´re going to make it guys!! :-)

regards and GL




SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byrjr
Posted on06/01/02 10:48 AM



> > But the binaries are never portable, of course. The source code still could be
> -
> > I have done this before.
> >
> > It is potentially as portable as the current system.
>
> How? Please enlighten me?

It's not too hard. If you look into cygwin and mingw, they can be used to treat DLLs much like shared objects on unix systems. Beyond that, some per-architecture macros and such are simple enough to cleanly implement.

> And how exactly would you handle the DOS port? Or the Kodak port?

I wouldn't have them use dynamic loading, of course. Problem solved.

Or have you never seen a project that can be compiled either way? There are thousands out there.

> Or the Dreamcast port? Or the EPOC version?

See above.

> And who would voluteer to rewrite the entire MAME source code (all 2000
> drivers). Yourself?

Now you are getting petty. If I get less busy, I might consider it. It's not as if you need individual effort on each driver, any more than you do to convert the linefeeds. (Well, more, but it's mostly a template process). And just because I'm not doing it myself right now does not mean it is not a good idea.

- Rob



SubjectRe: Is there a developer here ? new Reply to this message
Posted byfinaldave
Posted on06/02/02 09:09 PM



> All right guys, settle down.
>
> I think you both presented valid information and I will take both into
> consideration when I get a chance to do some more work on this project.

TechMaster - It's not actually for me (I haven't downloaded MameCE to try out yet), I was just pointing out basic logical flaws in the supposed 'definite information' this guy was presenting to you!

It's a pet hate of mine when people crop up claiming they are 99% sure that X,Y,Z are true (e.g. the now infamous SHFullscreen call). Amazingly frequently I have found the bastards actually haven't got a clue! I was caught not once, not twice but THREE TIMES by these people. The first time was with a 'bug' in Strider which the person swore to me was not in the original. The second was a bug in Street Fighter 2 where the person swore that a piece of graphics appeared in the original but not in the emu. The third time is a long-standing one which keeps being revisited and revolved around a phantom extra music track in After Burner II. Honestly, you would not believe the e-mails I get from this guy DEMANDING I fix my sound code because I am missing a music track.

All three times it turned out that however passionate and forceful their complains were, they were ultimately found out to be talking complete and utter crapola. I spent in total something in the order of weeks searching for the non-existant bugs.

Take bug reports and suggestions as objectively as you can. Also if you find someone placing too much faith in their brand new expensive hardware NOT being at fault, that's another warning sign (newer Geforce owners refusing to believe they have crap drivers is a great example of this).
Honestly all the crap is enough to make you put automatic bug reporting code in you program like Microsoft did!

Good luck mate, and most importantly keep development fun. If you find you are confusing work with play, take a short break and do another project you enjoy. You enthuasiasm will always come back and you code better with it.


> -snip-
> > "If you make any special enhancements or fix any substantial bugs, please
> submit
> > them to me to be included in the Official MameCE3 Release."
> >
> > That's I'm trying to do ( I wanted that to be concluded >but here,
>
> Thank you, that is what I like to see here, more discussion on how to make it
> better.
> Good, bad, and off the wall suggestions are all appropriate and none is
> discarded without at least a little thought.
>
>
> Cheers,
> -Techmaster
>





SubjectRe: Is there a developer here ? new Reply to this message
Posted byTekhmaster
Posted on06/02/02 11:47 PM



-snip-
> > consideration when I get a chance to do some more work >on this project.
>
> TechMaster - It's not actually for me (I haven't >downloaded MameCE to try out
> yet), I was just pointing out basic logical flaws in >.supposed 'definite
> information' this guy was presenting to you!
I agree, he was defintely a bit to 'definitive' as his comment about the hack showed.
However, he made a good attempt and pointed out that shfullscreen was a possibility and he provided a point of reference where it showed that you can indeed use it (something both of us were not aware of).
How much gain is still to be tested 'officially' but it was a posative attempt to help improve the EMU.


> It's a pet hate of mine when people crop up claiming they are 99% sure that
> X,Y,Z are true (e.g. the now infamous SHFullscreen call).
I can understand :)
I try to ignore the non-contributers and focus on the postive comments. Thats why I chose a public forum, one that I can ignore or read at my leasure ;)

-snip-
> Take bug reports and suggestions as objectively as you can. Also if you find
-snip-
I always do. I make a note or copy the comments and when I get time or feel like working on another angle, I analyze what has been submitted.


> Good luck mate, and most importantly keep development fun. If you find you are
> confusing work with play, take a short break and do another project you enjoy.
> You enthuasiasm will always come back and you code better >with it.
Thank you. I saw what some of the nags did to you and other good coders and I learn from both mine and others experiences when I can. Thats why you see gaps in development, I take a brake whenever I feel the need. A good game of Quake, or a romp thru Lands of Lore can put a new perspective on things :)

I enjoy comments from everyone, both experienced folks like yourself and other neophytes (myself being one of them) :)
So feel free to comment by all means. I just wanted to remind everyone to keep it civil.


Cheers,
-Techmaster


SubjectRe: SHfullscreen new Reply to this message
Posted byfinaldave
Posted on06/03/02 01:09 PM



> > Had a quick look at the MAMECE code
> >
> > hWnd = CreateWindow( _T("MAMECE_PLAYWINDOW"),
> > _T(""),
> > WS_POPUP,
> > 0,
> > 0,
> > GetSystemMetrics(SM_CXSCREEN),
> > GetSystemMetrics(SM_CYSCREEN) ,
> > MAMECE3App.m_hwndUI,
> > NULL,
> > hInstance,
> > NULL);
> >
> > ShowWindow(hWnd, SW_SHOWNORMAL);
> > UpdateWindow(hWnd);
> >
> >
> >
> > As far as I can see there are some things to try before trying the
> SHFullscreen
> > call. The WS_POPUP and the ShowWindow(hWnd,SW_SHOWNORMAL) call (I just used
> > WS_VISIBLE). Maybe give that a try?
> >
>
> Would that really change much? After all, this routine is run once, when the
> window initializes. I always thought the WS_popup was wrong but it was from the
> original Mame Code so I left it in.

Yes WS_POPUP is the correct style to use in Win32, however it doesn't seem to be used in Windows CE (all windows have no borders anyway). Also all of the examples use a style of 0 (no WS_POPUP flag).

Would that really change much? - Possibly - it can do as Windows is a little bit eccentric - that was the only difference I could see between your code and mine.

If it doesn't work, give the SHFullscreen a try, since there's nothing else left. But it's just strange as I seem to having no trouble. Maybe there is menus and stuff in MameCE which changes things. Who knows.






SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byfused
Posted on06/10/02 08:30 PM



> Also, the landscape mode is faster than the regular mode because you can blit
> the screen with a single memcpy (it's +10 % faster). This is something to
> investigate further (needs to rotate the paddle keys too ...).
>
> Actually the rotate option left/right option does not work ( flips the display
> of 180 degrees instead of 90 degrees, I mean, on my Ipaq ).
>
> To refresh the clock and bar at exit, here my tip I use: (which should be also
> performed when changing of task WM_FOCUSLOST (not sure for the exact name))

WM_KILLFOCUS

> Grab the memory buffer (with GXBeginDraw(), copy it into a a 320x240x2 byte
> buffer ( but you can compress it with a rle routine to reduce memory footprint )

But you will refresh with the wrong time.
Doesn't InvalidateRect work?

> When returning to the GUI, copy back this buffer, and voila, everything will be
> restored.
>
> Last thing again, allow an 'safe mode option' using DIB instead of GAPI. Can be
> convenient ..
>
>
>
> > Thats exactly why I didn't use it either, I had no idea you could.
> > All the sample apps using Gapi (that I used right after it came out) use the
> > CreateWindow() function.
> >
> > I'll take a look at it and rewrite it to use that function a soon as I get a
> > chance.
> >
> > FYI, My first attempt at rewriting this had the full screen blacked out,
> however
> > it would never refresh the menu bar and clock when I exited MameCE3. I always
> > assumed it was becuase we were blitting to the screen directly and the OS
> didn't
> > know that we overwrote the menubar. I also couldn't figure out how to tell it
> > that I had written on the menu at the time.
> > Also, (becuase of this)my blit routine in display.c does not reblit the
> menubar.
> > It start its blit at the screenframe+=26.
> >
> > Perhaps we will get a few more frames per second after this change :)
> >
> >
> > Cheers,
> > -Techmaster
> >
>





SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byVidgamer
Posted on06/27/02 11:28 PM



On my HPC, I have a mouse-like device. I am unsure how to access this in WinCE, and even less sure how to get it to work in MAME CE. I played around with the mouse and trackball stuff in MAME CE (I'm using Darren's 10X code I think?), but didn't get very far.

Anyway, yeah, I think it'd be great to have an alternative input. Warlords is almost unplayable with the buttons. It has a decent frame rate, so a mouse-like input would make this actually playable beyond level 1.

By the way, I agree that separating things into separate .dlls would be ideal given the small memory in these devices, but then, it's hard to get excited about rewriting the code to do that, eh? :-)

> Some games in MameCE can be played with the stylus (like Starwars, Arkanoid, why
> not 1942 or 1943). Why don't try to emulate the mouse (I means to add the same
> mame32 option 'mouse support'.
....

G.


SubjectRe: Move/Stylus support and suggestions.. new Reply to this message
Posted byexecom_rt
Posted on06/28/02 05:10 AM



Actually, the code is disabled, however, i've my own version running with pen (with several enhancing), and working fine. I will try to make a build for you if you want.

> By the way, I agree that separating things into separate .dlls would be ideal given the small memory in these devices, but then, it's hard to get excited
> about rewriting the code to do that, eh? :-)

Actually, not so hard, because I've already started that. It was very easy because the actuel source code can do that.

In fact, Mame was a DOS project and this platform does not handle dynamic code relocation (it does but it's a pain in the *ss). by legacy code, this was not done.
By the increasing number of game, maybe the author will change that.

I'm thinking about developing a fresh new port of Mame for WinCE. Using updated code. I've looked the source code of MameCE and MameBoy and I think a fresh new approach need to be done. If the Ipaq 3900 with the new multimedia extension with a new frequency and new display is really quick ass, I will probably start a new port using latest mame source 0.36 is a minimum and some tools to manage roms from Windows to your ipaq. And also, sounds and all the stuffs will work.

But it will be optimised for intel xscale 3970, sorry for your HPC (btw, HP is now merged with compaq)

You will probably heard in the month to come about this new port of mame.

(Also, the user interface, will be designed, stylus support, *full* sound support etc..) and written from scratch.

Best;

http://www.intel.com/design/pca/prodbref/298620.htm
Best;

> > Some games in MameCE can be played with the stylus (like Starwars, Arkanoid,
> why
> > not 1942 or 1943). Why don't try to emulate the mouse (I means to add the same
> > mame32 option 'mouse support'.
> ....
>
> G.
>





Previous ThreadView All ThreadsNext Thread*Show in Threaded Mode