[Jason Dunn]

Originally Posted by pocketfuncouk

Try this article for some interesting info on j2me and games.
http://www.gamasutra.com/resource_gu...917/fox_01.htm

Very good article to read for the Java Heroes...

For example, here are some big stumbling blocks:

No transparent images. Without transparency, overlapping sprites look really prickly. Any image that may overlap another image, or a background element will need to be rectangular in order to look good! 
You cannot grab, copy, or edit the pixels of RGB images on the fly. This means that ultra-cool graphic effects like fading in, explosions, and dynamic shadows are impossible.
There is no fill-polygon or fill-triangle method, which makes rendering 3D images quite difficult.
You cannot copy raw pixel data to the screen (blit). This makes is pretty much unfeasible to do any texture-mapping or particle effects, etc.
There is no audio at all. I'll say that again: There is no freakin' audio at all! 
There is no floating-point math. This makes some 3D and physics pretty difficult.
There is no native support or Java Native Interface (JNI). That means you can't dial the phone, work with any of the ringtones, work with any native user interface widgets, etc. 
Additionally, the Anfyteam in Italy has put together a detailed list of gaming and graphics-related stuff that MIDP is missing. 

Due to all the restrictions on a small device, there is no way of fitting in a just-in-time compiler (JIT). This means code will run quite slowly. In fact, while playing around with some casual tests, a Java 2 Micro Edition (J2ME) application runs about three to eight times slower than a native Palm application written in a compiled language such as C.

Does that really sound like a killer platform? :twisted:

[Jason Dunn]

Originally Posted by pocketfuncouk

Try this article for some interesting info on j2me and games.
http://www.gamasutra.com/resource_gu...917/fox_01.htm

Very good article to read for the Java Heroes...

For example, here are some big stumbling blocks:

No transparent images. Without transparency, overlapping sprites look really prickly. Any image that may overlap another image, or a background element will need to be rectangular in order to look good! 
You cannot grab, copy, or edit the pixels of RGB images on the fly. This means that ultra-cool graphic effects like fading in, explosions, and dynamic shadows are impossible.
There is no fill-polygon or fill-triangle method, which makes rendering 3D images quite difficult.
You cannot copy raw pixel data to the screen (blit). This makes is pretty much unfeasible to do any texture-mapping or particle effects, etc.
There is no audio at all. I'll say that again: There is no freakin' audio at all! 
There is no floating-point math. This makes some 3D and physics pretty difficult.
There is no native support or Java Native Interface (JNI). That means you can't dial the phone, work with any of the ringtones, work with any native user interface widgets, etc. 
Additionally, the Anfyteam in Italy has put together a detailed list of gaming and graphics-related stuff that MIDP is missing. 

Due to all the restrictions on a small device, there is no way of fitting in a just-in-time compiler (JIT). This means code will run quite slowly. In fact, while playing around with some casual tests, a Java 2 Micro Edition (J2ME) application runs about three to eight times slower than a native Palm application written in a compiled language such as C.

Does that really sound like a killer platform? :twisted:

[JohnnyFlash]

Sounds pants.... if you're a pimply faced kid who wants to play games. But professionals appreciate what positive things it can bring. :roll:

[SwitchBlade]

Jason can you code and if so have you lent your hand to grephics before. The "limitations" you list are the same in all progamming laguages unless you are a lamer and take someone else's api cos you are too lazy to work for your money. Transparency effects and so on are easy to produce using your brain and some code. Java implements things in strange ways, I know, but once you take time out to look through it's standard api and realise that all types are inheritors from the simple char it becomes easy to see how you can modify your types to your advantage.

Personally I have Java as a language, but then others swear by it and claim it to be the future. Time will tell, but till then I'll return to C/C++ and ASM. Anyone know where I can get ASM docs for the ARM9?

SwitchBlade

[entropy1980]

Again why as a developer if i am comfortable and have developed my own set of tools would i want to shift platforms? And using API's doesn't mean your lazy it's there to help and take some of the work out of basic functions having to be written over for every program, heck if you want to re-invent the wheel all the time be my guest while your writing code for stuff i have in an API I will get my product out faster and more integrated...

[SwitchBlade]

Re-inventing the wheel is a mad idea, and if the languages standard API supports a function you need use it (unless it's too slow). Many groups code their own libraries for graphics work, my old demo group on the x86 did it, not because we wanted to reinvent the wheel, but because we wanted one to our specs, that was the right size and rotated cleanly how we wanted it to.

SwitchBlade

[entropy1980]

that's fine and dandy but a majority of developers want API's (as shown by popularity of Windows and associated programming tools) being that windows is a consumer market and games a consumer market I think we see that the masses have spoken, I don't deny Java will have a huge installed base I don't see them doing much beyond that, it is not mainstream enough until you see a gaming platform ( i am talking console) or a OS that has huge market share use JAVA as a backbone i think it's relegated to nifty add-on but not the core of a system.

[SwitchBlade]

I dont see java becomming a mainstream games platform because of the speed of the virtual machine. Unless the machine ceases to be virtual and gains full hardware support it will carry on needing stupidly fast machines to perform what compiled code can do comfortable on a machine with half the spec. As for API's you can't claim that windoze has a good API, there are still API calls in there from windoze 3.1, and later API (such as the OO one) are just bolt ons on top of the earlier APIs, it's a mess. To see a real API look at BeOS, clean simple and functional. This is what is needed on a smartphone style device.

SwitchBlade

[entropy1980]

Well smartphone has a new API not based on past windows so your dealing with a clean slate here! ops: Just kidding! hehe

[bitbank]

Entropy,
You are not correct. The smartphone is Windows CE and is 99.9% the same as programming Pocket PCs which is 95% the same as programming for the desktop version of Windows.

Quite appealing to me since I have 12 years experience programming the Windows API.

L.B.

[entropy1980]

I stand corrected ops: there must be something missing to get it down to under 32mb in rom? No?