high level display screens in j2me made in china

2023-01-03 12:32:11

This game got several versions for various feature phones in Japan, starting with the simplified 2001 release that had a huge gap between the power bar and the lower edge of the screen. Then in 2003 an improved version was released, including a sound test option (hardware dependent) and a "warming up" boot animation, but before that there was a version with 11 levels, four of which were exclusive. That version existed in the Western market for low-end Nokia phones.

A year later, Konami released a fourth and definitive version for FOMA 900 feature phone series, with even better graphics and making it closer to the arcade original. This version was the base for the Chinese localization, first in 2005 with all levels split into seven JAR files due to hardware limitations at the time, and then in 2009 with the full version (the latter was distributed via China Mobile"s Game Center).

It should be noted that the Chinese version contains some minor inconsistences, such as the BGM for Volcano stage being played in all levels, but all the rest is the same, save for the sound test and the warming up animation which are absent for some reason.

This version runs on QVGA feature phones, I am preserving the SE S700 version because it has a faster framerate (noticeable on Nokia S40v5/6 phones) though it is labeled as a Nokia compatible version.

In Japan, lots of industries (mainly gaming companies) tend to release stuff related or based on anime series or mangas, Dragon Ball for example. The game I have preserved here is based on one of the famous anime franchises in the 80"s and 90"s: Mobile Fighter G Gundam,which was licensed by Bandai for its Western localization.

Bandai was acquired by Namco in 2005, and since then the company is known as Namco Bandai Holdings. A year later, they released a couple of games featuring various characters from the Gundam franchise, one of them got a Taiwanese release because it complied with J2ME"s limitations.

This one is a pretty interesting fighting game, with a total of 14 playable characters, seven for each story mode (four of themare unlockable by completing both story modes a few times),though a refreshed version was released in 2008 with an additional"player vs player"mode via Bluetooth. It also includes a survival mode, a screen with information about each character and short cinematics before battles. The Taiwanese J2ME version was released in around 2009-2010, using the first version as base.

You won"t need to learn Chinese (it uses Traditional rather than the Simplified one) to play this game, unless you want to read all those text in the intro, Gundam info gallery and each of the cinematics.

From Konami"s (now disappeared) Konami Net DX service, another port of an arcade game has been preserved. This time featuring soldiers, six levels and lots of action.

Rush"n Attack (also known as Green Beret in Japan) had various ports that followed the arcade version in terms of levels, weapons and plot. However the Famicom version was somewhat superior because they added music, two more levels and even had its plot changed (objective was to destroy the enemy"s secret weapon, while in the arcade original it was to rescue the POWs).

Konami released a port for Japanese feature phones in 2006, basing it on the Famicom version. A health bar was also included, especially for those who find it difficult and want to explore the whole game. All the rest is the same: weapons, music, levels, etc. Konami China then released it in three parts for J2ME phones, each one had two levels (for some reason, this was done because most Western phones at the time were limited in terms of Java heap and maximum JAR size); though a second version with all levels was released later. It should be noted that the split Chinese release lacked the health bar, plus that its three JAR files had contents dated back to 2005, meaning that it was developed months before the Japanese release.

The preserved game file is compatible with QVGA feature phones, even those with landscape displays. Originally it was "copy protected" like Sina Mobile did with TwinBee, but this one has it fixed so you won"t need their specialized JAD file to install.

I guess some of you have ever heard or seen about Kemco, a company which was behind various platformers and RPGs released for consoles, even though their most known franchise is the Top Gear racing game series. In around 2006, Kemco entered the mobile market, where they began releasing lots of JRPGs, like the Alphadia series. Most of them got a re-release for iOS and Android devices.

