Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - sorlok_reaves

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »
General ENIGMA / Cross-platform filename mangling
« on: July 02, 2014, 08:12:20 PM »
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:
Code: [Select]
//Every instance of "fname", such as :
int file_exists(std::string fname);

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:
Code: [Select]
file_exists("somefile.txt") 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:
Code: [Select]
//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.

General ENIGMA / Re: Compatibility flags.
« on: June 26, 2014, 10:13:32 AM »
In that case, we can keep indexes, and I'll just use an enum inside enigma. That actually makes it easier; I can just cast the returned integer to an enum.

String IDs are more stable when adding/removing items from the list, but if I make "Standard" compliance equal to 0, then most people won't be affected by this.

General ENIGMA / Re: Compatibility flags.
« on: June 25, 2014, 08:55:45 PM »
Further digging in the LGMPlugin reveals this:

Code: [Select]
String getValue()
  if (combo != null) return Integer.toString(combo.getSelectedIndex());

Is there any reason we don't return getSelectedItem().toString()?

General ENIGMA / Re: Compatibility flags.
« on: June 24, 2014, 12:12:25 PM »
I was able to get the feature working pretty easily (see screenshot and the branch).

Since this seems to be a somewhat contentious issue, I'll continue the discussion here before making a pull request:
  • Regarding Ism's worry about supporting old GM's, I feel the line setting::compliance_mode=="GM5"?"true":"false" is pretty self-documenting. I also feel that the scope of my commit is fairly limited and encapsulated; nothing in the engine changes (just compiler + 1 value in generated code).
  • The compliance setting should default to GM5 when importing GM5 games; Standard for everything else. Is it possible to check which version of GM the GUI is currently importing? (I.e., when the Enigma settings file for a new project is first created.)
  • Combo boxes, unfortunately, still return integer strings ("0", "1"). I understand Josh's idea about returning the values in plaintext, but I haven't worked with the plugin at all before. Is this something that someone could look at? For me, "0", and "1" is sufficient (even if it's ugly).
  • On a similar note, would you prefer if I stored "compliance_mode" as an enum (in the settings:: namespace) rather than a string?
  • The compiler scripting sounds cool! In the future, when it's available, I'll have a look at re-writing this option using that feature.

General ENIGMA / Compatibility flags.
« on: June 23, 2014, 05:49:18 PM »
Hello all,

Something came up during my timeline branch that I'm not quite sure how to address. The field "timeline_running" is (I think) OFF by default in GM:Studio. In GM5, however, it does not exist, and it is implied that all timelines start as running. So, GM5 games still can't use timelines (since I made the GM:Studio behavior the default).

There's a simple fix to this: in write_object_data.cpp, we can do something like this:
Code: [Select]
//Old code:
wto <<"instance->timeline_running = false;\n"

//New code:
wto <<"instance->timeline_running = " <<(GM5COMPAT?"true":"false") <<";\n"

However, I'm not quite sure where to put this option (a screenshot of the Enigma settings dialog is below for reference).
  • Unlike normal options, this should be set automatically when importing a project. Do we do that for anything else at the moment?
  • None of the current categories seem like a good place to put this option. Do we have any similar settings at the moment?

Any thoughts?

General ENIGMA / Re: GL3 lights fixes
« on: June 21, 2014, 09:59:53 PM »
FYI, I also get the "ugly title" for Project Mario on Open GL3 (using nvidia's binary blob on Linux). If you need help investigating this further, let me know (but I know very little about Open GL).

General ENIGMA / Re: GL3 lights fixes
« on: June 20, 2014, 06:46:51 PM »

It looks fine on my machine (GeForce GTX 760, Linux, Open GL3). Unfortunately, I do not have a Radeon machine to test this on.

Announcements / Re: Timelines Implemented
« on: June 17, 2014, 01:46:57 PM »
Double-posting; just wanted to thank egofree again for his detailed bug report; without it, this issue would have hidden stealthily until undoubtedly the worst possible time.

The issue is now fixed, as of this commit:

General ENIGMA / Re: Timelines won't update correctly after saving.
« on: June 16, 2014, 10:37:06 PM »
Figured it out; my "clever hack" was not quite clever enough. One line fix for a very confusing error:

General ENIGMA / Re: Timelines won't update correctly after saving.
« on: June 15, 2014, 08:59:26 PM »
In the code and the timeline? And opening them back up reveals the changes have been saved internally? There's literally no other place for this information to exist.... If that's really happening, something more than a little fishy is going on.

Yes, that is what I think is happening. It is entirely possible I am making a mistake, so I've uploaded a video that shows the entire process. (Please view at 1080p.) Note the error in the output console, and the correct text (every time) in the code window:

Works in Progress / Re: Project Mario
« on: June 15, 2014, 08:18:37 PM »
Yep, that did it. Along with the fixes in my branch (and the filename fixes in the zip I linked earlier), you can now enjoy Project Mario on Linux. The only minor issue is that GL3 doesn't seem to do any shadows correctly:



I've added these to my "Project Mario" pull request, which is now ready for review (again).

General ENIGMA / Re: Timelines won't update correctly after saving.
« on: June 15, 2014, 07:42:08 PM »
Amazing how we do no caching and still have cache problems. What if you click the green check in the code window? That should almost certainly fix it without reloading LGM.

It may be that the "Save" action is custom-tailored to iterate open dialogs and grab their updated version.

Clicking the green check mark in the code window does not fix the problem.

Works in Progress / Re: Project Mario
« on: June 14, 2014, 07:26:51 PM »
Good work Sorlok, DaSpirit wrote that INI extension but never finished. Second, the issues you are seeing with geometry are related to the model struct for GL1. Josh fixed it for GL3, it has to do with how we handle color, but he didn't add the fixes to GL1.

Thanks for the insight; I'll dig into this a little more, since it would be kind of fun to have Project Mario working properly on Linux too.

General ENIGMA / Re: Question about audio:none
« on: June 14, 2014, 07:21:31 PM »
What about doing it at the API level, you know where you select OpenAL, DirectSound and None, you could add a null option or whatever, which will work like the other APIs but not actually process sound and output it to your audio device, so you can easily switch back and forth APIs as you are testing your game.

This makes the most sense to me. Since there seems to be some interest, I'll prepare a pull request so it can be properly evaluated.

Works in Progress / Re: Project Mario
« on: June 13, 2014, 07:52:21 PM »
I was able to get Project Mario to build and run on Linux with the Ini Extension. There's a few problems with it though:

1) Some random bugs. I'll file a pull request with my fixes.

2) Textures (or more likely polygons?) loading improperly:

