Hey guys,I've written a new version of Minecraft
The game is open-source.
- Included with each game client is un-obfuscated source-code along with an intelligent Integrated game editor.
Game DownloadVer 1.2.3 | 12.5 megs
Comments Questions Bug-reports Ideas and Help are very welcome !
Thanks alot guys, Enjoy!
Additional Notes
About the games engine
Using C++ to handle rendering for performance, This engine assembled from scratch in Multimedi Fusion 2; a visual programming IDE.
A highly efficiant Just-In-Time embedded Lua script engine handles game-logic and also provides light-weight short cycle extensibility.About my motivations
As an 3D games programmer I was immediately tempted to write my own game client for Minecraft !
As an Redstone engineer I'm always driven to find new ways to tighten my grasp on the subtleties of Redstone.Thanks again guys
![Diamond T 4 ton truck [With Download] Minecraft Map & Project](https://static.planetminecraft.com/files/image/minecraft/project/2021/344/13871658-default_s.jpg)
DreamWanderer
DanielTNC
![Cat PM825 Cold Planer [With Download] Minecraft Map & Project](https://static.planetminecraft.com/files/image/minecraft/project/2021/710/13867174-default_s.jpg)
ardsan
Is there a similar feature here? can this be implimented as I use a Mac and pc, and if i can get both working with the old sorta web .swf that would be amazing!
I understand exactly what you suggest and yes you are absolutely correct, multi-threading is a great approach !
There are also other techniques which work within a single thread like working out all of a chunks geometry on the CPU BEFORE starting a new upload to the graphics card to minimize the time the GPU stalls while it listens to the CPU and also limiting the number of chunks you try to regenerate per second things like that can have fairly good success ( maintain a FPS above 50 while reloading ) but ofcoarse; multi threading is optimal.
From working at euclideon these last 6 months i've learned that there is little reason to use graphics cards to render voxel games at all - the software we use here is able to render the entire exploreable area of a minecraft map ( 2x10^6 by 2x10^6) just as fast as it renders one block.
I'm busily programming for the defense force at the moment ( which is fun ), but as soon as that's done i'm back to programming minecraft (voxel games) : )
Would you maybe like to see my source code? You can probably find allot of things that could be improved, especially in the rendering code. ;)
Send me a link when you get the chance!
You have clearly learned a whole lot of Lua!
I will need to keep reading the code for a while but with your blessing i'de love to make some of my own additions to the code and send it back to you ( along with a newer code editor )
Very impressed niels!
i just had to post it to a 3 month old comment
EDIT:
Ok I got some kind of World/Chunk interface going, but due to lack of documentation of what a function does, when it's called, the needed parameters and return values I can't really continue. Do you have some documentation? Also is there a way to find out in what world the player is in?
One simple approach is to flood-fill an area to see whether it is even hypothetically visable to the player ( eg it is open to the sky or it contains the player )
more advanced approaches can all but completely combat this problem but they require extreme graphics programming prowess - one very effective approach is to stitch faces together which are both connected and coplanar this drastically reduces the number of vertex's which must be rendered ( in a beta 1.8 minecraft map i reduced a 4kilometre square area from an utterly untenable 36 million polygons down to the easily displayed number of 180 thousand ) - this approach can be ever further improved by stitching non-connected coplanar faces such that the number of verticies becomes ABSOLUTELY tiny ( 900 polys while perfectly displaying the "normal view distance" in minecraft ) and indipendent of the complexity or number of blocks in the world - however if you push it that far the textures which must be generated for those connected polys become extremely bad for the graphics pipeline during the fragment shading stage and you become bottlenecked there instead - a happy mix of the connected and non-connected approaches can be used to acheive massive view distances on extremely out-dated computers... but it's very complex to use that technique ( from a programming/math perspective ).
ultimately graphics cards are relics of the past which just havn't yet died out - techniques similar to backwards-raytracing are currently limited by the resolution of the screen but are not limited by the size of or number of objects in a virtual world, as long as the number of things in our virtual worlds continues to increase and as long as the resolutions of our screeens continues to crawl or stand-still ( which seems inevitable given that our eyes arn't evolving improved fidelity at any noticable rate ) a tipping point is impending and people are not going to look back.
Interesting question you raised thanks again niels!
I am still working on it.
The Lua functions which handled chunks looked like the following.
Chunk_Load(id,que,x,z)
Chunk_Unload(id)
Chunk_Update(id,force)
Chunk_Modify(id,x,y,z,newblock)
If you're still working on the world generator then you might want to look at some documentation about the MCServer generator. Our developer just started an article where he explains how the generator from MCServer works(although it's currently only the biome generators :)) If you're interested then you can find the documentation here: link
Anyway it's great to see that you're still active. Keep up the good work. :)
Its nice to see you around here too : )
But one problem I'm having is that I can't break blocks generated by the terrain (i.e logs, leaves and grassblock). It's really annoying, as to really build anything I have to set it without any natural terrain, and that looks too artificial.
The programs support files and library's are embedded within the program.
OpenGL's API comes with the installation so you really don't need anything.
i heard Nvidia has a developer zone with CUDA Tools.
And im going to start learning c++ real soon :3
The memory required to define the blocks which must be drawn to makeup a Minecraft world; represents only a minute fraction of any graphics cards bandwidth.
The number of texels in a Minecraft scene remains bound thanks to mip-mapping. fillrate usage ( the dominant bottle neck on old cards ) has been slashed by replacing buffer clears with partitioned z-buffer offset access. ( which by the way ive learned is an absolutely excellent trade off when your world is made of large non-intersecting cube faces) And finally an early z-pass keeps overdraw to near 0%...
Put another way, Minecraft is not at all expensive to render with the powerful 3D APIs which have today become ubiquitous, what is expensive however is hard-drive access ! Which makes intelligent chunk loading currently the most important bottleneck.
Unfortunately I clicked cancel not submit and then proceeded to bang the desk and say Grrr !
So anyway, there is certainly room for improving the process of rendering which could come with ridiculesly cool side effects ( such as infinite view distance ).
Its awesome your going to learn ++, there is so much more ide like to say about it, but right now I must adjourn at good luck.
I ran some tests also. it appears there is the infinite view distance as you were talking about,(Tested on Large and Small).
It also appeared that you had a few UI bugs.
Other than that, Good luck Improving and hopefully Infinite worlds.