Viewing Issue Advanced Details
ID Category [?] Severity [?] Reproducibility Date Submitted Last Update
02195 Misc. Trivial Always Sep 2, 2008, 20:44 Oct 16, 2008, 15:55
Tester M.A.S.H. View Status Public Platform MAME (Self-compiled)
Assigned To Resolution Open OS Windows XP/Vista 32-bit
Status [?] Confirmed Driver
Version 0.127u1 Fixed in Version Build Normal
Fixed in Git Commit Github Pull Request #
Summary 02195: profpac, tenpindx: The 'screen ram' test in the TEST menu is BAD.
Description The 'screen ram' test in the TEST menu (F2) of Professor Pac-Man and Ten Pin Deluxe is BAD. See screenshots
1. Test menu
2. Circuitry tests
3. Ram tests
4. Screen ram test (all bit planes are bad!)
Steps To Reproduce
Additional Information
Github Commit
Flags
Regression Version
Affected Sets / Systems profpac, tenpindx
Attached Files
png file icon profpac1-2-3-4.png (30,891 bytes) Sep 2, 2008, 20:44
Relationships
There are no relationship linked to this issue.
Notes
25
User avatar
No.02313
Fujix
Administrator
Sep 3, 2008, 04:25
edited on: May 17, 2009, 19:31
It's already known in the source code:

        * No audio board for Demons & Dragons
        * Demons & Dragons doesn't work with RAM protection enabled
        * Professor Pac-Man fails screen RAM test

Closing the report.

MASH, please read tutorial again.
http://mametesters.org/tutorial.html
User avatar
No.02314
Tafoid
Administrator
Sep 3, 2008, 04:26
Re: profpac - the source file clearly states in it's bugs listed at the top:

    Known bugs:
        * No audio board for Demons & Dragons
        * Demons & Dragons doesn't work with RAM protection enabled
       * Professor Pac-Man fails screen RAM test

No bug report needed for this one.

Re: tenpindx - This set is labeled GAME_NOT_WORKING. No bug accepted at this time for GAME_NOT_WORKING, as any amount of working is purely coincidental. If it were a recent regression from another version - it might be valid.

So, no changes.. closing report. M.A.S.H - you should know better than to put up reports like this :D
User avatar
No.02318
robiza
Developer
Sep 4, 2008, 05:40
in this case i prefer a mantis entry
this is a standard bug (only the bug about "screen ram test") not a useful info in the source that explain why a feature is not present (like the bugs about audio or protection)
obviuos IMO
User avatar
No.02321
Fujix
Administrator
Sep 4, 2008, 06:52
robiza, our policy that we don't add report which is already known by the driver author to avoid duplicate (and offending the author's feeling) is lead by long experience between Devs and testers and it works well for long time

It is impossible for all testers to determine which bug is standard and to be listed in Mantis.
User avatar
No.02327
Haze
Senior Tester
Sep 4, 2008, 14:24
Nicola, Robiza, and myself all disagree with the current policy. I still advocate that ALL bugs should be reported here (regardless of flags / code notes)

This is being discussed by the dev team.
User avatar
No.02330
Tafoid
Administrator
Sep 4, 2008, 14:56
For what it's worth, I have no problem with either way we want to go here. All I'm looking for in consistency across the board. Having policy instituted way back and desires now differ is frustrating, to say the least (as Fujix has gotten a rant or two from me about it). I am glad, finally, this is being discussed by the Dev team.
User avatar
No.02331
Fujix
Administrator
Sep 4, 2008, 15:11
edited on: Sep 4, 2008, 15:26
In either way, we should consider a way to avoid useless complaining for obvious incomplete emulation by who doesn't have enough knowledge of the situation.

How about introducing a flag "The driver author is rejecting bug reports."?

The problem is that some of Devs don't like being criticized.
It was the main reason that Smitdogg has introduced this rule.
User avatar
No.02332
Haze
Senior Tester
Sep 4, 2008, 15:39
> The problem is that some of Devs don't like being criticized.

tough sh*t, they shouldn't write buggy drivers.
User avatar
No.02338
aaron
Developer
Sep 4, 2008, 20:30
I agree in principle that we should consolidate all bugs here. It is much easier to find all the issues in one place.

If you are a dev on this project, you have to be willing to accept criticism. At least one dev was not open to this and he has decided not to contribute for the time being (his choice).

