Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4
  ignore  |  Print  
  Defection To Mono  (Read 12691 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2005-01-25 15:16:19 »

Ok, fine, I can see how this discussion's going to go, consider the matter closed...

Cas Smiley

Offline dranonymous

Junior Member




Hoping to become a Java Titan someday!


« Reply #31 - Posted 2005-01-25 15:28:48 »

My quick 2 cents -

- End users don't care how cool languages are, tool sets, or anything else about development.

- Users do care about how easy it is to install and use software.

Based on the above, use the language and tools which you are most productive in and can most easily support.

Since I want to try and sell my current children's game (still unfinished, sigh) I am facing the problem of deployment as well.  Especially, since I want to ensure an easy process for all 3 platforms.  

I'm not really concerned with the same issues you are princec.  From my view, though, I don't see Mono or .Net solving all your issues.  It just distributes the aggravation differently than where it is in Java Land.

Regards,
Dr. A>
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #32 - Posted 2005-01-25 15:35:22 »

Before you close this Cas, I do have to wonder, did you talk to your customers about what their biggest issue was? As someone who's run an online business before, I've found that you can sell just about anything, but you have to make it attractive enough. The majority of people will NEVER purchase something cold. If they make a purchase, it's because the advertising and marketing campaigns have convinced them over time, or they received a recommendation by word of mouth.

Whoever said "build it and they will come" should be shot. :-/

Quote
However, I think Mono has gotten to the point where it might actually be the solution to all my Java problems, and there's an irony.


Have you tried Kaffe? I'm willing to bet that most of what you like about Mono is there as well. It just gets less press. (Primarily because the project was originally started for all the wrong reasons. :-()

Quote
Not officially allowed to ship tweaked VMs embedded into my products. Looking at the Sun license this is actually a bit of a grey area but the fact is it's not endorsed and my efforts to get permission to do this have been faced variously with silence, ridicule, vague promises to contact someone about it, or hostility. Why do I need to do this anyway? Because Webstart is shit for my customers - period - and I won't here another word said about the subject by anyone not in my position. Talk to the hand, baby.


Kaffe. You can't call it Java, but it should work fine.

Quote
Proper generics, delegates, etc. and a host of other C# niceness. C# has some very, very cool language. It's as if a magic fairy got fed up with all the annoying bits in Java and fixed them. And then released the language to a standards body!


Umm... okay. If you say so. *shrug*

Quote
Easy compilation down to native code. .net was designed to allow this kind of thing. Sure I'll lose 10% performance. But as the Java freaks in here are so happy to point out, who cares when I'm not using anywhere near 100% CPU even on weedy machines?


Whatever happened to your JET experiments? You used to distribute Alien Flux as an EXE, and went on and on about how wonderful JET was. Why the sudden change?

Quote
Easy integration with native libraries. Imagine just how easy LWMGL would be to code when 90% of the glue needn't be written, as Mono can call GL directly for most of its calls.


As others have said, LWJGL is done. There's no need to be concerned about it. JOGL took a different tack and simply auto-generated the glue (smart, very smart). There are also a variety of products out there that can give you very similar results to Mono via their custom loaders.

Quote
The extreme mismanagement of all things Sun. Endless meetings to discuss minutiea of GL bindings, for chrissakes! A blithering CEO without a clue!! The ever-mysterious GTG who've been on the case for well over a year now with nothing to actually show for it!!! Where's my million bucks guys? Do you want to showcase Java or just let it all happen by accident? See the pioneer over there? He's the guy with the arrow in his back! It ain't gonna happen without proper money!


No comment.

Quote
Consoles. I'll not be getting Java on any console, ever, in a capacity that I can use. Mono on the other hand might as well just be a nice portable DLL. Perfect.


Right. Did you know that none of the big 3 consoles supports OpenGL? There are (expensive!) third party extensions for all of them, but none come with OpenGL as part of the core. In fact, these consoles go out of their way to avoid it to encourage developers to write for their extra technology.

BTW: Kaffe. GCJ. Have you investigated any of those options? What was your findings?

Quote
Besides, using monkeys for a mascot how could they go wrong?


They wrote that POS known as GNOME, didn't they? (Sorry, just had to get my crack at GNOME in there.) ;-)

Java Game Console Project
Last Journal Entry: 12/17/04
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2005-01-25 17:12:26 »

Ah, Jerry's being constructive. So:

Kaffe I have yet to investigate but the last time I looked - not too long ago - its performance was just about the worst there was. While it could cope with Puppytron I'm not so sure about some of my more ambitious ideas. As I type 1.1.4 Kaffe is being downloaded and I will no doubt have lovely time attempting to compile it for Win32. Probably more time than I can be bothered with.

GCJ is like Jet, except crap.

Jet is brilliant. In fact I'm still perfectly happy with Jet except it adds another extremely fiddly step to the build / test / release cycle. This fiddliness cost me days of time when I did 'Flux and frankly one of the main reasons I like Java and managed environments is the speed and ease of development and deployment. Were I working for a "real" games company writing big titles I'd have no hesitation in determining that Jet would solve our problems (ha, well, now LWJGL is here anyway).

I hate Gnome too btw Smiley In fact I've yet to like any aspect of Linux apart from the "free" one, haha!

Some people in the thread here seem to be making an assumption that I've got a problem with sales or my games or distribution. I've got no problem with sales, and people do appear to like my games really, as they convert well enough. I do have a problem with exposure, largely down to my inactivity in this area, and I do have a problem with distribution. Currently I ship what can best be described as an embedded VM in all of my games for Windows, and there's the problem: I'm not technically supposed to do this, but having begged to get a license sorted and been stonewalled on it I thought I'd just go ahead and do it anyway because it's more convenient for me than dusting off Jet and all of its hassles.

That's what instigated the thread in fact. Still not quite legal. I basically am unable to evangelise Java further than this forum because there is no other realistic way to distribute small Java games to the great unwashed apart from Jet and the cost and hassle of doing so completely outweighs the benefits of using Java for everybody else.

Cas Smiley

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #34 - Posted 2005-01-25 17:59:05 »

Quote
Kaffe I have yet to investigate but the last time I looked - not too long ago - its performance was just about the worst there was. While it could cope with Puppytron I'm not so sure about some of my more ambitious ideas.


As long as the JNI interface works, and the NIO/ByteBuffer stuff functions like it's supposed to, I see little reason why all your current games wouldn't function. Removing the JIT does slow things down, but not THAT much. You can count on a minimum of 500MHz for the main processor! When you consider that 95% of the work is being shunted to the vector processor, your games should run just fine on even the worst processors! :-)

