QuoteDoes that mean it won't be directly compatible with mplay_ ? As in you can't just load any old Game Maker game into Enigma, hit compile and have it function the same? Because I thought that was the point.
As my code stands, mplay_ will remain in the set of "currently unimplemented functions, aka TODO", while there will be a functional set of alternative online functions using my library to achieve the ends. How mplay is implemented ultimately is of no interest to me - I just wrote my code on my own set of functions, and if someone wants to wrap mplay into my functions or wants to do a serious rewrite or re-implementation of DirectPlay for porting to mplay, then more power to them, but it's beyond my scope.
QuoteI'm sure there're people who'll modify it for you down the track anyway
Precisely.
QuoteWhat exactly do you mean by "lower level" than mplay_? I thought mplay_ was about as low level as it got (including low quality <_<)
Low level in software terms refers to how closely to the hardware level you are, and high level refers to how abstracted or detached from the hardware level you are. For computer languages, PHP and Java would be considered high level languages, whereas C and ASM would be low level languages. In terms of networking, you can consider the entire stream of individual bits as they go through the tubes, including your own code determining where the bits go (which is very low level). Or you can consider "Protocols", which is a predefined arrangement of bits that computers all agree on to use for networking. Protocols, then, are a higher level than individual bits. Even within protocols, you have lower level protocols, like IP, which is a very basic definition of how bits are sent in a packet-like fashion (so we're looking at bunches of bits, or packets, rather than each individual bit in the stream, and each packet contains a set of information like who it's headed to). On top of IP (that is to say, higher level), there's two primary protocols of TCP and UDP, which basically define how computers try to compensate for packets that get lost or damaged along the way. On top of each of those are a number of higher level protocols like HTTP, FTP, SSH, etc, which define how data inside those packets is formed for specific kinds of communication. Another kind of protocol, kind of along the same lines as HTTP and FTP and such, is DirectPlay, or an online game handling library for Direct X, which builds off of both TCP and UDP to create protocols for handling game servers and game clients and handling more abstract concepts like online variables, sessions, and players. GM's mplay_ functions are built off of DirectPlay, so they are even higher level than DirectPlay. Unfortunately, DirectPlay is based on Direct X, is windows only, is proprietary, and worst of all, is deprecated. It's a very complex library of network related routines that I certainly would not want to rewrite myself. As such, I cannot write mplay_ functions. Instead, I went a couple layers down, down to TCP and UDP, and created my routines from there. I also made a couple wrapper functions that extended those routines into HTTP, FTP, and SSH protocols, mostly just for testing and personal purposes, but it was pretty easy to do. As such, whereas DirectPlay/Mplay is restricted exclusively to games, with my routines now you are allowed to communicate with webpages, online databases, and other things of that nature, or you can just use routines for game communication - it's completely open ended.
Quoteand if Ism doesn't do it himself
Herself.
QuoteYou are right though, someone will implement mplay_ on Ism's framework to do it anyway if they need it. mplay_ is a pretty poor setup anyway, no serious online GM game uses it.
Exactly.
