mika76 / mamesaver

Mamesaver is a mame emulated screensaver - get all the good ol' games playing their demo modes while you procrastinate and enjoy!
https://mika76.github.io/mamesaver/
MIT License
37 stars 10 forks source link

Game info display #12

Closed nullpainter closed 6 years ago

nullpainter commented 6 years ago

I was watching some games today, didn't know what they were and was thinking that instead of the current splash screen and its associated 10s delay, it may be far nicer to overlay the same details while each game is playing.

Is this something you had considered? What are your thoughts? I'm assuming it's possible...

mika76 commented 6 years ago

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 commented 6 years ago

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

mika76 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Just had a look at the docs

What are you doing reading documentation?! :wink: 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 commented 6 years ago

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

mika76 commented 6 years ago

@nullpainter the -effect flag wasn't useful?

nullpainter commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

mika76 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

🍀 Good luck man - doesn't look easy

nullpainter commented 6 years ago

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 commented 6 years ago

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.

image

mika76 commented 6 years ago

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 commented 6 years ago

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

nullpainter commented 6 years ago

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. 😶

image

nullpainter commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

nullpainter commented 6 years ago

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

nullpainter commented 6 years ago

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 commented 6 years ago

Nah - I got 2017 too

nullpainter commented 6 years ago

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