Complete and utter nonsense. Minecraft uses OpenGL so it's by definition hardware accelerated.The reason it's quite heavy is simply because simulating an entire world is a lot of work for your CPU (not GPU). Have a look at dwarf fortress; that game is even more CPU bound thanks to all the pathfinding and liquid simulations.
Aside from that; Java used JIT compiling. Porting it to C++ would hardly have an impact.
It would be nice if people would not talk about stuff they know so little about. I have over 15 years of experience programming in Java and also wrote my own minecraft viewer. You can't compare MC to typical shooters that look very pretty but don't have to cope with simulating a fully destructable world.
nods. caveats noted and ignored apparently. examples ranging from comparison to DATABASE SOFTWARE not shooters which have the advantage of essentially precomputing and having human optimization passes done, already having noted the cpu bound nature(and lack of multicore development where the core load could be parallelized well) while highlighting the irrational additional bus stress of constantly pushing large volume data needlessly, and ponderings about actual java hardware acceleration bandied about in both IEEE articles and by sun and the openjdk teams themselves. oh yeah and in your directly quoted segment, what part of "mostly viewed as" in the realm of caveats added to a statement skipped by unnoticed? i pointedly never stated the common perception was correct. if i had we'd have been going down the "everything in asm 100% all the time because performance" logical herpaderp that crops up from time to time as well. java is just fine as a language, and when wielded well can be at near parity with most others. minecraft as an example product made with java was a small indie title to begin, so from that perspective it works rather well.
opengl acceleration of minecraft is not hardware virtualization or a dedicated bit of hardware for interpreting a language mind you, and as you kindly reinforced even were we talking about the same thing (i said virtualization not acceleration, acceleration was mentioned with respect to the "common view" only)the title is not exactly gpu bound in any case.
perhaps my taking the jvms' options to utilize hardware features like various sse* extensions, and considering a full hardware interpreter/compiler vs a software layer using some hardware functions was taking too much for granted, as was specifically differentiating between minecraft and the language it was made with.when i say hardware accelerated i mean it has dedicated equipment. if i have an audio device which uses cpu clocks to function, and compare it to a dedicated dsp chip based audio device, only the latter is actually hardware accelerated audio. setting aside strange middle ground for the oddball fpga based devices that reconfigure on the fly to service modem and soundcard with the same hardware(mostly extinct nowadays). i must remind myself or be kicked from time to time into so doing, that audience experience can sometimes be quite a long mile different.
simply because some things are "common" beliefs, lack of experience or lack of knowledge will lead even tongue in cheek references to the same into a hazard. which isn't even to say those beliefs are wrong, but frankly in relative terms the differences in code execution time between java and c/c++ when written with equivalent expertise will be negligible for most things of any reasonable complexity. the reactor planner is the sort of thing i'd be able to get an intro to vb student to churn out by the end of a semester if he wasn't slumming. i wouldn't exactly consider a rewrite improving its performance a huge leap. you could probably double it's performance metrics as an application even rewriting it in java. but hey, it works, isn't terribly buggy, and has been done, so let us say that reinventing the wheel in that instance is more of a mild nuisance, and that performance optimizations there probably aren't as critical given its use case.
the last title i went boring through that was java based was in fact terraria, and i pondered some of the same items therein initially, although with only two dimensions to work with the data sizes were commensurately smaller. there a system of multidimensional arrays were used,
which i suspect if i actually spend the time looking will be the case here as well seems like the chunk class and it's overloads handle things a bit strangely what with the independent regioning array for entities along a 16x16 y axis and the use of raw integers for each x,y,z then tagging on metadata and block info and lighting being yet another layer is odd compared to say a four dimensional array containing instances of the populating class information.it might actually be functionally doing exactly that, and seeing it as odd might just be my lack of specific java language experience and nuance or the 5 minute perusal( the nibble segment? the heck? and just what the sam hell is actually the driving logic for the view frustruming here, the frustrum calls seem .. abbreviated..).
i cannot definitively even say dravarden is flat wrong, as logically, populated or not if the coordinate exists in the loaded boundary region it must be initialized at the very least for the other passes.
so in spite of the nether only world generating a 128 high y axis region, the remaining 128 must be instantiated as air, receive a lighting pass, etc from what i'm seeing. air is a blocktype. observationally outside the code, given one can build there, the engine considers that top region above the nether as a valid spawn region, and mobs can spawn there, it exists and is tracked.
thus the note on the number of blocks to track per chunk remains, barring a function somewhere to explicitly void regions from handling that i simply didn't lay eyes on as yet, at the full volume. thats a lot of data to churn through volumetrically, and each of those 6 million per chunk locations isn't a simple bit being flipped on or off, its quite a bit more. all said and done while the texturemap push every tick is a needless strain on the system bus, and memory bandwidth, it seems a more than fair wager it still pales next to the raw data throughput for the block data being tracked in any given loaded region.
further given what it looks like is happening with block updates informing every adjacent block that's nearly multiplicative in work done.
but then again, sandbox. while one could simplify a cfd sim to work around the concurrent interactions complexities, this sort of thing requires a bit different tack.
a text mode roguelike (c'mon you know you've at least fiddled with trying to write one at some point) can be complicated enough( ever seen nethack bring a modern machine to it's knees? a floor with multiple mobs that summon other mobs, and extinction of many species that aren't summoner types. hurrah exponentiating workloads).
as to background however, i agree my experience with java is somewhat limited to some conjectural reading about and fiddling with a couple of games using it. were we discussing instead anything from basic, vb, asm, ladder logic, python, c/c++ and a smattering of others, i've taught them to junior level undergraduates. the further irony being a background in electrical engineering, not "pure" computer science. i'll also be the first to (abashedly) admit that much of my upper tier knowledge has gone somewhat to rot given overexposure to beginner level language instruction and underexposure to much beyond the same.
in any event if i ruffled your sensibilities in there, my apologies. i thought the modders are humans bit at the end would make the tone of the post clear as somewhat conversational with a bent towards tongue in cheek style humor, not raging iron man absolutist.
as a final note, i'm absolutely certain i'll have phrased something, or said something that will a) be taken wrongly and b) considered wrong, abrasive, or somesuch, by at least someone somewhere. i'd even wager someone somewhere going through that, seeing that i've taught at a collegiate level and having a fit over something or other. only human, sorry.
i'm all for being wrong on occasion, so long as it's not fatal, and not the same thing twice. it engenders not only learning on occasion, but also discussion and elucidation on related issues.
