[Grug]

That's pretty kewl, I did a bit with Server code didn't get to much of a chance to play with it.
I was going to make my own chat prog to distribute among friends, among a turnbased computer rip off of 40k / Warhammer etc.

I used to have NWN, pretty fun game.
Making a server for it is interesting, the little OGL window even more so.
By the looks your using good'ol netbeans eh?
If you ever wanted to try out working on a co-project I'd probably be up for it.

As for garbage collection, I probably never got to the level where it became much of an issue, but in the latest version isn't there a dispatch garbage call? I thought there was anyway...?

I can kinda half read C/++ and have a very basic understanding on how pointers work, but not a terrible amount about how keeping track of all the memory allocation would work.
Sometimes it boggles my mind completely just thinking about how much stuff you'd have to do manually without some of Java's niche's. But it would seem overall that the higher level of control is worth it.

[aldo_14]

Originally posted by PhReAk
The reason i wouldn't like making a game in Java, is that you can't deallocate memory on demand like you can in any other language in existance.  Using a freespace example, you don't want the briefing images still loaded into memory once you've launched into a mission.  Additionally, you don't want any other critical things such as ship textures and model data to be garbage collected while the player is still in the briefing (since they are already being used).  Hell you don't even know when the garbage collector will run, so something could crash in mid-mission.  I guess that could present a small problem.  Plus pointers are fun.

IIRC there is both a compiled and translated JVM; the latter which uses a more dynamic memory model.... the former, IIRC (again) sets up a degree of pre-allocation to speed up storage.

Garbage collection in Java is done automatically to clear up variables which are no longer referenced, or you can do it manually using System.gc() (NB: this does not force it; it suggests that the JVM might want to perform collection).

 There is no way in hell you can have already-referenced memory being garbage collected before used, though....only the dereferenced stuff will be.

Oh, and garbage collection runs as a minimum priority thread in the background, using an algorithm balanced between speed & effectiveness.  

Apparently, the java method of memory allocation is faster than heap allocation with C++, it's the deallocation - tracing the referenced & unreferenced memory space - that it (offhand there are 2 seperate methods for this, I don't know the details but one is based on when the allocated blocks are 'long living', i.e. referenced for a longer period of time).  I've read that - potentially - Java could be as fast or faster than C++ allocation if they get this bit working fast enough, but i'm not aware if there's a succesfull test case for this.  Much, I suspect, would depend on the local JVM optimisations.

I'd again say that java isn't ideal for games, though.  But it's still doable, IMO; it's just that C++ is - at least currently - a far more suited language to it.  Whether something will come along in a few years+ time and supplant C++'s position (be it Java or something more specifically designed), I don't know...

[karajorma]

If your complaint against Java is simply that it's slower than C it's worth remembering that C is itself slower than assembly (at least for simple systems).

The reasons why games are written in C rather than assembly are actually quite analogous to the advantages of Java over C (i.e easier development, better portability, more of the basics being handled internally, better hardware abstraction).

Now I'm not saying that anyone should go back to Assembly or use Java for games but I do find that quite amusing

[aldo_14]

To be fair, C programs are more or less equal to assembly with optimizing compilers nowadays; it's arguable that they are even faster.... of course, you could probably apply the same to optimized JVMs (be it JIT or altogether compilation) in a few months/years/whatevers time.

[karajorma]

On simple systems Assembler is always faster. The limitation that makes it equal to C on more complicated systems is the fact that only a real genius can code assembler as well as the compiler can optimise it. The limitation is on the programmer and not the language.  

Whenever they have competitions to see who can write faster code the results are inconclusive.

[aldo_14]

Originally posted by karajorma
On simple systems Assembler is always faster. The limitation that makes it equal to C on more complicated systems is the fact that only a real genius can code assembler as well as the compiler can optimise it. The limitation is on the programmer and not the language.  

Whenever they have competitions to see who can write faster code the results are inconclusive.

Ah, but the point is that's changing/changed. There's a point of complexity below which human programmers are still better, but that point is being pushed incrementally back with each generation of compilers.  Especially with the bastardy-complex CISC architectures (which, to be fair, are not the main assembly programming environments nowadays).

 At least according to my old CAD* professor (who was a big fan of writing in assembly language, particularly - it seemed - MIP/RISC).  The guy worked on a few of the old 1980s computers - the Dragon in particular - so he seemed to know what he was talking about.  Hates Microsoft and Intel with a quite amusing passion, though...so much so that I think MS complained to the uni about his long rants in lectures

*no, not that CAD - Computer Architecture and Design it was, 2nd year class in the low-level architecture.

[karajorma]

