Mala Internals Question for LoadMan

[drventure]

Hey Loadman

Had a question about the main Mala Window. I'm working on a little addin and figured I'd just ask and hopefully save a bunch of poking around.

Are all the various "components" of the Mala screen (ie, the video window, scroll list, tree, snapshot picture, etc) contained in more or less "normal" child windows (ie each has a window handle subordinate to the main window), or is everything "drawn" directly on the main window?

I ask because I'm working on an adding that will allow arbitrary additions to the Mala UI. If all the subelements are child windows, then my addin can put windows "under" or "over the built-in Mala controls.

If not, well, that might make things more tricky!

Any ideas?

[SGT]

Wow, that sounds very interesting!  Can't wait to hear Loadman's reply on this.

[drventure]

Well, Loadman may have some additional info, but I played around with Spy++ and it looks like everything except the video is drawn directly to the main mala screen surface.
That would explain why the video is always "on top" of everything else in the mala window, at any rate.

Hmm, Kinda sucks cause it'll make things a little more tricky to get it to "play nice" with Mala, but, that's ok. Should make for an interesting diversion 

[youki]

AFAIK Mala uses GDI to paint its screen.  Except the Video control that is a 3rd party component and that explains why the video is always on top.

You can draw your own component on Mala screen by capturing the DC of the window and use it to paint. But of course using this way you won't be able to draw "under" existing component just "above".

However, i think there is a way to have more control using windows's hooking mecanisms but it will be lot more tricky indeed.

The ideal  would be that loadman enhance its plug'in interface to allow coder to interact with the layout.  He could for instance create a PaintLayer(HDC dc) interface that would be called just before each layout (or component) is drawn. It would let you  the possibilities to draw something before the normal drawing of each component occurs. 

[drventure]

True enough. But it sounds like loadman's got enough on his plate that those kind of enhancements aren't likely.

Not a huge deal anyway. I believe with the right kind of region masking and transparency, I'll be able to do pretty much anything I want over the mala screen and still blend in more or less.

[Stormrider]

Can you tell us more about those additions to the ui? I'm interested. Have you considered programming an addition to display title snapshots and normal snapshots in the same place as a slideshow? If I knew programming that would be the first thing I would do.

[drventure]

Cool idea. Hadn't thought of that, but I don't think it'd be too tough to add. You're talking about just cycling between the TITLES folder and the SNAPS folder right?

Basically, I had considered building my own FE for a long while, but I like Mala, and, well, building my own FE would take a phenomenal amount of work, and I'm a tad lazy.

However, I don't want to spoil the surprise just yet. Besides, talking about it before it's actually 100% would just jinx things 

But, if everything goes well, i plan on making what I end up with freely available.

If you have any other ideas for features that would be cool to see in Mala, let me know.

[Stormrider]

Exactly, same place for snaps and title snaps and define an interval time. That allows more graphic information in the same screen without the need or extra room. Moreover, the frontend will look much more dynamic without the need for videos, which slow down the frontend, stress the cpu and take lots of gbs in your hard disk. Actually, this could be applied to all elements in the layout Imagine you can link definable 1 with definable 2, and set a interval time. In my opinion, it's the only important thing that I am missing in MaLa and that would make my layout perfect. Good luck with your frontend. I'll try it as soon as it's released. But, please, if it's not difficult, consider the MaLa addon. It would be a very helpful feature for many users who want to stay with MaLa.

[drventure]

Oh. Sorry for the confusion. I'd +considered+ writing my own front end, but because of the amount of work involved, I decided it'd probably be better to try a Mala Plugin instead.

So, no, no new front end from me (at least not anytime soon)!

Mala plugins though. Oh yeah, there'll be something here in a bit...

[loadman]

Hi, Came late on this

Sounds like you guys have figured out the way of the world at the moment 

[drventure]

Hey loadman, yeah, got that working.

Now I'm just cleaning up my interfaces a bit.

I like the idea of a slideshow, so that's the first plugin i'm putting together.

We'll see how it turns out in a bit.

[Stormrider]

 

[Stormrider]

Are you announcing the addon for slideshow snapshots here? I don't wanna miss it.

[drventure]

Yep. I'll Announce here once I've got it up. It's actually working (more or less), but the slideshow part is only one small bit of what I'm working on. Actually its just the example project. I've got some more work left to do on the big part, but it's coming.

[Stormrider]

It's too cruel not to give us any clue about what it's about!

[drventure]

Ah, hell, I'll spill the beans, it's close enough

Basically, it's an plugin that wraps all of Mala's api in a nice, easy to consume .net wrapper, then extends Malas api in all sorts of ways.

You can easily design configuration panels using user controls that get "fit into" a config tree view, there are Window classes that you can use to overlay the existing mala windows easily and replace their function (so, lets say you position the user definable window in the mala layout, then you can write a plugin that lays a window OVER that window, to do whatever you want with it).

The windows have full region support, so they can take on the shape of any bitmask bitmap you want (or let it default to use the transparent color that you use in the mala layout image).

I've got images coming up in circular windows, video playing in a hexagonal window. Custom text, etc.

