ENIGMA Development Environment

Just FYI:

After two previous attempts, I've finally got image_single working. These three commits (#1, #2, #3), in order, comprise the basic solution.

Before explaining what my solution does, I need to explain why the previous two approaches fell short.

• Approach 1: #define image_single as image_index. The problem here is that, when image_single is set back to -1, image_index must be set back to its old value, including the fractional component (if, e.g., speed is <1). But the fractional component must be dropped if image_index was manually reset any time during that period.
• Approach 2: Use events.res to overwrite image_index in some event (say, End Step). The problem here is that image_single can be set by another event using "with(object)". This leads to flickering, as the image_index has likely advanced a frame, but image_single won't be applied until the next frame.

My approach is basically to create two classes that wrap gs_scalars/integers and overload operator= to track every access. Then, the following logic occurs:

• ImageIndex::operator=() -- Sets a "manual" flag to let the program know that image_index was set by the user (not by image_single). (Protects against image_index updated while image_single is still in control.)
• ImageSingle::operator=() -- If the new value is -1, restore the old value. Else, save the old value of image_index, but only if the manual flag is set. (Protects against multiple calls to image_single in a row.)
• The step event -- don't update if image_single is >=0.

This approach works very well (tested in Iji, a very image_single-heavy game). There's a potential issue with image_index getting a few frames ahead if image_single is called from another object's with() block, but it doesn't come up in practice, because everyone just resets image_index manually most of the time anyway when setting image_single to -1. This is, I think, part of the reason why image_single was dropped originally.

Caveat emptor: I'm not planning on merging this anytime soon. It adds a penalty to every image_index access even if image_single is not used, which I don't think is fair (since no-one uses it for new games). Also, it's only been tested on GM5 (yes, technically GM:S also supports image_single, and I've heard it behaves slightly differently). So I'm only presenting this as an overview to answer the question "What would be necessary to properly support image_single?". The nice thing is that these changes, although messy, are all relatively localized, so we could, in theory, enable them selectively at compile time.

Hello again everyone,

I've run into an issue that requires sweeping changes, and I thought I'd post here to get everyone's thoughts on my proposed solution. The issue: "\" on Linux messes up things like "file_exists()" and "sound_add()" (and a LOT of other functions). Although using "/" will work on both Windows and Linux, many developers forget or aren't aware. At the very least, both Project Mario and Iji are affected.

My proposed fix is outlined in this commit, which is a prototype fix that I will expand to cover all the other file functions if everyone thinks it makes sense.

Basically, I've changed the following:
//Every instance of "fname", such as :
int file_exists(std::string fname);

//...becomes:
int file_exists(const filestr& fname);
The "filestr" class is defined in PFfilemanip.h, and takes a "const char*" in a single-argument constructor. This allows you do the following in your script:
file_exists("somefile.txt")
...in other words, no changes are required to user scripts. The "filestr" class also exports "c_str()", so the functions themselves (e.g., "file_exists") only need to change the parameter type of "fname". The constructor of "filestr" is platform-dependent:
//On Linux:
filestr::filestr(const char* fname) : data(fname) { std::replace(data.begin(), data.end(), '\\', '/');}

//On Windows:
filestr::filestr(const char* fname) : data(fname) {}
In other words, Windows filenames are unaffected, and Linux filenames should "just work". (There are still potential problems with case sensitivity, but by far the most common problem I've seen is with backslashes.)

Please let me know what your thoughts are on my solution. In particular:

• Is this something generic enough to replace *every* occurrence of "string fname" with "const filestr& fname"?
• Is the "filestr" class defined in the right place?
• Are there any other concerns I should be aware of, or reasons this is not considered a good solution?

I'm happy to scour the code base and make these changes, but I want to make sure this is a good approach first.

Good evening,

I've got a development-based question about the "None" audio backend. Would it make sense to add empty initializations of "sound_add", "sound_play", etc. to this backend? In other words, "sound_add()" would check for the file and return an id, sound_play would take that id and do nothing (no sound). Basically, this would allow developers to compile games that use audio functions without actually linking to an audio backend, which is useful for debugging, performance testing, and other things.

If this doesn't really belong in "None", what about a "Mute" backend that does what I described? I'm comfortable implementing such a system, but I thought I'd check first.

Hey all,

I was up late for unrelated reasons, so I decided to consolidate all of my mega-unstable ENIGMA hacks to see what the end result was. And here it is:



That's right, you can watch the entire intro cutscene from Iji now. Back when I started hacking on this, you couldn't even get past the title screen, or see any text. The heavy lifting for cutscenes is done by my Timelines code, but there's a slew of bug fixes to boot. Gameplay is still impossible; there's a weird room-related bug I'm trying to track down. But this is very encouraging!

If you're curious to try it yourself, you can use this branch. Just be forewarned: that code is NOT production ready. I'll be cleaning it up and testing it more thoroughly in the coming weeks.

Happy hacking all.

Hey all,

I've found a really nasty bug that corrupts any multi-sub-image texture when it's swapped out and reclaimed. Observe:


The first pic shows what happens on master; the second pic shows the correct behavior. The patch is here:
https://github.com/sorlok/enigma-dev/compare/texturecache_fix

And my test game:
https://drive.google.com/file/d/0B1P7NepPcOslbDlZanZNLUg2WDQ/edit?usp=sharing

Edit: Second test game, same glitch, no sub-images:
https://drive.google.com/file/d/0B1P7NepPcOslQVNBYjE1SlNKV0k/edit?usp=sharing

However, I really need someone to test this on other backends. In particular:

• DirectX9 -- I cannot, for the life of me, manage to get Enigma to work properly from SVN on Windows.
• OpenGL3 -- Everything compiles and runs, but I get no textures whatsoever (even on master).

(I've confirmed that my patch works fine on OpenGL1.)

Once I get confirmed tests for these two platforms, I'll issue a pull request. I would really appreciate your help in this; Platform-specific bugs are a real pain, and this one affects everyone.

Thanks~

Hello all, looking for some advice on a plugin I've been working on for GM5 compatibility in Enigma. Branch is here:
https://github.com/sorlok/enigma-dev/tree/gm5_compat

Basically, I've been working on getting Iji running in Enigma. To that end, I've pushed a few bug fixes here and there. Combined with the branch linked to above (which I do NOT recommend merging; it's buggy and hackish) the game basically starts:
http://i.imgur.com/aXG69zA.png

I'd like some feedback on the idea of GM5 compatibility in general. Currently, I'm doing it all through a plugin, including the following:

• I've duplicated functions like draw_rectangle(), since GM5 does not provide an "outline" parameter. JDI finds these duplicates just fine, but perhaps this affects argument validation?
• My duplicate draw_*() functions take pen_size into account and use draw_line_width() to mimic GM5 wide outlines.
• pen_color, brush_color and other "magic" global variables are added as top-level static variables in the plugin.
• draw_text_sprite() and draw_polygon*() were also implemented. These might be useful for other games, or they might be too niche, and should be left in the compat library.
• There are some outstanding issues on C++ keywords being used as variable names (e.g., "short") that will inevitably have to be addressed.

For now, my approach to GM5 compatibility has been to keep as much as possible isolated in a plugin, so that compatibility can be turned "on" or "off" easily. This makes sense to me, but I figured now would be the best time to start discussing this.

Thanks, and happy coding.