JoJo's Bizarre Adventure/Compliance

From Sega Retro

Back to: JoJo's Bizarre Adventure.

Sega Dreamcast compliance standards are defined by the Dreamcast Software Creation Standards, created by Sega of America. The following are points marked as "required". Some duplicates have been removed.

Controllers


Compilance Screenshot(s) Pass/fail Comments
1: A should "accept" (perform) and B should "cancel" (reject) an operation, unless redefined by the user.[1]
Use the A button to Accept (perform) an operation and the B button to Cancel (reject) an operation.

Allocation of "Accept" and "Cancel" to the A and B buttons, respectively, is always assumed to be the default configuration. However, if a user chooses to redefine the uses of these two buttons using a configuration menu, it is permissible to allow the buttons to be redefined as requested.

Untested, assumed pass
2.1: Software must not stop when an incompatible controller is inserted, but the manual must warn that continued operation is not guaranteed.[2]
It is not permissible for a game to stop when an incompatible controller is inserted in the control port.

Under past development standards, applications were not allowed to start or operate when an incompatible controller was used. This restriction has now been relaxed. If an application does not stop and continued operation is possible when a nonstandard controller is inserted, continued operation is allowed. However, if a game allows the use of nonstandard controllers, the application's instruction manual must warn that "operation with incompatible controllers is not guaranteed."

Untested, assumed pass
2.2.1: In single-player games, it must be possible to start and operate software from any of the four controller ports (A-through-D).[3]
In games that can be played by only one person, as well as in multi-player games, it must be possible to start and operate the game from any of the four front-panel ports (A through D) to which a compatible controller is connected.
Untested, assumed pass
2.2.2: In multi-player games, the number of ports from which games can be started and operated must not exceed the number of supported players. For example, if three controllers are connected in a two-player game, the third controller should not work.[3]
Unless an expansion socket is used (as described in Chapter 12, "Pause,") the number of ports from which games can be started or operated must not exceed the number of users playing a game. (When an expansion socket is used, it doesn't matter if the ports being used exceed the number of players. Even if you use a memory card to save a game that is being played by only one or two people, it won't cause any problems if an unused expansion socket happens to be plugged in.

Example 1 In a fighting game (a type of game normally designed for either one or two players), it should be possible to connect standard controllers to ports A and B. Starting or playing from port D should not be possible.

Example 2 In a four-player fighting game, it should be possible to connect standard controllers to all four ports on the front of the Sega Dreamcast console. Consequently, it should be possible to start and play from all ports with compatible controllers connected.)

Untested, assumed pass
2.2.3: If a controller is connected after the system turns on, software should recognise it.[4]
Even though a compatible controller is not connected to a port when power is turned on, if it is connected before a game begins, it must be properly recognized and enabled for start and operation. So your application must test the ports frequently in the Title Loop before starting a game.
Untested, assumed pass
2.2.6: For games where only one controller type is used and the user swaps controller ports mid-game, play should not be resumed.[5]
In an application in which single player uses a single controller, play is not resumed.
Untested, assumed pass

Software reset


