Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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  
  Why Java, not C++?  (Read 13029 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #30 - Posted 2004-12-07 16:00:21 »

Quote
Why would M$ offer C# (read: Java clone) as their forward-moving replacement for C++?


+1 interesting angle.

Anyone got any good references on MS's own BS about why C++ devs should "grin and bear it" whilst MS are forcing them to move to C#?

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #31 - Posted 2004-12-07 16:02:38 »

Quote
Another thought on Java evangelisation for you: tools. With NetBeans and Eclipse you get code completion and javadoc lookup with live error checking while you're writing code. You just can't do this effectively in C/C++ because even if you got over the hurdles presented by the language, you'd still have the preprocessor and the archaic header structure to contend with.configure...


Interestingly, "there's no way realistically we can do without visual studio" , "it's the de facto standard - the standard file format for exchanging projects, the standard for teams to work on, etc" and "I need a debugger at least as good as VS's" are big noisy complaints in the games devs I've spoken to.

Now, it's been a loooong time since I used VS, and they've moved on a version or three since then, so I'm not really able to comment on how eclipse etc match up to VS. But it seems the *belief* is that C++ is better than java for tools at the moment.

?

malloc will be first against the wall when the revolution comes...
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #32 - Posted 2004-12-07 23:58:52 »

blahx3 wrote:
Quote

Interestingly, "there's no way realistically we can do without visual studio" , "it's the de facto standard

Interesting footnote then: Eclipse is rapidly becoming the defacto ide of choice for embedded C use particularly in the embedded linux/eCoS/etc world. For a Java ide it has really good C/C++ support - I've used it myself for embedded work.

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

Junior Member




Need to write more games


« Reply #33 - Posted 2004-12-08 07:36:45 »

Vis studio is still not a patch on eclipse Wink
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2004-12-08 07:53:06 »

On the other hand, Eclipse is still a dog-slow memory hog.

Cas Smiley

Offline cfmdobbie

Senior Member




Who, me?


« Reply #35 - Posted 2004-12-08 08:13:00 »

...which is irrelevant on any serious development machine, surely?

Chuck in a gig and it'll run fine.  What's that, 80 quid?

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #36 - Posted 2004-12-08 10:41:15 »

Not irrelevant at all. I've got a gig and it's still a dog slow memory hog. On a 3GHz HT machine. By my reckoning it's using twice the memory it should do and running at about a tenth of the speed it should.

Cas Smiley

Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #37 - Posted 2004-12-08 12:41:01 »

Strange - I run Eclipse on a little old 600Mhz laptop with 256Mb and it runs fine - even with a source tree of over 10,000 C and Java files.

Maybe it could be faster and smaller, but it is more than fast enough for me.

NetBeans is more of a hog and doesn't run so well on my laptop but it is fine on the desktop.

Don't forget with Java, comparing Eclipse/NetBeans with Vis Studio can give you a false result as Java IDEs 'understand' the source code in far greater depth than a bit of basic pretty printing. All this code structure takes memory - lots more than the raw characters.

Offline Middy

Junior Member




Java games rock!


« Reply #38 - Posted 2004-12-08 16:32:34 »

DaveLloyd netbeans is swing based while eclipse is SWT based. Thats prolly the difference

When do I get my makeMyGameAsILike() extension?
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #39 - Posted 2004-12-08 16:47:02 »

Middy wrote:
Quote
DaveLloyd netbeans is swing based while eclipse is SWT based


I'm not convinced. Swing is often held up as the culprit but for what I'm doing the GUI response is not the issue. I suspect it's more that NetBeans is more deeply structured than Eclipse.

Incidentally, for all NetBeans is a bit of a hog, I still find the more useful of the two.

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

Junior Member




Guitar, Norse Mythology, java and women=life


« Reply #40 - Posted 2004-12-08 17:12:09 »

I read this topic and I found it very interesting to see the advantages of Java weighed up against C++, so I thought I'd help you out.

I googled: "Java+Advantages" games; and this is what I came up with.

http://margrabe.com/JavaDP.html

Good Luck with the convincing Smiley

Hauk

I want to become a hermit and live in the harsh wastelands of Norway. I want to have a cloak made of bearskin and hunt the demons of the night.

I was born for a reason and am not about to lie down and die like the rest of you. Anybody with me?
Offline Raghar

Junior Member




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


« Reply #41 - Posted 2004-12-08 17:21:54 »

I used Eclipse on 450 MHz with 220MB RAM. It runed reasonably. I however liked more jEdit with some pluggins, because I dislike to leave source files handling to an IDE. One click could delete all your source files, and using  HD recovery programs is a lenthfull problematic proces.
I believe Eclipse has some options that alows disable automatic reparsiong of the current source file.

Re cas

Everything not writen in the Assembly takes more memory and time to run than it should.
(In fact sometimes even writing program in C++ takes more time than writing it in the Assembly. )
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #42 - Posted 2004-12-09 01:12:31 »

Quote
I used Eclipse on 450 MHz with 220MB RAM. It runed reasonably. I however liked more jEdit with some pluggins, because I dislike to leave source files handling to an IDE. One click could delete all your source files, and using  HD recovery programs is a lenthfull problematic proces.


Which is why we have subversion.

Will.

Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #43 - Posted 2004-12-09 02:35:00 »

I noticed that most people have been responding to this thread from a developer's perspective.  And maybe that was the intention of the author of this thread.  But you have to think about the game player and what a language can give to him/her.

Cinematic effects, high performance and response time.

I'm into AI.  I'm at the start of designing an AI engine that will be complex to say the least.  Is it very useful for game animation?  I don't know yet.  But I do know that I need with this novel design I'm playing with, complex calculations being perform every second requiring lots of multithreading.  I have been programming for quite some time.  I'm just new to game development.

If you want real time rendering of photorealistic images, real time complex collision detection and real time performance, which seem like what the game writers are persuing, then you have to have a language/OS/hardware that can give it to you.

IMHO.

Jeffrey F. Elrod
Complexsive Systems
Offline Catharsis

Junior Member




EGR Software rocks!


« Reply #44 - Posted 2004-12-09 04:43:31 »

Quote

If you want real time rendering of photorealistic images, real time complex collision detection and real time performance, which seem like what the game writers are persuing, then you have to have a language/OS/hardware that can give it to you.


General comment:
In regard to rendering a good portion of us here use OpenGL via LWJGL or JOGL which is offloading this aspect to preferably recent hardware via the native OpenGL library. Since the 1.4 JDK JNI has definitely improved.

My developent:
In regard to collision detection.. Well I have found that standard BSP collision detection works great in Java with the Auriga3D engine (Q3 based) that I will be releasing for preview soon.

Dynamics is another story.. I will soon be looking into using the ODEJava project / ODE engine to provide dynamics with collision handled on the Java side.  This integrating of the BSP collision system Java side with dynamics handled with ODE will be tricky and is theory at this point.

Audio:
I am using a state of the art audio engine called SuperCollider3. It is a C based audio engine, but it is also a network server and accepts a network protocol called OSC (Open Sound Control).  Java is a wonderful language for sending OSC to this audio engine and controlling it locally or across a network. Either way it executes in a separate thread.  NIO plays a big part here in efficiency on the Java side.

Your development:
I'd like to hear more on the AI engine you mention you are building.  So far I have looked into Simbionic which has a Java port of the engine.  

Conceivably you could build your AI engine in C/C++ and provide an accessible Java API if you find out that implementation in Java is prohibitive. Though it may not be.. It depends on what you are doing.  A fuzzy FSM based AI system should be able to be optimized for Java.

I dunno I am just throwing out my viewpoint given your comment.. Of course as you see in three areas crucial to systems in game development I am looking at C/C++ oriented engines to handle the work. These parts are OpenGL/hardware accel rendering , ODE/dynamics, and SuperCollider3/audio.

Java is great as a bridge to DSLs (Domain Specific Languages or engines) that may be implemented in other languages.

Java can facilitate an easy to extend component oriented control environment that essentially forms a flexible glue between all of these areas.  Given that the DSLs/engines implemented in other languages are cross platform (OpenGL, ODE, SC3 are) provides a nice pairing with a Java control environment as it should be cross platform as well.


Perhaps in closing these comments I will mention that right now something that is holding me up in my development activities has nothing to do with Java at all. At this point in time I  believe I will be able to greatly extend the rendering options of my current work once the Render to Target OpenGL extension is approved and implemented by ATI/NVidia and other IHV vendors.

http://www.opengl.org/resources/features/GL_EXT_render_target.txt

I dunno.. I am firmly convinced that Java has a part in modern development of advanced applications. Many of us here are forging the way..  Smiley

Founder & Principal Architect; EGR Software LLC
http://www.typhonrt.org/
http://www.egrsoftware.com/
Offline jfelrod1960

Junior Member




Use the source Luke, use the source!!!


« Reply #45 - Posted 2004-12-09 18:32:22 »

Catharsis,

The AI engine I'm working on is still in the design and analysis stage.  All I have is a first draft of an UML design and some test code written in C++.  I'm a little reluctant to discuss it because I don't know if it will work and I would like to save myself the embarrassment.  As I stated before, I'm new to game development.  But the thing I'm going for here is adaptive control.

Adaptive control is when a device or in our case a game character changes its behavior in response to a change in the environment.

Let's take for example a space battle that requires many space vehicles to be in combat with each other.  If the environment changes, for example the battle migrates into an asteroid belt, the vehicles will have to adapt to the new environment. (Recognize that an asteroid is not an enemy space vehicle, but it has to be able to navigate around it.)

I don't really think this has been accomplished yet in a game environment.  It may have.

But once I get to a point where I feel like this is acheivable I will be willing to show you or point you to a website that will show the progress of this project.

To make this post somewhat appropriate to this thread, I wonder if I could develop such a sophisticated design using Java.  I like the language very much and have been asking questions (in another forum) about Java and 3D.  There are games perfect for Java.  But games that require lots of mathematically calculations done by the CPU as well as the GPU ... I wonder?

I appreciate your inquiry.  Wish me luck! Smiley

Jeffrey F. Elrod
Complexsive Systems
Offline DaveLloyd

Junior Member




Making things happen fast with Java!


« Reply #46 - Posted 2004-12-10 09:05:41 »

jfelrod - I'm not sure quite what kind of AI you're talking about but Java should in fact be very well suited. AI is usually less number crunching and more object manipulation and method calling. Most AI used to be implemented in LISP to take advantage of lambdas and closures - these map onto classes (particularly anonymous instances) in Java. A while back I tried some unification algorithms in Java (core of a lot of deductive reasoning) and found them significantly faster than the equivalent C. Main reason being (I suppose) that Java doesn't really use a stack - it's all already on the heap - and Java's method dispatch is well optimised while the C equivalent used a handrolled scheme that wasn't as good. There are also very good and very fast implementations of Rete-style forward reasoning in Java.

Dave

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #47 - Posted 2004-12-10 09:50:13 »

Quote
A while back I tried some unification algorithms in Java (core of a lot of deductive reasoning) and found them significantly faster than the equivalent C. Main reason being (I suppose) that Java doesn't really use a stack - it's all already on the heap


Interestingly, you take us back on-topic. I've had C++ devs complaining that "java must be slow because it does everything on the stack". I'm mildly embarassed to admit that it's been so long since I cared that I can't remember how much java does on one and how much on the other; I know I can still hand-code assembler routines to set up efficient stack frames for fn calls, and other pointless/useless bits of related knowledge, but the important bits have rusted away Sad.

malloc will be first against the wall when the revolution comes...
Offline bw9

Junior Newbie




Everyone has X-Ray Vision


« Reply #48 - Posted 2005-01-07 18:01:14 »

Ok this is my first post.

I'm old salt.  Once my friends called me Bjarny because of my in-depth knowledge of C/C++.  But I pretty much do everything in Java these days.  And the everything is high performance computing - in java.

My .02 on the performance argument.  For pure number crunching, a native compiled language will always win.  It doesn't matter how good the optimizer is, because the best optimizer is the developer, and if you hand code optimized stuff in C/C++, it will always out perform Java.  And you can code directly to your hardware too...

Flames on!  But a game isn't all about blitting as fast as you can, right?  All the optimizations that are often forgotten from the C/C++ world can be applied in the Java world.  And writing slick Java code makes up for stupid performance issues when you take into account that anyone doing C/C++ development usually has to hunt around for all sorts of libraries or make them themselves to do UI, network, and the like.  Java toolkits give you all this out-of-the-box, so you don't need to develop it yourself, and for the most part its all x-platform.  Tieing stuff to specific hardware means someone somewhere won't be able to play your game.  (HalfLife2 won't run on my 100% Dx9 savvy portable /w integrated video.)

