Proof-of-concept of Howard's idea

[ultrastyle]

I'll throw my 2 cents into the ring. I was reading about the list of controls and that got me thinking. (please realize at this point the original link to the original d/l is gone, so I haven't seen what has been done so far.) what about a list of controls that is color coded, over a static image of your control panel. then all you need to do is drop colored circles over buttons to demonstrate what button goes where. I.E. Fire is red, Jump is Green, Turbo is blue, etc. the xy coordinates would always be the same, button 1 would simply change color according to what its used for. The list itself could be dynamic and the colors static. Which means you simply have to generate text over a static picture. Joysticks, I imagine are intuitive. If not, they wouldn't have gotten all of our quarters when we were kids. It's really button layouts your after here.

[Howard_Casto]

Because:

1.  That's what the viewer does for the most part.

2.  This is quite difficult to do in mame without extensive modification.  

3.  If you would have read the thread discussing this before I've already gone over the fact that Mame only supports a single, ugly font of the same font size.  There simply wouldn't be enough room on the screen to generate a viewable layout with such a large font.  

3a.  Mame doesn't allow you to position text, it is all done using one of two menu generating macros.  It would require core changes to position text.  

4.  That would still require the hacks budda is doing to implement static image support.  It's far far easier for me to make the viewer generate the image (which would actually be more accurate do to some of my special functions) than to struggle through doing it in mame.  



I'm all honesty that would probably be the best solution, but good luck finding someone willing to put in the tremendous effort and time required to make the engine.  

[Howard_Casto]

Ok,  I compiled it and it runs without a hitch.  I will package up a beta soon.  

I have some concerns about rotation though......  

It appears that mame wants the artwork files in whatever orientation the game is rendered.  That seems like a simple problem... just rotate all the verticals right?  Well not exactly..... render orientation apparently also involves the sync of the monitor as well..... mario bros for example.... it uses an inverse sync and thus the bezel has to be upside down.  Donkey Kong, I believe also uses an inverse sync AND it's vertical, so it has to be rotate 270 degrees.  

What this means to me is rotation might have to be determined on a per-game basis.  That could get ugly.  

[SirPoonga]

Yeah, I could have told you that since I've been working on the artwork fill edges hack.

I am also looking into what it would take to output a png over everything with a button push.  That won;t be simple inside of mame with how it figures the viewable area.  Might have to have something that stores the game's viewable areea and the controls viewable area and do a swap.  Could get messy.

[Buddabing]

Ok,  I compiled it and it runs without a hitch.  I will package up a beta soon.  

I have some concerns about rotation though......  

It appears that mame wants the artwork files in whatever orientation the game is rendered.  That seems like a simple problem... just rotate all the verticals right?  Well not exactly..... render orientation apparently also involves the sync of the monitor as well..... mario bros for example.... it uses an inverse sync and thus the bezel has to be upside down.  Donkey Kong, I believe also uses an inverse sync AND it's vertical, so it has to be rotate 270 degrees.  

What this means to me is rotation might have to be determined on a per-game basis.  That could get ugly.  

Hmmmmm. If it's easier to calculate the rotation angle within MAME, maybe I could add another parameter to the batch file that has either the angle (0,90,180,270) or 0,1,2,3 in it.

I really don't want the angle calculation per game. What would we do every time a game is added?

[Howard_Casto]

Yeah, I could have told you that since I've been working on the artwork fill edges hack.

I am also looking into what it would take to output a png over everything with a button push.  That won;t be simple inside of mame with how it figures the viewable area.  Might have to have something that stores the game's viewable areea and the controls viewable area and do a swap.  Could get messy.

Viewable area actually works pretty well....  The only issue I'm finding is like if you have bezel artwork turned on the controls.png is only displayed inside the bezel.  Your right, it really needs to use the physical screen aspect to calculate area rather than the game size, else when we do get vertical games working the image will be horribly squashed.  I think the quickest fix would be to check for orientation and alter the layout dimensions depending upon them.  

Example....... In horizontal games the aspect of both the image generated and the game are 4:3 so the coordinates of the artwork file are in 1:1 factors.  (I.E the full screen or a percentage of the screen matching the same ratio).  If it's vertical take those same coordinates and leave the width alone but take half off of the height.  That should fix the squashing.  This doesn't fix games with odd aspect ratios though, so I dunno about them.  


