Yo dawg, I herd you like Minecraft, so I put an ALU in your Minecraft so you can play Minecraft while you play Minecraft. B)
minecraft
- Thread starter TreeLach
- Start date
Yo dawg, I herd you like Minecraft, so I put an ALU in your Minecraft so you can play Minecraft while you play Minecraft. B)
Twisted
Still Fresh
- Joined
- Dec 27, 2005
- Messages
- 72
I guess they'll need to be doing it in multiplayer - only blocks within a certain distance of the player are "active" in single-player. OR, they could/should investigate the vertical possibilities, and end up with a CPU that works properly when the player is standing in the middle of it, pulling switches 
MarkoeZ
arr matey?
Wow! I got bored with minecraft just a couple of months ago. But reading this topic, a LOT seems to have been changed/added since then.
Looks like i'll be wasting some more time on it then
And pandora version, not necessarily 100% fullspeed, but playable, would be awesome indeed!
Cheers!
MarkoeZ
edit: grammar
Looks like i'll be wasting some more time on it then
And pandora version, not necessarily 100% fullspeed, but playable, would be awesome indeed!
Cheers!
MarkoeZ
edit: grammar
Last edited by a moderator:
Looks like a custom minecraft client for Android is progressing along nicely. http://www.youtube.com/watch?v=s-9K8ZQTOMY. Performance actually looks pretty decent.
I know Pandora is very different, but it is proof of concept that minecraft CAN run on handhelds.
I know Pandora is very different, but it is proof of concept that minecraft CAN run on handhelds.
- Joined
- Dec 8, 2005
- Messages
- 6,603
- Age
- 41
- Location
- UK
- Website
- pokeparadox.itch.io
- WEBSITE
- https://github.com/pokeparadox
- YOUTUBE
- pokeparadox
Please remember you can adjust the draw distance and gfx quality...
I reckon Minecraft for Pandora is do-able.
I reckon Minecraft for Pandora is do-able.
But, really, why Java ? Unlike Java; languages such C, C++, Fortran can give dramatic speed boosts to a particular platform. If you compile for ARM - optimize for NEON, if you compile for PowerPC - optimize for Velocity Engine ( AltiVec ), if you compile for CellBE - optimize for SPU elements, etc. Java can't do that. Compiling is as easy as hell for people who know how to do that. Make the game in C/C++/Fortran; compile it for x86, ARM, i386, etc and let the people buy binaries + libraries for their own platform. x86 is not the only arch that exist - there are many others. ( I had a little bit of experience with patches, diffs, modifications in C sources, etc. C rules ! )
)
Last edited by a moderator:
Fortran! And you think Notch gets weird looks because he wrote the damn thing in Java? :lol:
- Joined
- Jan 18, 2010
- Messages
- 11,418
There isn't enough love for Cobol either, how about ALGOL...
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Because Notch knows Java. Notch likes Java. Java works suitably well for what it was meant to do in this case. He could have just as easily written it in C++ and DirectX, and then not only would it have no chance to run on the Pandora, it wouldn't run on Mac or Linux desktops either (except maybe with Wine, but you shouldn't count on Wine)
darfgarf
Well-Known Member
if dx was the case, java is the nicer alternative XD
Well, it is his opinion anyway.
Write in C/C++ ( not much difference ) and OpenGL ( Who needs DirectX, when OpenGL works everywhere: Windows, Mac, Linux, etc ???
), and here you go. B) Such binaries would work on PC, Mac ( even G4, G5 ), Pandora and even my 3d acceleration-less PS3 YDL if you add SPE support. Most linux best staff is in C anyhow. It always was. The good thing about Java is that you don't need to compile it, but there is no benefit for any other-then-x86 arch. Intel, AMD, VIA, PowerPC, POWER, CellBE, ARM, SPARC, etc ... They are different processors and have different optimizations, which Java so brutally ignores.( You can't argue - C++ will always > Java/other scripting language, because machine-dependent code > machine-independent one B) )
sebt3
homebrew player (P. & C.)
Because OpenGL offer feature parity with DirectX, right ?
I've yet to found the documentation for the API for the joystick handling with OpenGL, or for 3D sounds... Maybe you have it ?
So what does javac binary ?
So There is no hardware optimized JRE. I wonder what Jazelle think about that...
Java is not a scripting language. It can even be compiled into native binaries using gcj. But sure ASM is way better than C++. That's why we are all running zsnes on our pandora
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
A binary compiled for x86 Windows will run on x86 Windows only, and maybe x86 Mac and x86 Linux with a compatibility layer. Even if he had written it in C++ with OpenGL and SDL and OpenAL, what it runs on is still limited by what the developer chooses to compile it for.Write in C/C++ ( not much difference ) and OpenGL ( Who needs DirectX, when OpenGL works everywhere: Windows, Mac, Linux, etc ???
And even if he had chosen C++ and OpenGL, and he decides he'll do the work to compile it for as many platforms as he can, we're STILL out of luck because the Pandora does not have full OpenGL support: it has OpenGLES.
I am not in any way a Java fanboy, I'm simply pointing out that the statement "if it had been written in C++ instead of Java it could be made to run on the Pandora" is false because there are a lot of other things that would also have to happen before it could be made to run on the Pandora, and in fact a switch to C++ simply because you disagree with the usage of Java could result in an even worse situation then the one we're in now.
edit:
Actually, you can, and some people have, quite successfully, run benchmarks to show that at least some times Java will perform better than native code.
Last edited by a moderator:
Joystick and 3D sound ... you say it is much more important then ability to use the driver on any OS/platform you want ? For me, as for all linux users, the ability to be able to play game on any damn thing I want is a top priority. That is why most GPUs now have OpenGL support - both closed and open hardware.
Wait, so what was the language used for the game: Java or JavaScript ?
JavaScript ( what I was talking about ) doesn't need to be compiled and doesn't in any way depend on arch ( other then resources ).
Java programming language ( high level ) is compiled.
If the game was created using Java language, then it does depends on the arch, and I see no reason why it wouldn't run on Pandora. :blink: ( Just compile damn ARM binary - that is all. )
@Stan, but do you believe those benchmarks ? I mean, he states Java is faster then optimized native code. :blink: ( Doesn't make sense, especially the word "optimized". ) In any case he uses Intel ... so common platform. He would prove something by running benchmarks on a number of platforms, don't you think ?
Btw he is wrong:
-O2/-O3 optimizes for speed
-Os optimizes for size
EDIT: Other guy after working with such benchmarks came to another conclusion - C++ wins.
"C++ is well over twice as fast as Java -s."
http://www.w3sys.com/pages.meta/benchmarks.html
Last edited by a moderator:
Of course. :lol:
EDIT:
CPU - must handle
GPU - supposed to handle ( OpenGL 2.0 ES support ? it is soft anyhow )
RAM - .........
Last edited by a moderator:
WizardStan
Mega GP Mania
- Joined
- May 24, 2008
- Messages
- 16,731
Java is compiled, but it is compiled to byte code: ie, it is not compiled to native machine language the way C++ is. This byte code, while smaller than the source, still needs to be "interpreted". I put quotes around interpreted because it is not interpreted the way a scripting language is, at least not anymore. There was a time that it may have been so. Now a days, the JVM (Java Virtual Machine) takes that byte code and turns it into native code at run time. This is what allows someone to compile a Java program once and run it on many different systems: the JVM does the work of turning that single set of byte code and turning it into native code. It's kind of like running an emulator with a dynamic recompiler, except even better because the JVM was designed around being portable from the start so includes a bunch of helpers that traditional CPU emulators don't have.
One example: the C++ compiler makes a best guess as to what optimizations will actually help, and which will hinder in different circumstances; yes, there are optimizations that will make one piece of code faster and another piece of code slower. The C++ compiler does a pretty good job at guessing, but in the end that's all it is: a reasonable guess. The JVM, on the other hand, is able to manipulate the native code it has produced while it is running. This can result in a slightly better runtime for Java than for C++. CAN, I say, but not always, and some C++ compilers might be better than others.
Another point where Java can be better than C++ is in its memory management. If your C++ program is creating and destroying a bunch of objects, it will be creating and freeing memory a lot, actions which have their own overhead. Java, with its garbage collection, has its own pool of memory to pick from and doesn't free that memory right away, instead waiting (in theory) until it needs to or it is more convenient to do so. So this create/free in a tight loop that C++ might do would have significant overhead that doesn't exist in Java. Java would have to free the memory eventually, but it hopes it can wait until a time when not much else is going on, or if it must free a bunch up, it can do so in an efficient block way rather than a few bytes at a time.
There are other ways that Java can theoretically outperform native compiled code in C++, but I don't understand them enough to explain them.
And he doesn't have to run it on different platforms. The point of the benchmark was to show that the statement "C++ compiled code is always faster than Java" is a false blanket statement. Compiled native code may be faster in a lot of ways, but it is no longer the case that it is guaranteed to be faster, and you should really look at your use cases before blaming the tool
The good thing is that you have explained those reasons.
So, in the end, the time has changed and Java is no longer called "slow, memory hungry" language as everyone stated to me. All people I knew were choosing C++. ( And; if you type a name of popular open source program into google like mplayer, gzip, tar, vlc, bzip, xmms etc ; you will find that all of them ... are written in C/C++. Devs are not going to abandon it and write everything from starch, they will further optimize their code, just like GNU team will improve gcc and g++. )
Klaue
Member
- Joined
- Aug 4, 2009
- Messages
- 240
It's an old bias many people still hold dearly. It is true in some instances, but not in all of them. A normal java prog will be just as fast as a C++ one most of the time.
Even most of the Benchmarks, be it for or against java, deal with stuff in a millisecond range. If you don't do such stuff in a big loop, the time difference is not even observable for a human user.
It also depends on the external code you use. Take for example md5sum, which was done in C or C++, as far as I know. It's one of the basic binaries you find on pretty much every linux system, yet the "Fast MD5 Implementation in Java" actually outperforms it. But then again, the fastest mode of FMIJ uses native code and the standard java MD5 mechanism is slower than md5sum. So in short, the not-as-optimized native code runs faster than the not-as-optimized java code, but slower than the optimized one.
Since no one probably always reinvents the wheel and uses libraries and stuff to help him, the speed of the program also always depends on the speed of that external code. If you used md5sum in a C++ project and someone else used FMIJ in java, chances are his stuff would run faster (assuming, of course, that the MD5-summing would be a mayor part of the project).
However, it also always depends on the circumstances. Some stuff can be slower/faster or memory-heavier/lighter in java depending on the way you use it. For example, Strings in Java are UTF-16, which I think is great because it's a mayor pain in the butt to work with non-ASCII in vanilla C++/STL. But if you're handling a big pile of ASCII, then this will mean a huge memory waste in Java because instead of a single byte per character as in C++, java uses two and therefore uses the double amount of memory (it may be a good idea to instead build an ASCII-String-class in that case). On the other hand, if you're dealing with the same strings over and over again, you have to allocate and de-allocate memory for every single string in C++, while in java, two instances of the same string point to the same memory location. Something like
String y = "bla"; String x = "bla";
would therefore use the double amount of memory in C++ and waste time allocating.
But I digress..
You can't say "Java is slower than C++" or "Java is faster than C++", it always depends on what you do with it.
