Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Topic started by: xenthorious on March 25, 2005, 10:57:28 pm
-
A bit off the subject, I'm super happy right now. I just FINALLY[/COLOR] got OpenGL libraries sucessfully working with Java. I can do OpenGL Programing under Java now. I'm working on getting JSDL (Java for SDL) libraries installed next. I'm sorry if this is off the subject, but I been working this thing out for over 4 months. I'm totally siked! :)
-
Lol.
Awsome. I'm also a Java programmer. :D
I havn't gotten around to learning the OGL libraries for it though.
So what were you planning to do with it?
-
Chrome is a game of which was made by Java around the year 2000-2001. It was finally published around 2002.
I plan to make games with Java.
I believe Java would be far more suitable for game developement because it is cross-platform compatable. C++ is as well, but requires lots of code adjustments to work between each and every system. Java does not require code adjustments.
I believe OpenGL is a far better library then DirectX. I also believe that focusing on OpenGL opens more cash-flow for companies, such as Blizzard Entertainment. I say this because by developing a game for OpenGL, the software can be used on Windows, Mac, UNIX and Linux.
If you combined the universal use of OpenGL, and the Universal use of Java, I see more money, less headaches, greater security. Another thing that bothers me about C++ (Or C#) is the .Net. There are some serious security issues with it. Java can work under MONO, which works much the same as .NET without the security issues.
I believe Java is easier to use, if you can get past learning it. C# is pretty much the same thing as Java as far as Syntext goes. In addition, powerful tools, such as Netbeans is free for Java Programing. MS Visual C++ is not.
In a nut shell, I see Java vs C++ more the same as I see Linux vs Windows. I think C++ is fantastic and I know it was not made by MS. But I also see C++ as more work and less cost efficient.
That's my 2 cents.
-
The problem with Java however is that it's inherently slower than C++. Yes you can write games in it and pretty good ones at that but if you're really pushing the machine then Java isn't the right language to use.
That said C took over from assembly because it was easier to use, with machines getting faster it could happen again but I can't see it happening any time soon.
-
I use Java - hell, my job is programming in Java, at least until next week - but I wouldn't use it for games programming. Problem with Java is that the interpretative nature of it (the virtual machine abstracts out hardware differences and converts java to VM bytecode to machine code) both creates a slowdown, and locks out control and optimisation over machine-level details. And it's these things you need to work with to maximise speed.
That said, there is a bit more work been done with, in particualr, graphics on Java - there's support for DX and OGL (both directly and via Java3D libraries), and AFAIK support for using GFX hardware to speed rendering.
But I don't think you'd be getting anywhere near the same level of optimized performance with Java as you will with C/C++ ever (but overally performance will improve to a state it doesn;t matter).
I'm also intending to learn OGL, but I'm planning on learning C/C++ alongside. The only Java graphics programming I've done, has really been in very basic 2D mainly using my own libraries, which are crap. :)
-
Basically what I was going to say but I couldn't be bothered to explain it all :D
BTW We're going to need to get an admin to split this off to somewhere cause it's completely OT and in an important thread.
-
Hahaha! :lol:
I don't blame ya. I was way to excited about my sucess.
Hey, can these plug-ins be made in Java?
-
Originally posted by xenthorious
Hahaha! :lol:
I don't blame ya. I was way to excited about my sucess.
Nowt wrong with that :) I've been meaning to learn OGL with java as well.... actually intended on designing a single simpl game and implementing it in 3 methods; java+OGL, c++ and OGL, and a hybrid using c++ code for the graphics engine and java for the game engine (idea being that you could replace the graphics engine based on the platform - i.e. a nice 3d-fixed-view engine for an RTS on Pc, and use a simpler 2D engine for a PDA version, yet keeping enough common code to allow multiplayer to occur between both)
Hellish finding the free time, though...
Originally posted by xenthorious
Hey, can these plug-ins be made in Java?
Max plugins? I think they're written in a max scripting language.
-
lols cool.
There was some guy making a Java game engine. He had it highly optimized which was quite surprising how well I got it to run with an insanely high amount of poly's on screen.
True though, that there wasn't much else other than landscape, and about 300 fighter planes with 2-3 variants.
But still, for SMALL games, Java would kickass.
I've been meaning to learn C++, but its a difficult thing to be self taught...
Actually, I might as well say here anyway, but I was intending on writing a small app for someone in my line of modding when it comes to FSO.
I spend a lot of time photoshop -> wpn tables -> test ingame ->tables-> test ingame etc etc,
I want to cut the test ingame part out.
So you have a table reader that reads the weapons then renders what it will look like ingame, and also another window where it shows what it will look like at its max fire rate, and other details.
Would save alot of time messing around...
-
I was thinking, and here's my thoughts:
>C++ and Java can work on any system, but only java can execute on any system without changes.
>Why is C++ different, and how could we change C++ to be the same as Java without losing the performance difference?
>What is java known to be good for: Middleware.
>So if Java is good to be known for middleware, but middleware and the way Java works, degrades performance, how can we eliminate this?
Then this simple word came through my mind; Polymorphism.
How is this one method of programming so valuable in this circumstances?
Correct me if I'm wrong, but the biggest cause for why so many values in C++ need to be changed is because of how the program with associate with the operating system. So let's say, we made a Java program that operated as a System Ananlist, which evaluated everything on the operating system of which it felt the program would need. Let us say, it collected the information, and after feeling the program could run; passed the information to a C++ program which compiled the information to an understandable format for the program by working directly with the java program. The C++ program then instanciate the values from a script file of which that first C++ program generated. At this point, the Java program and the first C++ program would be shutting down. After the values were pulled, the program would then go online, and operate with the operating system directly based on the values it found on that script file. Java would ultimately be the responsable data member of which allowed C++ to work on any computer without the limitation of slow performance from how Java works.
In a nut shell, if Java would simple collect the information of the operatign system, and have the first C++ program compile it to a usable data, then final and main program could operate on any operating system because any value of difference between each and every operating system would be made the same.
Does this sound like a valid hypothephis?
-
C++ is inheirently more flexible and will probably be around for a very long time. Its also more stable and resource efficient.
I say stick with C++ but thats just me. Make your own choice.
-
If you build from the ground up to be portable, it's really not that hard to run a C++ program between two computers. If you wanted to write a game to run on a PDA or something, write it for Linux and keep the graphics code separate from all of the game do-stuff code. :D
Also, there's virtually no difference between C++ and Java when doing mathematical calculations (Under windows, at least). I think Microsoft has some sort of proprietary program that converts Java files to native code when you start them.
-
Java can't run on any system without changes always.
It can do that, if you design your program to do so.
But if you design your program correctly (laughs) with UML etc, then the basic outline of classes etc should be the same between Java and C++. But there are still quite a few changes between them.
C++ for example doesn't have such a strict heirarchy to follow.
But hey, if you goto do a small project in Java xenthorious, I wouldn't mind helping out or being a part of the design / implementation. :)
I've been meaning to develop some small time apps of my own, but havn't touched Java in a long while...
-
Originally posted by xenthorious
I was thinking, and here's my thoughts:
>C++ and Java can work on any system, but only java can execute on any system without changes.
>Why is C++ different, and how could we change C++ to be the same as Java without losing the performance difference?
>What is java known to be good for: Middleware.
>So if Java is good to be known for middleware, but middleware and the way Java works, degrades performance, how can we eliminate this?
Then this simple word came through my mind; Polymorphism.
How is this one method of programming so valuable in this circumstances?
Correct me if I'm wrong, but the biggest cause for why so many values in C++ need to be changed is because of how the program with associate with the operating system. So let's say, we made a Java program that operated as a System Ananlist, which evaluated everything on the operating system of which it felt the program would need. Let us say, it collected the information, and after feeling the program could run; passed the information to a C++ program which compiled the information to an understandable format for the program by working directly with the java program. The C++ program then instanciate the values from a script file of which that first C++ program generated. At this point, the Java program and the first C++ program would be shutting down. After the values were pulled, the program would then go online, and operate with the operating system directly based on the values it found on that script file. Java would ultimately be the responsable data member of which allowed C++ to work on any computer without the limitation of slow performance from how Java works.
In a nut shell, if Java would simple collect the information of the operatign system, and have the first C++ program compile it to a usable data, then final and main program could operate on any operating system because any value of difference between each and every operating system would be made the same.
Does this sound like a valid hypothephis?
@grug
Java is intended to be machine-independent, though. Whereas C/C++ that's left up to the programmer (in Java any problems are basically a maturation issue).
----
The pain-in-the-tits aspect of C, IIRc, is handling memory allocation, pointer, etc; at the same time, that's where you can finetune performance, which is why odds are a well-written C/c++ program will be faster than a well-written Java one.
The aspect of speeding up java on machines by compiling to assembly is a fairly simple one, albeit relying upon optimizing compilers. The main problem, IIRC, is that Java doesn't run in that way. It runs over 2 stages; java bytecode on JVM, and JVM on machine. If you switch to compiling directly to machine code, then you move back to the C++ model (so why abstract out any machine details?) - but it means you have to compile on every machine.
That's a problem - one of the main advantages of Java is not only that a class file will run unaltered on multiple architectures, but that a distributed system can dynamically distribute and run those classes. for example, agent systems (mobile code that moves and executes between hosts). Or what I've been working no for the last 36 weeks, which will require (for lack of a better term, and to avoid giving patent info away) servers to be dynamically and rapidly relocated to new physical hosts.
In all those cases, requiring recompilation sacrifices (switch) performance, and also places external requirements upon the host environment. You go from 'write once, run anywhere', to 'write once, run anywhere which has the right stuff'.
Move to - concretely- supporting local compilation, and you risk sacrificing this ability. And you lose one of the reasons for selecting Java over, for example, C or C++.
Ultimately, if you want to maximise Java performance, what you need to do is optimize your bytecode, and hope Sun optimizes the arse off of the local JVM.....
NB: not really fair to compare C++/Java - both have different purposes, different stages of maturation and use. It's been suggested to me (by professors nonetheless), that there's increasingly less benefit learning C++ as an adjunct to Java compared to C. In the business world, that may be true.
-
java :ick:
What I really think is that you can't compare a compiled language, such as C/C++/Pascal/whatever else, with an interpreter, like perl/php/java. Indeed, there are different purposes for these languages. I think I agree with Aldo on this.
And for great games, like Freespace you can't use Java :D
-
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.
-
There are ways to remove features such as this without having to use the garbage collection. Also, though not garenteed, if you set all processes to minimum priority, you increase the opitunity of garbage collection. So let's say between stages of each part of the game, you put all processes to sleep for 3 seconds. That's 3 seconds garbage collection can conclude it's job.
Again, there are ways to avoid stuff like, texture mappings, to be handled by the garbage collection. It all comes down to how you program the code.
-
Originally posted by Grug
But hey, if you goto do a small project in Java xenthorious, I wouldn't mind helping out or being a part of the design / implementation. :)
I've been meaning to develop some small time apps of my own, but havn't touched Java in a long while...
I do have a small project in the works, but it is unrelated to Hard Light Productions, and/or OpenGL. If anything, it is a client-to-server console of which operates and maintains a NWN server. http://nwn.bioware.com.
I am totally new to Java; just finished learning about how to write stuff to files. But I can make a GUI like a pro, thanks to tools I use. =)
Here's some examples:
(http://agdse.game-host.org/serverConsole001.JPG)
(http://agdse.game-host.org/serverConsole002.JPG)
(http://agdse.game-host.org/serverConsole003.JPG)
I have plug-ins for 3DS to make models for NWN. If this project finishes, I might be tempted to putting in a NPC spawn controller, which would require the use of OpenGL libraries to display a small sample of each NPC in 3D format.
In addition, this software would need to be used directly on the server itself. I may be tempted to putting in some network interfacing, so it can be used remotely from the server.
Anyways, this is a bit off the subject, but you asked, and I offered.
-
Originally posted by xenthorious
There are ways to remove features such as this without having to use the garbage collection. Also, though not garenteed, if you set all processes to minimum priority, you increase the opitunity of garbage collection. So let's say between stages of each part of the game, you put all processes to sleep for 3 seconds. That's 3 seconds garbage collection can conclude it's job.
Again, there are ways to avoid stuff like, texture mappings, to be handled by the garbage collection. It all comes down to how you program the code.
hah.. garbage collector... /me pukes :P
-
Originally posted by PhReAk
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).
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.
All that said I don't think Java is a good language for writing games in.
-
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. :p
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? :D
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. :blah: But it would seem overall that the higher level of control is worth it.
-
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...
-
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
-
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.
-
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. :)
-
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 :D
*no, not that CAD :) - Computer Architecture and Design it was, 2nd year class in the low-level architecture.
-
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?
-
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)
-
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).
-
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 :D
-
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 :D
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.
-
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.
-
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.
-
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
-
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.
-
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.