I have always had issue with finding good socket libraries in C/C++.  I was so happy with Java, that I use it for all networking and db work.  And this area is a place where it doesn't matter if it is coded in C/C++ because you are typically bound by your connection speed and putting together your own brilliant adaptive gaming protocol.

Writing core games often meant writing your own memory managers and crap.  This ground level structural work is a waste of time.  The argument that Java bleeds objects and your game stops when the GC goes is bunk - because it means the developer architected/implemented it wrong.

So, the real advantages, IMHO
- the wealth of libraries (especially the toolkit out of the box) cuts your dev time drastically
- kick butt dev tools (some are free)
- the ability to delegate to native when you absolutely need to (JNI to optional native accelerator libraries)

One cool thing if you aren't writing network games portability to J2ME (that's right, it runs on your cell phone too).

And then there are the caveats about Java... that will come up.
- memory footprint
- lack of gaming libraries (a good sprite engine)



Bernie Wieser
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #49 - Posted 2005-01-07 18:22:42 »

Quote

My .02 on the performance argument.  For pure number crunching, a native compiled language will always win.


Well, that's almost the opposite of the truth, assuming you mean "will always win against java" because a dynamically (re-)compiled language is always, in theory going to be at least as fast and often faster than a one-time compiled one, assuming complete optimization of both.