That said, I also agree that we need a way to flag drivers that are in an known incomplete state. Are the current flags sufficient? How about no graphics bugs if GAME_IMPERFECT_GRAPHICS and no sound bugs if GAME_IMPERFECT_SOUND/GAME_NO_SOUND? The problem with those flags is that they imply knowledge of problems, but that doesn't mean there aren't other things worth tracking here. Obviously GAME_NOT_WORKING should be respected.
User avatar
No.02339
Haze
Senior Tester
Sep 4, 2008, 20:50
> How about no graphics bugs if GAME_IMPERFECT_GRAPHICS and no sound > bugs if GAME_IMPERFECT_SOUND/GAME_NO_SOUND?

these are the current rules, and IMHO they simply don't work.

I'd simply say 'no sound bugs if GAME_NO_SOUND' and 'no bugs at all if GAME_NOT_WORKING' Those imply that there is something *seriously* wrong.

If a game is marked as working, specific graphic / sound issues should be logged here even if they're flagged, that way if somebody wants to fix them they can look here instead of relying on a knowledge of the problem.

Just because R.Belmont (for example) has a comprehensive list of KonamiGX bugs he knows about doesn't mean everybody else knows about them. Having them logged here would change that. Likewise there are drives I've written with graphic bugs I know about, which aren't logged here because of the current 'rules'. Some of them occur only on the last level of the games so somebody finding them (to fix them) without knowing about them in advance is remote.

We need to do *everything* we can to move the project forward, and create drivers with the highest level of accuracy possible. MAME is still severely lacking, even for some common chips. Proper documentation of bugs would help.
User avatar
No.02342
Fujix
Administrator
Sep 4, 2008, 22:46
edited on: Sep 4, 2008, 23:37
OK, I'll lift the old restrictions for flagged games (except GAME_NOT_WORKING) and known bugs in the source files.
Before that, I'd like an agreement of all devs on this (and won't accuse reporters for their ignorance).

Tafoid is now making up new handling of reports for games with each flag.
Maybe we will call for volunteers when we move known bugs in source files to mantis.
In the future, driver authors themselves will have to enumerate known bugs when they write a driver.

Thanks in advance.

(Reopened the entry to allow everyone to add a note.)
User avatar
No.02344
Reip
Developer
Sep 5, 2008, 07:58
I agree with the new policy, but what about, for example, listing all the graphics bug for a game flagged as IMPERFECT_GRAPHICS in the same report?
User avatar
No.02346
stephh
Developer
Sep 5, 2008, 09:56
It seems that there has been some changes as I don't find how to create a new BTANB entry. Are such entries supposed to be "Documentation" ?

BTW, for such entries, the required fields shall be "Affected sets" (I can't tell about "Driver"), "Summary" and "Description" ("Version" isn't needed).
User avatar
No.02347
Fujix
Administrator
Sep 5, 2008, 10:18
edited on: Sep 5, 2008, 11:04
Yes, as long as these bugs are from the same cause, they should be in one entry as ever.
Although these regulations are removed, it doesn't mean we will accept any reports. A report like "The game has no sound." for a game without sound emulation is neither helpful nor informative for anyone, it will be invalid as heretofore.

GAME_NOT_WORKING flag will be respected and we won't accept "bug" reports for these games except heavy regression. (We accept information for them)
If you think your driver is in the initial stage and/or it's too early to accept bug reports, you can prevent bug reports by leaving this flag.
User avatar
No.02348
Fujix
Administrator
Sep 5, 2008, 10:38
edited on: Sep 5, 2008, 12:20
BTANB is not a category anymore and is a resolution.

This may sound strange for you, but this was done from half-year operation of the tester site.
Category is supposed to categorize the attribution of the report contents such as sound, graphics, color etc.
Resolution is to show how it was processed and the current or final position of the report.
Also, it is not very good when a bug turns out to be an original bug and changing the category, the original category is lost.

So we determined to move BTANB to Resolution from Category.

The version field for BTANB is not harmful. And I'd like to keep it to show when it was found and filed.
User avatar
No.02349
Haze
Senior Tester
Sep 5, 2008, 12:11
these changes sound good.
User avatar
No.02363
Tafoid
Administrator
Sep 5, 2008, 20:18
edited on: Sep 5, 2008, 21:02
A long note, but here is what has been written up as a detail for handling specific flags. If there are Devs that find something out of place or think something isn't correct or can suggest a better plan, please speak up now.

GAME_NOT_WORKING - The only usefulness that this flag guarantees to the end user is that you can load the romset into memory, setup MAME and type "OK". Anything beyond this is completely bonus when dealing with this flag. The only time a bug should be accepted for this flag is when the game fails to load correctly (fatal error or assertion) or any other bug which causes you not to be able to see the disclaimer screen. If you cannot see the screen, the end user has no idea that the game is flagged.