However, in the summer of 2008, an elusive JRPG was released for Japanese feature phones, called Soul Tears. This game is about a knight named Legato, who decided to escape from the Order and his brother Emilio joins his steps, to stop the hidden evil plans of his lover Feria (according to a Japanese press site: http://www.ksol.jp/v2/information20110112.html). In the source, it also mentions about a Taiwanese J2ME release that was distributed via the iScreen mobile service in that territory.

For those who love RPGs despite the language barrier, this is a game I recommend trying it out. Graphics, music, story and the combat mechanics are pretty good for a J2ME game standard. You can even save your progress in three slots, which is an interesting addition here. Even though I"d like to see a remade version for iOS/Android with better graphics and music... which seems to be very unlikely since the developers might have forgotten about this one.

This preserved Taiwanese version runs on any feature phone with a QVGA display. Tested on the following devices with positive results: Nokia C2-02, J2ME Loader for Android and even on landscape devices like the Nokia C3-00 (despite cutting out part of the screen).

This one is very interesting: in early 2002, a version with details similar to the Famicom release was distributed via the Konami Net service, for Japanese FOMA 501/503 feature phones only. However, a year and a half later, Konami updated their mobile game service in Japan by renaming it to "Konami Net DX" and then they started to remake their old works with modern graphics. Their mobile port of TwinBee was among them.

Released in October 2003 to make better use of the FOMA 505i feature phone line, it also includes a difficulty setting and, for some reason, they re-released the game seven years later with the ability to play in 2-player cooperative mode.

The game also got some treatment by Konami China. In 2006, it was distributed as separate levels, just like they did with Salamander previously. Then Sina Mobile released the full game, but with a small detail: it was meant to be installed along with the JAD file it came with. However the weak "copy protection" it had was related to the MANIFEST.MF file in the original archive, since an attribute line was missing. Also that a re-release was silently distributed via the Game Center for users on the China Mobile network.

This time I am preserving both Chinese releases, which are essentially the version with all levels altogether. These files will work on any feature phone with a QVGA display. For some strange reason, it won"t work on KEmulator nor on J2ME Loader for Android, because it crashes right after selecting the Start option.

Konami started with the mobile game market in 2001 opening their Konami-Net service, which had a subscription cost of 315 Japanese yen per month for users on the NTT DoCoMo network. The game catalogue back then, though interesting, was very limited due to the hardware that was being sold, take Castlevania as example: there were three versions of that game for mobile phones in Japan, all of them being hardware/heap dependent. The first version, released in 2001, had lots of graphical details removed and some of them were very simplified.

Then in 2005, their Chinese division silently released a version of that game for J2ME phones, though they initially decided to do so by splitting all levels into six executable files, one per level. Two years later, Konami China (in conjunction with Sina Mobile) joined those separate levels together, reverting the previous part-by-part strategy and making it even closer to the Japanese release. Only differences are: Chinese language and that the score HUD is slightly modified.

The preserved game file is compatible with Nokia and SonyEricsson feature phones with a 240x320 display. In-game screenshots were taken from an Android phone via the J2ME Loader emulator.

Mobile gaming is something most people are not into, since quality (even for 2018 standards) is inferior to what you see in PC/console games. However, it has an interesting history which only a few know or remember.

Before Android phones started to hit the market, the cellphone selection was pretty varied: models from different vendors, even with different OSes (Symbian was an example, used mostly in high-end Nokia phones that belonged to the N series, until the Nokia 808 Pureview which was the last Symbian phone ever released, back in 2012). But they did not have only Symbian as their option for apps/games. Remember the N-Gage? It started as a failure (only a limited selection of games released as exclusives for that platform) and then it became an addon for certain Series 60 devices until 2009.

Other vendors, though, resorted to something simpler that quickly became popular during the second half of the 2000"s. You know what platform I am referring to. For those who do not know, I am talking about J2ME (Java 2 Micro Edition) which was a very simplified Java runtime engine used in older basic phones. Series 40 6th Edition from Nokia was the last system that used it, before Microsoft decided to replace it with Series 30+ based on MediaTek"s MRE platform (thus closing sideloading and support of J2ME apps), though the 3G version of their 2017 Nokia 3310 seems to support the apps most people loved back in its era.

The real purpose of this site is to preserve and document the very rare J2ME ports of some games that did not see the light in the west. And that are virtually extinct due to the fact people nowadays think on Android and iOS as the actual concept of mobile gaming.

high level display screens in j2me made in china

For further setting forth the technological means that the present invention takes and the effect obtaining, below in conjunction with accompanying drawing and preferred embodiment, to J2ME game running method proposed by the invention and the technical scheme of device, know and complete description.

Refer to Fig. 1, the schematic flow diagram of J2ME game running method of the present invention.J2ME game running method of the present invention comprises the following steps:

S101 preserves MIDlet class on Android platform; In the MIDlet of described preservation class, create a method of calling switch view for other class;

MIDlet class is the entrance of J2ME game application.MIDlet is similar with Android Activity life cycle, and MIDlet directly inherits Activity, thereby Activity API is converted to MIDlet API.Defined method in J2ME MIDlet is carried out to same definition, and call accordingly in the life cycle of Activity, mainly comprise: definition abstract method abstract void startApp (), abstract void destroyApp (boolean unconditional), and in onCreate (), call startApp (), and realize destroyApp () in MIDlet derived class, only need call System.exit (0).

The interface that a difference that it is pointed out that Android platform and J2ME platform is Android is refreshed and is switched and can only in main thread, carry out, and sub-thread need to be notified main thread to refresh or be switched Canvas interface by Handler.Therefore, need in MIDlet, create the method that other class of confession is called switch view, refresh picture and in Canvas, realize.

S102 preserves Canvas class, Display class, Front class and Graphics class on Android platform; Wherein, by the SurfaceView on succession Android platform, to preserve Canvas class, by the android.view.Display on Android platform, change to preserve Display class;

J2ME Canvas is the core of 2D development of games, and the function of the Canvas function of Canvas on corresponding A ndroid platform not on J2ME platform, but the function of corresponding SurfaceView.Therefore preserving Canvas need to inherit SurfaceView.

Because Android need to inherit interface SurfaceHolder.Callback.SurfaceHolder.Callback has defined the life cycle of SurfaceView, Canvas is defined as abstract method by SurfaceHolder.Callback interface method and is realized by derived class, and derived class needs the initialization content in structure to move on in the surfaceCreated () method of SurfaceHolder.Callback definition.

Definition abstract method paint (Graphics g) offers derived class and realizes.SurfaceHolder object mHolder of initialization in building method, in paint () method, by mHolder, obtain android.graphics.Canvas object, and be Graphics object as parameter initialization, and then pass to paint (Graphics g) method as parameter.

While preserving Canvas on Android platform, other method can adopt similarly directly conversion regime, and as key response method, definition keyPressed () calls keyPressed () in onKeyDown ().

Although MIDlet has realized the control that view is switched, in J2ME game application, generally by Display, control view and switch.Transplanting for convenience of J2ME game application, has defined Display class in the present invention, and this Display class is by changing and obtain android.view.Display.The method providing due to android.view.Display be difficult to J2ME platform on Display method directly corresponding, so the present invention defines an android.view.Display member object in the Display of J2ME.So just can directly define initial method static Display getDisplay (MIDlet mid), by MIDlet object, obtain WindowManager, then by WindowManager initialization android.view.Display object.Above-mentioned define method in the present invention than the Display.getDisplay () of J2ME platform just many MIDlet parameter, can at utmost reduce difference semantically, reduced the complexity of transplanting.

Another important method of preserving Display on Android platform is setCurrent (View view), directly calls the sendMessage (View obj) of MIDlet object in the method.

Font function is comparatively simple, is mainly used in recording font size and style, only needs the corresponding variable of definition, and assignment method is provided.Obtain character string width and highly by Paint, take out font size and directly calculate.

Graphics member comprises android.graphics.Canvas, Bitmap, Paint, Rect, Font object, and realizes its function by these objects.Method for drafting (comprising draw characters, figure) is realized jointly by Paint and android.graphics.Canvas.Rendered images needs to obtain Bitmap object, draw out, and Bitmap is included in the parameter of Image type by android.graphics.Canvas.Rect is for shearing the region of drafting.Because android.graphics.Canvas does not support to arrange reference point, so the coordinate that need to draw according to reference point parameter adjustment by program is realized.

S103 preserves Image class on Android platform; Wherein, on Android platform, define a Bitmap object, described Btmap object is changed to preserve Image class;

Image class is the function of corresponding A ndroid API directly, defines Bitmap object on Android platform, directly Btmap object is changed, and games are converted to the operation to Bitmap object to the operation of Image.

S104 calls MIDlet class, Canvas class, Display class, Front class, Graphics class and the Image class of above-mentioned preservation, moves J2ME game on Android platform.

Due to each class of preserving, program entry, Graphic graphics module and picture resource module in playing with J2ME are respectively set up corresponding relation, therefore by raising and use above-mentioned class at Android platform, can realize the operation of J2ME game on Android platform.

After preserving MIDlet class, set up the one-to-one relationship of MIDlet class and J2ME games entrance.By calling MIDlet class, enter J2ME program entry, thereby start J2ME game master routine.

Graphic graphics module is the nucleus module of J2ME game, and the visual effect of game all realizes by graphics module.After preserving Canvas class, Display class, Front class and Graphics class, set up the corresponding relation of Graphic graphics module in Canvas class, Display class, Front class and Graphics class and J2ME games.After game main thread starts, called Graphic graphics module, Graphic graphics module is calling the above-mentioned class of Android platform, and particularly the Canvas mechanism of drawing realizes the function that Graphic draws.

Preserve Image class on Android platform after, set up the corresponding relation of picture resource module in Image class and J2ME games.In J2ME game Graphic graphics module by calling the resource such as picture resource module Loads Image, audio files.Call the Image class of preservation, can on Android platform, realize the function of picture resource module for J2ME game.

J2ME program adopts the storage of RMS data, for to RMS data, storage provides support, the RMS memory mechanism of J2ME platform need to be converted to the file memory mechanism of Android, in the file that the data stream that J2ME game is transmitted and key word directly output to key word appointment, preserve.The data layout of RMS storage only limits to byte arrays, its data layout can be converted into string format and call Android file storage API the data that write are saved as to file.

Preferably, preserve class DataStore, (android carries to create Properties object, the storage class of similar Hash table), by save () save data, game data is converted to Object object, and add key assignments (key), be saved in Properties, create file input stream, by properties.store () method, be written to file output stream; By load () method reading out data, by filename, create file input stream, write data in properties, then from properties, take out data object Object by key assignments, then carry out corresponding data type conversion.

The multimedia of J2ME game is mainly sound played file, if audio files is judged as audio according to the time span of audio files, plays or music.Preferably, if time span is greater than 5 seconds, be judged as music file, otherwise be judged as audio effect file.

Preferably, if audio effect file is play by the audio pond of Android platform.By setting up the mode in " audio pond ", when initialization, record the identifier list of audio, and audio effect file is loaded in " audio pond ", J2ME games call play sound effect method at the node of playing, and find corresponding audio to play by identifier.If music file is play by the MediaPlayer object of Android platform.Audio loading velocity is very fast, and reproduction time is shorter.And the support of music multimedia is play for a long time, but the load time is longer.Preserve acoustic management class SoundManager, by addSound (), load audio files used, judgement sound reproduction time length, if be greater than 5 seconds, be loaded as MediaPlayer object, otherwise be loaded as SoundPool object, and deposit in Hash table, when playing, by key assignments, from Hash table, find corresponding target voice, call its player method.

Control information is the mode of user and program interaction.J2ME games are general, and only to physical button, control information responds, for this feature, Android platform is except sending to J2ME games physical button control information correspondence, also adopt the characteristic control mode of Android platform, touch screen and gravity sensing are played and are expanded J2ME.J2ME games are converted to the control information of the same operating physical button of response by receiving after the touch screen of supporting frame and gravity sensing control information the operation of response as required.

Android control information is sent on Canvas, then by Canvas, information is mapped as to key information, implementation method is that Canvas has inherited Android gesture and gravity sensing is monitored interface OnTouchListener, realize onTouch (View v, MotionEvent event) method (system passes over information by calling the method), by the method, take out the coordinates regional that screen triggers, according to real needs, be set as the button value of response, and call key response method.Game state is converted to corresponding key-press event (J2ME game generally can complete all operations by key-press event and control) to touch screen gesture event and gravity sensing event.Module receives the state value of J2ME games, corresponding key value and toggle area, and toggle area is a rectangular pixels region, if certain toggle area produces touch screen event, according to game current state, returns to corresponding key-press event.In like manner, gravity-feed tank is to make Canvas inherit interface SensorEventListener, by onSensorChanged (SensorEvent e) method receive gravity towards coordinate figure, according to real needs, be mapped as corresponding button value, and call key response method.Gravity sensing event according to mobile phone towards being converted to corresponding key-press event.J2ME games only need carry out the setting of control module at each initialized node, can expand to and support touch screen and gravity sensing function, have enriched user"s experience.

J2ME game running method provided by the present invention provides the running environment of J2ME game application on Android platform, has realized the support of Android platform to J2ME game application.Game developer adopts can be extended to after J2ME platform development on Android platform, also develops a set of games and can run on J2ME platform and Android platform simultaneously.So both guaranteed that the J2ME game of developing can cover more low and middle-end mobile phone, also greatly reduced the cost that J2ME game application is transplanted to Android platform, improved development efficiency and the maintainability of game application simultaneously.

And the API opening to J2ME game on Android platform all realizes same function with reference to the function of J2ME platform api, and with corresponding J2ME API name, make the program code of J2ME game self without making an amendment, greatly improve operability and maintainability.

Refer to Fig. 2, the structural representation of J2ME game running device of the present invention.J2ME game running device of the present invention comprises games entrance respective modules 201, Graphic graphics module respective modules 202, picture resource module respective modules 203 and game running module 204;

Described games entrance respective modules 201, for preserving MIDlet class on Android platform; And in the MIDlet of described preservation class, create a method of calling switch view for other class;

Described Graphic graphics module respective modules 202, for preserving Canvas class, Display class, Front class and Graphics class on Android platform; Wherein, by the SurfaceView on succession Android platform, to preserve Canvas class, by the android.view.Display on Android platform, change to preserve Display class;

Described picture resource module respective modules 203, for preserving Image class on Android platform; Wherein, on Android platform, define a Bitmap object, described Btmap object is changed to preserve Image class;

Described game running module 204 for calling MIDlet class, Canvas class, Display class, Front class, Graphics class and the Image class of above-mentioned preservation, is moved J2ME game on Android platform.

Described game running module 204 comprises that J2ME games start module, Graphic graphics module operation module and picture resource module operation module.

After preserving MIDlet class, set up the one-to-one relationship of MIDlet class and J2ME games entrance, by calling MIDlet class, enter J2ME program entry, thereby start J2ME game master routine.

Described Graphic graphics module operation module for calling Canvas class, Display class, Front class and the Graphics class of preservation, is moved the Graphic graphics module in J2ME games on Android platform.

Described picture resource module operation module for calling the Image class of preservation, is moved the picture resource module in J2ME games on Android platform.

Preserve Image class on Android platform after, set up the corresponding relation of picture resource module in Image class and J2ME games, in J2ME game Graphic graphics module by calling the resource such as picture resource module Loads Image, audio files.

The file storage API that described data memory module calls Android platform stores the data of the string format of conversion in the file on Android platform into.

If multimedia file is sound played file, described multimedia playing module classifies the documents as audio effect file or music file according to the reproduction time length of file;

J2ME game running device provided by the present invention has encapsulated the total solution that J2ME game application is expanded to Android game application on Android platform.Not only realized the support of Android platform to J2ME game application, for the control characteristic of touch screen machine, J2ME has been played and done many improvement to improve user"s experience simultaneously.Realize the J2ME development of games across Android platform, improved development efficiency, reduced the cost that Android platform is transplanted in J2ME game.

Above-described embodiment of the present invention, does not form limiting the scope of the present invention.Any modification of doing within the spirit and principles in the present invention, be equal to and replace and improvement etc., within all should being included in claim protection domain of the present invention.

high level display screens in j2me made in china

Before the smartphones we know today were staples of mainstream culture, mobile phones, and their technology were pretty rudimentary and often relied on apps made in Java seeing as the language was designed to be portable (though Windows Mobile and Symbian were also somewhat popular as proto-smartphone platforms of choice). This didn"t keep games from being developed for these platforms. Casual simplistic games and rip-offs of retro franchises thrived, but it attracted some genuinely fun games that forever remained obscure, such as those from Gameloft.

The situation is quite different in Japan where mobile hardware was much more developed, only loosely Java-based, and major video game developers were much more invested in creating unique and high-quality content that"s most obscure and unpreserved, let alone emulated, today. Those are the very different Galapagos mobile phones (like NTT DoCoMo i-mode, DeNa, RoID...). Some of these games got ported to the inferior Western hardware but these are in the tiny minority.

A free cross-platform language capable of working in devices with highly reduced capabilities. It was basically Java stripped down to the bare essentials.

While originally not intended for games (until its more advanced game-oriented API came), it became the de facto market standard for cell phone gaming - due in no small part to the SDK being free and without licensing costs.

Currently, the Android-exclusive J2ME Loader is able to run most of the 2D and 3D J2ME games with the Mascot Capsule 3D exclusive games. On desktops KEmulator and FreeJ2ME should suffice for most games, but there"s a minority of games making use of obscure vendor-specific APIs supported only on their respective SDK tools. Given the scarcity of such tools, this list aims to comprehensively list the available ones for convenience.

Has fewer features than KEmulator, but better compatibility. It"s recommended for games that don"t work with KEmulator. It has an optional libretro core and development is active. Games that freeze on KEmulator, such as Wolfenstein RPG and Doom 2 RPG, run on FreeJ2ME with no issues, although compatibility and accuracy are not as good as J2ME Loader. Some games run too fast and require tinkering with the frame rate options. No 3D support.

Has more features than others, as well as 3D emulation (Compared with SJ Boy and midp2exe, KEmulator has better performance). It"s feature-packed with debugging features, like HTTP proxying. Requires Java Runtime Environment installed. It is a recommended emulator if you"re on a Windows, although some games (such as Wolfenstein RPG and Doom 2 RPG) freeze indefinitely on the loading screen. Last update was in 2012, brought by Gameloft.

A set of different device emulators released by Nokia along with their J2ME SDKs. Keyboard bindings are not friendly for playing games. Some of them are buggy. The Nokia 3410 SDK emulator is capable of running some ancient black & white J2ME games no other emulator can.

Device emulators released by Sony Ericsson along their J2ME SDKs. Some of them have support for Mascot Capsule 3D APIs. Can run some games at better framerates than the original devices.

More compatible than MidpX. Can take snapshots. More resolutions (but still buggy). Appears to run correctly some older games FreeJ2ME and KEmulator don"t and available for Windows only (play SJ Boy on Linux and Mac through Wine ). Also available Special Edition, it has chinese bootleg games support.

Experimental emulator from the SJ Boy authors. Appears to properly emulate transparency on older games making use of Nokia APIs. To open a game, drag and drop the .JAR file onto the MiniSoyo window.

Emulator from a company that used to develop solutions to allow users to try J2ME game demos on their computer before purchasing them. Doesn"t have any known advantageous features. Requires : JRE.

Project developing a full JVM implementation + Java ME 8 APIs. Full compatibility with old J2ME software and high portability are among its main goals. Under heavy development.

This is currently the highest compatibility J2ME emulator available. Converts .JAR files offline using its own resources. Easily launches both 2D & 3D apps. Samsung & Nokia API implemented. Supports different keyboard layouts and customization. It is highly accurate, with the right frame rate for each game, as well as vibration. Has slightly improved performance through hardware acceleration, but games won"t run too fast. Runs almost every Nokia game, even ones that don"t work with KEmulator or FreeJ2ME, but as well as Sony Ericsson"s 3D engine (Mascot Capsule 3D).

Old tool, launches J2ME Applications on Android using native library. Apps have to be converted first, using Netmite.com. Overall 2D stability is acceptable, but 3D support almost does not work. Different types of keyboard & screen stics are included. Unfortunately, often experiences troubles with .JAR conversion Here and Catalog of games for Java J2ME Runner

This is a Android J2ME Runner so that any J2ME or MIDP applications can run without modification. Developers can enter the Android Market quickly. You can use your familiar development environment such as J2ME and MIDP or easily port your existing J2ME Application to Android with minimum code change. Users can use java applications directly inside Android. J2ME apps converted found here

Might be the first one that"s open-source. Last update was in 2011. PSPKVM is a J2ME emulator for PlayStation Portable, port of Sun"s open-source JavaME implementation phoneME Feature.

phoneME for Windows CE/Mobile and Android is an implementation of the phoneME open source J2ME application platform for your Windows Mobile phone or Android mobile device. There are two different platforms of the phoneME Virtual machine : phoneME Feature and phoneME Advanced. Beyond precompiled binaries of these VMs for WinCE and Android based operating systems, this website provides information, patches and instructions in order to compile the phoneME sources yourself.

announced on 4 November 2002 and released on 7 October 2003. "N-Gage QD" introduced in 2004 as a redesign of the original "N-Gage Classic", fixing widely criticized issues and design problems. "N-Gage" was discontinued in February 2006, with Nokia moving its gaming capabilities onto selected Series 60 smartphones. "N-Gage 2.0" was announced in 2007.

Originally a joint Nintendo-Nokia cellphone handheld hybrid project slated for 2005, Nintendo backed away from the project (and its plans for NES/Game Boy ports for mobile were repurposed for their Virtual Engine project). Nokia continued the project on their own anyways and released N-Gage on October 7, 2003, for $299 as the most powerful handheld of its time, that is up until the DS and PSP came along and ended Nokia"s hopes at dominating the handheld gaming market. It had an ARM920T CPU at 104 MHz.

However, while gaining support through GBA/PS1 ports (including the only English version of the JP-only Xanadu series until 2016) and a few original exclusives, the thing suffered from huge design flaws, from the button layout to the display and cell phone functionality.

The first known Nokia N-Gage emulator (with high-level emulation), although it is currently on hiatus due to a lack of information required to further development. Linux support is planned for the future.

A freeware solution developed by In-Fusio (French) around 2000. The company re-developed the ExEn V2 engine in 2002, which further improved the speed and expressiveness of mobile. It was first a Java-based game engine entirely dedicated to mobile devices itself as an alternative to the limitations of J2ME"s game development (offering missing feautures like sprite zooming, parallax scrolling, rotations).

The API is based on Java and is very similar to J2ME, but is optimized for game development and deployment instead. Even the programming style is almost the same. Its significance is very similar to the Mophun platform. The ExEn API has various gaming specific classes that are absent from J2ME. ExEn was the first mass market downloadable game engine to be made available in Europe. It achieved relative success and widespread hardware support in Europe, and was also used in China. It"s not as widely distributed though, and according to In-Fusio"s website, it isn"t available on Nokia, Sony Ericsson, Samsung or Motorola handsets.

Palm launched webOS, then called Palm webOS, in January 2009 as the successor to Palm OS. The first webOS device was the original Palm Pre, released by Sprint in June 2009. In April 2010, HP acquired Palm.

Being the turnkey solutions firm that they are known for, as their chips are used on millions and millions of el-cheapo "Shanzhai" devices all over the world (especially counterfeit Nokias and Goophones among other things), Mediatek has also come up with their own mobile platform and API known as the Mediatek Runtime Environment, aka MAUI. It is targeted for so-called "smart" feature phones, i.e. those that offer similar functionality to standard mobile operating systems like Android, but are watered down for entry-level users. Games and applications for this platform are in .VXP format and other applications appear to be available on the usual WAP sites.

An official emulator, designed for development and demos. As such, encrypted or compressed games do not boot. However, this has been worked around, both by decrypting the files and decompressing them (except for compressed resources), and modifying the emulator to perform decryption on the fly, albeit only when opening them via the Open menu. Exile is not known to work in any found version of the emulator.

A new, open source emulator by Luca91. It is only a proof of concept, as only a few opcodes and a couple of SDK APIs are emulated, and there is no heap. There is sprite and input support, as well as support for the collision API. It is compatible with a few small homebrews. Luca91 mentions the SDK API handler needs to be better organized.

The official website for the platform, mophun.com, used to host development demos playable in the browser using the ActiveX platform (crawled demo files here). The mophun plugin itself can run unencrypted .mpn files. Although it is not playable through the web archives of the site, it is expected to be curated for Flashpoint.

Several Japanese-centric mobile game technologies spawned during the 2000"s as part of convoluted all-in-one technological solutions, mostly based on Java.

NTT DoCoMo released DoJa (later renamed to Star), based on Java ME CLDC, but not MIDP. Applications come in the form of .JAR files accompained by a .JAM descriptor.

KDDI released ezplus (later renamed to "EZ-appli (Java)"), based on Java ME extended with proprietary APIs. Applications come in the form of .KJX files. It was later replaced with a BREW-based solution called "EZ-appli (BREW)"

J-PHONE released J-SKY, based on standard J2ME MIDP extended with several proprietary 3D/sound/gfx APIs. It was later renamed to "Vodafone Live!" and "Yahoo! Keitai" as the company got purchased by Vodafone and SoftBank, respectively. Applications come in the form of .JAR and .JAD files.

Japanese mobile manufacturer NTT DoCoMo released DoJa (DoCoMo"s Java) as part of their i-mode set of standards for mobile telephony. It is based on Java ME CLDC, but not MIDP. The profile received several updates, being later renamed to "Star". It was used on DoCoMo"s mova and FOMA series of mobile phones, being first featured on the mova 503i from 2001.

While i-mode phones were made available in a limited fashion in Europe, the game apps weren"t exported, the i-mode specific features were mainly used for enhancing web pages for mobile browsers and even the Java API is the different more limited "Overseas Edition". The main reason behind this was the fierce push back by Nokia and other western mobile hardware manufacturers refusing to support the DoJa software standard until very late.

DeNa (Mobage), Namco (Tales of Mobile) and Level-5 (RoiD) set up Steam-like game distribution portals specific to some cell-phone models yet i-mode based. The different names are to confuse dirty gaijin, probably.

Official development kit from NTT DoCoMo, featuring a device emulator. Several releases were archived by Wayback Machine ::DoJa 1.5 DoJa 2.? DoJa 2.1 DoJa 3.0 DoJa 3.5 DoJa 4.0 DoJa 4.1 (111) DoJa 4.1 (201) DoJa 5.0 Star 2.0

Japanese carrier KDDI/Au released ezplus as part of their EZweb set of standards for mobile telephony. It is based on Java ME extended with proprietary APIs. The first device supporting it was released on 2001 (Hitachi C451H).

In 2006 an Open Application Player (Japanese: オープンアプリプレイヤー) feature was added allowing to run MIDP 2.0 Java apps on the BREW devices, which were often denominated as オープンアプリ. It lacks support for the original proprietary extensions of ezplus. On 2011, Open Application Player was updated and renamed to "EZ-appli (J)" along EZ-appli (BREW) which became "EZ-appli (B)"

Japanese service provider "J-PHONE" released the J-SKY platform as part of their set of standards for mobile telephony. It was based on J2ME and MIDP extended with several proprietary 3D/sound/gfx APIs called JSCL.

J-PHONE had been purchased by Vodafone on 2001, which two years later took over the original branding renaming the carrier to Vodafone KK. The J-SKY technology became then known as "Vodafone Live!" and it was extended with the VSCL set of APIs.

Applications were called "Java™ App" (Japanese : Java™アプリ) during the J-SKY era, "V-Appli" (Japanese : Vアプリ) during the Vodafone era and "S! Appli" (Japanese : S!アプリ) during the SoftBank era. They come in the form of .JAR accompained by a .JAD descriptor text file.

SKT provided two development platforms: GVM and SK-VM. GVM based on Mobile C, and SK-VM based on Java. SK-VM was a Java-based development platform, but the execution speed was slower than GVM due to the nature of Java. SK-VM is a J2ME (Java 2 Micro Eidtion) Java execution environment developed

Mobile platform created based on Mobile C (modified to fit the mobile environment, such as reduction of pointer and union functions in the existing C language) developed by Shinji Soft.

A mobile platform that eliminates the limitations of the existing GVM and further strengthens functions such as file system, network, and graphics. GNEX is an upgraded version of GVM, and has the advantage of having few capacity restrictions and fast speed, but its penetration has fallen significantly compared to GVM. Therefore, when releasing a GNEX version of a game, we developed both the GVM version and the GNEX version to support phones that do not support GNEX

KTF provided Qualcomm"s BREW. The biggest advantage is that it is based on C/C++, and unlike other development platforms, it is executed in the form of a native binary rather than being executed based on a VM. it is an integrated platform, but it has been divided into SKT-WIPI, KT-WIPI, and LGT-WIPI. For example, SKT-WIPI and LGT-WIPI supported C/C++, while KTF-WIPI supported only C. Aside from that, many other aspects differed from carrier to carrier.

A mobile platform that adds additional functions such as sound to J2ME (Java 2 Micro Edition) of LG MIDP JAVA SUN. LGT"s platform is sometimes called MIDP and JAVA

WIPI a national middleware platform standard in South Korea. Almost all cellphone games released in South Korea from 2002 to 2009 were developed as WIPI.

SKT (GNEX, SKVM), KTF (BREW), LGT (MIDP-JAVA), etc. are these, and they are currently converting to an integrated platform called WIPI. After conversion to an integrated platform called WIPI, mobile games have higher quality graphics and game ability than before.

MiniJ is a lightweight mobile platform developed by Hangzhou Sky Network Technology Co., Ltd. and it"s widespread in China (and in some other countries). It has excellent overall performance and could run applications and games smoothly with very limited hardware resources. MiniJ applications are written in C programming language.

A mobile development platform by Qualcomm, originally intended for CDMA handsets such as those sold by Verizon. Unlike Java ME, applications and games for BREW use native code as opposed to running in a virtual machine in the case of Java ME. Also, BREW development has a higher barrier to entry due to stringent certification requirements, which led it to be significantly less popular than Java ME even in markets where CDMA has a significant market share, such as in North America. To top it all off, downloaded BREW apps are tied to an individual handset via a digital signature, making piracy or sideloading difficult; it is however possible to unlock certain BREW-enabled CDMA phones to run backups and pirated apps, though downloads for BREW apps and games are rare and hard to find compared to Java ME.

Zeebo is a brazilian video game console and online distribution platform developed and released with developing markets in mind, also runs on BREW. Dumps of the Zeebo and its games exist, and gameplay footage of them have been uploaded on YouTube.

Developed by Danger Incorporated. Danger OS was a Java-based OS used on phones that Danger designed themselves. These devices were sold under many names such as Hiptop, Mobiflip, Sharp Jump, and (most notably) T-Mobile Sidekick. While it could run some J2ME apps (from version 2.3 onward), it also used its own proprietary J2SE-based APIs and SDK; for this reason, anything built using these APIs won"t run on a standard J2ME emulator. To aid third-party software design, Danger has released a comprehensive SDK that contains a Hiptop simulator, development installation utilities, and Danger API information.

Danger OS uses special files called "bundles". Bundle files have the extension .bndl. Bundles have inside a custom resource format for storing assets and code which is converted from Java bytecode into a custom bytecode format. Each bundle file is linked to a specific operating system version and build number. For example, a bundle file for v3.4/155053 (T-Mobile Sidekick 3) would be denied installation on a v3.3/149695 device (T-Mobile Sidekick iD). Installation of bundles require a developer key to be installed on your device if you are using a Production OS. Internal OS builds do not require developer keys.

Earlier black & white cellphone games (both in Japan and worldwide) didn"t get as much love either when it comes to emulation and preservation of game binaries. There were, however, recreations of Snake and Space Impact for Nokia phones on their website at one time, along with remakes of the aforementioned games for Android and iOS. There are several Nokia phone models with MAME support, though they are preliminary at best with most models displaying a "CONTACT SERVICE" error if not a white screen.

There however exists an SDK for the Nokia 3410, an enhanced variant of the infamous 3310 with a higher-resolution screen and support for MIDP applications. A fixed rip of the simulator can be downloaded on the Internet Archive, though it may have some issues especially on later Windows versions.

Released in 2000 by Microsoft as their first mobile OS, originally called "Pocket PC" and made to run on PDA"s, the name changed to Windows Mobile when the PDA market began to shrink. WM was initially based on Windows CE before evolving into something unique. It was mainly designed for business users, so it didn"t have a lot of games for it.

Bada (바다) is a mobile operating system developed by Samsung Electronics for devices such as mid- to high-end smartphones and tablet computers. The name is derived from "바다 (bada)", meaning "ocean" or "sea" in Korean. All phones running Bada were branded with the name Wave, unlike Samsung"s Android devices which are branded as Galaxy.

high level display screens in j2me made in china

This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.

high level display screens in j2me made in china

To write our first MIDlet we will use the J2ME Wireless Toolkit and the tools it provides. The most important tool is the KToolbar, from within the KToolbar you can create and manage your MIDlet projects. It has features to compile, package, run and even obfuscate your MIDlet.

Using the KToolbar to manage your MIDlet build process will enable you to quickly get into the development of your first MIDlet. You wont have to worry about doing all the compiling and packaging on the command line, but rather you can save this for later when you are comfortable with the environment. As your projects grow in size your needs for a tailored build process will increase and you will most probably need more control! (More on this in part 2)

In the first field, enter the name of your Project. The second field "MIDlet Class Name" is where you define the name of your MIDlets main class. This class will be the one that extends MIDlet and is instantiated by the AMS. The actual name you give it is not important, but it must be a valid Java Class name. For now lets call it Startup. The next window holds all the properties that must be present in your MIDlets Jad and Manifest file.

MIDlet-Jar-URL - The url to the Jar file of your MIDlet. (Typically just the filename of the jar file, this is more important in conjunction with delivery of the MIDlet via over the air downloads)

What happened now is that the KToolbar has created a directory structure for your project. KToolbar projects are placed in their own subdirectory in the "apps" folder which is located in the folder where you chose to install the WTK.

Ok, we have the project set up and are ready to go. In the "src" folder, create a file called Startup.java (case sensitive). This will be the source file for our MIDlets main class. The Startup Class will extend javax.microedition.midlet.MIDlet which has 3 abstract methods that need implementing. These are the all important methods that control the lifecycle of our MIDlets.

What the KToolbar does now is to compile your source code against the MIDP and CLDC APIs (and any libraries in the /lib folder of the currently selected emulator) into a folder called tmpclasses. The command it executes would be similar to (relative to project folder):

The next step the KToolbar takes is to preverify your java Classes and place them in the "classes" folder in your project. Class files must be preverified before they can be run on a MIDP device.

Now that your MIDlet is compiled and preverified you can run it by pressing "Run". As the only thing we are doing in our MIDlet is to print 2 strings to the console nothing will actually happen in the display of the emulator, but you should see the following in the WTK console:

This shows us that the Startup class was constructed through its default constructor and then startApp() was called. Not very exciting, but important for our MIDlet to start :)

Forms and Commands are high level UI components that come in handy for building menus and showing instructions in games. The Form class is a subclass of Displayable, this means that we can directly display it on the devices Display.

The devices current Displayable can be set by help from the Display class. To get a reference to a Display object for our MIDlet we call the static method getDisplay() on the Display class. The method takes one parameter which is a reference to an instance of our MIDlet class:

Now that we have the Form, lets add a Command so that we can get some high-level input from the user. Lets make a Command that allows the user to generate a random number and append it to the Form.

A Command is a component that triggers an action in our MIDlet. To capture the event triggered when the user activates the Command we need to use the CommandListener interface. The CommandListener interface defines one method that we must implement:

When the user triggers the Command, the implementation will call the commandAction method on the associated CommandListener. The CommandListener is set by the setCommandListener() method on the Displayable where the Command has been added.

The Command constructor takes 3 parameters, the String associated with the Command, the type of Command (indicates to the implementation what type of action this Command will perform, sometimes affects the positioning of the Command on the screen) and the Commands priority or display order if you wish. And add it to our Form (addCommand() is inherited from Displayable, so all Displayables can have Commands):

This was a brief introduction to the High-level components of the MIDP API. They provide a generic portable way of displaying information and getting high-level user input. Next is where the heart of your game will take place, so get ready to paint() that Canvas!

Maybe the most important thing in a game is being able to draw stuff to the screen, be it characters, items or backgrounds. To do this in MIDP we will be using the Canvas, Graphics and Image classes, these are the main classes you will be using for your low-level graphics handling.

The Canvas is an abstract class and we must therefore subclass it to be able to use it, lets make a new Class called GameScreen that extends Canvas. As we have seen before the Canvas class defines the abstract paint( Graphics g ) method, in our GameScreen class we will override this method which will allow us to draw to the Graphics object passed to the paint() method by the Virtual Machine.

Now we have the basics we need to draw to the screen, lets get things set up to receive key events from the user. The Canvas class defines 3 methods that handle key events, keyPressed(), keyReleased() and keyRepeated(). The canvas class has empty implementations of these methods, so it is up to us to override them and handle the events as we see fit.

As you see we have only implemented keyPressed() and keyReleased() not keyRepeated(). You should try not to rely on keyRepeated() events as the frequency of the calls to keyRepeated() varies a lot from device to device. And using the behaviour keyRepeated() provides us is not the optimal way to check whether the user has held the key down or not.

Ok so we are now ready to receive input and draw to the screen, before we go any further lets make sure we know how to get the Canvas we have made displayed on the screen. Remember the Startup class we made earlier? Lets change this class so that its sole purpose is to serve as an entry point to our game and create and display a new instance of our GameScreen class.

So now we are creating a new GameScreen and displaying it. Now we can try out some of the primitive drawing methods available from the Graphics class.

By setting the colour via setColor( int rgbColor ) we will affect all subsequent rendering operations to this Graphics context. Hence our call to fillRect( x, y, width, height ) will draw a filled rectangle in our desired colour. This also introduces 2 quite important methods of the Canvas class, getWidth() and getHeight() you will use these methods to obtain the total available for you to draw to on the Canvas. These are important values when targeting multiple devices with varying screen sizes. Always obtain the values via getWidth() and getHeight() don"t be tempted to hardcode the values as you will create a lot of extra work for yourself when you want to port your game. Try to make all your draws to the screen (where possible) relative to the width and height of the Canvas.

Just to get the hang of handling key events lets make the colour of our filled rectangle change when the user presses a key. For fun we can make the rectangle red when the user presses the LEFT key, green when for RIGHT, black for UP, white for DOWN and blue for FIRE.

As you might have noticed, a key pressed event is represented by a int value reflecting the key code of the key the user pressed. This key code can be treated in 2 separate ways, either via its actual value (KEY_NUM0 to KEY_NUM9, KEY_STAR or KEY_POUND which make up a standard telephone keypad) or its game action value (UP, DOWN, LEFT, RIGHT, FIRE, GAME_A, GAME_B,GAME_C,GAME_D). Why have 2 approaches you ask? As there are so many different keypad layouts and configuration, using the game action value of a key code will allow us to identify keys by their game action in a portable fashion. To retrieve the game action mapped to a key code we use the getGameAction( int keyCode ) method of the Canvas class.

If you look at the last line of the keyPressed() method you will see a call to repaint(). This schedules a repaint of the Canvas. Normally we would not do this from within the keyPressed() method, but at the end of our game loop. So now is a good time to get that main game loop going!

The Thread class will be used to spawn our game thread so we can use this for our main loop. Threads can be created in 2 different ways. Either by subclassing Thread and overriding the run() method of the Thread class. But as mutliple inheritance is not possible in Java (our GameScreen class is already extending Canvas) we will use the second approach which is to implement the Runnable interface and implement the run() method of that interface. This means we can spawn a new Thread by passing the instance of our GameScreen class (which implements Runnable) to the Threads constructor.

We want our main loop to be called at a fixed rate, for this example lets set the rate to 15 times per second. (Although it is impossible to give an exact performance figure that will apply to all games, 15fps is a reasonably indicative average to start off with)

To test our main loop lets make it change the colour of the background to a random colour every frame. We can use this opportunity to move the repaint() call to within our game loop.

Images in MIDP are very easy to create. The easiest way is to call the static method of the Image class, createImage( String name ). The String passed to the method is the location of the image within the MIDlets jar file. So the first thing we need to to is make a image to use in our game. Generic MIDP only supports PNG images. When using the KToolbar to build our projects, all we need to to is place the image file in the "res" folder of our project. Create a image and called "sprite.png" and put it in the res folder. Normally you should keep your images files as small as possible, there are several tricks, the obvious ones are to save them as indexed mode PNGs. To gain an extra few bytes you can optimise them with for example XAT image optimiser or pngcrush, these tools on average save you 30% of your original image size! Note: for transparency to work in the default WTK emulators your files must be saved as 24bit pngs, this is not true for most of the actual devices or device specific emulators.

There you go, image created. Images take time to create and require a lot of runtime memory, so keep your image creation within controlled areas of your game. Actual memory usage varies between implementations, bear in mind graphic modes are not palette based, a typical implementation will use 2 bytes of memory per pixel.

The Graphics.TOP | Graphics.LEFT parameter is called an anchor. This defines how the Image should be drawn relative to the x and y coordinates. The Graphics.TOP constant causes the TOP of the image to be at the y coordinate, and the Graphics.LEFT constant causes the LEFT of the image to be at the x coordinate. So if you wanted to draw an image at the center of the screen, the quickest way to do it is to set the anchor to the vertical and horizontal center of the Image:

To avoid flickering when drawing to the screen we will need to use well known double buffering techniques, where everything is rendered to an off screen buffer then later drawn to the visible screen. Some implementations will actually do the double buffering for us! Whether a device does so or not can be queried at runtime via the isDoubleBuffered() method on the Canvas. The advantage of not having to do the double buffering yourself is that it saves us the runtime memory needed to store the off screen buffer. We can easily write our code to automatically check and cater for devices that need us to implement double buffering ourselves.

We create a new empty Image by calling Image.createImage( width, height ). The Image should be the exact same size as the Canvas"s viewable area. In MIDP there are Mutable and Immutable Images. The difference being that Immutable Images, the ones created from image files/data, cannot be modified once created. A mutable Image, normally created through Image.createImage( width, height) can be modified by obtaining a Graphics context that will render to the Image itself. This is done by calling getGraphics() on the Image. This is what we have done for our back buffer!

This might be a little confusing at first, at the top of the paint() method we keep a reference to the original Graphics context that was passed as a parameter to the method. We then check whether we need to perform the double buffering, if so we change the Graphics context that the g variable references to the Graphics context obtained from the buffer Image. At the end of the paint method we again check if we needed to perform the double buffering, and draw the buffer Image to the original Graphics context we kept earlier.

That sums up the first part of the article, you should now be equipped with the tools and knowledge you need to make your first MIDP game. You know how to display and capture high level information, you can create and draw to a Canvas, you can even set up a game loop and handle key events, so now it is all up to you and your imagination!

The next part of the article will among other things focus on specific devices and their APIs, optimising the size of your MIDlet and look into ways you can more easily target multiple devices.

high level display screens in j2me made in china

Binary Runtime Environment for Wireless (Brew MP, Brew, Qualcomm BREW, or BREW) is an application development platform created by Qualcomm, originally for code division multiple access (CDMA) mobile phones, featuring third-party applications such as mobile games. It is offered in some feature phones (mostly with specifications similar to those of mid to high-end mobile phones) but not in smartphones. First developed in 1999, as a platform for wireless applications on CDMA-based mobile phones, it debuted in September 2001.

As a software platform that can download and run small programs for playing games, sending messages, and sharing photos, the main advantage of Brew MP is that the application developers can easily port their applications among all Brew MP devices by providing a standardized set of application programming interfaces. Software for Brew MP enabled handsets can be developed in C or C++ using the freely downloadable Brew MP software development kit (SDK).runtime library is part of the wireless device on-chip firmware or operating system to allow programmers to develop applications without needing to code for system interface or understand wireless applications. BREW is described as a pseudo operating system, but not a true mobile operating system. BREW is not a virtual machine such as Java ME, but it runs

high level display screens in j2me made in china

You Might Also Be Interested In