Quote
As I type 1.1.4 Kaffe is being downloaded and I will no doubt have lovely time attempting to compile it for Win32. Probably more time than I can be bothered with.


Perhaps. My personal opinion is that you should distribute an EXE for Windows. The EXE would check the machine for a JVM of the correct version (or higher) and warn the user if they don't have a JVM. In the case that they don't, then the program should redirect them to the download page on java.com. Since most people would have already downloaded your game (and they have no idea how long the Java download will take ;-)), they will happily sit through the "Required Plugin" installation.

For Linux, make the lazy bums install a JVM themselves. For Mac OS X... there is no step 3. ;-)

Quote
GCJ is like Jet, except crap.


True. But GCJ does something that Jet can't: Compile to the XBOX or Playstation. Granted, I've never tried it, but it's something worth pursuing.

Same with Kaffe. It's already ported to the Japanese PS2. If you can get developer access to these consoles, you may be able to get some help in porting it to XBOX and American PS2. In the case of the XBOX, it may just compile. :-)

Quote
Jet is brilliant. In fact I'm still perfectly happy with Jet except it adds another extremely fiddly step to the build / test / release cycle. This fiddliness cost me days of time when I did 'Flux and frankly one of the main reasons I like Java and managed environments is the speed and ease of development and deployment. Were I working for a "real" games company writing big titles I'd have no hesitation in determining that Jet would solve our problems (ha, well, now LWJGL is here anyway).


I'm sure they're glad to hear that you're still a satisfied customer. :-) So why did you take down the EXE for Alien Flux? Wasn't that one already tested and ready to go? Or did you decide to ditch it in a later version of AF? Hmm... I think I answered my own question.


Quote
That's what instigated the thread in fact. Still not quite legal. I basically am unable to evangelise Java further than this forum because there is no other realistic way to distribute small Java games to the great unwashed apart from Jet and the cost and hassle of doing so completely outweighs the benefits of using Java for everybody else.