On a practical level there's really no difference in raw number crunching since the executed code is practically identical, assuming no compiler bugs or quirks, assuming that your JVM is correctly written, etc.

So...what, exactly, do you really mean here?

Maybe you're thinking of specific cases, e.g. new instruction codes? Historically, it's taken Sun on the order of years to capitalise on new instruction codes (c.f. how long it took to get automatic SIMD, and even now it's limited applicability. Ditto (on both counts) the OGL acceleration for 2D. Etc etc) That's not number crunching, that's a problem with the compiler authors (Sun) investing insufficient money. IMHO this is is foolish given the value of Java to Sun - I really struggle to see why Java gets such a bum wrap from the company. If Sony's execs had been as conservative as Sun's we'd probably still be on PS one, with "rumours" of a new version to come sometime in 2005...instead, they realised that PS == Sony's future.

malloc will be first against the wall when the revolution comes...
Offline bw9

Junior Newbie




Everyone has X-Ray Vision


« Reply #50 - Posted 2005-01-07 23:40:04 »

Actually, no, I don't mean that.  Local (loop) optimizing and code caching like hotspot are great, but they can get confused.

Take the following example.

I'm doing a FFT on a matrix of complex numbers to do some funky image processing.

First problem, complex numbers are most intuitively interpretted by objects in Java, and so every access of a field means overhead of 2 to 3 indirect reads.  We are always virtual - so we have a churn of both objects and reads.  For O(N^2 or N^3) operations on such matricies, the computational cost adds up.

And here is the other difference.  Implementing this as a class in C++ you can take advantage of operator overloading as opposed to chaining methods to add/multiply.  The generated code typically has a lot less in working code.

So, what I generally do, is rely on JNI and reduce my overhead my dumping the packaging and moving everything into arrays where I can use index magic and atomic types and/or hardware acceleration that works on atomic vectors where possible.

Problem again, is moving this back into Java, the repackaging and other (though minute) overhead of JNI.  (Remember the argument of the defunt Microsoft RNI vs JNI.)

You can refactor/rearchitect your Java code to be more friendly at the expensive of intuitive behavior.

For gaming, most of the time, you can avoid any of the nastiness associated with using transcendental functions or complex numbers and the like... but not many people remember the old days/ways of approximating FP math with precalculated integer math.


Bernie Wieser
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #51 - Posted 2005-01-08 01:55:06 »

Quote

First problem, complex numbers are most intuitively interpretted by objects in Java,


I strongly disagree with the tendency to say "lets have an object for every complex number". There's little or no rationale behind it, other than people think it's what they're supposed to do. Objects are not something to make just because you had a Noun. So...I think you're going out on a limb with your assertion here.

Quote

and so every access of a field means overhead of 2 to 3 indirect reads.  We are always virtual - so we have a churn of both objects and reads.  For O(N^2 or N^3) operations on such matricies, the computational cost adds up.


So, you're saying that because in your example the author choose to do a stupid algorithm design java is therefore bad at number-crunching? That doesn't follow.

Quote

And here is the other difference.  Implementing this as a class in C++ you can take advantage of operator overloading as opposed to chaining methods to add/multiply.  The generated code typically has a lot less in working code.


You've lost me completely. Whenever I've used operator overloading it was a sugar for method calls - what is the difference?

Quote

For gaming, most of the time, you can avoid any of the nastiness associated with using transcendental functions or complex numbers and the like... but not many people remember the old days/ways of approximating FP math with precalculated integer math.


Going by these forums, it's more often a problem convincing people NOT to use lookup tables. Personal experience of current and ex-colleagues follows similar lines. Lookup tables can even be slower than just using the correct methods, thanks to JVM optimizations.

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #52 - Posted 2005-01-08 13:00:19 »

Structs! Structs! Structs!

Cas Smiley

Offline Mark Thornton

Senior Member





« Reply #53 - Posted 2005-01-08 16:06:45 »

Quote
I'm doing a FFT on a matrix of complex numbers to do some funky image processing.

First problem, complex numbers are most intuitively interpretted by objects in Java, and so every access of a field means overhead of 2 to 3 indirect reads.


Most performance critical computation with complex numbers involves aggregates of complex numbers (array, matrices, etc). It is natural to have objects representing these aggregates, but the implementation of these aggregates will usually use float or double arrays rather than arrays of some Complex class. When done properly you find Java gives performance similar to C/C++.

While it would be nice to have an efficient Complex class, it isn't necessary to obtain good performance.
Offline bw9

Junior Newbie




Everyone has X-Ray Vision


« Reply #54 - Posted 2005-01-09 05:40:39 »

Good or optimal performance...  I can do anything with good performance based on right algorithm, data structure, and hand coded optimization.

The reality of it though is the same strategies in compiled C/C++ outperform what I've done in Java, and I know this from experience and metrics I've gathered.

Its unfortunate that blah discounts everything I say as opposed to disproving it.  All I can add is that conversations like this aren't productive... buddy, write a gaussian blur in java and the same thing in C/C++.  Do it on a 1024/768 32 bit image as many times as you can over 1000 iterations.  The throughput will be at least 3 times more on the C/C++ side than in Java for the same implementation.

I've written my own complex libraries, linear libraries, optimization libraries, in C/C++ and Java.  I've optimized code for a healthy portion of my coding life (20 years).  I guess this means I know absolutely nothing.

Bernie Wieser
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #55 - Posted 2005-01-09 06:28:17 »

Quote

The reality of it though is the same strategies in compiled C/C++ outperform what I've done in Java, and I know this from experience and metrics I've gathered.


That implies you do the same thing in java as in C++ and expect it to work as well, which clearly is not the case. I'm getting the impression that you tend to expect java to execute c++ code with no more alteration thatn changing the syntax. Different languages, different architecutres, require different approaches; given the topic, I assume everyone has that in mind already.

Otherwise C programmers would be insisting on writing single-class java applications with no objects and complaining that the java doesn't shine compared to the C.

Quote

Its unfortunate that blah discounts everything I say as opposed to disproving it.


Not at all. Look back at your posts and mine. You have made some silly claims, including one that flies in the fact of simple logic, and one that is based upon the assumption that the code-writer uses a naive or just plain foolish implementation technique that in fact java developers don't generally use.

You made a reference to operator overloading as being somehow more efficient, but you didn't explain, and when I queried this you said nothing.

It's hardly a case of me shouting down everything you say, is it? Until this post I wasn't even aware I was arguing with you, I just thought I was pointing out some statements that - unless you decided to clarify them - were clearly mistaken.

Quote
I guess this means I know absolutely nothing.


Shrug. If you say so Tongue.

malloc will be first against the wall when the revolution comes...
Offline Mark Thornton

Senior Member





« Reply #56 - Posted 2005-01-09 08:48:02 »

Quote

The reality of it though is the same strategies in compiled C/C++ outperform what I've done in Java, and I know this from experience and metrics I've gathered.

Others (including me) have done tests on a variety of code including FFT and found Java to give very similar results o C++ (Java has frequently been found to be faster in the case of the FFT).
If you are finding significant performance advantages for C++ over Java, then either there is some peculiar feature in the test (such as use of certain trig methods which are slow in Java because its accuracy specification is greater than that of C++), or there is probably something wrong with your coding.
NOTE: it is unreasonable to expect a good C++ implementation of a task to look very similar to a good Java implementation of the same task. Java's superficial similarities are something of a trap. So while a simplistic translation is easy to do, when it comes to achieving best performance from Java, much C++ experience and habits are near worthless.
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #57 - Posted 2005-01-09 13:54:53 »

Most of the current perceived performance problems in Java stem from the fact that the only decent speed in Java is available in the server VM, and the server VM takes so long to get into its stride it's basically 100% true that C/C++ is loads faster at doing smaller jobs. Until that two-phase compile stuff turns up, and maybe a bit of cacheing JIT code, C/C++ is pretty much always going to be a lot faster in this respect.

Case in point: JET compiled Alien Flux starts up in under 1 second. Server VM version takes maybe 30 seconds, client takes about 15. AOT compilation I'm afraid is just that much better right now until the VM engineers seriously address the issue.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #58 - Posted 2005-01-09 14:38:22 »

Quote

Case in point: JET compiled Alien Flux starts up in under 1 second. Server VM version takes maybe 30 seconds, client takes about 15. AOT compilation I'm afraid is just that much better right now until the VM engineers seriously address the issue.

Cas Smiley



With that, we're going right back on topic, right to the core.

Speaking to C++ games studios, I've found a major issue I wasn't previously aware of, that potentially ranks right up there beside "no playstation jvm": fast deserialization of game-data (at least, according to them. But they don't know java well enough and I don't know C++ well enough Wink).

The method is that to load a 50MB level as lots of objects, polygons, and behaviours (event triggers) etc, at compile time you "bake" it into a serialized copy, and at runtime you deserialize the bytes straight into memory, with no time spent parsing or instantiating any data. I understand how this all works - with C it's quite straightforward to be dumping data structures directly into RAM from disk, and then using pointer arithmetic to setup your function pointers to known offsets (i.e. it's just that in C/C++ you have direct access to do your own runtime loader + linker, basically, within your program).

