I like testing limits and constructing designs that eliminate extents.
It's often simple to test limits. I've done so in many situations, such as with Altimit01's Eschaton, prompting him to make version 0.8.1. I tested limits with SAPP, and who hasn't tested limits with the HEK, and many of us have messed around with Halo's runtime memory. I also used to make lots of different maps for Halo Demo PPC Mac and Halo MD and Custom Edition -- I stopped counting at 50 -- to experiment with different gameplay. I tested server configurations, etc. etc. etc. Fun times. I spent years gathering ideas from a wide variety of games, single player, multi player, etc., and I gained experience setting up and managing servers, using different operating systems, looking at a variety of software, gaining ideas, designing web sites, messing around with various scripting and programming languages, and so on. (I'm simply glossing over this.) And I've done so many different things with Halo, much more than most people, and I have for the most part enjoyed sharing some of my work.
I have no qualms with high workloads. And when a pattern has been established, there's a regex sequence and a "for loop" for that.
Now I am pondering how I might design a new game engine
. Instead of mentioning what I've already learned and what improvements I would want to make beyond what Halo and contemporary games typically offer (which would take too long), I'd simply like to say that I have in mind using C and the very same OpenGL the bridge to which Apple has chosen to burn.
Now I didn't like GitHub when I was using it, and this forum does not perfectly display code blocks, so I'm kind of left with Pastebin or hosting plain text files on one of my web servers to show source code. I know, I know, there are alternatives. Whatever.
So there are a few things I'd like to do first, before I dive into discussing topics like C structs and kernel drivers. At the moment, I'm transferring files around, off of floppy disks onto some 4TB drives... and this will all take some time. I'm not proposing a timetable for progress (as usual), I simply want to present some thoughts to you all, for discussion. You know some of what I've talked about in the past, and you've probably already seen or heard of some of what I've done, especially if you were in my various Discord servers in the past. Nevertheless, I'm going to consider irrelevant whatever experience and perspective you think I have and simply present some ideas for (additional) discussion.Programming Language and Memory Handling
I have tried to do everything in C when I could, and to design interfaces using Objective-C for Mac and C# for Windows. Of course, there's GTK or whatever for Linux, but I've only focused on web page interfaces on Linux so far.
OpenGL is in C.
I kind of dislike C++. It's too much for me. I'll leave it at that.
MacSoft's port of Halo PPC Mac was of course a Carbon application, even with the Universal Binary version (I guess, nil or Samuco or 002 could correct me if they want). Samuco did his OpenGL injections or whatever with his HaloMD plug-ins. That was weird. Anyway... I have no interest in DirectX at this time.
And there are weird alterations that Halo does with things, like I mentioned in another thread how it inverts the CRC32 result.
All of these things hint at a path that is saying, "Go back and put all the Halo file data structures into C structures, including all the work from retribution.h, and then rethink the necessity of tag files for flexibility; consider filesystems like squashfs or others with sparse file support; using a (relational) database has been a shoddy approach... and load all the data into RAM all at once."
Halo was designed for low-memory systems and uses static address pointers. Blam is a work of art, but let's re-think the approach given modern hardware. We no longer have to fear thrashing the hard drive since many people nowadays have PCs that use 1TB SSD drives and at least 16GB of RAM.Networking
I remember that years ago, nil commented that Halo spams UDP packets. Halo was designed for 56k connections, as you know, limiting that to 4 players per multiplayer game. And its same-system split-screen co-op mode has up to 2 players, and its same-system split-screen multiplayer mode has up to 4 players; it supports at most 16 players per game server instance.
You can have millions of simultaneous connections
to a computer. And if you're using a single IP address, and you want to be super-duper conservative about the whole thing, you can of course have tens of thousands of simultaneous connections. Something's got to improve.
UDP spamming is debatable. UDP vs RDP vs TCP is debatable. There is plenty of room to discuss scalability and proper programming strategies.
Halo 2 doesn't have the ping lead issues that Halo 1 has. It has been advised to never trust the client; does Halo 2?
Don't even get me started on the absurd overhead of GameSpy. At least some people have hacked into the game some kind of IPv6 support.Conclusion
Looking at the assembly, I wouldn't want to touch Halo's source code. They did what they could, using the technology they had at the time, and it was pretty impressive for ca. 2000, right?
Optimization is a consideration, but I'll leave it at that for now. Let me know what you guys think. I haven't even begun discussing physics calculations or other fun math things. Eventually, perhaps... And there are several differences between Halo 1, Halo 2, and newer versions of the game engine.
I haven't been around for half-a-year, and I'm still doing various things. Someone asked in another thread and in a PM, and I was transferring files anyway, so I'll put some info here later about a new mirror of files from the Halo Maps Archive.Edited by sparky on Apr 15, 2019 at 07:36 PM