This list will be updated randomly.
General:
- Entire DKCLB should be Freeware: With Game Maker, I am limited to giving people the source GM6/GMK file to be fed into a "core" engine that is closed-source - the GM runtime. By not using Game Maker, crucial parts of the engine are NOT stuck in somebody else's commercial software.
- In C++, You Can Do Everything for Free: With GM, you have to pay for some functionality, and not as much is possible as C++, even with the paid version of GM.
- Working with Raw Data Files: Reading binary data is cumbersome in Game Maker, and C++ is far better at this task. Working with hexadecimal data is a must, and GM isn't so great at doing that either. Again you have to have the paid version of GM for the external data to be of any real use.
- Sumo GM6/GMK files: In order to load graphics from external files to use them as sprites or backgrounds, you must have the paid version of GM (the same likely applies to sound files too). This means that for it to be freeware, we must stick to putting all our resources in the game maker file. Since all resources are in the GM6 or GMK file, this means that the files will become obscenely huge. Passing a 100MB file back and forth? No thanks.
- Internal Levels Locked inside the GM6/GMK: With GM, you are limited to using the game file itself to edit levels.
- Editing Text Files is also not Good Enough: Oh, and if you say level files could be using external text or binary files, yes, but in the case of text anyone could mess a file up by not typing in the correct statements. The DKCLB intends to be extremely usable, and I don't want people asking questions about how to edit text files - it should be a totally visual editing interface. As for binary (that is, .dat) files, there is much advantage to using C++ to do this. It is less cumbersome, is faster, and the process allows bit-by-bit compression to take place given you have the proper framework (I do, which is dubbed BFA, stands for Bitwise File Access). Also, you must have the paid version of GM for objects to be modified at runtime (in order to load the level).
- Objects in GM are Not Dynamic: Objects in game maker are created in such a way that they do not have any kinds of variables that can be modified before the level runs, without making a bazillion fully-duplicated copies of the object in question. This goes double for Barrel Cannons, which have more than 768 possible "variants" from just DKC1 alone. This can be gotten around with editing external files that tell GM to load the objects at level start, but then you'd need the paid version of GM and you'd have to create your own level editor anyway.
- Script Interpreting (GM is too Slow): Game Maker's engine runs by executing the GML scripts as the game runs, using a (pretty fast for its kind) script interpreter. However, DKCLB will not be doing small games, and is intended for very large games to be possible. Once you surpass about 100 objects, the engine will likely slow down no matter what you do. This forces you to split levels into more than one room, which is very ugly design. C++ is not script interpreted, and executes immedieately, on at least the order of 8 times faster if not more. DELTA is intended to be a real-time game engine, and script interpreting has no place here.
- Graphics Capability: In C++ it is possible to manipulate raw graphics to create special effects, do per-line scrolling, create "real time" benders or image filters, and countless other graphics-related possibilities.
- The 3D Acceleration is Slower: Although in the case of DKCLB all the graphics cannot use the graphics card hardware to accelerate the process, this is by design. Many graphics cards are now so focused on 3D that working with the 2D graphics to do anything other than put it onscreen is cumbersome or extremely slow. Doing the graphics in software also allows a finer level of control and allows highly optimized graphics routines - the main CPU can even outrun your graphics card at its own game, since there's not as much 2D acceleration support as there used to be.
- GM Wastes Time doing "Default Calculations": Each GM object contains some standard variables that are always acted upon even if you decide to use your own custom variables. This is just more time wasting junk that DKCLB doesn't need, and yet another reason GM is too slow for the job.
- Running Levels with Many Thousands of Objects: In order to run a large level that has a very large amount of objects in it, I need to code my own object system to get rid of as many unnecessary object checks/updates as possible. Game Maker always checks every single object, and this cannot be modified. Therefore, Game Maker would waste enough time running through all the objects that it would bog down almost immediately. Furthermore, only raw C++ provides the necessary level of programming power to create data structures that can accomplish this.
- Level Size may be Extremely Large: The DKCLB level size limit is defined at (as of this post) a maximum area of 1,073,741,824 (0x40000000 for you techies) square pixels. This translates to, for example, a level that is 32768 by 32768 pixels in size. Game Maker is likely to puke or just be extremely slow to load on this size of level. With C++ code can be tweaked to allow absolutely enormous levels, and 32768x32768 is just at the edge of the possibility spectrum.
- No Integer Math (needed for physics): All GM numeric variables are double-floating-point. This means that you cannot use true, bare-bones CPU integer math, which is required in order to get a 100% accurate DKC physics engine. The reason behind needing integer math is that the Super Nintendo only has integers - there is no floating point whatsoever. To replicate DKC physics properly, you need to work with values in the exact same manner as the SNES does.
- DKCLB Requires its Own Editing Interface: Game Maker is not well suited to this, period. Nor is Visual Studio (.NET Framework), because drawing images is slow as molasses there. The interface has to be done in raw C++, otherwise it will be totally unusable/unmanageable. Attempting to create an editor for such a large project in GM is worse than creating the entire editor from scratch in C++, for the simple reason that GM is a drag-and-drop interface designed solely for easy game creation.
- DKCLB needs Advanced File Identification: In order to manage the extremely large amount of resources that DKCLB is supposed to handle, it is necessary that each graphic, sound, DLL object, and/or other resource is given a globally unique identifier that will allow DKCLB and DELTA to differentiate from the myriad of resource files that users will be creating. In Game Maker this level of control is just not possible, especially with the DLL objects, since the IDs for these DLLs actually have to be compiled into the DLL file itself using a special method which only C++ code is going to recognize.
- GM Is Unsuitable Working with Many Objects: In Game Maker, having more than a few objects becomes impossible to manage.
- No Object Plugin DLLs Possible with GM: DLL plugins can only be accessed with the paid version of GM. In C++ you do this for free and no one gets in your way with ridiculous pricing schemes. Using DLLs with game maker, even with the paid version of GM, is cumbersome, and all the numeric variables are required to be double-floating-point to match GM's structure. The crux of this matter, though, is that it is impossible to create an interface where users can call API functions that tell the engine to act on objects. This is required for the objects system to work via DLLs, and it cannot be done with GM.
To Be Continued...