Not sure I would take the same step as you have. Most customers I've seen have been quite happy with the EXE Launcher concept. To each their own, though.

Quote
Ah, Jerry's being constructive.


Actually, I'm his son. Jerry's Son -> Jerason. ;-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #35 - Posted 2005-01-25 19:15:58 »

Wink

Actually Jet's perfectly capable of running on Xbox. You can simply create a big DLL and call it from your Xbox exe stub.

Cas Smiley

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #36 - Posted 2005-01-25 19:23:30 »

Quote
;)Actually Jet's perfectly capable of running on Xbox. You can simply create a big DLL and call it from your Xbox exe stub.


Well, there you go! Now you can stop complaining about console support, you've already got it! (That is, right after you build some OpenGL wrappers for DirectX 81. ;-))

Java Game Console Project
Last Journal Entry: 12/17/04
Offline vrm

Junior Member




where I should sign ?


« Reply #37 - Posted 2005-01-25 19:31:35 »

BTW Tried SableVM ? It looks a bit better than Kaffe.

Cas : I'm looking at Mono too since 2 days and I'm quite impressed. It's far better than I thought. I really start to like Gtk#. And the interface to C is so easy I wonder how the performances compare to JNI.

BTW :  it's a Java forum no wonder why you got flamed Wink
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #38 - Posted 2005-01-25 20:41:16 »

Cas: Merry Christmas ;-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline abies

Senior Member





« Reply #39 - Posted 2005-01-25 23:27:43 »

Quote


As long as the JNI interface works, and the NIO/ByteBuffer stuff functions like it's supposed to, I see little reason why all your current games wouldn't function. Removing the JIT does slow things down, but not THAT much. You can count on a minimum of 500MHz for the main processor! When you consider that 95% of the work is being shunted to the vector processor, your games should run just fine on even the worst processors! :-)



To allow 95% of work to be done on GPU, rest 5% has to run fast. AFAIK, kaffe has next to none optimalization for ByteBuffers at the moment. From what I can see from quick browse of code, on EVERY get/put, bounds are checked, JNI method is called and inside this JNI method, another JNI method is called to get value of pointer field - only then it is dereferenced and returned to caller.

This can be easily hundreds times slower than HotSpot implementation. Even if 1 from 5 percent above is dependent on buffer speed, slowing buffer access 200 times would mean that CPU part will take 66% of time instead of 5% - slowing everything 3 times.

Of course, only way to be sure is to check this. But it is not just a problem of kaffe supporting nio. It is a problem of kaffe supporting DirectByteBuffer deep inside jit machine, optimizing it as much as possible. Two JNI calls per every float get/put is just not acceptable for anything even remotely real time - unless you transfer entire arrays at once. But Buffers are created to avoid working on java arrays...

Artur Biesiadowski
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nonnus29

Senior Member




Giving Java a second chance after ludumdare fiasco


« Reply #40 - Posted 2005-01-26 00:36:25 »

I'm still not clear on why c++ isn't an option.  Are you all just pathologically afraid of it or something?  You don't have to use all the weird language features.....
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #41 - Posted 2005-01-26 00:40:53 »

Quote
To allow 95% of work to be done on GPU, rest 5% has to run fast.


That's an interesting statement. One that also requires some qualification. If the 5% of the CPU code runs in less than 1/60 of a second, then it doesn't matter how slow Kaffe is.

Quote
AFAIK, kaffe has next to none optimalization for ByteBuffers at the moment. From what I can see from quick browse of code, on EVERY get/put, bounds are checked, JNI method is called and inside this JNI method, another JNI method is called to get value of pointer field - only then it is dereferenced and returned to caller.


I was looking at the same thing. The problem is that the Java code comes from the GNU Classpath project. It's up to the Kaffe VM to recognize ByteBuffers as a special circumstance where no bounds checks are needed. And I'm not about to dig through all of Kaffe looking for it. It would be much easier just to profile it. :-)

Even if the optimizations don't exist, it's probably not a big deal. Once the textures are committed to the GL Pipeline, then you only have to worry about shunting vertexes. If Cas used massive triangle fans, then I'd worry. But he doesn't, so the performance probably is not significantly different. The big thing is that the NIO support *exists*. Without it, LWJGL won't compile.