GAME_UNEMULATED_PROTECTION - Similar to GAME_NOT_WORKING. The only time we should accept a bug with this flag is there a noticeable/obvious regression from one version to another. For example: A game plays as it has for numerous versions prior then suddenly, in a recent version, the sound is completely missing. A bug report would then be acceptable here.

GAME_WRONG_COLORS / GAME_IMPERFECT_COLORS - These shouldn't need a report unless it's a side-by-side or an informational bug report including reference documents or materials.

GAME_NO_COCKTAIL - No reports should be accepted as they are sets which knowingly have this feature known to be in the hardware but unimplemented.

GAME_IMPERFECT_GRAPHICS - All bugs as related to a specifically identified problem with graphics presentation in sprites, tilemaps or color/palette. All bugs reported under this flag must be VERY specific to be useful. Reports stating: "The graphics on the first level are wrong" is not good enough for a valid and acceptable report. The tester must be verbose and as descriptive as possible with details and, of course, attach screenshots and other reference materials when available to PROVE this is an authentic problem with the way the game is being emulated.

GAME_NO_SOUND - If flagged, there is no need to file a report. The game likely will not produce any sound anyway.

GAME_IMPERFECT_SOUND - All bugs as related to a specifically identified problem with the audio output as it's being presented. Reports will be accepted for confirmed missing voices/sounds or music elements from prior versions or original sources. Sound mixing or sound level bugs are not valid unless evidence is provided by PCB/OST source recordings to support the claim. Like the graphics flag, the report must be as descriptive as possible, noting exactly what is missing and providing comparison sound recordings to prove the point. Company produced (game specific) OSTs can be used be used as a source of reference but are not to be taken as "100% correct" when dealing with certain sound related differences. It's been noted that in some cases released OSTs are given special audio enhancements (reverb/echo) or are "remastered" and it's important to note that much of this is not included in the original PCB output.

GAME_SUPPORTS_SAVE - Reports concerning only games which have SPECIFICALLY CODED Save State support in the source are to be accepted. If a game has support but fails in a saving or fails to properly resume a game - it is eligible for reporting.

MAME Source TODO and KNOWN BUG entries - These will need to be added to MANTIS eventually. It's assumed that once all items in the source are transitioned over - any additional entries of this type will have to be monitored and entered by the driver maintainer himself. Those who have intimate knowledge of a driver or a gaming system should be the ones entering the items that are known to fall short of perfect emulation.
User avatar
No.02366
robiza
Developer
Sep 6, 2008, 07:29
thanks fot the change
User avatar
No.02367
Robbbert
Developer
Sep 6, 2008, 08:38
edited on: Sep 6, 2008, 08:46
This all looks pretty good.

In my opinion, if the game is GAME_NOT_WORKING and it crashes MAME (assert or violation), it should be reportable.

Doesn't mean it has to be fixed - just on record as an extremely serious error.
User avatar
No.02387
Fujix
Administrator
Sep 7, 2008, 05:00
Yes, they will be accepted.

Now I'm updating the rule and tutorial page. And added new flag "Noted in Source" for known issues.
User avatar
No.02389
Firewave
Senior Tester
Sep 7, 2008, 11:35
I don't think games with the GAME_NOT_WORKING flag, that are bailing out should be reported, unless it's a regression.
There are various games in MAME with that flag, that bail out, but it's always been this way.
User avatar
No.02390
Tafoid
Administrator
Sep 7, 2008, 14:16
edited on: Sep 7, 2008, 14:17
To Reiterate: All games in MAME should at least bring you to the disclaimer screen/game information screen. If not, it's reportable, even if it's a GAME_NOT_WORKING.
User avatar
No.02391
Haze
Senior Tester
Sep 7, 2008, 14:43
yeah, GAME_NOT_WORKING should at least get to the red screen that tells you the game doesn't work. If they crash *before* that point it's a bug. If they crash after that point it isn't, you were already warned ;-)
User avatar
No.02420
Fujix
Administrator
Sep 10, 2008, 02:22
edited on: Sep 10, 2008, 12:33
We are asking devs on the list what kind of issues should be imported from source notes here. Still no response yet though.

Testers' current plan is:

- Just adding items in known bugs or to-do that effect emulation in a visible manner. No speculation, no "might be" or "unsure if" notes. Only things that can be confirmed as lacking and identifiable as bugs.

- Devs can add their driver's note whatever it is as long as it's done consistently.
User avatar
No.02872
Fujix
Administrator
Oct 16, 2008, 15:55
As seen in a few releases, it seems that Devs don't feel up for maintaining source known bugs for their updates.

Actually, it's a job, not only for Devs, but also us...