Compilance Screenshot(s) Pass/fail Comments
4.1.2a: For standard controllers, the software reset must be implemented with A+B+X+Y+ START .[6]
With a few exceptions, a soft reset must occur when the START Button is pressed while the A + B + X + Y buttons are all held down together. Exceptions include racing controllers, gun controllers and hardware keyboards (for which this operation is impossible), and certain controllers for which such operation is difficult. Note that if you cannot make soft reset possible using the operation described in this standard, you must make it possible using some other kind of operation, as explained under the next "Required" subheading.
Untested, assumed pass
4.1.2b: If the current controller means the pressing of A+B+X+Y+ START  for a software reset is difficult or impossible, implement an option in software for performing a software reset (e.g. a menu item).[7]
For controllers such as racing controllers, gun controllers and the keyboard (for which the soft reset operation of pressing the A + B + X + Y buttons and the START button simultaneously is difficult or impossible), applications must make soft resets possible using the method outlined in Chapter 18, Development Standards for Peripherals, or through either a software keyboard or another procedure displayed in a separate menu. When soft reset is supported using a procedure described in a separate menu, your application is not required to display that menu at all times if that would adversely affect your game. Nonetheless, the soft reset option should be clearly displayed on a suitable menu and made selectable for the user.
Untested, assumed pass
4.1.2c: The software reset must be possible from all controllers in use.[7]
Soft Reset must be possible from all controllers (ports) in use. As explained in Chapter 2, Single User, Single Controller Applications, operation of an application is disabled for controllers connected to ports that are not being used by the application, so as a matter of course, soft reset is also disabled for those controllers.
Untested, assumed pass
4.1.4.1a: Performing a software reset from the title loop must return to the boot ROM.[8]
Soft reset from the Title Loop must jump to the Main Unit Boot ROM Menu.
Untested, assumed pass
4.1.4.1b: Performing a software reset from outside the title loop must return to the title screen.[8]
Soft reset from the main game (after the application is started) must jump to the Title Screen.
Untested, assumed pass
4.2.1: The boot ROM must appear within ten seconds of opening the disc lid, save for situations where legitimate disc swapping is required.[9]
The Main Unit Boot ROM menu must appear when the Main Unit "OPEN button" is pressed and the disc lid is opened. Please note the alternative cases described in 4.2.2, Exceptions when the Disc Lid is Open, 4.2.3, When the Disc Lid is Opened during Saves, and 4.2.4, When File Loading Fails from the Disc,. When the disc lid is opened, your application must go to the Main Unit Boot ROM menu within ten seconds.
Untested, assumed pass
4.2.3: Any operation that returns to the boot ROM must wait until a save has finished.[10]
When executing saves, do not go to the Main Unit Boot ROM main screen until that save is finished. (This requirement is imposed to avoid the loss of the file being saved). Go to the main screen as soon as the save is finished.
Untested, assumed pass

Logos, title screen, demos and menus


Compilance Screenshot(s) Pass/fail Comments
3.2: Upon booting software, the stereo/monaural output setting should be changed to match the boot ROM.[11]
Immediately upon loading an application (before the Title Loop starts), the stereo/monaural output setting should be changed to match the Boot ROM settings of the Main Unit. Even if sound output is not listed in Chapter 9, Options, an application internally determines if it is stereo or monaural, so the settings must be changed to correspond to the Main Unit Boot ROM settings on the application side. Currently, the stereo/monaural output settings are saved on the Main Unit, and should not be saved under any circumstances to the memory card. Refer to Chapter 9.2, Storing Option Settings, for more details.
Untested, assumed pass
5.1.1: Upon boot, the Sega license logo must appear on screen (and if utilising Windows CE, the Windows CE logo).[12]
As soon as power is turned on, the Sega License Logo display must appear on the screen. In titles developed using Windows CE for Dreamcast, the Microsoft logo must appear along with the Sega License Logo (see the following screen shot). To display these two logos simultaneously, enable both "Sega License Logo" and "Microsoft Logo" on your application disc's IP.BIN file.
Untested, assumed pass
5.2.6: Any other logo screens must occur after the Sega license logo, and should be visible for at least two seconds.[13]
After the Sega License logo is displayed, display any other logo screens. Display each screen for at least two seconds.
Untested, assumed pass
5.2.7: License and middleware logos should observe the standards outlined in the contract document in Chapter 24[14]
To display the license logo and library logo, observe the following standards:

1. Follow the rules outlined in the contract document regarding the content of logo display. 2. The order of logo display and the possibility of skipping screens is defined in the terms of the contract document. 3. To display the library logo, refer to Chapter 24, License Acknowledgment when Using Libraries and Patents 4. When you need to display a license logo that is not regulated in the related contract document, we recommend you prepare a detailed display of the contents and send it to the Sega Legal Department for consultation to avoid possible problems of rights infringement.

