• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
MasterQ

Java is fast?

111 posts in this topic

Quote:
Original post by jfclavette
Of course. I was talking about the PC.


That's not an excuse to ignore the industry as a whole.

Quote:
Original post by jfclavette
That's why you have to use an extension for pretty much anything that doesn't have its roots back in the nineties


There's no correlation between the use of extensions being underdeveloped.

Quote:
Original post by jfclavette
Why the studios go trough the pain of converting their OpenGL code to D3D on the PC.


It's the major 3D API on windows. It doesn't mean that OpenGL isn't undersupported just look at OpenGL at the GDC.

Quote:
Original post by jfclavette
Meanwhile, I'd still like to see how Mono is underdevelopped.


It a new technology. C++ used to just be C with objects and it took time to reach its current level of development.

...Man this topic has been derailed.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by The Reindeer Effect
And Lazy Foo, you need to keep in mind this is website is populated mainly by hobbyists who do not have access to DS, PSP, PS2, GC, Rev, or PS3 devkits. Windows is the most common target platform, likely followed by linux. PC developers can take advantage of existing infrastructure (such as Java), whereas I'm supposing that a console developer is very limited and has to make a choice between additional systems programming or just getting to work on the game.


It doesn't really matter who or what has access to it when the argument is whether or not OpenGL is used in the industry.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Lazy Foo
It doesn't really matter who or what has access to it when the argument is whether or not OpenGL is used in the industry.
On a console, you do not have a choice. On Linux or OSX, you do not have a choice. Therefore, examining OpenGL or the other respective APIs for those platforms is a meaningless and ultimately pointless exercise.

We then come to the Windows x86 platform, where you'll find Direct3D dominates. Draw your own conclusions as to why. I have my beliefs, but they're not terribly relevant.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Therefore, examining OpenGL or the other respective APIs for those platforms is a meaningless and ultimately pointless exercise.


1) All internet arguments are pointless.

2) When the claim "OpenGL is not used widely in the industry" it doesn't not matter why or how, all it matter is that it's used widely period.

When the whole industry is taken into account and OpenGL is used widely, "OpenGL is not used widely in the industry" is proven to be false.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Lazy Foo
Quote:
Original post by Promit
Therefore, examining OpenGL or the other respective APIs for those platforms is a meaningless and ultimately pointless exercise.


1) All internet arguments are pointless.

2) When the claim "OpenGL is not used widely in the industry" it doesn't not matter why or how, all it matter is that it's used widely period.

When the whole industry is taken into account and OpenGL is used widely, "OpenGL is not used widely in the industry" is proven to be false.


Things are a bit (as in significantly) more complex than you paint them. There is no one language or API that is used, rather, what gets the task done most cleanly efficiently is used. Python, lua, xml, C++, proprietary language with C derived syntax, to name a few all find their place in the development of modern games. On the x86 PC you will find that the only people who still bother with/focus on OpenGL are academics who feel it necessary to make everything as difficult for themselves as possible.

MasterQ, do not worry about which language will dominate the market in x years, increase your skill by learning programming [concepts] in languages such as C# or Python (if games i suggest managed direct x 9 with c#)...when the time comes, you will find that it does not matter what language is in vogue, because you see, you will be able to program in a truer sense of the word. :)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Lazy Foo
When the whole industry is taken into account and OpenGL is used widely, "OpenGL is not used widely in the industry" is proven to be false.
Is it? OSX and Linux are sideline players that don't register on the meter. PSX, PS2, and the GC don't use it. (They use similar looking APIs, but those APIs are not OGL.) I'm not up to date on the APIs that the NDS and PSP use, but even if they are OGL, they form a fairly small segment of the market (certainly they're dwarfed by the home entertainment consoles). Neither Rev or PS3 are out yet, so they don't represent the state of the industry now.

In fact, if you run the numbers, you'll find that the PS2 API is the most used, simply due to the sheer vastness of the sales figures and the number of published titles. Again, this says nothing about the quality of their API (and indeed most of the stories I've heard from the trenches are somewhat grim).
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
They use similar looking APIs, but those APIs are not OGL.


If you completely seperate OpenGL ES from OpenGL.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Lazy Foo
Quote:
Original post by Promit
They use similar looking APIs, but those APIs are not OGL.


If you completely seperate OpenGL ES from OpenGL.
The PSX and PS2 do not natively use OpenGL|ES.

