ENIGMA:Todo - hpgDesigns/hpgdesigns-dev.io GitHub Wiki

This is a list of all the current things needed in ENIGMA. Developers can use this as a guide for things they could consider doing. General users can use this to know what things aren't functional yet in ENIGMA. {{-}}

Compatibility

This is a list of things needed for GM compatibility

  1. The remaining GM functions. A list of unimplemented functions can be found here: http://enigma-dev.org/docs/Wiki/Unimplemented
  2. A few GM variables also need to be added still (somebody needs to list them really)
  3. Redeclared variables in var statements (e.g var a, b, r, g, b, c, p, xx, yy;) The b var is declared twice.
  4. argument[i]
  5. Negatives treated as false in statements
  6. Game settings (constants, file includes)
  7. Event inheritance
  8. Windows widget system needs to work again
  9. C++ functions not conflicting when used within EDL
  10. Resource name conflicts resolved (since resources are allowed the same name in GM, also functions can be overloaded as scripts)
  11. Variables to be recognised as locals to instances when used inside with statements (and not used within an object)
  12. Resolving ENIGMA's Bugs

{{-}}

Odds and Ends

This is a list of bits and pieces that need to be done or aren't working

  1. room persistence functionality (keeps instances in the room when changing rooms so they're the same when the room is gone back to)
  2. make cursor sprite change when hovering over resizeable window border
  3. get enigma.exe to download windows patch and maintained mingw package
  4. string_copy_part should return false when position is given less than 0 or greater than width/height
  5. instance_id[] should be added as a global array
  6. lot's of window/display functions need to be sorted for linux
  7. d3d - shapes need normals adding to them, d3d_set_hidden, d3d_set_depth, d3d_save, d3d_load needs to be rewritten properly not using the file_text functions; also the function can be overloaded to add support for other model formats (ENIGMAsystem\SHELL\Graphics_Systems\OpenGL\GSd3d.cpp)
  8. game setting functions need to be added and implemented properly. At the moment LGM has a bug hindering their implementation: https://github.com/IsmAvatar/LateralGM/issues/23 (CompilerSource\compiler\components\write_defragged_events.cpp)
  9. Allow client to specify audio format and rate (ENIGMAsystem\SHELL\Audio_Systems\audio_mandatory.h)
  10. Add fastcall support to FFI (ENIGMAsystem\Additional\Windows\include\ffitarget.h)
  11. When ENIGMA generates configuration files support endian.h for drawing efficiency (ENIGMAsystem\SHELL\Graphics_Systems\OpenGL\GSstdraw.cpp)
  12. sprite_create_from_surface - toggling precise for generated sprite (ENIGMAsystem\SHELL\Graphics_Systems\OpenGL\GSsurface.cpp)
  13. organization of ENIGMA namespace (ENIGMAsystem\SHELL\Platforms\Win32\WINDOWSmain.cpp)
  14. implement map_resource_ids function (ENIGMAsystem\SHELL\Universal_System\resource_data.cpp)
  15. Look at why the width of the space glyph is not always provided (ENIGMAsystem\SHELL\Graphics_Systems\OpenGL\GSfont.cpp)
  16. reimplement untexture macro as function (ENIGMAsystem\SHELL\Platforms\Win32\WINDOWSfonts.cpp)
  17. sort out GAME_GLOBALS.h (ENIGMAsystem\SHELL\Universal_System\GAME_GLOBALS.h)
  18. move show_message function (ENIGMAsystem\SHELL\Platforms\xlib\XLIBdialog.cpp)
  19. move some draw functions from WINDOWSstd (ENIGMAsystem\SHELL\Platforms\Win32\WINDOWSstd.cpp)

Debug Code

Because everybody is lazy, a lot of functions are missing debug code. So there's plenty of easy work to do here around the place, adding in checks for when debug mode is used.

{{-}}

Little Things

These are a list of little things that need done. They have been categorised by difficulty, so those at different experience levels with C++ or ENIGMA can see what they may be capable of helping with.

Working Brain

If your brain functions, you're probably qualified to do these.

  • Branch the draw_SHAPE functions into sets of outline_SHAPE and fill_SHAPE functions to eliminate* `bool outline` (concerning SHELL/Graphics_Systems/OpenGL/GSstdraw.h). Alternative: draw_SHAPE_outline/draw_SHAPE_fill. (* Not really eliminate, just replace the need for. The outline argument would become optional)
  • Change the tabs in the Makefiles to spaces that actually line up properly. The beginnings of lines require tabs, but the commands themselves should use spaces to align actual characters - otherwise, it looks weird depending on the terminal that you're using.

Some Understanding of C++

If you can poke your way around a typical C++ project, you can probably do these.

  • Lay out a super class for ds_ structures. It should implement only essentials (which may be none) to store and iterate through all created data structures. The ds_ functions should blindly cast from ds_parent to its children (ie, ds_list) except in debug mode. (#ifdef DEBUG_MODE)
  • Go over the other resource-access-related functions adding anti-segfault checks in #ifdef DEBUG_MODE directives.

Reasonable familiarity with compiler's process

If you have a general feel for what happens when you press compile, you might be able to do these.

  • Allow forcing 32-bit or 64-bit building of the game. There may be issues with Rebuilding that need to be corrected in order for all object files to be built in the correct architecture.

{{-}}

What Josh has to do because no one else seems to be volunteering

  1. Implement an attribute in compiler.ey files for defining additional binaries (for resource linker at very least)
  2. Implement tiles using GL lists
  3. Implement DirectSound and DirectX, somehow (This is hard because MinGW doesn't get along with Microsoft's exceptionally propriety headers)
  4. Complete the Extension system
  5. Improve the instance system; add a second set of double links to iterators to allow for smooth updating of destroyed instances
  6. Finish implementing the DEBUG_MODE variable (var read checks, more access violation checking)
  7. Implement new graphics system using modern GL calls

{{-}}

Parsers/Managers

ENIGMA's compilation sequence is also in need of a few amendments

  1. The extension system needs spread to each system
  2. The extension system should provide a way of "hooking" the load system to add support for more resource formats.
  3. Pretty-printers need written for each supported language.

{{-}}

Proposed Systems

This is a list of all the systems that have been proposed to use in ENIGMA

  1. Additional statements: when, step and draw -polygone suggestion
  2. Member functions
  3. Pause system

Major System Suggestions

This is a list of external pages which have suggestions for major systems in ENIGMA

  1. ENIGMA:Suggestions (for general ENIGMA suggestions)
  2. Function:Suggestions
  3. Script:Suggestions
  4. Event:Suggestions

Ultimate Goals

A bunch of other things need done to get ENIGMA ready for serious game development.

Code Export Revamp

To decrease build times in succession, we need to look into separating the main header from engine code and placing individual objects in their own source files. The main header, which is currently the main source, would be moved into its own file apart from compiler-exported code, then ideally be pre-compiled. Another option is to have object files built for each object in the game packaged into the EGM to facilitate faster building between runs of different games.

With the ability to compile objects separate from each other comes the ability to compile objects during run time and link them in dynamically, which will facilitate hot-swapping code in debug mode, as is a feature in other IDEs for other languages. Since instance_create will have to be refactored to call a function to create an object with a certain index, and in all likelihood, so will dynamic dot-access functions, it would not be a difficult matter to replace the code which allocates obj_character with code to allocate a new object of that type, as loaded from a DLL. The dot-access system may, in turn, need to be less efficient when compiled in Debug Mode to facilitate this hot-swapping.

File Storage Revamp

In order to enable ENIGMA to be placed in write-protected portions of disk, such as /usr/bin/ENIGMA or C:/Program\ Files/ENIGMA, main configuration files will need to be overridden by files of the same name found in ~/.ENIGMA, and objects will be exported and built to /tmp/ and then optionally copied to the EGM as mentioned above.

While this system is not necessary for the performance of ENIGMA, it accounts for a large piece of the distribution mechanism for ENIGMA. Linux packages and Windows installers, by convention, unpack into /usr/bin and Program Files. While unpacking to Program Files may cause issues due to the space in the pathname (that Microshaft has still not corrected, 20 years later), unpacking to /usr/bin is a must if we intend for package repositories used by major Linux distributions to allow installing ENIGMA on a fresh system.

Resource Revamp

We have this beautiful resource tree, but all your efforts organizing resources into it go to waste.

LateralGM loads all your resources into memory at startup, even for formats such as EGM which do not require doing so at all. Then, to make matters worse, ENIGMA adds them all right on top of the game, and loads them all into memory at once, too.

This system needs reworked so that resources can be stored externally—with or without encryption—and loaded into memory either on an as-needed basis, or, better yet, by resource group name as they appear in the resource tree.

For example, when you hop from the volcano zone of your game to the ice zone, you would call resource_tree_unload("Scenery/Zones/Volcano"), resource_tree_load("Scenery/Zones/Ice");. That would automatically unload all resources of any type found in the "Volcano" subtree of the "Zones" subtree of the "Scenery" subtree of the resource tree, loading instead the "Ice" folder from the same subtrees.

The idea is that the resources still remain segregate, but share an identical tree structure. So, the Sprites and Backgrounds resource trees may contain Scenery/Zones/Volcano, while the sounds directory does not. In regular GM6 view, the Sprites subtree will contain a Scenery subtree containing a Zone subtree containing other subtrees full of sprites, the Backgrounds subtree will contain a Scenery subtree containing a Zone subtree containing other subtrees full of backgrounds, but the Sounds subtree will not contain a Scenery subtree at all. In the universal view, the resource tree will directly contain a Scenery subtree containing a Zones subtree containing other subtrees full of sprites, backgrounds, and potentially other resources.

Objects may or may not be loaded dynamically as DLLs; the possibility of lazy-loading regular objects via the mechanism described in the code export revamp is something that should be investigated later on as well.

New Resources

It should be easy to add resource types to ENIGMA. Among the resources to be explored should be a 3D model resource and the Overworld resource discussed in the Proposals section of the forum.

Instance System Revamp

No globals should be used in the instance system which are not encapsulated by a thread class. The globals which control the "current" instance should not exist; they should be passed as parameters to functions which require this information. The lists of instances of each object should also go in a thread class. The instance_deactivate* functions should move deactivated instances to a dead thread class instead of whatever system TGMG used to implement them. Later, the thread class should be instantiated when the user tries to move objects to different threads. In general, only the events should be moved to a different thread; instance references should be left in the main game thread. The main game thread can be global.

Function Definition Revamp

We ought to move functions into a new namespace under enigma{}. The namespace can be either ::enigma_functions or ::enigma::functions. JDI will then assist ENIGMA in ignoring any C++ functions which are not using'd somewhere in the ENIGMA definitions. The ENIGMA {{include}} directive (not yet implemented) should be replaced with {{require}} and hint to the compiler to include the requested header, but not necessarily use it. This will also help keep code language-agnostic in the event that someone happens to create a JavaScript library called "map" or "vector" or "GL/gl.h".

In namespace enigma::functions, math and stdc functions required by EDL should likewise be adopted via (eg) using ::sin.

This removes the need for the Bessel function hack, which #defines each Bessel function to use a bessel_ prefix, then implements them in another source. Instead, the STDC Bessel functions will simply be ignored by ENIGMA and will need implemented as, eg, double (*bessel_y0)(double x) = ::y0;. This eliminates overhead and hacks alike.

Events.res Revamp

Events.res presently uses a custom breed of e-YAML that allows adding a default attribute to a group. We can do without that, which will allow the file to be plain e-YAML, and thus allow LGM/other IDEs to read it the same way they read everything else. Moreover, we need a way to just insert a call in place of the event, both in the event handler method and in the actual per-instance event loop.

The file also needs modified

Game Saving / Loading

One of the cooler perks of Game Maker is that the functions game_save and game_load create almost instantaneous dumps of your entire game's state. ENIGMA's compiler gives us the necessary control to implement these functions in the C++ engine dynamically. Here's what we need:

  1. ANYONE: Create a function write_dump with an overload for all ENIGMA primitive types, and as many STL types as possible.
    • The first parameter should be a FILE* or ostream, or a typedef to something platform-dependent.
    • The second parameter should be a const reference to the type mentioned earlier.
    • This function should serialize the given reference and write it to the given stream.
  2. ANYONE: Create a function read_dump with an overload for all ENIGMA primitive types, and as many STL types as possible.
    • This function should take identical parameters to write_dump, but use a non-const reference and load into it.
  3. COMPILER: Construct a save_binary(FILE*) function into each object.
    • This function should invoke write_dump for each local variable in the object.
    • We may want this function to write a header with a magic value such as char[4]("OBJ") so we know we're reading right later.
  4. COMPILER: Construct a static load_binary(FILE*) function
    • This function should create a new instance of the object, loading locals from the given FILE*.
  5. ANYONE: Make the game_save function iterate all instances, calling their save_binary method.
  6. COMPILER: Pack the load_binary functions of each object into an array, loader_array by object_index.
  7. ANYONE: Create a load_binary function in object_basic
    • This function should verify the object header, them read the ID and object index from it.
    • It should then use the object index to invoke the correct loader_array method.
  8. ANYONE: Make the game_load function call the object_basic load_binary until EOF.

Threading

In the sprite and background sources, eg, Universal_System/spritestruct.cpp, you will notice there are two macro functions to fetch a resource from its ID. For example, get_sprite vs get_sprite_mutable. This is to facilitate the implementation of threads later on.

When the time comes, these macros will place locks on the sprite data being accessed. While the sprite is locked for write, no other threads will have access. While it is locked for read, no writers will have access. By using the wrong macro, you will introduce unnecessary wait time that could potentially be noticed but never found.

We will also need a THREADS_ENABLED macro to avoid making single-threaded games place locks on that information.