Originally posted by aldo_14
Ah, but the point is that's changing/changed. There's a point of complexity below which human programmers are still better, but that point is being pushed incrementally back with each generation of compilers.

I agree that assembly is needed less and less these days Didn't the change over to C happen when assembler was still the fastest though?

[aldo_14]

Originally posted by karajorma


I agree that assembly is needed less and less these days Didn't the change over to C happen when assembler was still the fastest though?

I'd expect so.  

I'm not saying people moved to C because it was faster or anything; if people hadn't changed over to C, then there probably wouldn't have been as much optimizational work done/needed on compilers (for obvious reasons).  Just that now, the performance advantages of assembly programming are being eroded more and more - proboably partly because AFAIK it's a less frequently taught skill - and that in time I'd expect the same to happen vis-a-vis high and 'medium' level languages.

(I sort of consider C/C++ as medium and Java as high level simply to disambiguate their levels of abstraction... purely my own term for it, of course - AFAIK there is no medium level term, everything > assembly is basically considered as high-level.  Which is maybe itself a bit of a mistake nowadays, because languages are moving towards a state where some - like java - can be considered 'ultra high' compared to the likes of C, due to distributed capacity)

[CmdKewin]

Screw Java, way too slow. And screw C++ too. Way too complicated.


Go for a nice "real-time" language. ADA.

....
....

Ok, just kidding. Stick with C, for any serious OpenGL developement, it's still the best you can have.

Do not use VS C++, unless you've got VS.NET 2003 (the first one isn't ANSI/ISO compliant, the second one sticks 98% percent to it... wich is more or less the same as gcc does). And, you know, there are FREE Ide's for C++ around... www.bloodshed.net

p.s.: DirectX is very good at Games, OpenGL is better at stientific and industrial Graphic Visualization (you get my point).

p.s.s.: It's not entirely true that OpenGL works seamlessly over Unix, WIN32, Linux and other OSes. If you stick to the basic, you're right, but whenever you get to something more complicated, pieces of your code stop to work. ARB Multi-Texturing anyone?... And that's true for Java3D too.

