Hotgmck cheat menu

[mahoneyt944]

Doesn't display correctly

@MistyDreams opened an issue for this.

It looks like the string is read in properly just not being formated correctly in the interface.

[mahoneyt944]

Maybe an issue with a newline or return? Seems to jam it all in one line. Or maybe a sizing issue.

[MistyDreams]

the 999 comets length is the issue. The second issue is even if you edit the cheat dat it wont update because the rzip. might want to check the lengths and edit the ones that are too big in the dat. Someone just probably dropped a later mame cheat dat in and expected it to work properly. I never opened any issue just pointed this out to you in the or thread that caused seg faults.

[mahoneyt944]

The rzip file has to be manually deleted, if trying to edit the dat. A new one will be automatically generated. When not found.

The first comment is this below, isn't the limit 255? If not what is the limit?

[ The winning hand cheat must be activated when there are 14 tiles in your hand, then press the RON   ]

[MistyDreams]

the limit its the characters that fit on cheat screen. The zrip is a real issue if the dat gets updated you might want to add a crc check or some kind of update mechanism.

[mahoneyt944]

The full comment is read in though, just not showing correctly on that page? That's what the pic I shared above shows anyhow.

So it's the characters that fit per line? Maybe it needs a new line to handle it?

[MistyDreams]

this is a dual screen game its only showing one screen though just checked in mame078 that shows the two screens. That might increase the columns available.

[mahoneyt944]

And the issue with crc checks with rzip is youd be checking the initial files crc and once edited, the file won't have the same crc anymore, and therefore would rebuild everytime you load a game, you'd have to save/ update this crc to reference on the next load but that seems like a hassle.

[mahoneyt944]

Ah yes the dual screen mode is probably why, it's formating the width wrong.

[arcadez2003]

Sorry to butt in here but it's related to these games, so long story short im about to commit an input change in this driver which will make Lode Runner The Dig Fight boot to the world English Region by default which is handy for game modes and types.

This could be done before by switching the region manually but it was a pain to traverse the service mode and this had to be done each time you booted the game as the settings never stuck, so im adding a new eeprom setting and a new region dip switch to the inputs.

@mahoneyt944 can you cast your eyes over the commit im going to push to see if you think i've done it correctly certainly the game is booting to the English region saving those settings to the eeprom and all the other inputs seem fine it's just there are so many fake inputs and i had to alter the original code from the tagging method...

So here is the change.

In the eeprom return readinputportbytag("JP4")<<16;

Inputs for taisen and hotgimmick extra input and fake port PORT_START_TAG("JP4")/ jumper pads 'JP4' on the PCB / UNUSED_PORT

inputs for Lode Runner new port for the region PORT_START_TAG("JP4")/ jumper pads 'JP4' on the PCB / // 1-ON,2-ON,3-ON,4-ON --> Japanese // 1-ON,2-ON,3-ON,4-OFF --> English PORT_DIPNAME( 0x03, 0x01, DEF_STR( Region ) ) PORT_DIPSETTING( 0x00, "Japan (Shows Version Number)" ) PORT_DIPSETTING( 0x01, "World (Does Not Show Version Number)" )

Basically i've counted the input ports for Lode Runner including the faked ones and came up with 9 so the extra one is 10 using the non tagged method i think hence.......

return readinputport(10)<<16;
PORT_START/* jumper pads 'JP4' on the PCB */

/ 1-ON,2-ON,3-ON,4-ON --> Japanese 1-ON,2-ON,3-ON,4-OFF --> English / PORT_DIPNAME( 0x03, 0x01, "Region" ) PORT_DIPSETTING( 0x00, "Japan (Shows Version Number)" ) PORT_DIPSETTING( 0x01, "World (Does Not Show Version Number)" ) INPUT_PORTS_END

Whatya think correct.?? https://github.com/libretro/mame2003-plus-libretro/commit/12b4c90b9146d9744b7cf6c98a37100767369e5e

[arcadez2003]

this is a dual screen game its only showing one screen though just checked in mame078 that shows the two screens. That might increase the columns available.

I turned on the single screen hack some years back so maybe that is affecting things also.

[mahoneyt944]

@arcadez2003 that looks ok to me.

[MistyDreams]

I turned on the single screen hack some years back so maybe that is affecting things also.

I dont think many play mahjong games to be honest its just the best example of the issue. I dont think changing to dual screen would help this issue looking at the code. Its the menu osd code that would need updated or the cheat file needing edited since its probably form a newer mame.

[arcadez2003]

@arcadez2003 that looks ok to me.

Thanks man i know your good at the inputs hence i thought it worth asking ya cheers

[arcadez2003]

I turned on the single screen hack some years back so maybe that is affecting things also.

I dont think many play mahjong games to be honest its just the best example of the issue. I dont think changing to dual screen would help this issue looking at the code. Its the menu osd code that would need updated or the cheat file needing edited since its probably form a newer mame.

Same here the only game in the driver worth bothering about is the Lode Runner update which is far better in single screen than two smaller ones IMO.

[mahoneyt944]

Does the osd have a dual screen flag or anything? I'm guessing the width needed divided by 2 for dual screen only.

[MistyDreams]

Does the osd have a dual screen flag or anything? I'm guessing the width needed divided by 2 for dual screen only.

https://github.com/libretro/mame2003-plus-libretro/blob/12b4c90b9146d9744b7cf6c98a37100767369e5e/src/mame2003/video.c#L84-L86

and the rest of the code menu code is else where

[mahoneyt944]