Regarding the rotation.....  Really even the rotation itself needs to be done in mame.  Mame has various devices to rotate and I think it would be faster.  

In theory figuring out the orientation shouldn't be that bad, I was just exaggerating to get my point across.  Afaik only nintendo games used inverse sync and that is easy to check for.  Also orientation and screen resolutions are stored in mame as well.  It's just all of this would depend upon the accuracy of mame, and we all know how that goes.  

[SirPoonga]

Ok, I hae learned some useful information since I have been working ont he artwork fill edges hack.  First, you don't want to be using the artwork system to display this in mame.  Mame will stretch the image upon keepaspect and hwstretch are on.

I know HowardC knows this but not sure about the rest.  The menu text in mame is actually converted to a bitmap.  This is all done in the usrintrf.c file.  However, everything in there puts everything to display into the screen bitmap.

Funny thing is this is done in artwork.c, you have this struct.
struct mame_bitmap *artwork_get_ui_bitmap(void)
{
   return uioverlay ? uioverlay : Machine->scrbitmap;
}

Then in mame.c you have a funtion updatescreen() which contains this line:
if (handle_user_interface(artwork_get_ui_bitmap()))

So, what's handl_)user_interface?  It's in usrintrf.c.  from what I can tell it setups of alot of what you see on screen including FPS, frameskip, handling keypress events that effect what is shown on screen, etc..

That is where you'd want to put a button press handle for the controls.png file to display.  However you wouldn't want to use the bitmap sent into the function.  You'd wnat to display it fullscreen.  That will require a new function built just to display that graphic.  Oh, in artwork.c there are some funcitons for loading graphics form png files that owuld be helpful in this cause.

Though for now I'd try displaying a controls.png to the bitmap sent into that function.  Just to see if you can get it to display.  Because making a special bitmap for that file might be a little more involved.  You want to start out with something a little more simple so why not use what is there for now.

If you note inside that function there are statements like:
/* if the user pressed F12, save the screen to a file */
   if (input_ui_pressed(IPT_UI_SNAPSHOT))
      save_screen_snapshot(bitmap);

   /* This call is for the cheat, it must be called once a frame */
   if (options.cheat) DoCheat(bitmap);
/* if the user pressed F4, show the character set */
   if (input_ui_pressed(IPT_UI_SHOW_GFX))
   {
      osd_sound_enable(0);

      showcharset(bitmap);

      osd_sound_enable(1);
   }

All you'd have to do is create your own keypress thing, like:
input_ui_pressed(IPT_UI_SHOW_CONTROLS)
whereever the IPT constants are defined.
Then make a function like
showcontrols(bitmap);
Put it together you have
if(input_ui_pressed(IPT_UI_SHOW_CONTROLS))
showcontrols(bitmap);

In the future then right before you call showcontrols(bitmap) you could make your own bitmap, then call the funciton, then display the bitmap.

I  might look into doing this after I get some other projects done, unless one of you want to try and tackle it.

If any of you want to try this but would like my help as I have been starting to get a good handle on what is going on in mame either PM me and I will give you my msn messenger account or we could talk int he byoac chat room.

[Buddabing]

Regarding the rotation.....  Really even the rotation itself needs to be done in mame.  Mame has various devices to rotate and I think it would be faster.  

In theory figuring out the orientation shouldn't be that bad, I was just exaggerating to get my point across.  Afaik only nintendo games used inverse sync and that is easy to check for.  Also orientation and screen resolutions are stored in mame as well.  It's just all of this would depend upon the accuracy of mame, and we all know how that goes.  

I looked at the code and it is trivial to find out what orientation to use. Once that is known, I can modify the existing artwork load routine to pre-rotate the controls.png image. So a rotated controls.png will load at the same speed as an unrotated one.

I'll make the necessary modifications for the rotation. You concentrate on generating a non-rotated image.

Controls.png will only display in the game area and not in the bezel area. I believe that is due to the way MAME sorts the various rectangles that it uses to calculate display regions.

[SirPoonga]

addition to what I said, actually you'd have to modify update_video_and_audio() in mame.c to to display the new bitmap.  Actually, I don;t think it would be too hard to do do, just need to really understand what is going on.

[Buddabing]

So we want to maintain the aspect ratio of controls.png regardless of the aspect ratio of the game, and display controls.png across the entire width of the screen, regardless of whatever artwork is already there?

