[Raion]

So what predicated this was the young man who bought my SGI mousepad at VCFE 2022 -- Usually goes by DirtPiper (I forget if he's here on IN). 

We have been talking on Reddit and discord about it, and here's what we discussed:

He wants to get Minecraft Alpha, aka VERY early MC, on IRIX. I did the liberty of checking build reqs for JDK6, (JDK5 is another option). 

We need: CUPS. that's it. Assuming sound/other IRIX-related issues (Ahem, BE MIPS!) don't get in the way. 

Now, I've never built Java, but I sympathize with the man and I wanna help out, so for those interested in a semi-modern Java, let's use this as a discussion area.

Outright, I suspect we may need GCC. Otherwise, I suspect that Java lacks a JIT and thus we will needto work on that... I'm not able to fix that. Not sure if Java even required JIT here for it. 

But anyways, are me and DirtPiper alone or not? I'm willing to help, however I can.

[jpstewart]

We need: CUPS. that's it.

What version of CUPS?  There's a fw_cups package in freeware that might do the trick.

[Raion]

Not sure, it just mentions CUPS include files. May just mean we can stub CUPS out? I dunno!

[linear]

Not sure, it just mentions CUPS include files. May just mean we can stub CUPS out? I dunno!

as of at least java 8, i know there's a build option for excluding cups entirely (i don't know what it is, just that i've seen distros that have a flag for it). i'm not sure if the same flag is in java 6, but i'd hazard a guess that it is.

any modern version of CUPS is right out, it used to have explicit support but it got ripped out completely about 10 years ago

[DirtPiper]

Hello! I am said young man. I'm currently finishing up finals for my final semester at university, so it will be a few more days before I can really devote myself to this. That said, here's some information on what I have done so far and what I seek to achieve:

I am the lead developer of a mod/fork of an Alpha version of minecraft (circa September 2010). This fork is called 'Not So Seecret Saturday', and, while originally intended as a means to bring some optimizations and quality-of-life improvements to this ancient build of the game, has evolved over the past ~4 years into my primary passion project, and is something of an experiment for me in game design, implementation, and code optimization. My selection of version to fork from has posed interesting challenges over the years, as community minecraft modding support was in its extreme infancy when the build I forked from was current - the vast majority of the original codebase I was working off of was totally unorganized and obfuscated, with much of the functionality of the code being manually gleaned through reverse engineering and just plain-old staring at the moonrunes hard enough. The codebase is now far more readable and organized than it was 4 years ago, and much of it has been refactored.

Lately, I have been focusing on optimization. From the beginning I made some simple improvements, such as backporting a newer save format that drastically improved saving and load times for worlds, and a handful of improved settings such as more minute control of the fog rendering. More recently, I have implemented some much more drastic optimizations, working partially off of source code for an old optimization mod called 'OptiMine' (which was kindly granted to me by the original creator) and also off of advice from other modders familiar with the so-called 'notchcode' that hampers minecraft's performance so.

In my view, the best way to enforce optimized code is to target "low-powered" or "legacy" systems - and being a retro computing enthusiast I had plenty of these lying around. Previously I had been using a Pentium IV machine running Windows 98 to test my builds (with my fork easily hitting 90 FPS on said machine - however I know it can go much higher), however, wanting to expand even further, I have been seeking out some more 'exotic' hardware - half as an excuse to improve my optimizations, and half as slightly more looney goal to run minecraft on systems it was never intended for. The hardware/architectures I plan on targeting are OSX-PowerPC (with my Powerbook Lombard being the test machine for ultimate pain), Solaris-SPARC (with my Sun Ultra 5 being the test machine for, again, ultimate pain), Win9x on Pentium II (yet to be sourced! I've seen newer, more bloated/sluggish versions of minecraft running in the ~20 fps range on a PII @ 367 MHz so I feel 400MHz is a reasonable target), and, as of two weeks ago, IRIX-MIPS (the test machine being an Octane2 with dual 400MHz R12ks and dual SE graphics, one with TRAM).

Here are the current minimum specs required to run my fork as I judge them:
- a CPU equivalent to or more powerful than a Pentium II @ 400 MHz (floating point especially - minecraft is extremely floating point heavy. I hope to bring this clock speed down but this will require some more intensive rewrites, though I believe them all to be feasible)
- any version of Java between version 5 and version 8 (java 4/1.4, the newest existing version for IRIX, is completely unviable from my experiments, and java versions 9+ break compatibility for confounding reasons.)
- support for OpenGL 1.1 (thankfully, minecraft was outdated upon release.)
- 96 MB of RAM (128-192 being recommended, as the sound system will not start without enough memory. I am looking into ways to dynamically compress/bitcrush the audio to bring this number down further.)

I have yet to conclusively determine the TRAM required, however the TRAM-less Graphics option on my Octane2 will absolutely be used to test a rendering option without textures, using flat-shaded polygons instead. I expect such an option to also bring about a performance boost on other systems.

Aside from the Java and OpenGL version requirements, I expect to be able to bring down these minimum specs even further - there are a lot of obvious problems with the existing codebase that can be solved with enough time and energy. I fully believe it to be possible to bring minecraft to IRIX, so long as Java can be built.

I look forward to working on this project alongside anyone who wishes to help! I am a beginner to IRIX, though I have drooled over SGI kit for years - I'm already fairly active over in the SGUG discord, but I certainly plan on being much more present here as well.

[Raion]

Hey Dirt, appreciated you posted here. We're not opposed to working with anyone interested at SGUG, but keep in mind it'd be inconvenient for me and others who don't/can't/won't use their chat/forums to collaborate, so if more than a few join we should either converge here or in a mutually agreed part of the web, e.g. /r/SiliconGraphics, an IRC, whatever. I'm not picky, and well, I'm just along to help document and support the effort however necessary. I don't use GH, but if you prefer that it's ok, I'll setup a repo fork or whatever and post diffs if I have any fixes. The good news is Linear told me that Java 6 is reasonably portable, and may not necessitate GCC as it can build on xlc and others (though, we agreed starting there and using any other compiler as a stretch goal is better)

Beyond that, we /should/ be able to do any version up to 8 according to this. Difficult project, but far from impossible!!

As for IRIX, the RAM ain't an issue (most systems in the octane and up category are well equipped), the R10000 is vaguely Pentium Pro class (both out of order superscalar) but lacks any MMX/SSE. The R12k+ are process shrinks, cache bumps and other incremental uarch improvements. Certainly VPro possible, but I'm shaky on MGRAS stuff. TRAM will be needed, like, without it Quake 1 gets sub-10 FPS. If that. So don't count on it haha.

Best to do IMHO, iron out whose interested, establish where we wanna collaborate, (e.g. I have gitea!) and set that all up

[DirtPiper]

Sounds good! I am open to a more centralized area to discuss this, as well as collaborate, whether it be through github or gitea as you have mentioned. I'll be sure to direct anyone over at SGUG who is interested in helping to whatever we do end up establishing. I am hopeful to be able to make a rendering mode where textures are not used in any capacity, which may alleviate the TRAM problem - much is possible.

[Shiunbird]

Some guy wrote a Minecraft clone in pure C and OpenGL, and it's open source.
I didn't have a look at the code, but it should be highly portable, and we would only need to replace modern OpenGL calls. However, since you are only creating cubes and loading textures, it should not be a big deal. If I had the time, I'd jump straight into it.

Perhaps we would need to port the network code and plug it to the core C engine. More a fork than a port. Java would be only used for network code and I bet this would improve performance as well.

[TruHobbyist]

Hello! I am said young man. I'm currently finishing up finals for my final semester at university, so it will be a few more days before I can really devote myself to this.

Good luck, young man! May Herobrine be with you!

Here are the current minimum specs required to run my fork as I judge them:
- a CPU equivalent to or more powerful than a Pentium II @ 400 MHz (floating point especially - minecraft is extremely floating point heavy. I hope to bring this clock speed down but this will require some more intensive rewrites, though I believe them all to be feasible)

Floating point on MIPS has some quirks. It is not entirely IEEE 754 compatible and allows some flags to be set in the coprocessor. Some CPU models need these, some not.

Just to mention this so you are aware and don't find yourself in front of strange, untraceable program behavior.

Most information can be found in the manpages.

- any version of Java between version 5 and version 8 (java 4/1.4, the newest existing version for IRIX, is completely unviable from my experiments, and java versions 9+ break compatibility for confounding reasons.)

Having briefly looked into a new Java some years ago, my findings are still applicable today. When Java was open sourced, many other projects were started that leveraged upon the open source. One of these projects is Java Zero https://openjdk.java.net/projects/zero/

It's a Java source without assembly (and thus no ISA and CPU specific code). This has the big advantage that porting should be far easier and faster. Downside is, you have no JIT, nor any other CPU-centric optimization originally implemented in assembly.

- 96 MB of RAM (128-192 being recommended, as the sound system will not start without enough memory. I am looking into ways to dynamically compress/bitcrush the audio to bring this number down further.)

Dmedia allows compressed audio. If you are going to use an Octane as a test machine, RAM shouldn't be so much of an issue, anyway.

I fully believe it to be possible to bring minecraft to IRIX, so long as Java can be built.

I think so too.

I look forward to working on this project alongside anyone who wishes to help! I am a beginner to IRIX, though I have drooled over SGI kit for years - I'm already fairly active over in the SGUG discord, but I certainly plan on being much more present here as well.

I'm glad to help with anything IRIX-related: compiler flags, compiler errors, system architecture, headers, ... . Just ask!

As for IRIX, the RAM ain't an issue (most systems in the octane and up category are well equipped),

I was going to say that, but you just beat me to it.

[DirtPiper]

Some guy wrote a Minecraft clone in pure C and OpenGL, and it's open source.

The clone of which you speak (the one made by jdh, I presume) is very lacking in features, as are the vast majority of FOSS minecraft ports to C - ClassiCube and MinecraftC come to mind. All of these ports/clones generally base themselves off the most basal mechanics of very ancient minecraft (older even than what I am working with) and do not typically feature actual interactive gameplay, ie. survival, mobs, resource collection, redstone, etc. There is also Minetest, which to my knowledge is much more fully-featured, though that is in C++ and may be less portable. I am aware of someone who has made a direct C port of the Java version which I forked off of, though they never released it and claimed that performance was unbearable.

Perhaps we would need to port the network code and plug it to the core C engine. More a fork than a port. Java would be only used for network code and I bet this would improve performance as well.

There would be no need to use Java for a netcode port, there already exist servers written in C which Java clients can connect to and I am certain the inverse is true if not possible. The real difficulties would arise in the fact that pairing the C version to any Stable Java server (or even an equivalent in C which is compatible with the Java version's protocols) would require a ton of features to be ported to the C version to ensure that multiplayer gameplay is not infuriating: I recently redid my fork's entire netcode, basing it off of a newer and more stable beta version, and spent nearly an entire year ironing out bugs and fixing asymmetry between the server and client - repeating such a process for a C port that does not support the same block types, feature a survival mode, have entities or resource collection, or (in the case of ClassiCube and MinecraftC) even support 'infinite' worlds would post a far more daunting task. As my fork is also (fairly) frequently updated, needing to simultaneously support the original Java implementation and a separate C codebase not even derived from the same development "yichus" would place severe strain on my ability to keep updates coming out.

Not that I'm saying it can't or shouldn't be done! I'd be happy to see any of a number of C-based minecraft ports running on IRIX alongside NSSS - I just feel it would not be a suitable route for me to go down with my existing project. Plus, the ability to run 'official' java-based minecraft on IRIX grants more options all around (some beta versions with performance-enhancing mods such as 'Optifine' may perform well on select SGI systems, and this also opens the gates to modded beta minecraft which is a whole host of potential content to toy around with on IRIX. Any C port would not benefit from this existing well of modifications).