Untested, assumed pass
5.2.8: The use of team or series logos must be approved by license holders and Sega's legal department. Do not use the words "Presents", "Presented by" or "Produced by" to avoid complications of rights ownership.[14]
To display a team logo and series logo, observe the following standards:

1. When creating a team logo or series logo, obtain approval for its use and register the trademark. 2. When using the logo, use only the logo in A. When using the logo, attach detailed specs of the logo display for the parties involved and send it to the Sega Legal department. 3. Obtain approval from the company in charge of the logo. 4. When displaying the logo, do not use the words "Presents", "Presented by" or "Produced by" together with the team or series logo to avoid complications of rights ownership.

Untested, assumed pass
5.2.9: OEM logos must be approved by Sega's legal department. "In cooperation with" must be added to the OEM company name.[15]
When displaying OEM logos other than manufacture and sales permit licensers, these are the standards to follow:

1. When you want to display an OEM logo, the logo display content is regulated in the development contract document. 2. If there is no regulation in the contract document, as a principle, any OEM logo display is disallowed. 3. However, even with the conditions of (2.), when absolutely necessary, logos can be displayed by attaching detailed specs of the logo display for the parties involved and bringing it to the Sega Legal Department. The OEM company name is displayed in the main position, with the logo display in the secondary position. • Add "In cooperation with"… to the display area of the OEM company name.