That should be doable. I already got the rotation part working.

[SirPoonga]

yeah, I believe it is doable, you just can't use the bitmap everything else in mame is outputting too.  BTW Howard, I think this is also how you can do dual monitors.

[wj2k3]

Buddabing - Great Job! This is an excellent addition to the Mame program.  I have downloaded and compiled your changes and it is working great.  

This is already worhwhile, even if I had to go through and create each controls.png files manually.

I look forward to testing out Howard's program but in the mean time I have been creating some of my own control.png files for games in my cab.  To that end, I was wondering if it would be possible to make it so that you could add a flag to run Mame without launching the makectrl.bat file.  

The reason is because along with the layout of my CP, I have been including the image of the insturction card/bezel of some games in the controls.png file to make it even more useful.

If not, i can just rename/delete the .bat file when I don't want  my custom controls.png files to be overwritten.

Anyways, thank you both for a great addition to my cab.

-wj2k3

[Howard_Casto]

Agreed.....  a flag is need imho.  

budda, i'll send you the updated beta of the viewer before the end of the week.  I was hoping to wait until the big changes but considering the ctrlr file format is now royally ahem "different" than before that could be some time.  

[Tiger-Heli]

Agreed.....  a flag is need imho.  

budda, i'll send you the updated beta of the viewer before the end of the week.  I was hoping to wait until the big changes but considering the ctrlr file format is now royally ahem "different" than before that could be some time.  

Idealized Requests:

I know this can't be answered until the concept is figured out, but I am not sure I like the new MAME changes, and either way, I will probably be using older MAME versions for some time.

Could the viewer be made to support ctrl.ini files and ctrl.cfg files and/or could separate versions of the viewer be released so you pick the one that matches your version of MAME?

Could the MAME changes to display the images be released as a -diff file so they could be applied to (virtually) any MAME version?

Thanks!!!

[Buddabing]

I think two flags would be nice:

1) -nomakectrl will prevent the batch file from being called, but will still allow the controls.png to be displayed. This will allow "roll your own" controls.png files.

2) -noshowctrl will not show any controls.png files. I don't know if we should have this include -nomakectrl or make the two flags mutually exclusive, to disable both the viewer and the display code you would need to specify both flags.

A user could use the second flag if he wants to exclude certain games, for example if he knows how to play pacman and doesn't want the controls shown or if the aspect ratio makes his controls look funny.

Maybe a third flag would cause the display to be off by default and then the user could specify -nomakectrl
-showctrl to display his roll your own images or just
-showctrl to generate and display.

Future releases of the display code will be in patch form.

Unfortunately, a patch which is created with version X of mame probably won't work on version Y. Now, it probably wouldn't be too hard to create patches for old versions, since the code is frozen.

[Tiger-Heli]

I think two flags would be nice:

1) -nomakectrl will prevent the batch file from being called, but will still allow the controls.png to be displayed. This will allow "roll your own" controls.png files.

2) -noshowctrl will not show any controls.png files. I don't know if we should have this include -nomakectrl or make the two flags mutually exclusive, to disable both the viewer and the display code you would need to specify both flags.

A user could use the second flag if he wants to exclude certain games, for example if he knows how to play pacman and doesn't want the controls shown or if the aspect ratio makes his controls look funny.

Agreed on the two flags.  Not sure about the exclusive part.  I think there would be games where you might want to disable it all together, some where you want to display your own files, and some where you want to use the viewer.

Maybe a third flag would cause the display to be off by default and then the user could specify -nomakectrl
-showctrl to display his roll your own images or just
-showctrl to generate and display.

I don't think a third flag would be required.  Couldn't you just specify
-nomakectrl 1
-noshowctrl 1
in mame.ini and then set it to 0 in the gamename.ini if you wanted it off by default, but on for individual games?

Future releases of the display code will be in patch form.
Unfortunately, a patch which is created with version X of mame probably won't work on version Y. Now, it probably wouldn't be too hard to create patches for old versions, since the code is frozen.

Cool.

BTW, I liked the idea of having the Cntrls come up when Pause was pressed, rather than having a dedicated key, but I assume if I assigned the viewer hotkey to P and Pause to P it would work that way, correct?

[Buddabing]

Agreed on the two flags.  Not sure about the exclusive part.  I think there would be games where you might want to disable it all together, some where you want to display your own files, and some where you want to use the viewer.

The two flags are in and are mutually exclusive. I'm open to suggestions as to different names for them.

I don't think a third flag would be required.  Couldn't you just specify
-nomakectrl 1
-noshowctrl 1
in mame.ini and then set it to 0 in the gamename.ini if you wanted it off by default, but on for individual games?

That .ini stuff is pretty cool! I had never used it before. It works like a champ. That will work well for wj2k3.

BTW, I liked the idea of having the Cntrls come up when Pause was pressed, rather than having a dedicated key, but I assume if I assigned the viewer hotkey to P and Pause to P it would work that way, correct?

Currently it is set up to whatever pause is set to, not necessarily P.

[Tiger-Heli]

BTW, I liked the idea of having the Cntrls come up when Pause was pressed, rather than having a dedicated key, but I assume if I assigned the viewer hotkey to P and Pause to P it would work that way, correct?
Currently it is set up to whatever pause is set to, not necessarily P.

That's what I would prefer, but I thought SirP was looking for a dedicated key that it could be set to, separate from pause.  I might have misinterpreted, though.

[SirPoonga]

I think it shoud be its own key, not pause.  you can map the pause and this to the same key.  When I pause sometimes I am looking at the games, I wouln;t want something to get in front of it unless I told it so.

[Buddabing]

I have a new version of the display code.

New features:
- The image is displayed across the entire width of the MAME window.

- The last remnants of the old controls.art have been swept away, it is not used anymore.

- An attempt is made to display the controls in the proper aspect ratio. It is better than the previous version, but not exactly right.

- Two flags have been added to mame, -nomakectrl and -noshowctrl. The names of these flags are subject to change, so be aware. The function of the flags should be obvious.

- The orientation of the image is automatically adjusted. The program now expects a controls.png with the normal orientation.

To Do:
- Make an option to use a different key than pause to view the controls.

- Improve the aspect ratio correction.

Here's the link to the zip file containing the patches.

[SirPoonga]

How do you use the patch?  It's not your normal diff and patch that everyone else uses.

http://gnuwin32.sourceforge.net/packages/diffutils.htm

[Buddabing]

How do you use the patch?  It's not your normal diff and patch that everyone else uses.

http://gnuwin32.sourceforge.net/packages/diffutils.htm

These patches have to be applied with patch -R. When I ran diff I was in my altered source directory, with the original source in a v0.84 branch of the directory tree.

So,
1) extract patches
2) copy patch1.txt to (MAMEROOT)\v0.84\src
3) copy patch2.txt to (MAMEROOT)\v0.84\src\windows
3) cd to (MAMEROOT)\v0.84\src
4) patch -R < patch1.txt
5) cd to (MAMEROOT\v0.84\src\windows
6) patch -R < patch2.txt
7) cd back to (MAMEROOT)\v0.84
8. make clean
9) make

If that doesn't work PM me and I can email you the altered source files.

[SirPoonga]

Interesting.  I only asked because this is odd.  You have seperate patch files, not one.  And the format is differnt than most others I have seen.  Then for those you do this: patch -u -p 1 -i [diff file name]

Edit:  ok, I deleted the .o files of the files that changed.  Compiling now.  linking....

What would you suggest be the best way to test this?  Just start up a game like bloodbro?

[Buddabing]

Interesting.  I only asked because this is odd.  You have seperate patch files, not one.  And the format is differnt than most others I have seen.  Then for those you do this: patch -u -p 1 -i [diff file name]

I know very little about diff and patch and this was the easiest and fastest way for me.

Edit:  ok, I deleted the .o files of the files that changed.  Compiling now.  linking....

Warning: if you don't do a full compile (make clean first) then MAME will probably crash. This is because the mame.h was changed and it changed the size of the options structure.

What would you suggest be the best way to test this?  Just start up a game like bloodbro?

I have a test suite of 8 games:
zookeep (ROT0 with artwork)
pacman (ROT90 with artwork)
mario (ROT180 with artwork)
gorf (ROT270 with artwork)
gravitar (ROT0 without artwork)
astrof (ROT90 without artwork)
darkplnt (ROT180 without artwork)
bagman (ROT270 without artwork)

I also run each game in a window and full screen.

[SirPoonga]

Edit:  ok, I deleted the .o files of the files that changed.  Compiling now.  linking....

