- What build of GCJ are you using?- Are you trying to build anything that depends on AWT?- I wrote this when I got it to work: http://www.cokeandcode.com/node/422 but I wouldn't call it step by step instructions.

- What build of GCJ are you using?- Are you trying to build anything that depends on AWT?- I wrote this when I got it to work: http://www.cokeandcode.com/node/422 but I wouldn't call it step by step instructions.

Kev

I downloaded the latest stable one - but it's not just one package to download, is it? There are several, and I'm not sure which I need, which I don't, and which (if any) would actually hurt. If you could list exactly which packages/files I need, I'll download all of them and post the exact errors if I still get them.

Right now, I just want HelloWorld.java to compile - which just prints to System.out. Later I can see about what classes may and may not be included.

(Is this a good time to say I'm trying to decide between Java and Blitz Basic?)

to compile them into object files. Finally I linked them like any other program with:

1

gcj --main=<main-class-here> -Xlinker -ssubsystem -Xlinkerwindows *.o

I found I had to manually link in libgcj.a to make it work - but I think that was probably me being dumb. If you're getting errors when you try to compile - you could post them here if you like - might be able to help

You know, I'm almost frustrated enough to write Java off as a possible development language.

Almost sounds like you think thats going to be a problem for people here. If it doesn't work for you, thats ok, as long as your produce games - its all good like

If you do want to persevere - could you let us know

a) Whether you downloaded your GCJ for win32 from GNU or from that the thisiscool post I posted aboveb) What are the errors you get when you're trying to compile your appc) The source code you're trying to compile (your hello world example for instance)

Incidently, have you considered http://www.excelsior-usa.com/jet.html - its another java native compiler that might work better for you if you don't want to fight with the edge that is GCJ

Kev

PS. I've just discovered my HTTP POST code breaks under GCJ so its not just you

5. Deploy with native installer, bundle sneaky small VM inside gameComplexity: pretty fiddlyAdvantages: guaranteed to work, very small payload, easy to work withDisadvantages: Grey legal area. Ahem. Use any AWT at all and you might as well bundle the whole VM.

6. Compile natively with JetComplexity: pretty fiddlyAdvantages: can't use a lot of Java classes. Very high performance.Disadvantages: Expensive. Use any AWT at all and you might as well bundle the whole VM. Difficult to work with.

7. Compile natively with GCJComplexity: ultrafiddlyAdvantages: can't use a lot of Java classes. Use any AWT at all and you might as well bundle the whole VM.Disadvantages: Incredibly difficult to work out. Questionable performance. Gain versus pain ratio also questionable.

If you use ANY AWT code at all, you won't be able to use #5, #6, or #7 to any real advantage.

None of this applies to the Mac. And forget about Linux if you want to actually make more money than the hair replacement therapy it will cost you.

On windows you can silently install the VM without the user knowing, so comiling to native shouldn't be necessary. I agree it would really be good if Sun provided an installer for java apps that included the VM. As well as WebStart there needs to be a DiskStart!.

No matter what programming language you use, you're going to have to include some kind of code for the graphical user interface, music, loading images, etc. You could write your own, download free libraries, or just use what's included in the SDK. Whichever way you do it, you're going to have a large download. The only way you could ever have a small download is if you were doing a game that lacked alot of features and didn't include any 3rd party libraries or the SDK.

So you might as well just embed the JRE or have an installer script that downloads it only if it's needed. Install4J can do either, but it costs a bundle. There are other cheaper alternatives, but they cost money too. Embedding the JRE yourself is relatively easy and free, and I believe you can write a script with NSIS that downloads other files (such as the JRE) only if they need to be installed.

No matter what programming language you use, you're going to have to include some kind of code for the graphical user interface, music, loading images, etc. You could write your own, download free libraries, or just use what's included in the SDK. Whichever way you do it, you're going to have a large download. The only way you could ever have a small download is if you were doing a game that lacked alot of features and didn't include any 3rd party libraries or the SDK.

This doesn't make any sense - just because a game will include a whole bunch of libraries means it's ok to bundle a whole load more unnessisary ones in the form of the JRE? Size does not equal features or quality.

No matter what programming language you use, you're going to have to include some kind of code for the graphical user interface, music, loading images, etc. You could write your own, download free libraries, or just use what's included in the SDK. Whichever way you do it, you're going to have a large download. The only way you could ever have a small download is if you were doing a game that lacked alot of features and didn't include any 3rd party libraries or the SDK.

