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 - Josh @ Dreamland

Pages: [1] 2 3 ... 188
1
Issues Help Desk / Re: CLI on Ubuntu?
« on: May 03, 2017, 03:03:38 PM »
As I said oh GitHub, a core dump only does so much for us—it tells us something exploded, and, at best, that the control was in X function when shit hit the fan. What it doesn't tell us is why something exploded. Maybe it's because a sprite was deleted, but code references it (this is a little too simple; we have plenty of code that checks against dumb shit like that).  Maybe it's because the parser wrote string data out of bounds. Maybe it's a bizarre JNA memory sizing nuance. The best way to get a bug fixed is to give us a way to make it happen, every time, at the push of a button. So provide the game that caused it, or if you'd prefer not to, provide a minified test case (the smallest possible game or sequence of actions) that will consistently produce this bug.

2
Issues Help Desk / Re: Required packages to run ENIGMA games on Linux?
« on: April 29, 2017, 12:16:25 AM »
There's a comprehensive list on the wiki; you will want (at very least) g++ and the zlib dev package.

3
Issues Help Desk / Re: CLI on Ubuntu?
« on: April 29, 2017, 12:14:42 AM »
If LGM crashes, it's because ENIGMA crashed, so the CLI will do the same thing. File the crash as a bug report; it may have a simple fix.

4
Issues Help Desk / Re: Networking Issue
« on: April 09, 2017, 05:00:32 PM »
What networking system do you have enabled? I'm not sure which system would declare that function and not implement it...

5
General ENIGMA / Re: What now?
« on: December 06, 2016, 06:06:40 PM »
So to confirm. Does this mean that ENIGMA for now lacks any active maintainers?
Not for any serious definition of "Active." Contributors are sending in code a month or so apart, now. Myself included, actually. So we have nibbles, but not active development. The project is currently best described as "maintenance mode." Note that in industry, that's a pretty grim prognosis. Note also that I am not worried.

I'm assuming that now that the GL3.3Normal branch has been merged, there's at least SOME of the functionality that TheExDeus has written up in the past progress reports, right? I feel like that sort of stuff should probably be documented in some way or form, or at least given a few examples. New functionality is there, but nobody knows how to use them unless they take the time and hours to experiment or search through the source code.
I believe that was the remainder of what Harri meant to add. Documentation is thin no matter where you go; ENIGMA is no exception. I don't see a technical writer in the cards, and no one else wants to do that sort of thing.

A part of me thinks that there should be something done about the vision of the engine, in general. Initially, it was made to replicate GameMaker's functionality, then, later on, it was decided to slowly make it its own thing. Now it sort of sits in limbo between the two. My general question with this is: What to do? Which direction to poke the engine towards? Personally, I think it should be the latter, but without entirely shedding away from all of the stuff GameMaker offered. I've taken a look at some of the progress stuff at the Progress page of the site, and while I don't know when has it last been updated, how much of it still applies? I honestly don't know. I feel like the general ToDo list on the page should be updated to include some of the more critical things that's apparently bothering the core engine, such as the parser, or the fact that the debugger isn't entirely reliable.
Vision isn't the problem. This thread's full of people's thoughts on where the project should be heading, and those thoughts would put us in an amazing state. There's not a need for a "throw out all the GML" revolution; the GML functions we implement may be unhippily non-OOP, but they're all that's required to make a game of any size. I suppose I haven't said much about my plans for ENIGMA's language (EDL) here. They are large and complicated and include a full-blown type system, generics (of all variance, with specialization), first-class functions, and comprehensions with lambdas. Note that our familiar library of C-namespaced utility commands in no way conflicts with this.

I hope you don't mind my rambling all too much, just that it's a little confusing for a guy like me as it stands now, among developers who know a lot better of the engine than I do.
I appreciate your thoughts, and welcome your contributions (even maintaining the Wiki ;)).

I mean something like a place where you can 'test' different sounds and organize them into cave/grass/ice/dungeon, like you said.
Interesting. I suppose being able to view texture atlases and having a sound test board for various environments/resource groups would be quite useful. Sounds like a nice feature to plan.

