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

Proposals / Re: Sprite sheets
« on: September 13, 2012, 03:53:12 PM »
What appears in the dropdown list?

Proposals / Re: Reintroduction of build mode
« on: September 13, 2012, 03:26:01 PM »
For all I know, it's already out, and you just haven't updated.

Proposals / Re: Reintroduction of build mode
« on: September 13, 2012, 03:12:06 PM »
I'm not hacking together a program to fix a mistake that shouldn't (and soon won't) exist.

Proposals / Re: Arrays
« on: September 13, 2012, 03:11:02 PM »
What would you have [] = scalar do?

Proposals / Re: Sprite sheets
« on: September 13, 2012, 02:41:12 PM »
That's the idea.

Proposals / Reintroduction of build mode
« on: September 13, 2012, 02:33:54 PM »
I need reports on a successful widget system from each platform. Widgets have not stopped working on Linux, to my knowledge, provided the correct GTK packages are installed. However, they don't work on Windows due to problems with the outdated windres.exe, to which I have still not heard an end, and they also do not work on Mac without serious poking, I imagine.

So I need TGMG or another similarly capable Mac developer to write Cocoa equivalents for the Win32 widget functions (if the Cocoa API is free-form like Windows) or to the GTK widget functions (if Cocoa is more like GTK). I stress this difference because the Windows widget functions have a function which behaves like the layout managers in wx, GTK, and Java Swing: It is capable of ordering items into a table for the existing layout option.

So get widgets working, people. I've coded what I can; we just need windres and a cocoa port.

After that, I'll need collaboration from IsmAvatar to actually set it back up as it once was.

If you're wondering what build mode is, it's a secret.

Proposals / Static Sprites
« on: September 13, 2012, 02:22:40 PM »
An idea you'll find in non-GM game development suites is static sprites. Mechanistically, they're sprites that you place at a fixed (static) position in the room. Essentially, they are animated tiles. This is 90% UI related, or I'd probably just throw it in without ever writing up a proposal. LGM's tile editor is sad as it stands, and so is ENIGMA's tile implementation (no offense to TGMG, who just wanted something in that worked).

Ideally, they'll be placed at a certain depth using the tile editor. We'd want a way to set their coordinates, animation speed, and maybe scale/rotation.

Proposals / Re: Arrays
« on: September 13, 2012, 02:19:11 PM »
This is an EDL feature; the expectation is that the user will distinguish those two with the use of a semicolon. However, if you have an idea to eliminate that, let's hear it.

Proposals / Re: Named loops vs numbered breaks
« on: September 13, 2012, 02:18:07 PM »
I see both sides. I'm pretty sure I'll end up doing both; the mechanism that handles the double break will be the same, so the difference between the two implementations C++-side will be in identifying the loop to which the user is referring.

Proposals / Arrays
« on: September 13, 2012, 02:11:37 PM »
I doubt anyone would disagree that ENIGMA needs arrays. What I'm proposing is that rather than inherit array syntax from C++, we take a page out of the JavaScript playbook and denote them with [].

I want to use [] for a couple reasons. First, of course, is that [1, 2, 3][1] looks neater than {1,2,3}[1]. That was a joke; I don't give a shit about that. What I want to allow is this sort of syntax:

Code: (EDL) [Select]
[x, y] = [y, x] // Switches the values of x and y
[x, y] = get_some_coordinates(); // Fetches a length-2 array of coordinates, assign

Using {} for arrays, {x,y} would be ambiguous; it could be a new scope which uses x and y, or it could be our assignment array. There would be next to no way to distinguish the two, so it's out of the question if we want the assignment array.

As for the dynamics, when compiling to C, this is what it would look like:
In the [a,b,c]=array_func() case:
Code: (C++) [Select]
  Array tmp = array_func(); // This is copied verbatim
  switch (tmp.length) { default: // Array size is size_t; must be >= 0
    case 3: c = tmp[3]; // Waterfall
    case 2: b = tmp[2];
    case 1: a = tmp[1];
    case 0: ;

In the [a,b,c] = scalar_func() special case:
Code: (C++) [Select]
  c = b = a = scalar_func();
As for building an array, that's easy. Old ENIGMA can do that. [expression1, expression2, expression3] simply becomes this:
Where Array(int N) reserves N variants, and Array& Array::put(int, variant) is the same as Array::operator[](int)::operator=(variant).

Proposals / Re: Sprite sheets
« on: September 13, 2012, 01:44:43 PM »
A sprite sheet would contain m subimages from n sprites, m >= n. Maybe the user wants one sprite sheet per sprite, maybe they want the entire world on one sheet (and maybe it's efficient to do so!).

I believe the better word for what I am describing is a "texture map." I am not sure if they are genuinely synonymous, but I figured more people here would know what a sprite sheet looked like. What I'm really referring to looks something like this:

Proposals / Re: Named loops vs numbered breaks
« on: September 13, 2012, 01:41:05 PM »
I'd warn/error on break 0, too.

It's easier to to read break 2, in my opinion; even if you're in a huge nested loop, you have an idea of how many loops you're in, whereas you can easily forget what a loop is named. Granted, you can assume it breaks the big one or huge one based on context, but with break 3, you know it's breaking all of them.

Proposals / Re: Resource group load/save functions
« on: September 13, 2012, 01:37:54 PM »
I should have clarified; I intended the non-threaded load to wait for any threads which may be loading the resources.
So during a cutscene, you would call the thread version, but after the cutscene, you would call the non-threaded version and it would make sure the load finished before returning.

Proposals / Preprocessors
« on: September 13, 2012, 11:13:41 AM »
Since ENIGMA supports compilation on a wide variety of platforms, and soon, a small variety of languages, it is going to become necessary to give the user a way to deal with that.

Now, C++ gives a fine way of doing that: Preprocessors. The issue with C preprocessors is that they are ugly. They must be the first thing on a line, and must consume the entire line. In EDL, we'll want to fix that.

My proposal is that preprocessors be given by {{}}. So, if you wanted a piece of code to run only on Mac, you'd use something like this:

Code: [Select]
{{if ENIGMA_Platform == "ios"}} gamecenter_initialize(); {{endif}} // Initialize the game center if we're on iOS
highscore_add(name, score);

That will bring up the game center on iOS, or something. Ask TGMG; I really have no clue about iOS.

Proposals / Definitions Resource
« on: September 13, 2012, 10:49:04 AM »
LateralGM offers a script editor in ENIGMA settings which allows the user to specify C++ definitions. The issue is, there's only one instance, and it only supports C++. Later on, when ENIGMA supports other languages as the back end (which so far we only plan to be JavaScript), we will want another such resource. If this becomes a big part of ENIGMA, it may be frugal to offer definitions as a tabbed script resource which allows specifying definitions in each language. So one Definitions resource can contain a script full of C++, a script full of JavaScript, etc.

When you save a definitions script, a reparse will be run, and the definitions will become available to you from within EDL. It would be possible to export the definitions resource, and it would be saved with the EGM (as the existing definitions script is now).