Faster, smaller, simpler: yours for $99

General Discussions
#41

I said I’d be unfair :slight_smile:

But it’s good to hear that FG runs on a 400/tnt2 :slight_smile:

Maybe there’s also a difference in scalability.

I never could see much difference between client and server vm e.g. — maybe bc. the game is no longer CPU-bound on faster machines?

Something like that.

But to make that clear: I never said or wanted to say that Jet sucks! In no respect! I only tried it ONCE and reported what I saw. Cannot afford Jet anyway.

But if you have a compiled binary for me, I can upload it to the SourceForge site and everybody will be able to compare himself!

#42

[quote]I didn’t compare Jet and gcj. I never tested Jet, so I can’t compare, but if you are happy with it, it’s probably a good product (honestly). Some people mentioned compilation to native code and AWT/Swing support, so I thought it’s worth mentioning gcj.

gcj is build on top of gcc, which is stable, fast and has a lot of options, too. AWT/Swing is not complete, but some parts are implemented. CORBA is missing. The other parts are mostly on 1.4 level. I don’t have to wrestle with gcj, because it’s as easy as any other install here. Maybe it’s a problem on Windows (don’t know).

What do you mean by saying “supports the whole JDK”? The Jet-FAQ says that, if I have Jet Professional + Jet Perfect and no GUI classes (AWT/Swing/Java2D?) I need no JRE. If I use GUI classes I need the JRE. “supports the whole JDK” has two possible meanings:

  1. You can compile every Java app by using an already installed complete JDK.
  2. You can compile every Java app by using only Jet/gcj.

The first possibility is true according to the FAQ. I didn’t test, if gcj can compile every Java app, if you feed it with the JDK libs, but chances are probably good.
[/quote]
Definitally one project to watch - it’s a shame it has taken so long to get this far but it really seems to be picking up steam recently.

I too like Swing - it makes all the pre-game stuff quicker to code.

Will.

#43

[quote]But if you have a compiled binary for me, I can upload it to the SourceForge site and everybody will be able to compare himself!
[/quote]
No problem except download size. Fluying Guns needs AWT, so the whole JRE has to be either bundled or preinstalled for the executable to work, as well as Java3D. Without JetPerfect Global Optimizer, the “all-included” download is 35MB (JRE 1.4.2_03 + Java3D 1.3), the executables-only download is 16MB.

With JetPerfect, the generated EXE is about 11MB (zips to 6MB). However, I could not put it to work on first attempt (got an NPE in Thread_1), and I have little means to figure out what causes the exception. FG developers would have done this much faster than me because they know how to enable logging in their app and so on.

#44

If I wanted to write native games for windows without AWT and Swing, I’d use C/C++.

However, the option of squeezing out extra performance, even if it’s just for windows, would be nice. But I’m not sure I’d want to spend $100 on it…
I voted a careful “no”.

#45

You’d still fall prey to all the crap problems presented by C/C++ that make Java development so easy though. Not to mention the fact that you can still deploy your game with Webstart on all 3 platforms* if you stick with Java, or packaged specifically for each OS with very little effort.

$99 too expensive!? Too used to stuff for free methinks!

Cas :slight_smile:

  • well, when we get the Mac LWJGL stuff working with webstart anyway :wink:
#46

Threadjack

What sort of progress are you making with LWJGL on Mac? This was an issue when I tried to package Cosmic Trip for Erik. If the AWT thread is started after LWJGL is used (e.g. by a BufferedImage access) the application will hang. This made the app appear to work with Webstart, but not when packaged as a Mac app bundle. The second issue was that keyboard input was totally hosed once we got it to not hang. Press a key and the machine beeps at you as if the queue is full or something.
Odd problems, perhaps related to LWJGL input APIs? (which should probably use Cocoa to play nice with 1.4 on Mac, but I think they are using Carbon).

#47

Well, those are mostly known problems. For now, it’s “don’t even touch AWT when using LWJGL”. That also means no webstart, because it uses swing. The input problem is a symptom too.

Now, the port is based on a natively created window and context, like the other ports, but that simply seemed to be too weird for a mac, so once we get a chance, we will convert LWJGL-for-mac to something like JOGL, that is, LWJGL-on-awt-plus-gl-context. The timeframe is before Tribal Trouble goes alpha when we will buy a mac and get it to work (hopefully) or when cas does it on his newly acquired mac, whichever comes first.

  • elias
