Jump to content
  • Advertisement
Sign in to follow this  
GCoda

[java] porting from ME MIDP 2.0 to SE ?

This topic is 4682 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I am new in java development and I just made my first MIDP applet that has couple of forms and custom Canvas which draws an image using a png file as resource. So nothing fancy or too complicated in that but my question is, what if I want to port my mobile game to PC (using java SE instead ME and MIDP, I assume) ? What 2D drawing classes are most close to MIDP 2.0 in SE? And what do you think of this solution for writing asbtract classes to ease the porting:

// not a complete example, just the basic idea

public class GameScreen
{
}

final class MobileGameCanvas extends Canvas, GameScreen {
 Image mImage; // Image would be used for images
 protected void paint(Graphics graph)
 {
 }
}

final class PCGameCanvas extends GameScreen {

}


Thank you, all tips are appreciated.

Share this post


Link to post
Share on other sites
Advertisement
Hey, wait dude. First things first!

If you intend to run mobile games in your pc, you must do so through emulators. The task of building code that is immediately portable between SE and ME is inviable. The reasons are obvious: different devices!

Java SE, Java EE and Java ME are different things. While Java EE sits on top of the basic Java SE API, the microedition is a complete different thing; it has its own JVM (KVM, in fact), it has its own set of APIs - yet it is possible to interact and communicate with the other layers, but not in the way you're imagining it - and it has restricted computational resources to expend.

In a few words, you either write a game for a PC, or for a mobile. The same bytecode won't work in both devices, unless you're using an emulator, but that's not what mentioned nor what you're trying to suggest with your post, I believe - or did I misunderstood you?

Sorry for the bad english, if I sound confuse. Someone who's native of an english-speaking country might give you a better answer ;)

Son Of Cain

Share this post


Link to post
Share on other sites
Hi

Quote:
Original post by Son of Cain
Hey, wait dude. First things first!

If you intend to run mobile games in your pc, you must do so through emulators. The task of building code that is immediately portable between SE and ME is inviable. The reasons are obvious: different devices!


Thanks but I know. :) I have made couple of test PIDlets and run them in the emulator and in my mobile.

Quote:
Original post by Son of Cain
Java SE, Java EE and Java ME are different things. While Java EE sits on top of the basic Java SE API, the microedition is a complete different thing; it has its own JVM (KVM, in fact), it has its own set of APIs - yet it is possible to interact and communicate with the other layers, but not in the way you're imagining it - and it has restricted computational resources to expend.


Ok, thank you for the information. This is understandable and I believe it's the same thing what the author of the book I'm reading was talking about.

Quote:
Original post by Son of Cain
In a few words, you either write a game for a PC, or for a mobile. The same bytecode won't work in both devices, unless you're using an emulator, but that's not what mentioned nor what you're trying to suggest with your post, I believe - or did I misunderstood you?


Well, I was planning to make a two versions of the game, mobile and PC. And what I'm trying to achieve is code reuseability. Since both versions will be coded in java I can reuse most of the code for sure but what comes to 2D drawing and user input I need an abstract code layer.


Quote:
Original post by Son of Cain
Sorry for the bad english, if I sound confuse. Someone who's native of an english-speaking country might give you a better answer ;)


No problem for me, my english is probably even worse. And thanks for the help. :)

Share this post


Link to post
Share on other sites
Some of the J2ME stuff is vaguely similar to AWT in its organization and event-handling model. For instance, the Graphics class looks somewhat like a simplified version of java.awt.Graphics.

You might want to consider coding up a set of mini-emulator classes. Chances are, it would take less time than porting the game itself. The only tricky part would be the event queue.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Some of the J2ME stuff is vaguely similar to AWT in its organization and event-handling model. For instance, the Graphics class looks somewhat like a simplified version of java.awt.Graphics.

You might want to consider coding up a set of mini-emulator classes. Chances are, it would take less time than porting the game itself. The only tricky part would be the event queue.


Thanks for the tips! I'll look into the AWT stuff.

Share this post


Link to post
Share on other sites
You will most certainly want to code a small framework of your own, to use with both the mobile and the PC versions of your game, with code to deal with your game entities in an abstract layer, then. I mean, instead of creating abstract representations of the drawing api for each device, create abstract code for your entities, and write the "drawing" code and other hardware dependent operations in the specific target device.

Son Of Cain

Share this post


Link to post
Share on other sites
This is why the .NET Compact Framework is superior to J2ME: It's a real subset of the full .NET API, with the exception of one or two extra classes. If one does not use those few classes, one can actually write programs that run on PDAs AND PCs from the same code (you have to compile different assemblies for each processor, though VS will handle that automatically).

Share this post


Link to post
Share on other sites
In my last place of work we made SE wrapper classes for all the MIDP classes, so that it was just a matter of recompiling with a different bootclasspath and the wrapper library in order to get the app as an applet instead of a MIDlet. It wasn't really hard, just a couple of days of grunt work. There is something similar (but I don't think it is as complete as what we did) publicly available: ME4SE.

shmoove

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!