U.S. Pat. No. 9,656,163

DETAILED DESCRIPTION

Although the following detailed description contains many specific details for the purposes of illustration, anyone of ordinary skill in the art will appreciate that many variations and alterations to the following details are within the scope of the present disclosure. Accordingly, the aspects of the present disclosure described below are set forth without any loss of generality to, and without imposing limitations upon, the claims that follow this description.

According to various aspects of the present disclosure, haptic response capabilities may be added to legacy games that were not originally programmed to support haptics. The haptic capabilities may be added to the legacy game while it is being emulated by an emulator. The emulator is designed to generate a haptic stimulus that may be sent to the client device platform when a haptic trigger is present in the legacy game. The client device platform may then use the haptic stimulus to generate a haptic response.

Introduction

The process of emulating the functionality of a first computer platform (the “target system”) on a second computer platform (the “host system”) so that the host system can execute programs designed for the target system is known as “emulation.” Emulation has commonly been achieved by creating software that converts program instructions designed for the target platform (target code instructions) into the native-language of a host platform (host instructions), thus achieving compatibility. More recently, emulation has also been realized through the creation of “virtual machines,” in which the target platform's physical architecture—the design of the hardware itself—is replicated via a virtual model in software.

Two main types of emulation strategies currently are available in the emulation field. The first strategy is known as “interpretation”, in which each target code instruction is decoded in turn as it is addressed, causing a small sequence of host instructions then to be executed that are semantically equivalent to the target code instruction. The main component of such an emulator is typically a software interpreter that converts each instruction of any program in the target machine language into a set of instructions in the host machine language, where the host machine language is the code language of the host computer on which the emulator is being used. In some instances, interpreters have been implemented in computer hardware or firmware, thereby enabling relatively fast execution of the emulated programs.

The other main emulation strategy is known as “translation”, in which the target instructions are analyzed and decoded. This is also referred to as “recompilation” or “cross-compilation”. It is well known that the execution speed of computer programs is often dramatically reduced by interpreters. It is not uncommon for a computer program to run ten to twenty times slower when it is executed via emulation than when the equivalent program is recompiled into target machine code and the target code version is executed. A number of products have successfully improved on the speed of executing source applications by translating portions of the target program at run time into host machine code, and then executing the recompiled program portions. While the translation process may take, e.g., 50 to 100 machine or clock cycles per instruction of the target code, the greater speed of the resulting host machine code is, on average, enough to improve the overall speed of execution of most source applications.

FIG. 1is a schematic of an embodiment of the present invention. Emulator107may be accessed by a client device platform103over a network160. Client device platform103may be one of a plurality of client device platforms103that are each able to access the same emulator107over the network160. Client device platform103may also access alternative emulators107.

Client device platform103may include a central processor unit (CPU)131. By way of example, a CPU131may include one or more processors, which may be configured according to, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The client device platform103may also include a memory132(e.g., RAM, DRAM, ROM, and the like). The CPU131may execute a process-control program133, portions of which may be stored in the memory132. The client device platform103may also include well-known support circuits140, such as input/output (I/O) circuits141, power supplies (P/S)142, a clock (CLK)143and cache144. The client device platform103may optionally include a mass storage device134such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The client device platform103may also optionally include a display unit137. The display unit137may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. A controller145may be connected to the client device platform103through the I/O circuit141or it may be directly integrated into the client device platform103. The controller145may facilitate interaction between the client device platform103and a user. The controller145may include a keyboard, mouse, joystick, light pen, hand-held controls or other device. The controller145is also capable of receiving a haptic stimulus111(not shown). In response to the haptic stimulus111, the controller may generate a haptic response146. By way of example and not by way of limitation, the haptic response146may be vibrations or any other feedback corresponding to the sense of touch. The client device platform103may include a network interface139, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via an electronic communications network160. The network interface139may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The client device platform103may send and receive data and/or requests for files via one or more data packets over the network160.

The preceding components may exchange signals with each other via an internal system bus150. The client device platform103may be a general purpose computer that becomes a special purpose computer when miming code that implements embodiments of the present invention as described herein.