p.s.s.s.: UML is the DEVIL, i tell you. As someone once told me "Only NASA engineers use it for real... And we've seen the results" (ok, a bit harsh if you want... but he's basicaly correct). The only diagram that serves a certain purpose is the Use Case Diagra, just because it gives you an overview of the whole project, which is the most important thing and that, whith big projects, people tend to forget.

"Excessive specialization brings to weakness" - "Major" Motoko Kusanagi.
(Ok. that's not the exact quote, but i've got the Italian Version of it).

[karajorma]

Originally posted by aldo_14
I'm not saying people moved to C because it was faster or anything; if people hadn't changed over to C, then there probably wouldn't have been as much optimizational work done/needed on compilers (for obvious reasons).

That's pretty much my point though. The arguments all the C people give for not changing over to Java are pretty much exactly the same ones the assembly people used to give for not converting over to C

The arguments why Java is good are also pretty similar to the ones that C originally used to say why it was a better choice than assembly too.

Personally I find that quite funny

[aldo_14]

Originally posted by karajorma


That's pretty much my point though. The arguments all the C people give for not changing over to Java are pretty much exactly the same ones the assembly people used to give for not converting over to C

The arguments why Java is good are also pretty similar to the ones that C originally used to say why it was a better choice than assembly too.

Personally I find that quite funny

Well, yeah.  My point was just that the situation there has somewhat changed with regards to the performance handicap, and I'd expect the same to happen with Java and similarly abstractive languages.

Originally posted by CmdKewin

p.s.s.s.: UML is the DEVIL, i tell you. As someone once told me "Only NASA engineers use it for real... And we've seen the results" (ok, a bit harsh if you want... but he's basicaly correct). The only diagram that serves a certain purpose is the Use Case Diagra, just because it gives you an overview of the whole project, which is the most important thing and that, whith big projects, people tend to forget.

Actually, I use UML a fair bit nowadays.  Class diagrams in particular.... at the end of the day, with any reasonably designed software you need some form of plan, and UML does have some use in being a standardized notation for that.

[CmdKewin]

Originally posted by aldo_14


Actually, I use UML a fair bit nowadays.  Class diagrams in particular.... at the end of the day, with any reasonably designed software you need some form of plan, and UML does have some use in being a standardized notation for that.

That's the main problem. Even tough it's "standardized" , the more you use it, the more you "will" tend to make "assumptions" and to deviate a little from the "standard", missing the whole point of UML. At least, that's what has been happening to me in the past 5 years.

[aldo_14]

Originally posted by CmdKewin



That's the main problem. Even tough it's "standardized" , the more you use it, the more you "will" tend to make "assumptions" and to deviate a little from the "standard", missing the whole point of UML. At least, that's what has been happening to me in the past 5 years.

Point is, I may prefer or tend to use my own bastardized notation schema... but when I have to discuss or show stuff to people, it invariably ends up being UML.  

You can't really blame the language for the speakers, so to speak, though; if people deviate from the standard, etc, then it's their fault, not the languages.  Especially as any unified general-purpose standard (as UML was designed to be) is invariably going to be compromised by both its scope and the different forms of input that went into defining it.

[phreak]

Originally posted by karajorma


If that's happening in your Java program then you've done a really bad job of writing it. Garbage collection of items you wanted to keep occur would only occur if you were silly enough to have no references to the object even though you wanted to use it again. You can do that in C just as easily. (not to mention that you can have references to an obect that no longer exists because you've called the destructor, something you can't do in Java).

So if you're having objects collected that shouldn't have been in Java you would still have had them out of the scope of your program in C and now would have to contend with a memory leak too.

I stand corrected, my Java professor is a douche

[xenthorious]

Quoted by Grug
That's pretty kewl, I did a bit with Server code didn't get to much of a chance to play with it.
I was going to make my own chat prog to distribute among friends, among a turnbased computer rip off of 40k / Warhammer etc.

I used to have NWN, pretty fun game.
Making a server for it is interesting, the little OGL window even more so.
By the looks your using good'ol netbeans eh?
If you ever wanted to try out working on a co-project I'd probably be up for it.

Absolutely, but not because I can make GUI easily.  This feature was discovered by me only after I got used to using NetBeans, and desired it over others.  No no, I liked NetBeans because of it's debugging tools.  First off, it helps me narrow down errors before compiling, which IMO, speeds up the completion of the job.  Second, most common and most irritating errors are the pethetic syntex errors of forgetting some character (e.g. "[] {} "*" ()").  Nothing like having 500 lines of code, and unable to isolate a stupid } syntext error.  Netbeans helps narrow this down.  When I learned about it's pallette, I fell in love with it.

Quoted by Grug
As for garbage collection, I probably never got to the level where it became much of an issue, but in the latest version isn't there a dispatch garbage call? I thought there was anyway...?

There is, but Garbage collection is never forcable.  Though aldo has mentioned a method (function) of which does do this, it is better to use a combination of techniques to achieve this.  As both I and Aldo have stated before, all process in Java are set with priorities, garbage collection being the lowest.  Putting a process to sleep lowers that priority, which is learned when using threads.  As I stated before, if you put the entire program to sleep for 3 seconds, you lower there priority.  Using the method Aldo expressed at this point, would increase the chances or garbage collection.

Quoted by Grug
I can kinda half read C/++ and have a very basic understanding on how pointers work, but not a terrible amount about how keeping track of all the memory allocation would work.
Sometimes it boggles my mind completely just thinking about how much stuff you'd have to do manually without some of Java's niche's. But it would seem overall that the higher level of control is worth it.

I admit, there are some areas of which I stand corrected with Java; those being areas of which performance could be issues of interest.  However, I have yet to be disputed on issues of which were brought up by karajorma, regarding the simplicity and portability of using Java.  Ultimately, C was chosen in the past because it was easier to use.  Again, it was stated that Java could at one point be as good as C++, but at this time it is not so.

Off the subject however, the program I am making will eventually be GPLed, which is why I am so openly talking about it.  What you will find interesting is how it works with the NWN server.

In order for this program to operate with the NWN server, several script files within the server have to be created.  Most of them have a small data base of which has serial numbers.  This java program works off sending a serial number code in through the server chat channels where on the combat message window.  The script in NWN seeks those numbers and when one is found, flags for a response.  Information to the java server console is given also by internal NWN scripts, where these scripts seek out certain critierals of which are areas of interest.  The information is then outputted to the log file, where the java console eliminates unwanted characters, keeping only the valued content.  The content is then charactorized, and passed over to it's proper method, which would in turn display it on the console.  Ultimately, this is a hybrid programing project, using NWN scripting as the secondary code.  I have not seen one project use this in the entire NWN forum, which is why I think my program will be of great interest to many of that area.

That's my 2 cents.

[aldo_14]

Originally posted by PhReAk


I stand corrected, my Java professor is a douche

Apparently so.... there's no way in hell the JVM should or will deallocate space for memory with a reference, the garbage collector is explicitly designed to ensure only dereferenced memory is 'deallocated', and the JVM to keep that reference data.

 If in-use memory is deallocated, then it means somewhere along the line it's been dereferenced; by moving out of the method scope, or accidentally setting to null somehow, etc.