color issues with mame 0.78 "backdrop" artwork about mame2003-plus-libretro

[markwkidd]

The term for this MAME artwork feature I'm thinking of is"backdrops"

[markwkidd]

It seems like one option is to turn on only support for MAME artwork backdrops. Those should scale with the video display anyway.

Then RetroArch could handle the bezels and other overlays.

[Wilstorm]

I'm not sure if this is what you meant but how about Boot Hill I believe had a "static" background that I think needs to be an underlay in MAME and the game played on top. Without the scenery backdrop it's a black and white game.

[Wilstorm]

Take a look at this link possibly http://mrdo.mameworld.info/old_artwork.php in the first section.

[markwkidd]

I have just added a line that should enable backdrops. It doesn't seem to be working after some very brief tests, so I have commited the line in a commented-out form here: 04d4d7b#diff-edd04c2b6251b9d0c967e87af8150cebR476

If you want to try it out, uncomment that options.use_artwork line, make, then place the artwork in the /libretro system/artwork folder

[dankcushions]

what artwork file are you using? 0.78 predates the current .lay format. i think it's these ones you need: http://mrdo.mameworld.info/old_artwork.php

[markwkidd]

OK, it's loading! And it looks like an image format issue, just as you said @dankcushions

I've put in a core option to turn on loading backdrop files to make it easier for others to test

[markwkidd]

asteroid seems to be a good one to test with, even though the asteroid backdrop from Mr. Do's old artwork site is IMO not good.

We might wind up having to 'backport' some better artwork from newer formats to this old one than rely on Mr. Do, but that .art format seems very straightforward. I don't think it would be that much work to create newer backdrop-only .art files and .pngs if it comes down to it.

[dankcushions]

my guess is the fix is somewhere around https://github.com/libretro/mame2003-libretro/blob/master/src/libretro/video.c#L27 - pixel formats, or resolution, dunno...

i guess even if fixed it's still that similar issue of the background artwork being a higher resolution than the low resolution game, and how do you square that with the API? tricky...

[Wilstorm]

Yeah that was what I linked above, the old .lay format for you to peruse. I read the post last night before leaving work and knew what you were looking for but I couldn't recall it. I kept thinking Outlaw, Outlaw of course it was pulling up the Atari 2600 and then it all came rushing back about 10PM last night. I was like Boot Hill the old 70's arcade game and 2 minutes later I was checking out Mr. Do's old artwork page linking it. :)

[markwkidd]

warrior demonstrates the role of backdrops

This is how the game looks in mame2003:

mame2003-plus makes progress

There is a graphics bug -- but this feature is having a revival!

@markwkidd nice job as per usual mate!

[markwkidd]

As it stands, I have only two leads, or maybe one lead and one intuition.

My lead is that there are messages from png.c in the debug log that suggest the png loading function is not correctly identifying the color depth of the artwork files.

My intuition is that something is going wrong when artwork.c calls osd_create_display. Maybe a color depth issue here as well.

A misidentified or misset depth makes sense to me -- as a color-depth layperson -- because of the way that the backdrop artwork "corrects" once the emulated video is displayed over the backdrop. That is portrayed in my immediately prior screenshot.

I don't have any coding background in image or video so I don't know if I'll be able to take this issue much farther now, I'm afraid.

I think the display is missing a lot of extra code it needs to be honest mark it more likely going to be that. It probably sets flags that are ignored atm. Have you look at the mame078s logs ?

on thing i know we arent doing and we should be is keeping track of the of the visible display are ect and we arent and the rotation flags they should be checked for change and updated ect

i sthe artwork currently still hooked up at all ?

[markwkidd]

Only the backdrop image is hooked up. the other artwork functions can be done with retroarch

ah ok well im just getting segfaults with it

(gdb) bt
#0 0x00007fffbd6a13b6 in fillbitmap (dest=0x555556321280, pen=32767, clip=0x7fffffffbd60) at src/drawgfx.c:1333
#1 0x00007fffbd6e10bd in ui_drawbox (bitmap=0x555556321280, leftx=5, topy=114, width=390, height=52) at src/usrintrf.c:724
#2 0x00007fffbd6e2840 in ui_displaymessagewindow (bitmap=0x555556321280,
text=0x7fffbf4e6ae0 " ----- Copyright Warning -----\nCopying game data without permission is forbidden by copyright law. If you are not entitled to emulate this system, please exit now.\n") at src/usrintrf.c:1003
#3 0x00007fffbd6e8b5c in displaymessage (bitmap=0x555556321280,
text=0x7fffbf4e6ae0 " ----- Copyright Warning -----\nCopying game data without permission is forbidden by copyright law. If you are not entitled to emulate this system, please exit now.\n") at src/usrintrf.c:3106
#4 0x00007fffbd6e8f88 in handle_user_interface (bitmap=0x555556321280) at src/usrintrf.c:3199
#5 0x00007fffbd6c9397 in updatescreen () at src/mame.c:1207
#6 0x00007fffbd647882 in cpu_vblankcallback (param=0) at src/cpuexec.c:1418
#7 0x00007fffbd6df39c in timer_adjust_global_time (delta=0.026315789473684209) at src/timer.c:327
#8 0x00007fffbd646285 in cpu_timeslice () at src/cpuexec.c:651
#9 0x00007fffbd645557 in mame_frame () at src/cpuexec.c:360
#10 0x00007fffbd618694 in retro_run () at src/mame2003/mame2003.c:834
#11 0x0000555555599f8a in core_run ()
#12 0x000055555559eb35 in runloop_iterate ()
#13 0x00005555556739e1 in ui_application_qt_run(void*) ()
#14 0x0000555555598b3e in rarch_main ()
#15 0x00007fffef0452e1 in __libc_start_main (main=0x555555595bb0