Don't forget that 'manually' having to edit things like image_[xy]scale is very tedious in comparison to having the right tools for scaling/translation/flipping (and the like) at hand.
Certainly. I believe we've had numerous requests for this feature, since even Yoyo managed to add it.

I'm not sure, how we are going to make these tests? This does remind me of a very useful feature of LilyPond/Frescobaldi's notation reference (it's an open-source music type-setting software). The (generated) reference shows graphical representations of the music, the snippets of which can be downloaded and opened in Frescobaldi, which is to LilyPond as GameMaker is to GML.
Unit testing (and integration testing) is a solved problem. The tests would be run automatically by Travis or the like (ENIGMA actually has one now, thanks to Cheeseboy, of all people). Don't think of it in terms of Travis playing games in ENIGMA. We wouldn't test things like playing sound—only things like the correct sound decoding occurring. This is possible simply by bundling compressed audio and making sure, eg, the proper codecs are invoked to create the output sound buffer. For FLAC, especially, this is quite easy. We can store a few kilobytes of FLAC and WAV in a test environment, and verify byte-for-byte that decompression succeeded. There are testing frameworks for graphics (even websites). The point is, there are ways to make sure that an application is behaving correctly.

Some of these tests will make good examples: consider tests of the object heredity system, for example. This test would work by creating an instance of objects that are children of various parent objects, and then verifying that the correct objects are considered in functions like instance_nearest. It could also be used to make sure that the correct inherited events are fired (either graphically or by use of console_show_message, for example).

We can also take advantage of mocks for creating better (quicker to run) testing setups.

What I meant with my paragraph under the image was just a means of telling the IDE what you're going to make. It will then leave out everything except the features you need to get started. Later on you could check some boxes in the preferences in order to add some unique elements (like adding an overworld to a previously specified puzzle game). I'm not too sure of this idea though. It could also just make things more obscure.
I believe this is more prone to obscuring things, personally. In general, if you're going to make a platform game, you probably just want to start with a platform game template. Not a whole lot of people want to create engines for people to abscond with, but it does happen. I don't think we could just bottle them up. That would be more of a Stencyl design goal.

As for hiding things, I like to think a well-designed IDE wouldn't require it. Look at MS Word over the ages. You'll see the feature creep you're trying to avoid come and go, for better and for worse. There will be some learning involved in presenting users all and only what they need, but we shouldn't try fitting that to specific game types. Relying on that will just hurt people; we want to keep ENIGMA general-purpose.

Also, everyone's thinking about an IDE, and if I may say I have a vision where there is no IDE but a set of independent tools, a resource tree editor, an editor for rooms, an editor for objects, an editor for sprites etc so that people can swap out tools easily.
As I said, I believe that supporting this workflow is a good idea, but requiring it is a grave mistake. The features of Game Maker's IDE are everything that made the project any good. Its language was inadequate, its workflow was somewhat messy; coding-wise, it was a nightmare. The fact that it loaded all your resources for you was a huge part of why people loved it, but was only half of the picture. You would not enjoy using Game Maker without a room editor. I know that some games don't require one, at all—look at Minecraft. But again, look at Super Metroid. You wouldn't want to make Super Metroid without the editors I have described, here. There's just so much extra work you're doing for no good reason. With 3D games, people have come to accept that you can't have a canned editor. In particular, I believe Harri is holding the inadequacy of GM's room editor as evidence that there's nothing to be gained from having it, but for most users, that just isn't so, and if someone actually invested the effort into making a better room editor, I imagine Harri would want to use it, too.

For real though, I'd very much like to contribute more, the issue is that it's not clear what actually needs to be done (aside from bugfixes obv), there's not enough of a detailed plan, just ideas being thrown around with very little idea about how they would actually fit into the project. I've been spending time trying to teach myself the codebase for a while now (mostly SHELL, still don't have much intimate knowledge of the compiler and JDI is still something I don't really understand).
I can give you a roadmap or a full task breakdown, or any granularity in-between. What's currently "on my plate" (in the scope of things I am looking at doing) this:
  • Replace JDI with LibCLang. JDI is the system that reads function definitions from ENIGMA's engine. In the good old days, we maintained a text file that had a list of defined functions in it. Eventually I started migrating that file into headers, and then I realized, wait; why not just read the headers? So I wrote JDI, a C++ parser. It wasn't great at the time, and has not aged well.

    LibCLang can parse ENIGMA's engine, just fine. It offers an interface (of questionable API stability) to retrieve that definition information. This will allow ENIGMA to understand what data you have access to.

    I have actually already written code that can do this, but adapting it to the current system is not an easy task. It's therefore one I'm not interested in, as I seek to replace the existing system. This brings us to our next point.
  • Re-code the parser to actually generate syntax trees. Currently, the parser essentially uses a find-and-replace strategy to insert parentheses and semicolons where they are needed. Building a tree will be necessary to add the new language features we want. I am personally breaking this down into a few smaller tasks:
    • Code a lexer to break UTF-8 encoded text into tokens. I am personally doing this by building a trie with wildcard paths, so that I can build a prefix tree of essentially regular expressions to extract tokens. I have only just started this; haven't resumed work, recently.
    • Write methods to handle basic code constructs, such as if, for, while, switch...
    • Declare a table of operators, with precedence flags and RTL markers. This should be a map of token type to data structure.
    • Write a handler for all operators in that table.

There are hidden nuances in the bullet points of the second table, which arise from functionality of this language about which I am not certain. A few key points I want are as follows:
  • The language should define a module system to define compilation units and supplant the private/public keywords Java uses for everything. This does not concern ENIGMA, but is important to me as I want ENIGMA's IDE to be written in EDL.
  • The language should have full-blown reflection and complex macros to facilitate the DSLs people tend to fuck up without language support. This is why I'm overkilling the lexer mechanism.
  • The language should have getters and setters, or possibly full-blown listeners. This is required for some features of the engine.
  • The with() construct should not be a part of this language, but rather, a construct defined by ENIGMA (preferably using features of the language itself). Essentially, with() should be a macro defined to accept an expression followed by a statement.
  • I am interested in the possibility of embracing Rust-like variable ownership and lifetimes.

This is all to do with the compiler. As for the engine, it's mostly bug fixes, because we need a lot more compiler and IDE support for more feature progress, there. It's not like we're missing fundamental building blocks: the engine supplies all the tools you need to make literally any kind of game. Could we add more features? Probably. But we're mostly just down to stability problems because the compiler and IDE suck.

One of the engine's biggest problems is the lack of a broad-phase collision check (we have no spatial partitioning, for example, because we need to update that whenever you assign to x and y, and I never felt right about doing that when people usually say x=foo, y=bar; in immediate succession). We can technically overcome that, now.

Otherwise, most of the "engine problems" are from the extension system being crap, the object inheritance model being underpowered and poorly implemented, and the parser constantly blowing a fuse and putting semicolons where they don't belong.

Missing features boil down the same way. The compiler doesn't allow setting resource load hooks, defining dynamic library dependencies, or grouping objects and other resources (except by direct, single-parent heredity for objects). The IDE allows making basically any kind of 2D game that doesn't use environmental scripting.

What I'm trying to convey is, if you aren't seeing much to do, it's because you're looking at the engine, and barring some bugs (which evade even my awareness), there aren't any serious missing features (except broad-phase collisions). The forward progress of this project depends immensely on the compiler and IDE.

6
General ENIGMA / Re: What now?
« on: November 29, 2016, 02:10:58 PM »
I'm floored, Harri; thank you for your words.

Times like this, I feel it's time for me to suck it up and focus more on where this project should be, instead of just on what I'm paid to do for work. I think my issue is that I'm spending all my CS frustration budget on corp infrastructure, so I don't feel like putting up with more aggravation working on personal projects.

Anyway.

@SaulGoodman—My (outdated) understanding of what Harri was doing is that he was trying to embrace pure C++ as the sole language used with this engine. C++ is essentially the best language for the task of developing an engine, and one of the worst languages for developing a game. I will grant Harri that it's still better than GML, which is part of what ENIGMA basically sought to demonstrate... it's unfortunate that ENIGMA's parser (A) was never great, and (B) has not aged well at all. I think the project could be improved just by me fixing that, but I have higher ambitions. I would never imply that someone should give up—only that they should rethink.

To DarkStar's point, ENIGMA does not have an expiration date. As a piece of GPL software written in a language that doesn't seem to age (for better, or for worse), ENIGMA is the sort of thing that can lay dormant and crop back up any time. As it stands, it seems our "Active" developer count is approximately zero. That's a highly impermanent state. As long as there is interest in the project, it will continue to grow. Obviously, we've hit a lull in its forward progress, but I'm not sure where people get the idea that this constitutes death. But the fact that you and I are here, and we are having this conversation, means that ENIGMA is "alive" and well.

@time-killer-games—I am reasonably comfortable bounding the number of active contributors we've had, simultaneously, at eight. The peak of that would be the falling edge of forthevin's presence, here, where we had me, Harri, forthevin, polygone, Robert, and canthelp actively contributing code. I might be missing others who contributed during that time (I can't remember if heathtech and/or dazappa was active then). IIRC, sorlok came later, and TGMG was already gone. IsmAvatar was somewhat active in LGM during that time, and she was assisted by Medo42 and possibly Stian (very fuzzy on the chronology, there). In reality, we've had roughly 15 serious contributors in the project's history. Not to discount those who only made one or two commits—as I've said, interested users are the life of an open-source project.

@Yambam—I think you and I are on the same page.
  • Overworlds, as I've expanded on already in this thread, are very important to me. What you call "constellations" I believe is what I was demonstrating with Super Metroid's map.
  • Color Palettes... I recall mentioning something like this on the Wiki; color palettes may be old tech, but along with vector graphics, I believe they're a great step toward the next generation of game graphics.
  • Sound Environments... I'm not completely sure what you mean, here. You might be describing two things. If you're talking about loading/unloading sound resources for you as you enter different rooms, I didn't just want to do this for sounds, but rather for all resources; the ability to load resources quickly as they become needed for an environment is frequently critical. If you mean sounds that play when you enter a certain region, this would be another great feature of the region-based scripting I described earlier. We could specialize it in the UI for playing/looping sounds; that would be cool.
  • The instance key/value property editor is a must. As I said, though, we also need the room and overworld editors to understand instance values, positional values, bounding box/radius values, and vectors. These particular value types should be represented in the room/overworld editor visually.
  • You may have just unified multiple meanings of "category" that I describe separately. Similar to (3), I wanted labels for resources, so that you can load and unload cave/grass/ice/dungeon resources. But I think what you're touching on, here, is traits. Traits are a kind of design pattern where you can add canned functionality to objects, essentially. In fact, I believe an interface (or Protocol) meets most of the use-cases you describe. These are an important language feature, and I agree they are something the object editor should represent visually. In particular, multiple inheritance allows you to do the sorts of things you're describing. As long as this hierarchy was represented in the object editor, it would be trivial to have the room editor enable editing these "categories" simply as the actual parent object that owns them. Right now, you can have, for example, obj_gold, obj_gem, and obj_treasure_chest all inherit from a parent object, obj_treasure; you can then use constructs such as with() or snippets like instance_nearest(x, y, obj_treasure) to treat all types of treasure as the same, and consider them equally. Generalizing this with multiple inheritance and a concept of traits would accomplish what you seem to be looking for. I've said a lot about this on the Wiki, as well.
I'm not sure how I feel about built-in game templates vs a library of examples. I think a bank of community-contributed examples meets that particular need. This project is sorely lacking documentation (and tests, which can serve as examples). That will be another focus of my attention....



The one thing I will take from Harri's remarks, regarding the direction of this project, is how important it is that the IDE is not the ONLY way to develop with the engine. I believe that if I could conjure up code for an IDE that suits my tastes, Harri would never want to use anything else. But since no IDE will fit everyone's workflow, and some will inevitably prefer their own code or image editors, it's important that the compiler is invocable without an IDE.

7
General ENIGMA / Re: What now?
« on: November 22, 2016, 09:33:18 PM »
Just to clarify: ENIGMA doesn't have an expiration date. It's a piece of open-source software, and even without me anywhere near the project, others (particularly Harri) continue to commit to it.

As to whether ENIGMA is headed in the right direction, I suppose that's mostly a question of whether Harri is taking it in the right direction. I believe Harri's work will only serve the project good, even if it's not what I'd do.

8
General ENIGMA / Re: What now?
« on: November 20, 2016, 04:31:59 PM »
Visual links and value editors are exactly what I'm describing, yes; I want you to see where rooms are in space, see which objects are linked together, which regions or points are being monitored or used, etc, etc.

Doors are an example; in reality, the Overworld editor wouldn't know what a door is. It would just know that an object wants to know about an instance of another object.

9
General ENIGMA / Re: What now?
« on: November 15, 2016, 11:36:48 AM »
This layout can make use of overworlds, but it's really not a shining example of how they will help you. I think this design lends itself to five rooms: one to show exactly the contents of that image (Butter Bridge, the Donut Plains, and Chocolate Island), then another two rooms for Yoshi's Island and the Forest of Illusion (which are rendered in low-detail on that map view), and then two more for Vanilla Dome and the Valley of Bowser (which only appear on that map as entryways).

Where the overworld would come in, here, is creating a virtual layout of those worlds and links between them (the bridge/ladder to Yoshi's Island, the door and pipe to Vanilla Dome, the paths leading to the Forest of Illusion, and the mouth entrance to the Valley of Bowser).

The reason I don't like this example is because it doesn't leverage the real strength of Overworlds, which is the ability to create an ENORMOUS game space using entire rooms as building blocks. You're really just fabricating an impossible virtual layout, because the valley of bowser doesn't fit in that tiny hole on the map, and the vanilla dome is every bit as big as the path through the Vanilla Plains, and I think anyone can tell Yoshi's Island has been shrunk on that map... the point is, these areas don't occupy a real space. They're linked artistically on a map. Overworlds can help you with the doors, but you've already failed a big part of why Overworlds would exist.

What you want to think about is Super Metroid.


This is the map to Super Metroid. It is enormous. Leviathan. It's not completely true to 2D space, but that's not for a lack of trying. Every 16×16 cell on that map is the equivalent of a 256×223 screenful. This is a 200 Megapixel world map, any way you slice it. That's what makes Super Metroid so immersive. (Related: Super Metroid is approximately the greatest game ever created; if you haven't played it, you should go correct that.)

The map image above serves as a literal in-game map. It's how players know where they are at any given time. Overworlds offer both the ability to organize individual rooms into this map, as well as the ability to programmatically generate that map image. They take the guess-and-check out of this process. I'm sure the original Super Metroid team would have killed for such a mechanism; this was probably extremely difficult for them to organize by hand (and code up in Assembly). As one of the few people who has written a Metroid clone in Game Maker, let me tell you: organizing the doors on the sides of each room is an impossible pain in the ass. Just like before: is it doable? Yes! Is it fun and easy? Fuck no!

Doors in Super Metroid are different from doors in, say, Super Mario World or Kirby's Adventure in that they actually attempt (as I've said like six times now) to preserve a coherent 2D space. That's why it's possible to create a map layout of Super Metroid at all. Overworlds seek to facilitate this by providing a "global" coordinate system over a plurality of rooms arranged in space. There's no more complicated transition logic, this way; you simply change rooms, which triggers the loading of objects around your character. Because absolute coordinates are managed by the room system, they can exist multiple times in this virtual space without redesign. And because you've encapsulated pieces of this huge world in modules called rooms, you can load and unload them painlessly, as a unit.

On that topic, the wiki has some other ideas of mine about resource management (such as bulk loading/unloading of resources fitting a particular theme or area). No sense rehashing that right now.

The point of all of this is that we need a better IDE, but I don't feel like writing one right now. Talking about this is good for my sense of motivation, though.

10
General ENIGMA / Re: What now?
« on: November 14, 2016, 10:57:58 PM »
It does appear that I've added steps, but that's not really the case. You're thinking about steps 3 and 4 as though they're something unnatural—something you do once to make a door. They're not; this is something you'd do in general to organize the layout of your game world in real, coherent space. Not to mention, steps 1 and 2 are mandatory, regardless. Let's look at the old steps:
  • Place a door in room 1.
  • Copy its instance ID.
  • Place a door in room 2.
  • Control+Right click, open its creation code.
  • Assign the other door's instance ID and room number to locals for this door.
  • Save and close the door's creation code, and copy its instance ID.
  • Open the first door's instance creation code.
  • Assign the other door's instance ID and room number to locals for this door.
  • Save and close this door's instance creation code.
Not to mention, the real benefit is the fact that you're not hard-coding door IDs, anymore. That link is maintained for you, as part of the Overworld's state. Overworld contents can be automatically maintained as easily as any other resource link.

The bigger question here is how we standardize the variables these two systems set/modify. I think I explained my ideas for this in detail elsewhere, but the short version is annotations on variables to tell the room/overworld editors that this particular constant (be it a coordinate, a region, an instance ID, a vector, a segment, a mesh... whatever) is meant to be modified per-instance in the editor. This opens up so many possibilities. Even just looking over Mark's own examples set, it's amazing what this system would simplify,

11
General ENIGMA / Re: What now?
« on: November 14, 2016, 11:21:21 AM »
As I've thought more about why ENIGMA and Game Maker were ever good, it's occurred to me that the projects are really only good for making simple games, while a few simple features would drastically increase the scope of what you can do well in that system. GML sucks, and half of what EDL added to it is broken. That's an easy fix, at this point, ignoring the fact that JDI's ability to keep up in the C++11 world is not very good. Replacing the entirety of that system would probably take me a month.  But the question of "then what" is very real, and it's a lot of what's prevented me (motivationally) from working on doing so.

I now believe two things:
  • Everything that made GM good was in the IDE's organizational structure;
  • GM's IDE had somewhat poor organizational structure.

I see immense room for improvement, there: improvements that could make ENIGMA as much better than GM as GM was better than your typical game engine/RAD kit.

My greatest examples of that are Overworlds and Design Mode, which I've detailed on the Wiki. I think Studio has started implementing the latter. The former would make development of late NES and SNES-era games as easy as ATARI/Early NES games currently are. The thing that makes those hard in Game Maker now is management of simple scripting, game story control, and world layout. It's so ridiculously hard to make a script trigger when you enter a given spot in a room. It's so preposterously hard to make a door lead to a given door in another room.

Maybe you're thinking, "No it isn't! I know how to do those things!" Well, good for you; so do most veteran Game Maker users. That doesn't mean it's easy. In fact, the single best way to do triggers right now is as follows:
  • Create an object.
  • Have its create event zero out a region and set a script number to -1.
  • In that object's step event, if (script != -1 && obj_player.x >= x1 && obj_player.y >= y1 &&) script_execute(script);
  • Create a script that does the thing you want to happen in your trigger.
  • Place the object in the room, and in its room creation code, assign x1, y1, x2, and y2 to specify the region you want, manually, and set script to your new script's name.

When I was little, I got clever, and I made two objects to represent a region. Instead of setting x1, y1, x2, and y2, I simply set an other_bound instance to the ID number of a separate instance in the room. Rather than an ugly (?) object in the room, this gave me two corner sprites, so I could sort of tell what they represented. Dr. Overmars likes to use a script sprite on the object, or a little computer sprite. Whatever. You can trade more work for aesthetics.

The point is, this is the single cleanest, most modular, scalable approach achievable in ENIGMA today, and it SUCKS. (Also, I wouldn't be surprised at all if script_execute was flaky.)

Door control has a similar solution; you use an instance creation script to tell the door where it's sending you. But there's no link! You have to maintain a room ID and an instance number or room coordinate yourself.

If you can't see why this approach is bad, you don't appreciate GM/ENIGMA for what they are. Implementing this wasteful approach has polluted your dev environment with an object that serves no purpose, a script whose purpose is so specific and nichey that it isn't worth an entry in your resource tree, and a weird, ugly instance in your room that you have to control-right click and hit Instance creation code to understand. Not to mention the magnitude of effort it took to set all this up.

The workflow for triggers should have looked like this:
  • Click a button
  • Drag a region
  • Type your code
  • Hit "save."

The workflow for cross-room doors should have looked like this:
  • Place a door in room 1.
  • Place a door in room 2.
  • Create an overworld.
  • Place the rooms in the overworld.
  • Hit a button.
  • Select the doors you placed in room 1 and room 2.
  • Hit OK.

My hope is that one day, they will.

Unfortunately, no one enjoys doing IDE work. We've got a ways to go before anyone's ready to commit to making a decent game editor a reality. This is why there's no communication and no roadmap. ENIGMA doesn't put bread on the table; that's why I work at Google. But I'm still planning.

12
Issues Help Desk / Re: Can't get ENIGMA to run on 64-bit Arch Linux
« on: July 10, 2016, 12:38:00 AM »
That 32-bit error sounds problematic... Arch has a set of C++ headers that don't agree with ENIGMA's parser. Try the fix posted here for a similar parse crash. It's been working for people with updated headers. It's a dirty hack, but it seems necessary for the time being.

13
General ENIGMA / Re: ENIGMA: Studio
« on: May 27, 2016, 09:25:10 PM »
Personally, I'm a fan of the current logo. Wouldn't change it. As for a banner, I'd prefer something that makes a bigger statement; something playful, but interesting.

I threw this together as an example:

Try hovering over it with your mouse.

The coloring's definitely off, and the shapes are off, but that's basically what I'm looking at.

14
What Robert is trying to say is that contained within ENIGMA's compiler is the parser part of a C++ compiler, which I called "Just Define It" (JDI). For ENIGMA's syntax checking and EDL parsing to work, JDI has to be able to read the engine file, as a C++ compiler would. While I coded in some support for C++11 when I wrote JDI, the specification was new at the time, and I didn't feel like meddling in it. So even though JDI has some C++11 features, I believe it's missing enough of them that I never told it to advertise support for the specification—it sets __cplusplus to reflect support only for like C++98/03.

This has never been a problem, because (A) all the STL headers are SUPPOSED to compile under C++98, and (B) the features of C++11 that you enjoy (and are using in ENIGMA) are blindingly easy to support in compilers, so I supported them. This was somewhat perforce, as GNU C++ has supported the bulk of these features since the dawn of time. That said, harder constructs, such as variadic template parameters, are missing from JDI, and I have no intentions of adding them. If you use them in ENIGMA's engine, this will create problems for the current compiler.

Since C++98 is still a thing, I don't know why JDI has suddenly been rendered incapable of parsing <string> correctly. I also don't know why it's printing only one error... did someone suppress the rest of them? I can't make a diagnosis without them. Still, I suspect it doesn't matter; no one actually relies on JDI knowing what string can do, as evidenced by the above working.

15
I'm sorry; I see the same problem on my Arch Linux install. I can only guess what's causing it, as the only error reported is a lack of support (by JDI) for C++11.

You can work around the issue temporarily by placing this at the top of SHELLmain.cpp:

Code: (C++) [Select]
#ifndef JUST_DEFINE_IT_RUN
  #include <string>
#else
  #define _GLIBCXX_STRING 1
  template<typename T, typename traits = int> class basic_string {};
  typedef basic_string<char> string;
#endif

That's really ugly, and I always hoped no one would ever have to do that, but I can't tell why this is failing, and a proper fix seems far off.

Pages: [1] 2 3 ... 188