The emulator107may include a central processor unit (CPU)131′. By way of example, a CPU131′ may include one or more multiple core processors, which may be configured according to, e.g., a dual-core, quad-core, multi-core, or Cell processor architecture. The emulator107may also include a memory132′ (e.g., RAM, DRAM, ROM, and the like). The CPU131′ may execute a process-control program133′, portions of which may be stored in the memory132′. The emulator107may also include well-known support circuits140′, such as input/output (I/O) circuits141′, power supplies (P/S)142′, a clock (CLK)143′ and cache144′. The emulator107may optionally include a mass storage device134′ such as a disk drive, CD-ROM drive, tape drive, or the like to store programs and/or data. The emulator107may also optionally include a display unit137′ and user interface unit138′ to facilitate interaction between the emulator107and a user who requires direct access to the emulator107. The display unit137′ may be in the form of a cathode ray tube (CRT) or flat panel screen that displays text, numerals, or graphical symbols. The user interface unit138′ may include a keyboard, mouse, joystick, light pen, or other device. The emulator107may include a network interface139′, configured to enable the use of Wi-Fi, an Ethernet port, or other communication methods.

The network interface139′ may incorporate suitable hardware, software, firmware or some combination of two or more of these to facilitate communication via the electronic communications network160. The network interface139′ may be configured to implement wired or wireless communication over local area networks and wide area networks such as the Internet. The emulator107may send and receive data and/or requests for files via one or more data packets over the network160.

The preceding components may exchange signals with each other via an internal system bus150′. The emulator107may be a general purpose computer that becomes a special purpose computer when running code that implements embodiments of the present invention as described herein.

Emulator107may access a legacy game106that has been selected by the client device platform103for emulation through the internal system bus150′. There may be more than one legacy game106stored in the emulator. The legacy games may also be stored in the memory132′ or in the mass storage device134′. Additionally, one or more legacy games106may be stored at a remote location accessible to the emulator107over the network160. Each legacy game106contains game code108. When the legacy game106is emulated, the game code108produces legacy game data109(not shown).

By way of example, a legacy game106may be any game that is not compatible with the client device platform103. By way of example and not by way of limitation, the legacy game106may have been designed to be played on Sony Computer Entertainment's PlayStation console, but the client device platform103is a home computer. By way of example, the legacy game106may have been designed to be played on a PlayStation 2 console, but the client device platform103is a PlayStation 3 console. Further, by way of example and not by way of limitation, a legacy game106may have been designed to be played on a PlayStation console, but the client device platform103is a hand held console such as the PlayStation Vita from Sony Computer Entertainment. Alternatively, the client device platform may be a device other than a game console or portable game device, e.g., a personal computer, a smart phone, a tablet computer, or other similar device.

As shown inFIG. 2, the client device platform103and the emulator107may be configured to implement a method for adding a haptic response146to a legacy game106that was not originally designed to produce haptic feedback according to an inventive method200. Various aspects of the method200may be implemented by execution of computer executable instructions running on the client device platform103and/or the emulator107. Specifically, a client device platform103may be configured, e.g., by suitable programming, to implement certain client device platform instructions270. In addition, an emulator107may be configured to implement certain emulation instructions271. InFIG. 2the dashed arrows represent the flow of data between the client device platform103and the emulator107over the network160.

Initially, at272the client device platform103may deliver information to the emulator107indicating that the user has selected a legacy game106that he wants emulated. The emulator107receives this information at block273and then proceeds to emulate the chosen legacy game106at274. While emulating the legacy game106, the emulator107will check the legacy game data109for haptic triggers110(not shown) at275.

A haptic trigger110is a portion of legacy game data109that has been identified as corresponding to a haptic game event. As used herein, a haptic game event is an event in the legacy game106that warrants a haptic response146. There are many different types of legacy game data109that can correspond to an event warranting a haptic response146. By way of example, and not by way of limitation, legacy game data109arising from the generation of certain sounds, such as an explosion that occurs during the game, may be identified as a haptic trigger110. The emulator107may determine that an explosion has occurred in the legacy game by identifying the portion of the legacy game data109which will generate the sound of an explosion from the sound card. However, it should be noted that haptic triggers110are not limited to sound events.

Alternatively a haptic trigger110may also be identified when a specified combination of conditions are met. By way example and not by way of limitation, a specified combination of conditions may be when, in a football game, there are only a few seconds remaining in the game and a user is trying to kick a game winning field goal. A haptic response146, such as shaking the controller145, may enable the user to feel the pressure of the situation in the game and produce a more realistic gaming experience. The emulator107may use screen scraping to find the time left on the clock, and the emulator107can detect that the legacy game106is accessing the play for kicking a field goal. Further, haptic triggers110may be any other event or combination of events that may be perceived by the emulator107, and which do not require changing the internal code108of the legacy game106. By way of example and without limitation these events may be sound card events, reading information from the disk, writing data to a memory card, or monitoring the memory contents of a legacy game106while the legacy game106is being emulated. The haptic triggers110described above are described in greater detail in the commonly assigned related patent application entitled “DETERMINING TRIGGERS FOR CLOUD-BASED EMULATED GAMES”61/666,628which has been incorporated herein in its entirety.

When the emulator107identifies a haptic trigger110, it proceeds to276and generates a haptic stimulus111. At277, both the emulated legacy game data109and the haptic stimulus111are sent to the client device platform103. The client device platform103receives the haptic stimulus111and the emulated data at278, and then utilizes the haptic stimulus111to produce a haptic response146at279.

As shown inFIG. 3A, a set of client device platform instructions370may be implemented, e.g., by the client device platform103. The client device platform instructions370may be formed on a nontransitory computer readable medium such as the memory132or the mass storage device134. The client device platform instructions370may also be part of the process control program133. The instructions include delivering the title of a selected legacy game106to the emulator107at372. Thereafter, the client emulation instructions370require the client's haptic software to receive the haptic stimulus111and the emulated legacy game data109from the emulator at378. Once the haptic stimulus111is received, the client device platform103is instructed to use the stimulus111to illicit a haptic response146from the client device platform103at379.

As shown inFIG. 3B, a set of emulator instructions371may be implemented, e.g., by the emulator107. The emulation instructions371may be formed on a nontransitory computer readable medium such as the memory132′ or the mass storage device134′. The emulator instructions371may also be part of the process control program133′. The instructions include receiving the title of a selected legacy game106from the client platform device103at373. Thereafter the emulator107is instructed to begin emulating the selected legacy game106at374. While emulating the legacy game106, the emulator107is instructed to check for haptic triggers110at375. Then at376, if there are any haptic triggers110present, the emulator107is instructed to generate a haptic stimulus111. The emulator107is then instructed to deliver the haptic stimulus111and the emulated legacy game data109to the client device platform at377.

Emulator107may be programmed to recognize which portions of the legacy game data109are considered haptic triggers110.FIG. 4provides a flow diagram that describes a method400for programming the emulator to recognize that an event in the legacy game106requires a haptic response146. First, at401a designer decides which events during the game should include a haptic response146. By way of example and not by way of limitation, the designer may decide that the controller145should shake when there is an explosion on screen, the character being controlled by the user is injured, or the level is portrayed as a noisy environment. After determining which events should be accompanied with haptic feedback146, the method proceeds to402. There the designer must find haptic triggers110which coincide with the events. By way of example and without limitation the haptic triggers110may be sound card events, reading information from the disk, writing data to a memory card, or monitoring the memory contents of a legacy game106while the legacy game106is being emulated. Identifying haptic triggers110is further described in the previously incorporated commonly assigned related provisional patent application No. 61/666,628, entitled “DETERMINING TRIGGERS FOR CLOUD-BASED EMULATED GAMES”, which has been incorporated herein by reference above. Once each event has been linked to a haptic trigger110, method400continues at403by having the designer program the process control program133′ to recognize each haptic trigger110and generate a haptic stimulus111when the emulator107detects one.

While the above is a complete description of the preferred embodiment of the present invention, it is possible to use various alternatives, modifications and equivalents. Therefore, the scope of the present invention should be determined not with reference to the above description but should, instead, be determined with reference to the appended claims, along with their full scope of equivalents. Any feature described herein, whether preferred or not, may be combined with any other feature described herein, whether preferred or not. In the claims that follow, the indefinite article “A”, or “An” refers to a quantity of one or more of the item following the article, except where expressly stated otherwise. The appended claims are not to be interpreted as including means-plus-function limitations, unless such a limitation is explicitly recited in a given claim using the phrase “means for.”