3) Filename case sensitivity issues. I've edited the project file to fix these:

Basically, here are the things I changed:
Code: [Select]
//Replace all backslashes with forward slashes in path names in the following files/objects:
./Objects/obj_map.obj:d3d_model_load(model, working_directory + "\maps\koopafalls\map_mod.d3d");
./Objects/obj_map.obj:texture = background_get_texture(background_add(working_directory + "\maps\koopafalls\texture.png", 0, 0));
./Objects/obj_map.obj:fname = working_directory + "\maps\koopafalls\map_col.d3d";
./Objects/obj_gamestate.obj:    path = working_directory + "\screenshots";
./Objects/obj_gamestate.obj:    path += "\";
./Objects/obj_gamestate.obj:    file = file_text_open_read(working_directory + "\maps\koopafalls\objects.dat");
./Objects/obj_tree.obj:    sound = sound_add(working_directory + "\Audio\Ambience\bird1.wav", 0, 1);
./Objects/obj_waterfall.obj:file = file_text_open_read(working_directory + "\maps\koopafalls\waterfall.d3d");
./Objects/obj_water.obj://surface_save(texturesurface, working_directory + "\test.png");

//Rename *.WAV to *.wav for the following files:

I've only tested this with the Open GL 1.1 backend at the moment.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 »