RFC-EMU

From DeSmuME
(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
  
 
An emulator MAY NOT attempt to be both powerful tool and toy. An emulator MUST choose which of these it is, and EXIT this document if it chooses to be a toy.
 
An emulator MAY NOT attempt to be both powerful tool and toy. An emulator MUST choose which of these it is, and EXIT this document if it chooses to be a toy.
 +
 +
An emulator MUST implement an EMULUA interface, which is necessary for testing and verification of the emulator stability.
 +
 +
This document wields capitalized command words more flippantly than a typical RFC, as it is endeavouring to formalize design principles in addition to operational principles. Emulator authors should exercise less creativity than they historically have in implementing certain core functions.
  
 
==Coding Guidelines==
 
==Coding Guidelines==
  
In order to combat routinely-created bugs in menus, an emulator SHOULD set up all of its menu state in one block of code at the time when the menu is created, analyzing the current emulator state and setting disabled and checkmark states accordingly. For instance, in Win32 this would be done with WM_ENTERMENULOOP.  
+
An emulator MUST execute deterministically and exactly reproducibly, down to the very sample, on every host system given the same emulator configuration. An emulator MAY NOT execute identically whe
  
 +
In keeping with the principle of deterministic execution, an emulator MUST have a straightforward internal reset process which yields identically initialized variables and can be called repeatedly. This process MUST be separate from any one-shot emulator host features initialization. In other words, emulation state reset and host state initialization MUST NOT be mixed.
 +
 +
In order to combat routinely-created bugs in menus, an emulator SHOULD set up all of its menu state in one block of code at the time when the menu is created, analyzing the current emulator state and setting disabled and checkmark states accordingly. For instance, in Win32 this would be done with WM_ENTERMENULOOP.
  
 
==User Interface Guidelines==
 
==User Interface Guidelines==

Revision as of 06:16, 12 September 2009

Some emulators are powerful tools, and some are toys for novices. The toys need not conform to the laws laid forth in the following document, which are designed to ensure that those who need power are able to get it without trouble.

An emulator MAY NOT attempt to be both powerful tool and toy. An emulator MUST choose which of these it is, and EXIT this document if it chooses to be a toy.

An emulator MUST implement an EMULUA interface, which is necessary for testing and verification of the emulator stability.

This document wields capitalized command words more flippantly than a typical RFC, as it is endeavouring to formalize design principles in addition to operational principles. Emulator authors should exercise less creativity than they historically have in implementing certain core functions.

Coding Guidelines

An emulator MUST execute deterministically and exactly reproducibly, down to the very sample, on every host system given the same emulator configuration. An emulator MAY NOT execute identically whe

In keeping with the principle of deterministic execution, an emulator MUST have a straightforward internal reset process which yields identically initialized variables and can be called repeatedly. This process MUST be separate from any one-shot emulator host features initialization. In other words, emulation state reset and host state initialization MUST NOT be mixed.

In order to combat routinely-created bugs in menus, an emulator SHOULD set up all of its menu state in one block of code at the time when the menu is created, analyzing the current emulator state and setting disabled and checkmark states accordingly. For instance, in Win32 this would be done with WM_ENTERMENULOOP.

User Interface Guidelines

While admittedly a matter of opinion, to bring order to the unruly thicket of default hotkeys, the following recommendations have been drafted:

An emulator SHOULD use F1 for this and F2 for that.

An emulator MUST have command-line arguments at least implementing the following:

* load state slot (0-9)
* play movie file

? OSD? Why do we even do this anymore? ?

Personal tools