Sign in to follow this  
I Like Bread

[java] Carmack starts making Phone Doom

Recommended Posts

evolutional    1393
Quote:
Original post by I Like Bread
DISCUSS LIKE YOU'VE NEVER DISCUSSED BEFORE!


Or indeed, like we did yesterday. [wink]

I'm *not* going to close this though as I believe this thread could be about the discussion of the java-oriented aspects of Carmack's blog and not about Carmack himself (although this is up to Strife's descretion).

Share this post


Link to post
Share on other sites
I Like Bread    630
Yes, I saw that in the lounge right after I visited this board. *smack*

Anyway, I get the feeling that most Java developers are going to take this as a bright omen (especially those who take their cues from him). So what exactly do you guys think he meant by "3D space" on the phone?

Share this post


Link to post
Share on other sites
evelyn    938
It'll be interesting how the Doom rpg actually works and on what handsets it'll be eventually working on - testing on 4 probably means just the high-end ones at present...

Share this post


Link to post
Share on other sites
capn_midnight    1707
First and foremost, he's not saying anything new here. The issues he talks about should be readily apparent to most people from practically the beginning. Now, let's actually talk about those issues.

The security model and the java class stacks are the main problems, I believe. If there were a compile time switch "Turn Off Array Bounds Checking" or something, it would help a lot. I think when there is so little data that I can actually count it on my hands and feet, then it is my own responsibility to make sure I don't go out of bounds. We've done it for years in C/C++ in really large applications, we can do it now in really, really small ones, it's not that hard.

The class stack is also an issue. There is just too much going on. I've only just started to learn about CLDC and MIDP, and already I can see that "It's a really cut down version of the JVM" means "but it's not cut down enough." GBA code in C is simple and lightweight, "simple" java midlet code is not.

I do like how the components (displays, input devices, sound players, etc) are all really compartmentallized, and you only have to import them if you want to. Too bad it's still really slow.

From coding on the GBA, it seems "right". The device boundaries are small enough that you can manage memory in your head. The interface to everything is extremely simple, you are just copying values from here to there. I think that programming games for cell phones should follow the model of the GBA, and this could very well be possible if the JVM were cut down to just a unifying layer over the hardware. Don't give us any drawing primitives, I'll write that myself, just give me access to the frame buffer, give me access to the sound buffer, give me access to some basic input, and I'll figure it out from there.

Grand Unified Theories of Cross Platform Wireless Communication are pipe dreams. For gaming, I doubt you would ever write a cell phone game that would communicate with another, different game, so writing your own protocol on top of the simplest possible communication interface is wholely feasible.

Share this post


Link to post
Share on other sites
aidan_walsh    739
Doug Twilleager blames the bad implementations of Java on most mobiles, given that (he claims, I haven't yet looked to verify this) most mobile manufacturers are happy to still include interpreted Java, as opposed to JIT compilers or Java processors, as well as the massive differences between mobile models as well as families, not to mention vendors...

Basically, it seems that Java on a moblie just isn't standardised enough yet in spite of what is already there.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this