, argc=4, argv=0x7fffffffe158, init=, fini=, rtld_fini=, stack_end=0x7fffffffe148)
at ../csu/libc-start.c:291
#16 0x0000555555595c6a in _start ()

[markwkidd]

well crap, that's new. it was working (albeit with the color depth issue) as of a week or two ago

…

On Thu, May 31, 2018 at 11:01 AM, grant2258 ***@***.***> wrote: (gdb) bt #0 0x00007fffbd6a13b6 in fillbitmap (dest=0x555556321280, pen=32767, clip=0x7fffffffbd60) at src/drawgfx.c:1333 #1 <#1> 0x00007fffbd6e10bd in ui_drawbox (bitmap=0x555556321280, leftx=5, topy=114, width=390, height=52) at src/usrintrf.c:724 #2 <#2> 0x00007fffbd6e2840 in ui_displaymessagewindow (bitmap=0x555556321280, text=0x7fffbf4e6ae0 " ----- Copyright Warning -----\nCopying game data without permission is forbidden by copyright law. If you are not entitled to emulate this system, please exit now.\n") at src/usrintrf.c:1003 #3 <#3> 0x00007fffbd6e8b5c in displaymessage (bitmap=0x555556321280, text=0x7fffbf4e6ae0 " ----- Copyright Warning -----\nCopying game data without permission is forbidden by copyright law. If you are not entitled to emulate this system, please exit now.\n") at src/usrintrf.c:3106 #4 <#4> 0x00007fffbd6e8f88 in handle_user_interface (bitmap=0x555556321280) at src/usrintrf.c:3199 #5 <#5> 0x00007fffbd6c9397 in updatescreen () at src/mame.c:1207 #6 <#6> 0x00007fffbd647882 in cpu_vblankcallback (param=0) at src/cpuexec.c:1418 #7 <#7> 0x00007fffbd6df39c in timer_adjust_global_time (delta=0.026315789473684209) at src/timer.c:327 #8 <#8> 0x00007fffbd646285 in cpu_timeslice () at src/cpuexec.c:651 #9 <#9> 0x00007fffbd645557 in mame_frame () at src/cpuexec.c:360 #10 <#10> 0x00007fffbd618694 in retro_run () at src/mame2003/mame2003.c:834 #11 <#11> 0x0000555555599f8a in core_run () #12 <#12> 0x000055555559eb35 in runloop_iterate () #13 <#13> 0x00005555556739e1 in ui_application_qt_run(void*) () #14 <#14> 0x0000555555598b3e in rarch_main () #15 <#15> 0x00007fffef0452e1 in __libc_start_main (main=0x555555595bb0 , argc=4, argv=0x7fffffffe158, init=, fini=, rtld_fini=, stack_end=0x7fffffffe148) at ../csu/libc-start.c:291 #16 <#16> 0x0000555555595c6a in _start () — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASphdlJMMInFNP1L58vUgpg39XxFRXKyks5t4BPFgaJpZM4TZKvx> .

-- Mark W. Kidd http://facebook.com/markwkidd [phone]

probably 64 bit mode for me again mate

[markwkidd]

if you haven't, could you try with `warrior.zip` and the warrior artwork that's in the github metadata folder? That's what I have been using to to test.

…

On Thu, May 31, 2018 at 12:12 PM, grant2258 ***@***.***> wrote: probably 64 bit mode for me again mate — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#95 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASphdoRbtAQL-p0Lhf2YQdDbAd-ecPmnks5t4CRlgaJpZM4TZKvx> .

-- Mark W. Kidd http://facebook.com/markwkidd [phone]

thats the one i am using mark

[markwkidd]

I have just contributed $10 to a bounty for adding MAME artwork support (including backdrops) to RetroArch, which for me would definitely moot this issue. libretro/RetroArch#7419

mark the backdrop does work now with the new video code

couldnt resist checking the bezel out in in this core.

[markwkidd]

awesome!! thank you @nayslayer although you may not have known you were also fixing this! :D

New discussion: #545

@markwkidd im still concerned the 64 bit casting issues still remain in this code somewhere just a heads up. It would be safer testing anything that doesn't appear to work or segfaults with artwork on on a 32 bit system to confirm.

[markwkidd]

Roger that. I have been playing with it a little bit today in Windows 10 x64 with no problems so far...