Warning: if you don't do a full compile (make clean first) then MAME will probably crash. This is because the mame.h was changed and it changed the size of the options structure.

Right, because if you change a .h but not the .c make won;t remake the .o file.  hence I deleted all the .o of that files that have been changed.  I'm on a slow machine, not going to recompile code that doesn't need recompiling  actually, sometimes you have to delete the entire root and windows folders.  But I wouldn't get rid of the driver and stuff, those don't have anything to do with this change

Anyway, I need a command-line zip.  suggestions?  Can winzip do commandline?

E:\mamedev\mamectrl>mame pacman
OK.
parsing puckman.ini...N/A
parsing pacman.ini...N/A
Using DirectInput 7
Keyboards=1  Mice=1  Joysticks=2 Lightguns=0
Mouse support disabled
Joystick support disabled
Keyboards=1  Mice=0  Joysticks=0
'zip' is not recognized as an internal or external command,
operable program or batch file.

-----------------------------------------------------
Exception at EIP=00484F14: ACCESS VIOLATION
While attempting to read memory at 00000000
-----------------------------------------------------
EAX=00000000 EBX=03630958 ECX=00000000 EDX=00000000
ESI=0022F9C4 EDI=00852060 EBP=00000005 ESP=0022F980

E:\mamedev\mamectrl>

[SirPoonga]

Ok, I got the commandline stuff for winzip, but it's evaluation so I ahve to press a key

Anyway, this is cool.

However there has to be a way to not use the artwork folder.  If you could just dump the pngs in a folder that would be the ultimate option.  That way an outside source creates the png file.

I know this is a proof of concept.  So it does show it is possible.

[Buddabing]

Anyway, I need a command-line zip.  suggestions?  Can winzip do commandline?

There is a free zip program here. I couldn't get on their web site when I tried it just now....

MAME should not crash if there is no controls.png in the zip file, or no zip file at all. So that is a bug.

[SirPoonga]

no, the crash is due to no zip command.

[Howard_Casto]

Ok, I got the commandline stuff for winzip, but it's evaluation so I ahve to press a key

Anyway, this is cool.

However there has to be a way to not use the artwork folder.  If you could just dump the pngs in a folder that would be the ultimate option.  That way an outside source creates the png file.

I know this is a proof of concept.  So it does show it is possible.

Open folders take priority over zip files.  My suggestion.... create the folder, dump the crap in it, upon exit delete the folder you created.  

[Buddabing]

I've improved my code to correct the aspect ratio on the display. So a square in the controls.png will appear square regardless of what game is being played. The code to do this is ugly, however.

Regarding the treatment of paths: MAME has a certain search order for artwork coded into it. It searches gamename.zip in the artwork directory and it searches the directory artwork\gamename. Changing the file path to the current directory or to a temporary directory is not easy. I want this patch to be as small as possible and I don't want to touch more source code files than I have to. Four files is more than enough. The average user will not care that there are many small zip files in his artwork directory.

I'm aiming for a code update tomorrow. I'll look again at the file handling, but if I can't do it in just a few lines of code then I don't want to do it.

Regards,
Buddabing

[SirPoonga]

My point is why use the mame artwork stuff to load the png.  Make a new load_png function, base it off the artwork stuff but modify it as needed.

[Buddabing]

My point is why use the mame artwork stuff to load the png.  Make a new load_png function, base it off the artwork stuff but modify it as needed.

IMO that is too much effort for not enough benefit. I'll look deeper into the code and I'll see what can be done.

[SirPoonga]

Well,  I just htink if this is done it should be done the right way.  This is possibly something that could get added into mame if done the right way.

I'm not saying I don't like what you are doing.  It's more than we have now.  But this should really be seperate from the artwork files as it's concept is different.

[Buddabing]

New version of display code as of 8-6-04 - I wanted to get this out so people could play with it over the weekend.

New features:
- The image is displayed across the entire width of the MAME window.

- The last remnants of the old controls.art have been swept away, it is not used anymore.

- The controls are displayed in the proper aspect ratio.

- Two flags have been added to mame, -nomakectrl and -noshowctrl. The names of these flags are subject to change, so be aware. The function of the flags should be obvious.

- The orientation of the controls.png image is automatically adjusted. The program now expects a controls.png with the normal orientation.

- You can use a different key than pause to view the controls. By default the show controls button is also set to P.