This doesn't make any sense - just because a game will include a whole bunch of libraries means it's ok to bundle a whole load more unnessisary ones in the form of the JRE? Size does not equal features or quality.

What I was saying is that you're going to have to have some sort of libraries anyways (even if you write them yourself). Maybe you could get by with a 10 MB library instead of a 17 MB JRE. But you're going to have to have something. In my opinion, the JRE is a good a bet. It has alot of what you need, and it isn't so terribly huge.

To make a game that's a small download, you would almost certainly have to sacrifice some features or quality. Features/quality, Size, and Speed are all "partially" exclusive. You might be able to write a really fast program that uses lots of RAM instead of a really slow program that uses little RAM. Similarly, you might be able to create a better game by increasing its size (e.g. adding artwork to a game will increase its size but will generally improve the quality of the game by making the characters in the game actually look different).

It's also possible that you might be able to change your program in such a way that it's both faster and uses less RAM. Similarly, it's possible that you might be able to change you game in such a way that it becomes both smaller and higher quality. Dropping the JRE will reduce the size of the game, but a game without the features provided by the JRE will generally be lower quality than a game that has them.

To me thats an important saving - though the game isn't released yet so I can't be sure its important to the end user. The straight GCJ was huge (i.e. it included everything that the JRE might provide). However, my game like many doesn't you half the stuff in the JRE - so stripping/UPX my executable removed that stuff. The JRE is great - it has lots of useful features - but once my game is written I know the set of features I'm in need of deploying - why deploy more than I need?

It'd like deploying a library to play OGG files if I only use WAVs - only on a bigger scale. Infact, its like deploying a bunch of stuff to do LDAP queries when I don't use a directory server of any sort - alot like it

10mb is a lot. With about 2mb (of library code) you can cover everything you need in a small game. Those 2mb would for example contain stuff like a few util/io/nio/net/lang classes, lwjgl, jorbis, ibxm, some small framwork thing for getting things faster done... and well thats about it.

I mean... yea sure we all love the JRE and all of its very useful and nicely documented classes, but that doesnt mean that we like shipping em if they dont serve any purpose.

Dropping the JRE will reduce the size of the game, but a game without the features provided by the JRE will generally be lower quality than a game that has them.

OMG! I don't use Java2D, my game must obviously be inferior to one that does, because it's using more features of the JRE than mine!

Again, size does not equal quality. Most of the JRE is highly flexible and generic, large portions of it are obviously focused towards "normal" applications (eg. Swing) which can be wholely unsuitable for games. It's also very broad, with whole libraries that you just don't need or care about. The end result being that if I'm bundling an (unmodified) JRE I'm shipping a whole load of code that is sitting there idle. Thats hardly a good use of bandwidth. Much better would be to use the space saved for more resources - more animation, more sounds, etc. then my game would be of better quality.

UM two things. I thiught there was actually a way to install webstart with a pre-loaded cache.

There is no such thing. This was a recent topic in the JOGL forum and Ken Russell asked the the deployment team whether it was possible with WebStart and they said it couldn't be done. You need to use *.bat scripts etc .

Sun has totally missed the boat with Web Start... When they first announced it, I thought it would be great.. but they don't have a clue what they are doing with respect to Web Start. In many cases Web Start simply can't do what the developers and users want. It's basically a slightly fancy Applet launcher and nothing more. And worse, Sun thinks that's all Web Start should be.

OMG! I don't use Java2D, my game must obviously be inferior to one that does, because it's using more features of the JRE than mine!

Again, size does not equal quality. Most of the JRE is highly flexible and generic, large portions of it are obviously focused towards "normal" applications (eg. Swing) which can be wholely unsuitable for games. It's also very broad, with whole libraries that you just don't need or care about. The end result being that if I'm bundling an (unmodified) JRE I'm shipping a whole load of code that is sitting there idle. Thats hardly a good use of bandwidth. Much better would be to use the space saved for more resources - more animation, more sounds, etc. then my game would be of better quality.

<flamebait>Are you an enterprise developer perchance? </flamebait>

Several people have said similar things, so I'll just make one final reply to this (before hijacking this thread any further).

I'm not saying that any particular game is better (or worse) than any other particular game. I'm not saying that a large game is automatically better than a small one. I don't mean that the JRE is the only option or that it's superior to everything else. If you use some alternative to Java2D (or any other Java library) that does the same thing, it won't make much difference. But then you still have some kind of library.