Quote
This can be easily hundreds times slower than HotSpot implementation. Even if 1 from 5 percent above is dependent on buffer speed, slowing buffer access 200 times would mean that CPU part will take 66% of time instead of 5% - slowing everything 3 times.


Ummm... 5% of program execution time != 5% of main CPU time. If his code executes at an effective 100MHz, then it's still faster than most of the previous generation consoles.  Remember, he's just doing 2D + some effects. Not exactly straining for more horsepower. (Of course, future efforts might. But then you need to profile!)

Quote
Of course, only way to be sure is to check this. But it is not just a problem of kaffe supporting nio. It is a problem of kaffe supporting DirectByteBuffer deep inside jit machine, optimizing it as much as possible. Two JNI calls per every float get/put is just not acceptable for anything even remotely real time - unless you transfer entire arrays at once. But Buffers are created to avoid working on java arrays...


Is there somewhere I'm missing something? From what I can see, he doesn't have any triangle fans or vertex arrays. In fact, he's probably using a set of vertex calls or glRect() calls. No ByteBuffers required. The only time he would need to worry is when he sends the textures to the card. Since that's a one time operation, any slowdown should be unnoticable.

Now with all that out of the way, let me mention that Kaffe does have a JIT compiler for certain platforms. So it's imperative that you profile the target platform to see if it will work for you. :-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2005-01-26 09:19:15 »

I don't want to use C++ because of all the problems it has. It's fiddly and complicated, even without using the sharp pointy bits. It always takes much longer to write anything nontrivial in it. I'm quite able to write in C++ obviously, I just abandoned it for a good reason, and that's safety, ease, stability and productivity.

The SciTech drivers are just an awesome bit of coolness. I tried them a few years ago and they were unstable as hell but if they can work on the XBox, then with Jet in tow, I've got a clear path to the console market! Result! I'll ask a couple of Xbox dev friends of mine about getting hold of the dev kit, because I reckon all my games would be great Xbox Live candidates.

Also - to get 60fps in Alien Flux I use about 500-600MHz flat out on a Hotspot 1.4 VM. Kaffe is at least 3x slower and I'm afraid that'd be completely unacceptable.

Cas Smiley

Offline abies

Senior Member





« Reply #43 - Posted 2005-01-26 10:03:03 »

Quote


Now with all that out of the way, let me mention that Kaffe does have a JIT compiler for certain platforms. So it's imperative that you profile the target platform to see if it will work for you. :-)


I know it has a jit. At the same time, I'm 95% sure that jit has not idea about ByteBuffers - I'm trying to keep a hand on kaffe development (even if only by browsing CVS commits/changelogs) and would probably notice something like this.

I agree with you, that for specific games Cas has, ByteBuffer performance is probably not critical. I have forgotten about context and started talking about more generic case, where you need to do some CLOD/skin/bone/etc on CPU - where buffer performance would be certainly a major issue.

Artur Biesiadowski
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #44 - Posted 2005-01-26 10:09:28 »

Run Alien Flux with -Xint -Xprof to get an idea of what Kaffe performance would be like and see where the bottlnecks lie...

Ah, and you'll be unhappy to discover that Flux rendering is extremely complex and very performance intensive.

