Minecraft In Its Entirety In Windows 95/98 Machines
This program is basically an beta recreation Beta 1.7.3 entirely developed in C89 Open Watcom V2.0 C code and uses only Open GL 1.1 Rendering. Newer versions of the program are even a hybrid between Beta 1.7.3/Release 1.2. This program was intended to run on Windows 95/98 machines, but it can also even run on newer windows. Documentation is included
Almost every implementations from the version was converted and implemented into C including world behavior. gameplay, visual style, GUIS, redstone/piston systems, "entities", and even able to load, render, and save actual Java worlds properly. The newer version supports enchanting, potions, newer blocks/items, and more. The custom rendering system, extensive frustum culling, lazy chunk updates, and more were key to achieving good performance and reaching hundreds of FPS in systems even in high render distances.
This program is intended to run on Windows 95/98 machines specifically, but can also run on modern windows and could be ported to other systems, it uses mcp43 for java files as reference and core boilerplates development as key with some conversion tools used, however much of the custom code implemented or even added and gl 1.1 rendering is described below.
When I first initially started this project, I used a tool to change the extensions of the java files from .java to .c while also deleting its main data along and also developed proper h files and unity manifests. However for some reason, it also left a bunch of junk metadata which I used as a bar to figure out the most importance of what implementations and code were needed to be added first to look and run like the real deal over time. Many of the files have just seemingly metadata, but many of them still have functional code and updated to run like the real deal. Files that were fully implemented and basically converted were called Direct C89 port of a java file. The entire program uses clean implementations and reverse engineering to prevent some level of copyright issues.
One of the key things actually developed, was the custom chunk rendering system and performance systems to make sure it looks and runs like the real deal. Extensive hidden face culling was implemented which hided faces of blocks not visible to the player. Another key thing developed was when the chunk geometry and its objects are compiled into Open Gl 1.1 lists, the CPU, instead of sending calls for every single vertices per frame which used to be really bad during development, but now only send a few calls to be processed, meaning the program uses its completed lists to render unless changes like block placing/breaking, lighting change, neighbor chunk changes, and more happens. The worlds uses the standard procedural terrain generation and Perlin and octave noises from the java version, biomes and their temperature code, standard placement of blocks like trees, grass, flowers, gravel, stone, sand, overworld/nether rendering, and more. The geometry has separated into three groups, opaque terrain such as stone, and dirt, clear geometry like water and ice blocks,. and cutout geometry which is basically objects/items that are seemingly 3d, but are see through like grass, ladders, iron bars, and more which all were manually configured and separated to allow graphic processors mainly to process them efficiently in open gl properly. There is still a bit of bottleneck of CPU and GPU performance especially in way newer systems as open gl 1.1 uses immediate mode for rendering and newer versions like Open Gl 1.5 actually do support VBOs and actually skip draw calls when needed, but performance is still relatively decent for its codebase.
Chunks were rendered in this version using nearest-first chunk admission which loaded nearest chunks closest first before loading chunks first which prevented extreme lag and frame issues. Caps were also implemented in the memory management and in how many meshes could the world use. Just like in the java version, it runs at 20 ticks per second to allow the world and entities to function as normal and made sure to not tie in with the FPS rate. Mathhelper files from the java version were also converted and developed to have much more efficient equations and perform better mathematical equations in trigonometry, mainly for graphics rendering, 3d movements, and block placement which was important to getting good performance on older hardware.
The NBT and McRegion storage code was also really tedious to convert and was initially very unstable to use. When a chunk was updated, like placing a block or dropping an item, it became a dirty chunk which needed to be meshed and be converted into graphical data, when it needed to be saved, it used to take very long as it saved somehow even entities in chunks, but it was later excluded and rendered individually as individual 3D models.
Neighbor-border invalidation in more detail was also implemented properly to help save processing power and tells chunk to just recalculate its edges when touching another chunk. The lighting system and their algorithms were also implemented and converted to be just like from the java version that allowed different light levels and detect sunlight code to initiate any chunk updates, however it was simplified a little to make sure it wouldn't lag out the system. A render distance meter was actually introduced, like in the newer java versions instead of the original used java version, tiny, medium, and far distance which allowed the player to see more of the world which for some reason during development, it kept being too short. Now for the Open Gl 1.1 code, display lists were used which compiled all the color and vertex data in a chunk in a single list where the CPU would just send a couple of commands instead of the hundreds if not thousands of commands to draw and send the many vertices, which was a bit bugged and actually heavily lagged out the game during testing.
glGetError which used to initiate every frame and bog down the system, it was now removed and later coded in to sample every 128 frames. The check of whether or not chunk graphics list were valid were removed along with replacing the glGetFloat which pulled data back and forth to Cpu and GPU which could slow down system, to just use the earlier calculated frustum matrices and render that. A 3x3 read only chunk neighborhood was implemented where it basically copies around 9 chunks to read only memory to prevent world corruption and process the data to then build a visual mesh. This fixed much of the stuttering and lag issues that were in earlier versions.
The physics and collider systems entities and blocks were using it exactly as the java version which was converted This was how mob attacks, water/lava flow, and more related were implemented to look like the real deal. The day and night cycle is around 24,000 ticks which was exactly implemented in the program and dropped items despawn around 6000 ticks in loaded chunks.
Now for networking and multiplayer support, nearly all packet files were implemented from the original java version and converted into C code, though most of its related and needed code is concentrated in packet.c and the rest is a bit metadata. It currently only uses/supports Winsock 2 code which was like around Windows 98 and above systems, windows 95 could have it if it has winsock 2 dependencies. Restarting the games a couple times and waiting between time intervals like from 1-3 seconds before reopening seems to fix some ghost networking errors.
All the 45 GUI files were able to be converted and later developed to make it all work in Open Watcom, and work under windows 95/98 restrictions. An additional meant usable button was added later on in the controls section which is the double sprint toggle button which can be on or off.
For memory allocation, there were different memory modes developed depending on the Windows OS chosen, for example, Win98 has a max ceiling ram limit of 128mb, 48 chunks renderable, 8-12mb chunk budget, and 20 mb for CPU mesh budget. NT operating systems which usually have a decent amount of Ram has max ram limit of around 256mb, 80-96 render distance limit which was the max the render distance can go currently, 20-32mb chunk budget, and around 64-128 mb CPU mesh budget. Networking queues were even also limited, going from 512kb in lower end windows 98 machines to around 8 mb on modern machines. The memory management and pointers were really hard to develop and there were hundreds of versions before this that just kept crashing the game.
The assets folder which contain all the textures and atlases for the game uses mainly pngs for newer windows and tga or older windows. The texture for blocks mainly uses terrain.png while items use items.png. TexturePackList files in the java version were later on converted to also have support for texture packs for mainly beta 1.7.3. There is however a glitch, especially in newer versions of the game where the sounds and music folder in the assets folder would cause the game to crash, especially in Win9x compatibility mode from some mp3 issues, though it may not happen on a real win9x system, if it somehow crashes the game, renaming the sounds and music folder in the main assets folder to something gibberish can help, but there would be no sound. Initially during development, the music and sounds were fillers, and there are some real songs and sounds from the game. Texture UV mapping also wasn't really thought of until V3 and then later V5 which now has proper java limb math and uv mapped textures from the atlases. Even still, there are some slight gameplay glitches and rendering issues, but it is overall stable and playable.
The bare requirements for running the program, especially the stable V135 version is just having the exe file as well has having a texturepacks folder with a texture pack zip file inside of it. This should work and even stop some crashes on Win9x machines however it may be missing some icons and textures for some items and GUIS which are in the actual assets folder.
Minimum Requirements: OpenGL 1.1-compatible graphics adapter, Approximately 16 MB video memory, recommended is 64-128mb of vram Working 16-bit or 32-bit color desktop mode Approximately 800 MHz Pentium III, Athlon, or comparable x86 processor "Possible to Work On Windows 98" but text rendering may fail Can Work On Modern Windows As Well Around 256mb of Ram Hardware texture support A stable vendor OpenGL driver is strongly recommended, but Open Gl 1.1 can work Module-registration manifests Asset paths Version and executable-name definitions for it to run.
This program uses only imports of WS2_32, OPENGL32, GDI32, USER32, WINMM, KERNEL32, and WS2_32 which I later on figured out it can be relatively easily to be converted or even able to run with a x86-64 emulator on Linux.
I gave the project a very basic name, called CloneMC V2.0 which might change soon, the repo is still a bit of a mess, but the source code files and the executable, along with other files like the makefile is all in the zip file. There is a lot more info about this there.
This project was more or less like a side project with an efficient CAD program being the main goal for the test creation of this project. The License Example file is provided if needed to use any of the java files for references or for adding features, however understanding of the code and custom code may be needed currently to implement any additional features/bug fixes/missing implementations from the java version.
https://github.com/sworks692/CloneMC-V2.0-Entirely-In-C-and-Open-Gl-1.1/tree/main