Untested, assumed pass
6: A title screen must display a title logo and the text "PRESS START BUTTON" (or for non-English software, a term that signifies that pressing  START  will start a game. Copyright information must also be displayed unless specified otherwise by the contract document, or there is not enough space.[16]
The Title Screen displays the Title Logo, "PRESS START BUTTON" and a copyright, unless specified otherwise by contract document or difficulty (such as a movie title) to display the copyright because of lack of space. If "PRESS START BUTTON" is displayed in any language other than English, express the idea that pressing the start button will start the game as simply as possible.
Untested, assumed pass
6.1: If the transition past the title screen is not initiated by user input, display the title screen for about two seconds.[16]
If transition to the next screen is not initiated by user input, display the Title Logo for about two seconds.
Untested, assumed pass
6.1.1: Advancing past the title screen should only occur when  START  is pressed.[16]
Advancing to the Main Game or Start/Option screen should occur only when the START button is pressed at the Title Screen. If the START button is not pressed, proceed to the next screen of the title loop after a short time has elapsed, as mentioned in Chapter 3, Sequences before Game Start.
Untested, assumed pass
7.1: During the demo sequence, "PRESS START BUTTON" and/or "DEMO PLAY" must be displayed on screen to distinguish the demo from normal play.[17]
During the Play Demo sequence, "PRESS START BUTTON," and/or "DEMO PLAY," should be displayed on the screen to clearly distinguish from the main game (after game start).
Untested, assumed pass
7.2: Pressing  START  during a demo sequence should return to the title screen.[17]
Pressing the START button during either the Play Demo or Story Demo should immediately bring up the Title Screen. If the START button is not pressed, end the demo after a short time has elapsed, and proceed to the next screen of the title loop.
Untested, assumed pass
8.1: Any menus must exist separately from the title screen.[18]
The Start/Option Selection screen exists separately from the Title Screen. If a "Menu" selection such as Start/Option is needed, it should appear when the START button is pressed at the Title Screen. Objects other than the Menu can be used and combined as needed.
Untested, assumed pass
8.2: Menu items should always be shown, even if the controller state means they cannot be used. When items cannot be used, (e.g. versus mode, when only one controller is connected) they should be greyed out.[18]
According to the controller connection state, items that are unusable should be displayed in the menu, but not be selectable. If a second controller is not present, "vs" mode should be grayed out. If the phone line is not plugged in, the network selection should be grayed out.
Untested, assumed pass
9.1: A stereo/monaural audio setting should be provided.[19]
Considering the many users who play on monaural TVs, the Stereo/Monaural selection should be provided whenever possible.
Untested, assumed pass
9.2: The stereo/monaural setting must not be saved. The default setting is saved in the boot ROM.[20]
If the option settings are to be backed up according to the above, the Stereo/Monaural setting should not be saved. On the Sega Dreamcast, the Stereo/Monaural settings are saved in the Main Unit, considering the case where the same data is to be used to play in another environment.
Untested, assumed pass
9.3: If the stereo/monaural setting is changed in-game, the boot ROM setting must be changed too.[20]
When the user changes the value of the voice output setting on the application option screen, the Main Unit Boot ROM setting should also be set to the same value before the option screen is exited. Wait until the user confirms. As used in the procedures of 3.1, 9.2 and 9.3, the Stereo/Monaural setting refers to Main Console setting, and other option settings refer to the saved data (if present).
Untested, assumed pass

Main game


Compilance Screenshot(s) Pass/fail Comments
10.1: Important HUD elements should not appear within 8 pixels of the horizontal edge of the screen, or 16 or 32 pixels vertically for 320x240 and 640x480 screen resolutions, respectively.[21]
Important displays such as score and remaining units should not appear within:
  • 8 pixels horizontally or 16 pixels vertically from the game screen (for 320x240 pixel displays).
  • 8 pixels horizontally or 32 pixels vertically from the game screen (for 640x480 pixel displays).
Untested, assumed pass
10.4: Avoid sudden switches from black to white to maintain compatibility with the sync interval in older TVs.[22]
To maintain compatibility with the sync interval in older TVs, applications should avoid suddenly switching the screen from black to white. (If such switching is necessary, take measures such as inserting gray between the extremes and lowering the brightness of the white.) When using a controller, the above measure is not possible on the hardware, and is an exception. However, as much as possible, don't insert an extremely bright color before a flash or change colors suddenly.
Untested, assumed pass
10.5: Colours with more than 75% brightness (0xC0) should not be allowed to persist for more than 300 seconds or cover more than two thirds of the screen.[23]
Screen display of more than 0XC0 (75% brightness) should not be allowed to persist for a long time (more than 300 seconds), or cover more than 2/3 of the screen. Sega Dreamcast image output is set to 800mV, to display bright white briefly, so if 0XC0 (not only white, but also yellow or other colors) is displayed for a long time on an NTSC/PAL TV, the screen phosphor could be burned. However, there is no problem displaying 0XFF (100% bright white) briefly and in small screen regions. We suggest using values below 0XC0 for large screen regions in applications where screen simulations are likely to be frozen. Currently, even the Boot ROM has the background white display corresponding to 0XC0. The standard brightness of the white color used for the screen flash when using the gun controller is 0x90; for a VGA monitor, it is 0xC0.

The brightness of the white color used for the screen flash is closely related to gun performance and may be hard on your eyes. You may want to lower the brightness of the flash to make it easier on your eyes, but so doing shortens the detection range of the peripheral device. The degree of brightness depends on the type and manufacturer of the monitor on which you view it, but in general, VGA monitors have a lower degree of brightness than a TV monitor. Taking the above conditions into consideration, the brightness of the flash is 0x90 for a TV screen, and 0xC0 for a VGA monitor.

Untested, assumed pass
12: The ability to pause a game should be provided, save for situations where there is nothing to "pause".[24]
A pause capability should be provided except when not needed due to the character of the game, and to allow time for an application to obtain matching service (19.3 Matching Service Functions) when connecting to a network.
Untested, assumed pass
12.1a: Pausing/unpausing must be done with  START .[24]
The START button turns the Pause function on and off.
Untested, assumed pass
12.1b: The pause function should be independent for each port.[24]
When the above condition is enacted to allow Pause from either port A or B, the Pause function is independent for each port (that is, if the Pause is performed from port A, only port A can perform the Resume).
Untested, assumed pass
12.2: A word such as "PAUSE" should be displayed while paused to distinguish the screen from software bugs. This should indicate which player initiated the pause (e.g. "PLAYER 1 PAUSE" or "PLAYER 2 PAUSE").[25]
A word such as "PAUSE" should be displayed while paused. This is to distinguish the Pause from a hang-up from a bug.

The display should so indicate the initiator of the Pause, such as "PLAYER 1 PAUSE" or "PLAYER 2 PAUSE."

Untested, assumed pass
12.3: After 300 seconds on a static screen, where more than two thirds of the screen is at or above 75% brightness, dim the screen or show a screensaver. The screensaver must be visually different from the main game and must not be completely blank.[25]
If the Pause function causes the screen display to persist, such that white display of more than 75% brightness would occur for a long time (more than 300 seconds), or cover more than 2/3 of the screen, a screen saver should be provided and should start automatically if the Pause persists for more than 300 seconds.

Sega Dreamcast image output is set to 800mV, to display bright white temporarily, so if 0XC0 (not only white, but also yellow or other colors) is displayed for a long time on an NTSC/PAL TV, the screen phosphor could be burned. However, there is no problem displaying 0XFF (100% bright white) for short periods and in a small screen region. It is up to the application whether the screen saver is an "After Dark" type or simply a reduction in screen brightness. (Refer to the partial sample program in the SDK.) Provide a screen different from the main game for the Pause Screen, and ensure that it does not include white display of more than 0XC0 (75% brightness).

Untested, assumed pass
12.4: Pausing is not allowed during logo or title screens, or demo sequences.[25]
A Pause must not be allowed during display of the Logo screen, Title Screen or Demo screen, and should not consist of a blank screen.
Untested, assumed pass
14.1: It must not be possible to skip middleware logos (e.g. ADX and Sofdec).[26]
In case of displaying library logos (such as True Motion and CRI MPEG Sofdec) during ending/credit scrolling, it should not be possible to skip forward. Also, follow the rules in the contract document regarding skipping screens when displaying license logos. When library logo and/or license logo display is not included in the Ending/Credit scroll display, the application side can decide whether or not to allow screen skipping. However, even if license logo display is not included in the Ending/Credit scroll, enable "Soft Reset" during the Ending/Credit scroll, as mentioned in 4.1.1, Soft Reset Timing.
Untested, assumed pass
14.2: After an ending or credits screen, the software return to the title screen, either after a timer elapses or by the press of the accept (default A) or  START  buttons.[26]
After Ending/Credit Scroll finishes, the game should advance to the Title Screen with a timer or by the action of the Accept or Start button.
Untested, assumed pass

Disc usage


Compilance Screenshot(s) Pass/fail Comments
16.1: If loading from a disc takes more than ten seconds, display a message (e.g. "Loading...") to distinguish the screen from software bugs.[27]
When loading a file from a disc, display a message such as "Loading..." on the screen when reading takes longer than 10 seconds, or otherwise indicate to the user that the delay is not due to a hangup from a bug.
Untested, assumed pass
20.1: Any *.da file saved in the single-density "CD-ROM" area should be voice data.[28]
In the single-density area of the Dreamcast-specific disc, DA (except for non-sound) should be input as voice data. DA sound should be made to run even if the specific-disc is put in a non-Dreamcast CD player.
Untested, assumed pass
20.2: Program data must be written to and executed from the high-density area of a GD-ROM, not the single-density "CD-ROM" area or a memory card.[29]
For security reasons, the Sega Dreamcast program execution code cannot be written to any area other than the Sega Dreamcast-specific disc high-density area. Sega Dreamcast program execution code should not be written to Sega Dreamcast-specific disc single-density area, save data, or Visual Memory special games.
Untested, assumed pass

Miscellaneous


Compilance Screenshot(s) Pass/fail Comments
26: Software must abide by the guidelines provided by the NHK and Japan Civil Broadcasting Union in regards to certain light patterns or flashing lights.[30]
A very small number of individuals may experience seizures when exposed to certain light patterns or flashing lights. Exposure to certain patterns or backgrounds on a television screen or while playing videogames could induce a seizure in such individuals. Certain conditions may induce undetected seizure symptoms even in persons who have no history of prior seizures or epilepsy.
Because of this possibility, an appropriate seizure warning should be included on videogame packaging. The following guidelines have been provided by NHK (Japan Broadcasting Co.), and should be used as a guideline for precautionary measures:

• Prepare an option that can toggle light ON/OFF when flashing lights appear. • Display a warning message like the one below at the beginning of a game. These guidelines are examined in more detail in the next section, "NHK (Japan Broadcasting Co.) and Japan Civil Broadcasting Union Guidelines."

Untested, assumed pass
27: Software designed for PAL systems must be compatible with the 21-pin RGB cable, as not all French televisions accept PAL video.[31]
Software designed for operation on European systems should be compatible with a 21-pin RGB cable (15kHz RGB output mode).

One potential problem is that in France, many television sets use 15kHz RGB skate cables, while not many are equipped with PAL video input jacks. For this reason, unless 15kHz RGB is consciously supported via software, it may not be possible to use the Sega Dreamcast system in many households in France.

Untested, assumed pass

Results

Pass 0
Fail 0
Partial 0
Untested 45
Total 45

References

  1. Sega Dreamcast Software Creation Standards, page 5
  2. Sega Dreamcast Software Creation Standards, page 8
  3. 3.0 3.1 Sega Dreamcast Software Creation Standards, page 9
  4. Sega Dreamcast Software Creation Standards, page 10
  5. Sega Dreamcast Software Creation Standards, page 12
  6. Sega Dreamcast Software Creation Standards, page 17
  7. 7.0 7.1 Sega Dreamcast Software Creation Standards, page 18
  8. 8.0 8.1 Sega Dreamcast Software Creation Standards, page 19
  9. Sega Dreamcast Software Creation Standards, page 20
  10. Sega Dreamcast Software Creation Standards, page 21
  11. Sega Dreamcast Software Creation Standards, page 15
  12. Sega Dreamcast Software Creation Standards, page 24
  13. Sega Dreamcast Software Creation Standards, page 27
  14. 14.0 14.1 Sega Dreamcast Software Creation Standards, page 28
  15. Sega Dreamcast Software Creation Standards, page 29
  16. 16.0 16.1 16.2 Sega Dreamcast Software Creation Standards, page 32
  17. 17.0 17.1 Sega Dreamcast Software Creation Standards, page 33
  18. 18.0 18.1 Sega Dreamcast Software Creation Standards, page 35
  19. Sega Dreamcast Software Creation Standards, page 38
  20. 20.0 20.1 Sega Dreamcast Software Creation Standards, page 39
  21. Sega Dreamcast Software Creation Standards, page 41
  22. Sega Dreamcast Software Creation Standards, page 42
  23. Sega Dreamcast Software Creation Standards, page 43
  24. 24.0 24.1 24.2 Sega Dreamcast Software Creation Standards, page 47
  25. 25.0 25.1 25.2 Sega Dreamcast Software Creation Standards, page 48
  26. 26.0 26.1 Sega Dreamcast Software Creation Standards, page 53
  27. Sega Dreamcast Software Creation Standards, page 77
  28. Sega Dreamcast Software Creation Standards, page 105
  29. Sega Dreamcast Software Creation Standards, page 106
  30. Sega Dreamcast Software Creation Standards, page 125
  31. Sega Dreamcast Software Creation Standards, page 127


JoJo's Bizarre Adventure

JoJosBizarreAdventure title.png

Main page | Comparisons | Magazine articles | Video coverage | Reception | Technical information



Sega Dreamcast
Prototypes: 2000-01-11