- No zip program is required anymore. The display code expects controls.png to be in the current directory.

Here is a link to the zip file containing the patches.

There are two patch files included, patch1.txt and patch2.txt. Patch 1 should be put into the src subdirectory and patched with the -R option.
Patch 2 should be put into the src\windows subdirectory and patched with -R.

I included a basic controls.png which I used to test the aspect ratios.

Once the patches are applied, make sure you "make clean"! Or else MAME will crash!

I hope that everyone enjoys this application. If you cannot apply the patches, PM me and I'll email you the complete source files.

Also let me know if there are any additional features you want.

Regards,
Buddabing

EDIT: Looks like the aspect correction only works if
-window is specified on the command line. Also the separate control doesn't appear to work right, so extract the mame.c which will make the controls appear when pausing.

[Buddabing]

New version of display code as of 8-6-04 - I wanted to get this out so people could play with it over the weekend.

EDIT: I fixed the problem with kick and dotron, which was that those games use a different orientation.

There are two bugs left that I know of. One is that MAME will crash if you turn on the controls display too close to resetting the machine. So don't do that!  

The other bug affects games that have hard-coded artwork. For example, Star Castle relied on colored overlays on the screen to show the colored rings, otherwise the screen would be black and white. Those games currently crash MAME.

There is also one weird orientation which affects only one game that I know of, solarfox.

Here is a list of the games that have hard-coded artwork, and thus crash MAME:
astdelux   avalnche   bzone   redbaron   starcas
tailg          sundance  solarq   circus    copsnrob
lazercmd   deadeye   gypsyjug   omegrace   sbrkout
geebee    sos   tinv2650

[SirPoonga]

You have vector games in that bunch, redbaron is, isn't it?  Mame handles the artwork slightly differently for those.

[Buddabing]

You have vector games in that bunch, redbaron is, isn't it?  Mame handles the artwork slightly differently for those.

Yep, that's one reason I had gravitar in my test suite. But tacscan, zektor, and starwars all work okay.

[Howard_Casto]

Ok as promised, a new viewer.  I decided to make it a public release as I'll have to rewrite most of it for the new xml-based ctrlr files and it could take quite some time.  But please don't everyone shout to the heavens that it's out.  It's still an early beta and not particularly user-friendly yet.  


http://www.oscarcontrols.com/lazarus/files/johnny5_0.7beta.zip

Note:  This build generates an image with the -justprint command and coupled with irfanview prepares the image for the mame hack.  

[Buddabing]

Ok as promised, a new viewer.  I decided to make it a public release as I'll have to rewrite most of it for the new xml-based ctrlr files and it could take quite some time.  But please don't everyone shout to the heavens that it's out.  It's still an early beta and not particularly user-friendly yet.  


http://www.oscarcontrols.com/lazarus/files/johnny5_0.7beta.zip

Note:  This build generates an image with the -justprint command and coupled with irfanview prepares the image for the mame hack.  

I downloaded the viewer and tried it. A .BMP image was generated and I can view the image with Gimp. Unfortunately, it looks like Irfanview doesn't do batch processing correctly. It just launches and displays johnny's .bmp file. Converting the image with Gimp should work but is much more complicated since there is a whole scripting language for it.

EDIT: I found a free conversion package calledImageMagick

Johnny5 clears the screen even when -justprint is specified, it probably shouldn't do that.

Here's the makectrl.bat I'm using.
@del controls.png
johnny5.exe -justprint %1 -clone %2
convert controls.bmp controls.png

It looks like it runs the first time through mame, but gives a run error 9 after that.

Running the batch program makectrl.bat from the command line works pretty well, except for the clear screen thing.

[Howard_Casto]

Irfanview works just fine..... you install it somewhere  (anywhere is ok)  and then you copy the exe and only the exe to the j5 folder, making sure it is named to match the name given in the docs.  The viewer does the rest, you don't use any command line options to convert.  

Also your bat file doesn't copy over the controls.png so that might be part of your error.  J5 can't be in the same folder as mame as it needs full read and write access to both controls.bmp and controls.png and vb is a tad slow with releasing it after the viewer exits.  

J5 doesn't clear the screen, it puts up a black window to hide the viewer while the bmp is being rendered behind it.  It's supposed to do that.  In a front end you would be shown a blank screen, as opposed to.... a blank screen.  So what exactly is the problem with that part?