[EDIT] I'm seeing vague claims that the GCN does use OGL|ES. Until that claim is verified or debunked, I will make no assumptions either way. Even if it does, it's still not that significant. Furthermore, the lack of mention of OpenGL on wiki's page for Gamecube leads me to seriously doubt that the system uses it.
0

Share this post


Link to post
Share on other sites
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.
Also by JavaVM they refer to a virtual machine? How can a virtual machine language can beat assembly machine language?
Is java faster then assembly too?
This sounds redicoules.
What is the explaination that java is faster then normal C?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by nullsmind
Java is definitely fast for most modern desktop games. For example, here are some links to some great 3d games developed in Java:

http://www.runescape.com
http://www.bytonic.de/html/jake2.html
http://www.oddlabs.com/
http://www.megacorpsonline.com/
http://www.wurmonline.com/
http://www.flyingguns.com/


I think the discussion is not if you can make in Java nineties games with todays hardware, the problem is if you can make today games in Java. Java VM has many advantages and lots of disanvantages. JIT generated code, can be, in some situations as fast or maybe faster than C++ native code, but the cost in terms of launching time is enormous, an gargantuan memory footprint and a lot of time to get a large app running with compiled and optimized code.
I did a benchmark using jake2, comparing native version and java one. Java version used 10 times C memory. Exactly 100 megs compared to 10 megs of process image. And we are talking about a 7-years old game with a really small code if compared with today games. It also lost about a 10 percent of performance of C version, running a GPU constrained game.
Chrome used Java for game logic, i tried it, and the time needed to launch a level was intolerable. I think non compiled Java code wont be ever used to make state of the art games.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.
Also by JavaVM they refer to a virtual machine? How can a virtual machine language can beat assembly machine language?
Is java faster then assembly too?
This sounds redicoules.
What is the explaination that java is faster then normal C?


There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.


0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by The C modest god
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.
Also by JavaVM they refer to a virtual machine? How can a virtual machine language can beat assembly machine language?
Is java faster then assembly too?
This sounds redicoules.
What is the explaination that java is faster then normal C?


There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.

I think I know why it might be faster, but I need to check it.
Perhaps the one that checked the performance of tje java application, checked only the time the actuall java code was running.
However, it didnt take into consideration the time the VM code was running and doing all sort of stuff.
However, I need to know how you measure how much time was passed in java.
The code size does not count, because you need to take into consideration also the code of the virtual machine running the java application
0

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
How do you get the time in miliseconds from the hardware in java?


Use System.nanoTime();

[from the JDK1.5 docs]

nanoTime

public static long nanoTime()

Returns the current value of the most precise available system timer, in nanoseconds.

This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

For example, to measure how long some code takes to execute:

long startTime = System.nanoTime();
// ... the code being measured ...
long estimatedTime = System.nanoTime() - startTime;


Returns:
The current value of the system timer, in nanoseconds.
Since:
1.5

0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.


That has no sense. You will always execute compiled code, thats obvious, bytecode is going to be compiled to native code or interpreted by a native progam, ¿whats the difference?. So bytecode size is not an issue when talking about cache sucess. And please, do not take too seriously all that java vs c++ stuff, usually there is a clear will to alter the benchmark.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by Anonymous Poster
There could be a number of reasons. One could be the codesize, JavaVM bytecode can be smaller compared to compiled C++ code. So there will be a bigger chance for Java bytecode to run out of the processor cache. The same goes for the memory model of Java.
This is a general rule for interpreted code compared to compiled code. In former days the CPU cache was to small, by today this is different.


That has no sense. You will always execute compiled code, thats obvious, bytecode is going to be compiled to native code or interpreted by a native progam, ¿whats the difference?. So bytecode size is not an issue when talking about cache sucess. And please, do not take too seriously all that java vs c++ stuff, usually there is a clear will to alter the benchmark.