<edit2>To save you the bother, on a 2GHz laptop with a Gf4Go in it, running maxed out I get 10fps:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
Flat profile of 398.68 secs (33440 total ticks): main

  Interpreted + native   Method                        
 13.1%  4363  +     0    com.shavenpuppy.jglib.algorithms.RadixSort.sort
  6.0%  2011  +     0    java.nio.Buffer.nextPutIndex
  3.6%  1217  +     0    com.shavenpuppy.jglib.sprites.SpriteRenderer.writeSpriteToBuffer
  3.2%  1063  +     0    com.shavenpuppy.jglib.algorithms.RadixSort.sort
  2.7%   909  +     0    xap.effects.WobblyPlaneEffect$WobblyPlaneEffectInstance.wibble
  2.1%   688  +     0    java.nio.DirectByteBuffer.put
  2.0%   673  +     0    com.shavenpuppy.jglib.geometry.Plane.distanceTo
  2.0%     0  +   659    sun.misc.Unsafe.putByte
  1.7%   560  +     0    com.shavenpuppy.jglib.resources.ColorSequenceResource.getColor
  1.7%   556  +     0    java.nio.DirectByteBuffer.ix
  1.7%   552  +     0    java.nio.DirectFloatBufferU.put
  1.6%   534  +     0    com.shavenpuppy.jglib.geometry.Box.classify
  1.6%   525  +     0    java.util.Arrays.fill
  1.5%     0  +   515    sun.misc.Unsafe.putFloat
  1.5%   505  +     0    java.nio.Buffer.position
  1.5%   487  +     0    java.nio.DirectFloatBufferU.ix
  1.4%   475  +     0    java.nio.Buffer.nextGetIndex
  1.3%   426  +     0    com.shavenpuppy.jglib.renderer.Renderer.sort
  1.3%   425  +     0    com.shavenpuppy.jglib.geometry.Plane.classify
  1.1%   362  +     0    com.shavenpuppy.jglib.renderer.Renderer.build
  1.0%   345  +     0    xap.effects.WobblyPlaneEffect$WobblyPlaneEffectInstance.wobble
  1.0%     0  +   325    org.lwjgl.opengl.Win32Display.swapBuffers
  0.9%   308  +     0    java.util.Arrays.fill
  0.9%   306  +     0    com.shavenpuppy.jglib.Image.mergePlanes
  0.9%   305  +     0    org.lwjgl.util.Color.setColor
100.0% 29023  +  4363    Total interpreted (including elided)

  Thread-local ticks:
  0.1%    46             Blocked (of total)
  0.0%     7             Class loader
  0.0%     1             Unknown: no last frame


Global summary of 398.68 seconds:
100.0% 33492             Received ticks
  0.1%    50             Received GC ticks
  0.0%     2             Other VM operations
  0.0%     7             Class loader
  0.0%     1             Unknown code

Notice that outside of radix sorting, the vast majority of the time is spent in shoving data into bytebuffers... 19% of CPU time in fact. The game code itself doesn't even get a look in Wink

Cas Smiley

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #45 - Posted 2005-01-26 10:27:23 »

*cough*
Troll.

Play Minecraft!
Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #46 - Posted 2005-01-26 14:22:40 »

Quote
Run Alien Flux with -Xint -Xprof to get an idea of what Kaffe performance would be like and see where the bottlnecks lie...


Actually, that may not be a very good indicator. Kaffe *does* have a JIT, so it should perform somewhat faster than -Xint.

Quote
Ah, and you'll be unhappy to discover that Flux rendering is extremely complex and very performance intensive. Notice that outside of radix sorting, the vast majority of the time is spent in shoving data into bytebuffers... 19% of CPU time in fact. The game code itself doesn't even get a look in Wink


1. What is the radix sorting code doing?
2. What in blazes are you doing that requires ByteBuffers in every frame?

Inquiring minds want to know! ;-)

Quote
<edit2>To save you the bother, on a 2GHz laptop with a Gf4Go in it, running maxed out I get 10fps:


I got similar results on my PIII 733. It wasn't that the game couldn't be playable at that speed, however, it would just need some tweaks to the movement rate per frame. :-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #47 - Posted 2005-01-26 16:05:38 »

The radix sorter is sorting primitives for rendering and sprites. Some of it is actually overkill but as it represents very little CPU work in the JITed version I left it alone.

The buffers are filled every frame with up to 4000 odd sprites and particles.

Cas Smiley

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #48 - Posted 2005-01-26 16:14:19 »

Quote
The radix sorter is sorting primitives for rendering and sprites. Some of it is actually overkill but as it represents very little CPU work in the JITed version I left it alone.


Hmmm... overkill indeed. I'm thinking a simple "render sprites in whatever order, then lasers, then render particles" would have sufficed. But maybe that's just me. ;-)

Quote
The buffers are filled every frame with up to 4000 odd sprites and particles.


I tried to download the source to see this, but the source code seems to have gone missing. In any case, I'm still wondering if that's really going to be a performance problem. If I get Kaffe compiled, I'll have to give it a try and see. :-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #49 - Posted 2005-01-26 17:30:24 »

'snot really overkill... there's a lot more going on than meets the eye. Sprites are first sorted by layer, then Y coordinate, then texture, then rendering style. And there are an awful lot of them.