I don't understand the objections to my comments about small game size and game fun being competing attributes. They just are. I didn't make it that way - it's just a fact. It's possible to make a 200 GB game that sucks so much that it's worse than a 1 MB game, but there is a correlation between the size of a game and how fun it is.

If you made a "game" that just writes the words "You win" to the console, would anyone play it? That is a game without features. By adding a feature (e.g. gameplay), you could make the game a million times better. If the size of a game doesn't make any difference to how fun it is, then why isn't every game 1 KB or less?

A program (of any kind) that has more features will generally be better. If you make a game with no sound, it could still be fun. However, it would probably be somewhat more enjoyable if it had sound. In some games, this would not be the case. You could go to the extremes and make a text-based game, which could be a very small download. It could be a fun game, but, generally, games with graphics are more fun than text-based games. Even so, there's nothing wrong with text-based games (in fact, I'm considering making one myself).

Let's look at non-game applications too. Think about Microsoft Notepad. You can type text, open and load files, etc. It works fine, and it's small. Then you have Microsoft Wordpad. You have underlining and so forth, as well as additional file types. Presumably, it's larger. The additional size is because of the code added to make it better. If someone could have written Microsoft Wordpad in such a way that it's smaller than Microsoft Notepad, then they could have written Microsoft Notepad in such a way that it would be even smaller than that. And, then, of course, there's Microsoft Word and Microsoft Publisher, which have WAY more capabilities.

Even so, I'd rather stick with Textpad, a shareware program that is somewhat like Microsoft Notepad but has a better layout than any of those other text editors. It's not the largest, but it's the one that has the particular features that I need.

But, you're right, there's no point in shipping a 17 MB JRE if you're only going to use 5 MB of it and have some easy alternative. The game I'm working on right now has 2d graphics, Swing components (yes, even though they're "unsuitable" for games), and will have music and sound effects as soon as I can secure sound resources. Additionally, I plan to add networking support for downloading updates to the game (primarily just so that I can use the same code for future games). I need alot of the JRE, so I might as well use it. I don't need things like AWT Components (the ones that aren't used by Swing anyways), database access, and xml processing. But I can't use GCJ because it doesn't work with Swing. And I don't want to shell out hundreds of dollars for a Java to .exe compiler when I'm making a freeware game. So I'm going to have to include the JRE (though I plan to make it only be downloaded as needed). I can leave out a couple of files, but the license doesn't allow any more than that.

And, no, I'm not an enterprise developer. But the only thing in Enterprise Edition that I want to use is servlets (for my website, not for games). Again, if I were saying that bigger is absolutely better no matter what, I would use C# with its ridiculous 384 MB SDK.

There's only so many options for distributing games written in Java. How do you distribute games written in Java if you don't distribute the JRE in some way? Just hoping that the JRE is installed is unacceptable to me (meaning that Java Webstart is out). Compiling to a .exe doesn't seem to be worth paying alot of money for, and I can't use GCJ for Swing. What else is there? I can bundle the JRE or download it seperately. Barring compilation to .exe and blind faith that random people can figure out how to run a Java program, those are my only options.

but there is a correlation between the size of a game and how fun it is.

Ne'er a more misinformed and untrue statement has been made on these boards! For shame The rest of the argument is based in this entirely incorrect premise. Trust us! It's wrong.

However there is a strong correlation between game size and the number of downloads you get. The smaller it is, the more downloads you get, and if you're trying to make a bit of cash, that makes all the difference.

It's a bit depressing to see a newbie here facing the same crappy problems I faced years ago before I decided to cheat.But in any case:

Build your game first. If you want to deploy it you have 6 options, all of which have advantages and disadvantages. In order of increasing hassle and pain:Cas

Thanks for detailing those options. I read somewhere that we will soon be able to test if/what version of VM is installed on a computer using javascript, I think I read it on Stanley Ho's blog, of Sun's deployment team. This should make it easier to figure out what to offer the user since you can just offer WebStart if they have a VM, but an exe otherwise. This should make it easier to deploy a small download package, but harder since we'll have to mess around with javascript.

6. Compile natively with JetComplexity: pretty fiddlyAdvantages: can't use a lot of Java classes. Very high performance.Disadvantages: Expensive. Use any AWT at all and you might as well bundle the whole VM. Difficult to work with.

The new Excelsior JET 4.5 challenges disadvantages 2 and 3 to a considerable extent and we have a special deal for Java game authors - check my announcement in the Tools forum

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