#48

OK! Glad to have seen this, we are able to get our stuff “working” through webstart, but no textures are loaded properly (all image data is zeroed out, so all textures are black). But everything else seems to work. You can see a black model animating for instance. The input also does not work correctly. However, it is unconfirmed if it works any better without webstart. :slight_smile:

#49

I’m not so sure the garbled textures are my fault though. When TT was first run on a mac most textures were corrupt - because we had unintentionally made our loaders endian specific.

  • elias
#50

Ahhhh, thanks for the tip.

#51

[quote]$99 too expensive!? Too used to stuff for free methinks!
[/quote]
Yeah, like Java and WebStart.

#52

So I find this intriguing myself. Liek Shawn, I’m not sure of the speed claims, at least not without requiring some real ugliness like making all non-polymorphic calls static in your code. (This is one of the reasons JET bloated your app. In order to approach Hotspot speed it had to actually include multiple copies of key sections of the code to fall back to in order to provide functionality like the VM’s aggressive inlining.

However IF you could indeed reach even 95% of Hostpot Server speed on real apps AND if the system was extensible such that I didn’t have to use LWJGL but could, for instance with some work port JOGL/JOAL/JInput , I think sucha compiler at such a reasonable price point might have some appeal to me to play with.

I think it would have even MORE appeal though if it compiled to some of the platforms I can’t reach today witha VM, say PS2 and Dreamcube? Maybe even GBA?

#53

It easily reaches server speed in the real-world game code I’ve written, with the extra special advantage of insanely fast startup time and considerably reduced footprint.

If JOAL and JInput don’t depend on AWT then you’ve got free reign to use them. JOGL is sadly tied to AWT and therefore out of bounds. Hence the suggestion that LWJGL, which does all three in about 1/10th the size, would be shipped with it. (And what do you know, Gregory has figured out how to run LWJGL on top of AWT now I believe…)

Cas :slight_smile:

#54

Has anyone on these boards had a look at D from digital-mars. http://www.digitalmars.com/d/

Not tried it yet myself, but I am tempted to have a paddle at least.

#55

[quote]In D, strings are simply arrays of characters, not a special type.
[/quote]
Yet in the comparison table they have “Built-in strings:Yes”
The table also will change a bit with the release of Java 1.5.

#56

Its an example of one of them great comparison tables desinged to show the benefits of the supported product rather than a comparison. :slight_smile:

Kev

#57

Yes, it is a biased comparison, but it would be on the D website wouldnt it. I just like the way it seems to have been designed, so that the language provides all the nice stuff from Java like GC, no header files, etc but doesnt stop you from getting your hands dirty when you decide to. Of course, the libraries that come with the language are a big win for Java over D.

(And Snow Patrol - is the rest of the album as good as Run? Very tempted by it.)

#58

They just released the single Chocolate aswell, so you’ll get a second one to compare to. But yes, the album is fantastic, every bit as good as Run.

Kev

#59

[quote]So I find this intriguing myself. Liek Shawn, I’m not sure of the speed claims, at least not without requiring some real ugliness like making all non-polymorphic calls static in your code. (This is one of the reasons JET bloated your app. In order to approach Hotspot speed it had to actually include multiple copies of key sections of the code to fall back to in order to provide functionality like the VM’s aggressive inlining.

However IF you could indeed reach even 95% of Hostpot Server speed on real apps AND if the system was extensible such that I didn’t have to use LWJGL but could, for instance with some work port JOGL/JOAL/JInput , I think sucha compiler at such a reasonable price point might have some appeal to me to play with.

I think it would have even MORE appeal though if it compiled to some of the platforms I can’t reach today witha VM, say PS2 and Dreamcube? Maybe even GBA?
[/quote]
Regarding PS2, see my post in another forum.

#60

Okay,

So what about gamecube? :slight_smile:

On JOGL… well I’m hopign it wont be AWT dependant forever msyelf. If you hacked a version to remove awt dependnacies that woudl be fine for me I’d just like call-compatability with code written for the desktop…

JK