Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Game info display #12

Closed
nullpainter opened this issue Aug 14, 2018 · 28 comments
Closed

Game info display #12

nullpainter opened this issue Aug 14, 2018 · 28 comments
Milestone

Comments

@nullpainter
Copy link
Contributor

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
Copy link
Owner

mika76 commented Aug 14, 2018

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
Copy link
Contributor Author

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

@mika76
Copy link
Owner

mika76 commented Aug 14, 2018

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
Copy link
Owner

mika76 commented Aug 14, 2018

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
Copy link
Contributor Author

nullpainter commented Aug 14, 2018

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
Copy link
Contributor Author

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

@mika76
Copy link
Owner

mika76 commented Aug 15, 2018

@nullpainter the -effect flag wasn't useful?

@nullpainter
Copy link
Contributor Author

nullpainter commented Aug 15, 2018

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@mika76
Copy link
Owner

mika76 commented Aug 15, 2018

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
Copy link
Contributor Author

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
Copy link
Owner

mika76 commented Aug 15, 2018

🍀 Good luck man - doesn't look easy

@nullpainter
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Owner

mika76 commented Aug 15, 2018

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
Copy link
Owner

mika76 commented Aug 15, 2018

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

@nullpainter
Copy link
Contributor Author

nullpainter commented Aug 15, 2018

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
Copy link
Contributor Author

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
Copy link
Owner

mika76 commented Aug 16, 2018

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
Copy link
Owner

mika76 commented Aug 16, 2018

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
Copy link
Contributor Author

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
Copy link
Contributor Author

nullpainter commented Aug 19, 2018

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
Copy link
Owner

mika76 commented Aug 20, 2018

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

@nullpainter
Copy link
Contributor Author

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

@nullpainter
Copy link
Contributor Author

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
Copy link
Owner

mika76 commented Aug 20, 2018

Nah - I got 2017 too

@nullpainter
Copy link
Contributor Author

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

@mika76 mika76 closed this as completed in 0b11b11 Aug 28, 2018
@mika76 mika76 added this to the v2.0 milestone Sep 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants