Gundam

I really have to wonder how much Linux experience you have if this is your example.

Not that I’m defending Linux. After using Linux exclusively for 3+ years I gave up and now use Windows 99% of the time (and question everyday why I ever bought a PC in the first place :slight_smile: )

But really, Linux isn’t nearly that bad. All in all, the Linux community has done wonders with what they’ve got to work with.

[quote]I really have to wonder how much Linux experience you have if this is your example.
[/quote]
Well I’ve tried it 3 times for months at a time… it was very frustrating so I just gave up all three times. I still have a machine that boots into linux for testing Java apps, but I don’t use it. (The display resolution is too low :), and it locks up every 24 hours from what appears to be a memory leak in the SCSI drivers.)

I noticed you didn’t have a solution to changing the desktop resolution… let me guess… pull out VI search for some X11 config file, guess at values to put in some tables buried within, pray that your monitor can still sync when you restart X…

–edit-- I see the latest RedHat does have a GUI for this. When you choose to launch this program there is no feedback for about 10 seconds and you wonder if it is going to run or not. Then after changing the resolution it basically tells you that it has edited your XF86Config file for you and you will have to log out and restart the X server for the changes to take effect… Logging out is not enough though… it seems that doesn’t actually restart the X Server although it it looks like it might because the display goes black and comes back. Seems a reboot is required. Hmm. just tried that too… nope, no change, apparently the display resolution GUI is some cruel joke… it still has a long way to go.

Another example: configuring Samba… I spent hours on a linux help irc channel with someone helping me configure that… end result was that the linux expert gave up and blamed Red Hat. Oh, and the procedure - straight to the text files again - no UI, no showing a list of what is on the LAN so I can simply pick the machine to connect too. Just hours of fiddling with text files to no avail.

I can only speak from my months of experience… it is pretty darn frustrating if the installer (Red Hat) didn’t leave it exactly like you want it.

but let’s take this debate offline… I feel guilty for hijacking this thread.

GAGESound gets around this problem by doing its own mixing. The problem with using Clips is that to restart a Clip, the sound thread goes into a hard loop to drain the remaining data. Not a very cool design.

[quote] I noticed you didn’t have a solution to changing the desktop resolution… let me guess… pull out VI search for some X11 config file, guess at values to put in some tables buried within, pray that your monitor can still sync when you restart X…
[/quote]
If your system is configured to allow for more than one resolution, try CTRL++ and CTRL±.

Very nice game! The thing that stands out the most to me is:

  1. the excellent physics

  2. the wonderful gfx; not programmer art here!

  3. overall polish

Very nice.

Now about unx: I’ve played with it, but I agree with swpalmer, its just too steep of a learning curve and me personally, I don’t have the attention span. Another thing; I’ve used mingw quiet a bit and it bugs me to no end the way the unx tools all have 1-3 letter names

And my other main peeve; why does the iDev games pgming contest have to be natively compiled? I’d enter if I could use Java, but since I don’t have a Mac to compile on its not even an option.
[/rant]

Give me a free copy of your game and I’ll build it for you :slight_smile: In fact I’ll go ahead and talk to my partner about just offering it as a free service.

[quote]And my other main peeve; why does the iDev games pgming contest have to be natively compiled? I’d enter if I could use Java, but since I don’t have a Mac to compile on its not even an option.
[/quote]
If you are referring to this rule:
6. Only native Mac OS X double-clickable applications will be accepted (ie: without emulation software, including Classic).

Note that it doesn’t mean natively compiled. Standard Java apps can be packaged as a normal double clickable application on OS X. It’s just a matter of a bit of XML and keeping the files organized a certain way. Java apps are well supported on OS X.

[quote] 6. Only native Mac OS X double-clickable applications will be accepted (ie: without emulation software, including Classic).
[/quote]
I took the native bit to mean something else, obviously. Thanks!

There is a tool on OSX called Jar Bundler that simplifies the process entirely. All you need to do is put a .jar file together and send me the libraries along with the desktop icon and I can put together a double-clickable application for ya. No reason for any Java developer using our APIs to not be able to enter the contest.

[quote]There is a tool on OSX called Jar Bundler that simplifies the process entirely.
[/quote]
Has anyone else noticed that MRJBuilder doesn’t always finish filling out the Info XML file? At least on my iBook, I have to fill out the information related to the Java version manually, otherwise it won’t run.

Deftly stepping around issues of Linux complexity and Macintosh native jar building with such speed and elegance that no one notices…

To let you know I’ve just added an in-game option to change the colour bit depth of the display and Gundam can now run a hell of a lot faster than it used to. The bit depth used to be hard coded to 24 (bad Slimer, bad Slimer…) which may have caused problems on some machines…

As for Gundam not running on Java v1.4.2, yeah I’ve noticed that exclusive Full Screen Mode (on Win2K at least - apologies to all you Linux / Macintosh guys and gals) is a lot more unstable than in v1.4.1.

At last, an explanation for my sound problems! I think I’ll be looking at GAGE Sound in the not so distant future… Alternatively, as the MOD player doesn’t seem to suffer from sound glitches I always thought about trying to use that to mix sound samples together.

And for “3/5 of the freakin’ world” I’ve cobbled together a nifty Windows installer - separate .zip file still available for the other 2/5.

For the 3/5 and the other 2/5… try InstallAnywhere by ZeroG it’s a pretty good installer package in general. It makes installers for most platforms.

WebStart works for 5/5ths of the world :slight_smile:

The last time I looked, InstallAnywhere by ZeroG was not completely free :-[ - free being a requirement needed for a shareware program of mine (StrutsGUI). I then happened accross NSIS by Nullsoft (the WinAmp people). For a Windows only installer, it’s fantastic! :smiley:

WebStart :-/…hmm… I’ll look into it…

[quote]1. the excellent physics
[/quote]
I tried hard to get the momentum and energy transfer just right and the maths is not as easy as it looks. The one place where the physics still fail me is when Gundam bounces off solid rocks.

Unfortunately I could not get the game to run. The screen got black and then it crashed.
Specs: WinXP, JRE 1.4.2, 512 MB, GeForce256

As gregorypierce mentioned: Why not using webstart? It is not so difficult as it seems:

  • configuring server for new mime type
  • writing jnlp file (xml based)
  • sign all jars
  • using Thread.currentThread().getContextClassLoader().getResource(pathToResource + “/” + resourceName) for loading all your images, sound and whatever.

It is definately worth to include WebStart (in general JNLP) functionality because you get it handles downloading, installation und updating for you.

Here an excerpt from the crash log:


An unexpected exception has been detected in native outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x2EAB3B6
Function=Java_sun_print_Win32PrintJob_endPrintRawData+0x5282
Library=G:\JDK1.4\jre\bin\awt.dll

Current Java thread:
      at sun.java2d.DefaultDisposerRecord.invokeNativeDispose(Native Method)
      at sun.java2d.DefaultDisposerRecord.dispose(DefaultDisposerRecord.java:25)
      at sun.java2d.Disposer.run(Disposer.java:102)
      at java.lang.Thread.run(Thread.java:534)