The biggest thing I want to get to is leveraging WPF so you can layer in all those great WPF effects (though I'm a WPF newbie so that might take me a while).

Plus, I wrote a little code generator that generated Object wrappers for all of Mala's Configuration files (the main mala.INI and the layout.ini files) so you can easily pluck out any info in there that you might need to make use of.

And finally, because it's all .net objects, events and interfaces, it doesn't require any of the C++ old style DLL entry point mucking about (something that's not easy to do with .net anyway, at least not to +expose+ those elements).

Basically, it's an entry point to be able to use .net to write mala plugins quickly and easily.

Nothing earthshattering (at least not yet), but hopefully, it'll enable a lot of people that may not have wanted or been able to write plugins in C or delphi to do so now.

Is that anything anyone here would be interested in?

Me, I'm using it to build the "snapshot rotator" that you (stormrider) suggested and will probably through in being able to rotate in the video as well.

After that, I hope to get some feed back and extend the core functions so people can do all sorts of other things to Mala.

[loadman]

WOW. 

 

[SGT]

Good grief drventure, did you say "nothing earth shattering"?  Sounds pretty earth shattering to me.  Cannot wait to see what you come up with. 
 

[drventure]

Here's a little more detail.

First a live screenshot



The video is actually video in both places (though it's a little unnerving because it's impossible to get them exactly synced up so it sounds like an echo 

The white window toward the bottom is an addin controlled window. There's a label that just shows info on the current game, game list, etc.
then the video (shrunk down, but easily resizable). and finally the game snapshot (almost completely hidden, but that's the point with this little test).


Obviously, it's not much, but it also requires only this much code, literally.

Code: [Select]

    ''' <summary>
    ''' Handle the MalaGameSelected event
    ''' </summary>
    ''' <param name="EventGame"></param>
    ''' <remarks></remarks>
    Private Sub CustomMalaPlugin_MaLaGameSelected(ByVal EventGame As MaLaEventGame) Handles Me.MaLaGameSelected
        Try
            If _MessageWindow Is Nothing Then
                _MessageWindow = New MyMessageWindow
                _MessageWindow.AlignToMaLaWindow(BuiltInMalaWindows.Custom1)
                _MessageWindow.Visible = True
            End If
            Dim c = Me.Mala.Settings.String("Mame", "Snaps")
            Dim d = Me.Mala.Settings.Mame.ControlsFile.Value
            _MessageWindow.Caption = d & "=" & Me.Mala.CurrentGameList.Name & "=" & EventGame.Description & "=" & c
            _MessageWindow.picImage.Image = EventGame.MameDefinableImage1
            Dim snappath = System.IO.Path.Combine(Me.Mala.Settings.Mame.Snaps.Value, EventGame.Rom)
            Dim cppath = System.IO.Path.Combine(Me.Mala.Settings.Mame.CPanel.Value, EventGame.Rom)
            Dim marqueepath = System.IO.Path.Combine(Me.Mala.Settings.Mame.Marquee.Value, EventGame.Rom)

            Try
                With _MessageWindow.MediaPlayer
                    '---- stop playing anything that's playing
                    .Ctlcontrols.stop()

                    .settings.autoStart = False
                    .settings.enableErrorDialogs = False
                    .enableContextMenu = False

                    .uiMode = "none"
                    .URL = EventGame.VideoFile
                    If Len(.URL) > 0 Then
                        .Ctlcontrols.play()
                    End If
                End With
            Catch ex As Exception
                MsgBox(ex.ToString)
            End Try

        Catch ex As Exception
            MsgBox("Exception:" & ex.ToString)
        End Try
    End Sub

And you don't necessarily need the Exception stuff. It just helps with debugging right now.

The MyMessageWindow class is a user control that inherits from a control in the master plugin. It's virtually empty.

Code: [Select]

Imports Mala4Net


Public Class MyMessageWindow
    Inherits MalaWindow


    Public Sub New()

        ' This call is required by the Windows Form Designer.
        InitializeComponent()
    End Sub


    Public Property Caption() As String
        Get
            Return lblCaption.Text
        End Get
        Set(ByVal value As String)
            lblCaption.Text = value
        End Set
    End Property


    Private Sub MediaPlayer_EndOfStream(ByVal sender As Object, ByVal e As AxWMPLib._WMPOCXEvents_EndOfStreamEvent) Handles MediaPlayer.EndOfStream
        '---- automatically restart playing
        MediaPlayer.Ctlcontrols.play()
    End Sub
End Class


It may not be obvious from the code snippet, but there's no lowlevel api stuff exposed anywhere. You create whatever windows you need, inheriting from a base class, move them whereever you want (or align them to fit over an existing Mala window, that way you can leverage the already existing layout), and put whatever you need in them.

Of course, this is all done in code right now, but the idea is to have an application object framework exposing as much of Mala as I can expose, easily accessible to .net code. Notice how you can retrieve (and alter) settings via early bound properties (they mirror the Mala INI files for simplicity, though I'm altering the object layout a little to make things a little more intuitive):

Code: [Select]

debug.print Me.Mala.Settings.Mame.Snaps.Value
Once that's in place, stuff like laying flash movies down, swapping images, etc should be much easier to do.


The biggest shortcoming of it all is that since most of the Mala UI is owner drawn directly on the mala window, I can't really layer anything "under" any of the content that Mala draws. At least, not yet. Maybe if there was a "BeforeDraw" event or something 


But since this is a big Object Framework type project, documentation is a must, so now I'm off to continue figuring out how to get Sandcastle to automatically document everything for me 

[SGT]

Looks amazing, wonderful news!   

[Ryglore]

Nice DV, Very nice indeed! 

[drventure]

Cool.

Well, if it looks like something people will be interested in, I'll forge ahead.

My plan is to get something out that's "mostly there" and decently documented, to try and get some feedback on what else needs to be included.

I'm wondering if something like this should go into the file repository here, or maybe an open source portal like codeplex?

[Ryglore]

I'll be all over this if you get the snapshot slideshow working. I'm planning on going through my gameslist and making custom snaps starting this week. I've been torn between Title Screens and gameplay, but with the slideshow I could do both. Of course now I have a new idea for a mala layout.. sigh...

Keep it up DV!

[drventure]

Hmm, so for Slideshow, something like this...

1) allow rotating between the Cabinet picture, CP image, Snapshot, Video, and Marquee (any or all).
2) include additional files (videos, snaps etc). I'm thinking naming convention maybe something like. Make this options, so if checked, additional files would be checked for.

{romname}.png (for the actual rom snapshot, in the snaps folder).
{romname}-xxx.png (for any additional files that you'd want to include, xxx is whatever you want it to be, all files matching {romname}-*.* would be included

Check for additional files in the SNAPS folder, Videos folder, Marquees folder, Cabinets folder, maybe other places?

For transparency, I could try and support the Mala "Bottom left corner is the transparent color" or just go with those formats that support an alpha channel (PNG mainly). Any thoughts there? I don't think videos can have transparent areas though (although you could simulate that my putting on hole in the mask image used to establish the region of the window....Hmm, how funny would that be, video with holes it in!)

Hmm, I might start a new thread if this gathers any steam

Thanks for the feedback!

[Ryglore]

Would you make it so each file would be say:

{romname}-001.png
{romname}-002.png
{romname}-003.png
{romname}-004.png

or just

{romname}-1.png
{romname}-2.png
{romname}-3.png

[SGT]

I don't think many people yet know the implications of what you are doing.  I think as soon as they fully understand the capabilities, said steam will be gathered.   

[drventure]

Good news.

Finally figured out what you gotta do in VS2008 to debug a DLL in the IDE that's NOT got a DLL extension (Mala plugins have a ".mplugin" extension)

It's easy but not obvious and definitely not documented anywhere.

Basically, just copy over the PDB for the plugin to the PLUGINS folder in mala, then make sure the "Enable unmanaged code debugging" is checked in the project page in VS.

That's it.

This should make the dev process MUCH faster than the Edit-compile-run-add msgboxes-compile-run-more msgboxes.... approach I had be taking!

[loadman]

Good news.

Finally figured out what you gotta do in VS2008 to debug a DLL in the IDE that's NOT got a DLL extension (Mala plugins have a ".mplugin" extension)

It's easy but not obvious and definitely not documented anywhere.

I just checked. It's in the API pdf doc page 12 

http://malafe.net/files/download/MaLaPluginSDKv1.62.zip

Let me know if you need any help / details for your Projext

[drventure]

Hey Loadman
I don't quite follow. Do you mean that renaming your plugin dll to *.plugin in on Page 12?

Definitely. I had that part figured out. The snag was that renaming the dll and moving it to the plugins folder seemed to cause Visual Studio to "loose track of" the file, so I could no longer debug interactively in the IDE.

I could set breakpoints but they'd never get hit. That sort of thing.

The solution was to
1) copy over the PDB as well, but leave it as the same filename
2) Most importantly, you have to check that "Enable unmanaged code debugging" option for your plugin dll project.

I'm sure delphi is very different in this respect (and likely a lot more obvious about how to go about it, VB is notoriously shallow sometimes<g>)

But end result is I can debug from within the IDE again, which helps tremendously!

[loadman]

Hey Loadman
I don't quite follow. Do you mean that renaming your plugin dll to *.plugin in on Page 12?

Definitely. I had that part figured out. The snag was that renaming the dll and moving it to the plugins folder seemed to cause Visual Studio to "loose track of" the file, so I could no longer debug interactively in the IDE.

I could set breakpoints but they'd never get hit. That sort of thing.

The solution was to
1) copy over the PDB as well, but leave it as the same filename
2) Most importantly, you have to check that "Enable unmanaged code debugging" option for your plugin dll project.

I'm sure delphi is very different in this respect (and likely a lot more obvious about how to go about it, VB is notoriously shallow sometimes<g>)

But end result is I can debug from within the IDE again, which helps tremendously!

Hey, as long as you are having fun ;-)