https://github.com/libretro/mame2003-plus-libretro/blob/12b4c90b9146d9744b7cf6c98a37100767369e5e/src/mame2003/video.c#L84-L86

That's the width for the ui box itself which seems correct, it's the text within the box that's bigger than it should be.

[MistyDreams]

the menu code is in cheat.c as well if you want to change it. You could do the osd menu in a separate bitmap from the machine bitmap just make sure into account when dealing with the overlay

[MistyDreams]

just checked with mame078 it hides comments that are too long. Something has went wrong in the parsing or menu code its a regression from changes

[mahoneyt944]

Current mame2003 acts the same way as 2003+. Definitely need to look into what change was made. Here's current mame2003 with mspacman and hotgmck. Note that without loading the cheat file at all, the comment to unzip it and place it in the directory is still expanded too far. Seems the issue is formatting comments.

[mahoneyt944]

Do you have a screen capture from mame078 to reference?

[MistyDreams]

[mahoneyt944]

Ok, I reverted cheat.c to 078. It's not this file causing the issue. Must be in the menu code specifically

[MistyDreams]

the code for the menu is is cheat.c

[mahoneyt944]

I pulled it back to the first commit with this file and it still has that issue https://github.com/libretro/mame2003-plus-libretro/compare/T2

I think it might be an issue with the usrintf

[MistyDreams]

Looks like lots of the user interface has been ripped out. test it on xtreme they didnt gut the userinterface

[mahoneyt944]

I don't have an Android port of Xtreme to try.

[MistyDreams]

do you not have a pc at all?

[mahoneyt944]

Not at this time.

[MistyDreams]

just leave it unless it causes someone real issues.

[mahoneyt944]

Well it's effecting a lot of games, not necessarily game breaking but an annoyance for sure. Just need to investigate on it. Probably something dumb.

[mahoneyt944]

@KMFDManic could you load mspacman in mame2003 Xtreme and navigate to the cheat menu, under add/edit cheats and screenshot it? Looks like this in 2003+

[MistyDreams]

thats normal for add/edit if iits too long to fit the screen its invisible but can still be edited the bug is in enable cheats none of this should be showing there.

[mahoneyt944]

Hmm, well there should be a simple check on the comment length in relation to the UI's x size / width.... Since it has to fit within those parameters. Maybe this was missed somewhere?

I'm guessing the displayed comment text is a bitmap? Which needs a fix on the parameters when it's drawn?

[MistyDreams]

its the scan thats the issue tested on t2 branch

arguments matched =5
name: [ Here is the look-up list for the above watches.                                                     ] desc: 
name: [                                                                                                     ] desc: 
name: [ value  common name     chinese name      value  common name     chinese name                        ] desc: 
name: [ 00h    1 "characters"  1 "wan"           01h    2 "characters"  2 "wan"                             ] desc: 
name: [ 02h    3 "characters"  3 "wan"           03h    4 "characters"  4 "wan"                             ] desc: 
name: [ 04h    5 "characters"  5 "wan"           05h    6 "characters"  6 "wan"                             ] desc: 
name: [ 06h    7 "characters"  7 "wan"           07h    8 "characters"  8 "wan"                             ] desc: 
name: [ 08h    9 "characters"  9 "wan"           09h    1 "dots"        1 "tung"                            ] desc: 
name: [ 0Ah    2 "dots"        2 "tung"          0Bh    3 "dots"        3 "tung"                            ] desc: 
name: [ 0Ch    4 "dots"        4 "tung"          0Dh    5 "dots"        5 "tung"                            ] desc: 
name: [ 0Eh    6 "dots"        6 "tung"          0Fh    7 "dots"        7 "tung"                            ] desc: 
name: [ 10h    8 "dots"        8 "tung"          11h    9 "dots"        9 "tung"                            ] desc: 
name: [ 12h    1 "bamboo"      1"tiao/Bird"      13h    2 "bamboo"      2 "tiao"                            ] desc: 
name: [ 14h    3 "bamboo"      3 "tiao"          15h    4 "bamboo"      4 "tiao"                            ] desc: 
name: [ 16h    5 "bamboo"      5 "tiao"          17h    6 "bamboo"      6 "tiao"                            ] desc: 
name: [ 18h    7 "bamboo"      7 "tiao"          19h    8 "bamboo"      8 "tiao"                            ] desc: 
name: [ 1Ah    9 "bamboo"      9 "tiao"          1Bh    East  "wind"                                        ] desc: 
name: [ 1Ch    South "wind"                      1Dh    West  "wind"                                        ] desc: 
name: [ 1Eh    North "wind"                      1Fh    White "dragon"                                      ] desc: 
name: [ 20h    Green "dragon"                    21h    Red   "dragon"                                      ] desc: 
name: [ FFh    - no tile -                                                                                  ] desc: 
arguments matched =5

[mahoneyt944]

Which scan? Sscanf?

Honestly I figured those fields would be in the desc field.

[MistyDreams]

I have serious doubts that sprintf and sscanf are thread safe. Might be worth asking in the libretro people.

[mahoneyt944]

Doesn't 078 use those as well without this issue?

[MistyDreams]

yes but mame is not threaded everything in ra is threaded

[mahoneyt944]

It's worth a test, can we test an alternate approach to roll that out?

[mahoneyt944]

Though google shows

[MistyDreams]

You need to reverse your assumptions. If a library function is not documented as being re-entrant or threadsafe, always assume it isn't. https://linux.die.net/man/3/sscanf

[mahoneyt944]

That's fair, but I don't think that's the issue here. We aren't getting bad data, it's just not formated correctly in the ui. All the data is there.