Game info display about mamesaver

[mika76]

Hey that sounds awesome but I have no idea if it's possible and how 😆
Even if it's not - that splash screen could probably be spruced up a bit these days by using WPF or something...

[nullpainter]

Neither - I've done zero with Windows UI. May have a play, while Andy is fighting with his multi monitors :)

[mika76]

I was watching some games today, didn't know what they were

This imo is the best part of the screensaver - it's amazing how many games I'd forgotten about or never tried and the screensaver reminded me...

[mika76]

Just had a look at the docs - there is a command line -effect which can be used to show a png as an overlay - maybe that's the way forward?

[nullpainter]

Just had a look at the docs

What are you doing reading documentation?! 😉 I thought that flag was intended to overlay repeating CRT screen grilles etc.? Anyway, I'll see what can/can't be done. If that can be (mis)used, it might be a nice fallback.

[nullpainter]

It looks like the approach is to hook into Direct3D to provide overlays. Marginally terrifying.

[mika76]

@nullpainter the -effect flag wasn't useful?

[nullpainter]

I haven't actively looked at it yet. I just have a sneaky feeling it tiles images and may assume images are in a MAME directory. Also, it seems cleaner to render text directly than to save to a temporary image first (which would then need cleaning up)

[nullpainter]

Yeah, as suspected:

Specifies a single PNG file that is used as an overlay over any game screens in the video display. This PNG file is assumed to live in the root of one of the artpath directories. The pattern in the PNG file is repeated both horizontally and vertically to cover the entire game screen areas (but not any external artwork), and is rendered at the target resolution of the game image

Not really fit for purpose, I think.

[nullpainter]

But that's okay! Playing with Direct3D sounds fun 😀

[mika76]

Sure but then only if they are using the D3D renderer will it work, which is why I thought using mames built in artwork/overlay functionality might help. This seems to give some options - http://wiki.mamedev.org/index.php/LAY_File_Basics_-_Part_I although it implies dynamically creating these files for each game maybe...

[nullpainter]

Sure but then only if they are using the D3D renderer will it work

That is true. D3D is the default for MAME builds for Windows, but I take your point. Dynamically creating files is fine if there isn't a more elegant solution. I'm having a play with D3D overlays to see how straightforward it is with supporting libraries.

[mika76]

🍀 Good luck man - doesn't look easy

[nullpainter]

http://docs.mamedev.org/techspecs/luaengine.html also sounds promising:

Nowadays, the LUA interface is rich enough to let you inspect and manipulate devices state, access CPU registers, read and write memory, and draw a custom HUD on screen.

(emphasis mine)

[nullpainter]

Well, it's possible but ain't gonna win any design awards. At a cursory glance, I can't see any way to change any characteristics of the font. We can draw boxes, we can write text. Hmm.

[mika76]

Hey that's pretty cool! Seems all the functions are in https://github.com/mamedev/mame/blob/master/src/frontend/mame/luaengine.cpp - and yeah pretty barebones functions for writing text...

[mika76]

Although - even this simple text is not too bad - could be a good phase 1

[nullpainter]

If you create a .bdf font and place it in the same directory as the mame executable, you can reference it via the command-line. Here's an example with a font nasty enough to demonstrate that it's picked it up 😆

I originally had visions of a smart and thin semi-opaque overlay spanning the screen, with bold and regular weight text for some typographic interest. Sigh. Finding a decent-enough font may indeed by a good starting point. Also of note is that the LUA dimensions are relative to the game itself (so, text is always overlaid on graphics)

Unfortunately, the D3D overlay route seems remarkably fiddly, particularly for full-screen applications, and there doesn't appear to be any nice nuget package providing handy abstractions which work for non-windowed apps. The approach appears to be to create a new D3D dll, place it in the same folder as the executable so it's picked up instead of the system D3D dll, and use this to render what you need and also delegate to the real dll. 😶

[nullpainter]

This approach tentatively look promising, but I fear its limitations may be the death of it (the text is rotated 90 degrees for vertical games!)

machine = manager:machine()
system = machine:system()

screen = machine.screens[":screen"]
text = system.description .. " / " .. system.manufacturer .. " (" .. system.year .. ")"

 -- TODO consider using mame_manager:ui():get_line_height() to get font height to do 
 -- proper calculations (or find a way to get screen resolution either in LUA or injected)

xPos = 5
yPos = screen:height() - 10

function draw_hud()
   -- FIXME need to work out a fix for rotated screens - tempest, for example, results in vertical text
  screen:draw_text(xPos, yPos, text)
end

emu.register_frame_done(draw_hud, "frame")

[mika76]

Yeah it could work as a simple notice or a stop gap - but if you want something fancier, maybe have another look at bezels, artworks and layouts - could be the answer since it allows you to create your own image...

[mika76]

Of course it's probably not out of the question to ask the mame team to add missing functionality or send in a PR...

[nullpainter]

but if you want something fancier, maybe have another look at bezels, artworks and layouts

I think I will. I've been resisting thus far as it didn't sound as elegant, but I think you're right.

Of course it's probably not out of the question to ask the mame team to add missing functionality or send in a PR...

Yes, I was intending to do that also.

[nullpainter]

Good news! I've created a PoC which:

1. Generates a dynamic layout based on the rotation of the game and screen resolution
2. Renders the game details as a png (currently poorly), referencing this in the layout as a bezel
3. Invokes the game using this layout

I've added a rotation attribute to gamelist.xml as this is required to scale the game correctly in the layout. When a game is run, we check to see if the attribute is present. If it's not (i.e., due to an old game list), we retrieve it from Mame.

The game name and details are displayed at the bottom of the screen and the layout scales the game slightly so the bezel doesn't overlap any game elements. The layouts and bezels are written to a temporary directory which is cleaned up after the screensaver exists.

The Mame invocation adds an additional artpath specifying this temporary layout directory in addition to the user's existing art path(s). I'n not sure what the behaviour would be if the user already had legitimate layouts for their games - but if this is the case, they can always work around it by changing the default command line args.

This all sound a reasonable direction?

[mika76]

That sounds brilliant! Can't wait to check it out? Can you make a PR so thet appveyor can make a build?

[nullpainter]

Yes! All finished! Just doing a final sanity check 😄

[nullpainter]

Done. I tried to keep the commits self-contained so you can see what I changed. I noticed that the .sln version was bumped up in this commit as I'm using VS 2017. Let me know if this is a problem for you and I'll tweak it.

[mika76]

Nah - I got 2017 too

[nullpainter]

As per comment on issue #16, this is covered by PR #18.