Well, it's a matter of statictics, good designed Java programs compared to good designed C++ programs have a bigger chance of getting better cache results. Due to their tighter class structures.
But I surely argee that comparing ordinary "middle-of-road" programs, C++ programs will finish first.
But then.... I remember the time (I am getting old :-( ) when I had the same discussion while defending my assembler programs against those new C programmers...... tja...

Speed isn't everything..... Java programs are much easier to program and to maintain....
But that's my opinion ;-).



0

Share this post


Link to post
Share on other sites
Quote:
C#: Doubt it. A proprietary language will never take over an entire industry so unless microsoft allows an open standard I don't see it happening.


.NET is an open standard.
http://www.mono-project.com/ECMA

Quote:
Ok an open standard that doesn't suck.

and by doesn't suck, I mean something where I can easily take a language's code and use it where ever I want.


You can use it on many platforms.
http://www.mono-project.com/Supported_Platforms


Quote:
Mono is in it's infancy, and needs much more support.


It is a stable release 1.1.13.6. It has support form Novell.

At LinuxWorld 2006 in Boston, Mono won the award for "Best Application Development Platform or Tool".
http://www.mono-project.com/news/archive/2006/Apr-05-1.html



0

Share this post


Link to post
Share on other sites
Just to note, J# is a .NET language and will therefore compile to IL and be JIT compiled, and will run as fast as any other .NET language.

I don't know much about java but presumably it wouldn't take too much effort to port it to J#?
0

Share this post


Link to post
Share on other sites
The code for fibunachi given in that article is really faster on java.
But who does recursion in a place that needs performance?
I checked a non recursive fibunachi function in both java and Visual2003 C++, made it run 10000 times.
The result is that it took java 6.1 seconds and C++ 5.8 seconds
Maybe I dont know how to optimze java, I just ran it using JBuilder.
Are there super optimization to java? or the way I ran it is almost the most optimzed way to run a java application?
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Well, it's a matter of statictics, good designed Java programs compared to good designed C++ programs have a bigger chance of getting better cache results. Due to their tighter class structures.
But I surely argee that comparing ordinary "middle-of-road" programs, C++ programs will finish first.
But then.... I remember the time (I am getting old :-( ) when I had the same discussion while defending my assembler programs against those new C programmers...... tja...

Speed isn't everything..... Java programs are much easier to program and to maintain....
But that's my opinion ;-).


I dont see so easy the cache results performance advantage in the case of java apps. In fact the very large memory use in java implies lesser spatial reference, and thus a larger set of cache blocks, and that means more cache faults.

Of course, java development is faster than C++, but in games the performance is a fundamental constraint, and if it isnt fulfilled, the productivity gain doesnt matter.

0

Share this post


Link to post
Share on other sites
I like C# but I like C++ more. I will be very upset if it's replaced by C# or Java.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by The Reindeer Effect
JIT code can outperform statically compiled code in certain situations specifically because there is runtime information present, even all the whole-program analysis in the world cant provide the sort of procedure-branch statistics that allow a hotspot compiler to optimize.
Some C++ compilers can also use branching statistics to optimise code, using what they call profile-guided optimisation. It takes an extra compile and a test run, and I suspect that JIT compilers can do a better job of it, but I'd be interested if anyone knows of any benchmarks comparing their performance.
0

Share this post


Link to post
Share on other sites
Hm, a page over or so, someone (forgive me for not bothering to check...it's getting late) said something about -why- runescape is programmed in Java. Along the lines of that it is not a commercial game, yadda yadda yadda.

Truth is, Java is just so much easier to use for cross platform web apps -- It -is- what it was designed for after all. Runescape is a cunning application and has decent load times as long as the user has even modest broadband. Considering the amount of kids etc who play it, I'd say it's quite successful (even if that is because it is free).

~Shiny.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
There is also an article there, that Java is faster then normal C.
How is this possible? C is very close to assembly.

So? Who said assembly is fast? Try writing a small program in ASM, do the same in C, and see which ends up fastest. I'm willing to bet C will win. Because the compiler is a lot better at managing the complexities of code scheduling on todays cpu's.
ASM *can* be fast, just like C or Java *can* be fast. Anything running interpreted code has extra overhead, so it can never be quite as fast, but with JIT, there's nothing to stop Java from being fast.

Quote:

Is java faster then assembly too?

Again, why not? Depends on the java code and the asm code you're comparing. Writing in asm can produce terribly inefficient code if you don't know *exactly* what you're doing.
Writing in Java makes it a lot easier to get acceptable performance.
0

Share this post


Link to post
Share on other sites
I think people need to realize that Assembly, C++, and Java are all COMPILED to the SAME language (machine). This is what makes it possible for java to outperform assembly. It depends on if that java compiler generates better code than the assembly programmer.

So they all use the same language. If the Java compiler is superior to the C++ compiler, then java wins. And vice versa.

Now if interpreted java is used, then it's going to be slower than C++. Also the article mentions the server vs. client JVM. If your using the client JVM it will be slower than C++.

And runescape IS a commercial java game. You can buy a prem account and get extra featrues. They let you play for free to attract customers and end up getting more paying people than if they required payment from the start. Tibia is a C++ game and uses the same business model. The language has nothing to do with it.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0