Now, although I've done loaders and linkers I've only done toy examples (loaded a single class worth etc) - never thought of manually doing an entire level like this. But this is apparently very common practice in games dev on consoles. And a lot of different games devs have thrown this up as something they're seriously worried by the prospect of losing.

My initial reactions were:
- Why are your levels replete with so many objects that parsing + instantiating them all from a non-baked level file is significantly time consuming? (the instantiation cost has been cited as the main issue, although I would have thought it would be the parsing that was more of an issue; perhaps by instantiation they're mentally including the cost of hooking up all the internal pointers (which, I think, get baked-in - something you just can't do with java; you'd have to manually iterate across the classes and set references)

- How much time does it save anyway? (apparently an awful lot. Especially with poor console CPUs (c.f. consoles tend to have weak general CPU and instead lots of game-specific power)

- How close could you get in performance by using structs and a memmapped ByteBuffer? (modulo the fact that memmapping is buggered in java 4 and I hate the possibility of having to do all games dev on java 5 Smiley)

- ..how close without the memmaping (stream it instead) and without the structs (using the various hand-written simulations that several of us have done, which only differ in not being specially treated by the jvm)?

Presumably the reason AF starts so fast with JET is because similar baking is going on, so that in fact the game has been pre-instantiated at compile time, then serialized, and JET is deserializing and linking it?

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 284
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #59 - Posted 2005-01-09 16:37:33 »

Er, no Smiley The reason is because the JVM is slow. The JET VM has to do exactly the same operations as the JVM when it loads Flux - deserializing, etc. etc. It's basically a brilliant, real-world benchmark illustrating the only difference between the two deployments: AOT compilation.

This is why I'm willing to bet that a JIT that caches its code into AOT will be a huge winner.

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.

xsi3rr4x (56 views)
2014-04-15 18:08:23

BurntPizza (54 views)
2014-04-15 03:46:01

UprightPath (67 views)
2014-04-14 17:39:50

UprightPath (50 views)
2014-04-14 17:35:47

Porlus (67 views)
2014-04-14 15:48:38

tom_mai78101 (91 views)
2014-04-10 04:04:31

BurntPizza (152 views)
2014-04-08 23:06:04

tom_mai78101 (248 views)
2014-04-05 13:34:39

trollwarrior1 (205 views)
2014-04-04 12:06:45

CJLetsGame (212 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!