Even the background goes through a triangle pumping engine that sorts all the triangles in order of rendering style and adjacency. That's the overkill bit, but there are very few triangles involved in the background relatively.

Cas Smiley

Offline William

Junior Member




No Exit


« Reply #50 - Posted 2005-01-26 19:49:49 »

Cas: Be sure to let us know if you get your games to run on an XBox with JET and that graphics driver package.

With all the three-letter companies recently releasing hundreds of patents to open source development, one can always hope that there is some truth to the rumors at Javalobby of one of the companies putting out an open source JVM, but I guess that's a very very long shot...

William
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #51 - Posted 2005-01-26 20:05:58 »

Emails have been sent, contacts have been made. I'm going to pursue this idea until I get a conclusion. Xbox live here we come!

Cas Smiley

Offline jbanes

JGO Coder


Projects: 1


"Java Games? Incredible! Mr. Incredible, that is!"


« Reply #52 - Posted 2005-01-26 20:10:28 »

Quote
Emails have been sent, contacts have been made. I'm going to pursue this idea until I get a conclusion. Xbox live here we come!


*grin* See what happens when you set your mind to something? ;-)

Java Game Console Project
Last Journal Entry: 12/17/04
Offline mhale

Senior Newbie




Take pity, I'm just a poor blob!


« Reply #53 - Posted 2005-01-27 01:06:19 »

There is another possible option: the IKVM project (http://www.ikvm.net/). It is a JVM for .Net and also includes a bytecode to .Net CIL compiler. So you might be able to have your cake and eat it.


Offline vrm

Junior Member




where I should sign ?


« Reply #54 - Posted 2005-01-27 05:56:50 »

played a little with Mono runtime sources, and it's very easy to make your custom runtime, removing useless craps like Windows.Forms and other useless stuff. It's  easy to cleaning it (as sorting crap out of rt.jar and rest) and the license allow it.

So you can prolly emmbed our own Mono runtime for ~5Mb. NOW WHAT SUN IS WAITING FOR LET US FORGE EMBEDED JRE ?
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #55 - Posted 2005-01-27 18:07:57 »

FWIW, I think for now distribution with an embedded VM is the best way, especially because almost none of my games work anymore on 1.5  Angry
I'm currently being flooded by emails from especially JEmu users that most games stopped working since they upgraded their JVM.

Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #56 - Posted 2005-01-27 20:27:51 »

Quote
FWIW, I think for now distribution with an embedded VM is the best way, especially because almost none of my games work anymore on 1.5  Angry
I'm currently being flooded by emails from especially JEmu users that most games stopped working since they upgraded their JVM.

What was incopatibile between these two versions? My programs worked without problems.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #57 - Posted 2005-01-27 20:49:14 »

I haven't checked with all my games (and sound lib) why they don't work anymore, but something definitely has changed with javasound, maybe input, and XML. I probably did something wrong with Cosmic Trip in the way I included the XML parser since the XML packages I included simply are not there anymore. With JEmu, I'm not sure why about 80% of the games just hang. I don't think it has anything to do with sound because also games with no sound stopped working (and btw sound already stopped working since 1.4.something). With JEmu2, there was a problem with sound initialization which I had to change to make it work again. With CottAGE, I'm not sure what's wrong. For some, input doesn't work anymore, for others sound doesn't work anymore, for some it stopped working at all. On my machine, it still kinda works except that it starts running really slow after a while.
I'm not sure why my SoftSynth lib doesn't work, probably a sound init issue too.

Fortunately, the programs I made for my job still work! (phew!)

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #58 - Posted 2005-01-28 11:24:07 »

How odd.  Fortunately my LWJGL code all still works fine under 1.5! Grin

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #59 - Posted 2005-01-28 14:44:21 »

Mine too.

Cas Smiley

Pages: 1 [2] 3 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (36 views)
2014-07-24 01:59:36

Riven (37 views)
2014-07-23 21:16:32

Riven (25 views)
2014-07-23 21:07:15

Riven (27 views)
2014-07-23 20:56:16

ctomni231 (57 views)
2014-07-18 06:55:21

Zero Volt (49 views)
2014-07-17 23:47:54

danieldean (39 views)
2014-07-17 23:41:23

MustardPeter (43 views)
2014-07-16 23:30:00

Cero (59 views)
2014-07-16 00:42:17

Riven (56 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!