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

I don't see how. A function is a function....

Not sure. We could just abuse the const keyword, like so:
Code: (EDL) [Select]
when (x >= const(argument0))

You seemed to expect when() to fire for each call when you called it in that script. Each when would have only one id, but there's an issue with that, anyway; neither x nor argument0 is a constant. We haven't specified any way of denoting that one of the parameters passed to when() is constant. So when that when() was called, the condition x > argument0 would be superimposed on the step event, and that check would be done each step verbatim.

General ENIGMA / Re: ENIGMA games on DS
« on: December 24, 2010, 07:17:58 AM »
I'll be dealing with most of the problems you named for the DS when I do the Wii version. Sprites will need overhaul for use on phones anyway (for starters, storing them in strips rather than in individual texture buffers).

The DS -does- support 3D, though, and I do not intend to forsake that functionality. Just leave that part to me.

I'm presently combating something nasty with the compiler. When I'm done with that, I'm going to spend the next couple days making sure I got the job done, then I'll begin the Wii port which will use a custom GX graphics system. That is the only way ENIGMA will ever work at any considerably efficient rate on the DS. The prospect of Game Maker for DS existing infuriates me, but this is the one platform that I can say beyond the shadow of a doubt that GM will not even stand a snowball's chance in hell against ENIGMA. Every fucking microsecond finally counts, and that miserable interpreter of there's will be the end of them.

Announcements / Re: Collisions update
« on: December 23, 2010, 09:52:43 PM »
I'm always talking about performance, Rusky. Like everything else in GM, collision choices are relatively limited.

I'm not presently able to test your file, MrGriggs; I'll do so when I'm done working on this type resolver.

Function Peer Review / Re: distance_to_object
« on: December 23, 2010, 09:51:47 PM »
Issue is, I don't know what GM does either. It does compensate for something like a bbox, but I'm not sure if it calculates the distance between the closest two points in the entirety of either mask, or if it calculates the distance between those along a straight line, or if it just defaults to bbox (which would be the only reasonable method), and if in that case it uses a rotated bbox or just a standard one... I'm in the dark on it. But I might accept Retro's bottom function. Provided, of course, that dist_ranges be made inline or into a macro.

Yes, all of these will be queued in each event if used. Pay attention to that last clause. If no one uses the when(), step{}, or draw{} statement, they will not be added to any of the objects. As polygone mentioned, most of the events are entirely queue-based anyway, so the performance cut from when() will be roughly negligible. Those who are concerned about the negligible (such as myself) can opt to program the checks in manually so they are not stacked anywhere and iterated.

I like the draw {} idea. I think we'll limit it to that.

As for current_step making lives easier... I suppose so, but I think ENIGMA inherits enough bloat from GM as it is. I... guess I'll consider it since current_time in fact will not take space in ENIGMA's RAM unless used.

Ah, I see. Not a bad idea; I'll implement it when Ism reads events.res after we have our own format.

Yes, I'm pretty happy with the syntax we specified (used in my example code). We should probably document the alarm-like behavior of when (with the ++name) so new users know how to do so simply.

game_end(bool now = false): Good idea.
instance_destroy(obj): Already done. Since R3, and made public in R4.

I'm not actually sure it would work very well having it's own interface, it sounds like a lot of work to implement as well which is never good for Ism.

I was thinking before of perhaps a separate set of functions for pausing, similar to the high-score functions maybe. So it's functionality is not fully in the hands of the user but more generalised. This would be easier for plain pause menus and for most people to use but then a lot of pause menus also need to interact with the game itself which would be more difficult to do (maybe script_execute could be utilised though?).
Actually, it'd be as simple as another setting script like the four she offers now under "ENIGMA Settings." Each of those is supposed to be game-specific, and Definitions scripts are supposed to be instantiable. ENIGMA will, at that point, let you set code to be executed before game start, after game end, and (with my proposed addition) during game pause.

I think you should add a separate event for timers, which is executed every step until the count hits 0. Just like alarms really...
I see no distinction between your proposal and additional alarms. We could easily make alarms unlimited.

The when statement suggestion I think should definitely be added also, it really is a more powerful system. I don't think it's best suited like a for statement though, more like a do, until statement and I think it should be renamed from when to something else
when(){} and do_step{}  are two entirely different mechanisms, as I'm sure you realize. They are the step-based equivalents to if() and while(), respectively: if() and when() are performed only once (when the condition is finally met), where do_step() and while() are performed throughout the duration of a condition (or its negation). In ENIGMA, no distinction is made between while !() and until()... that may work to our advantage. How do you feel about when(){} and step(){}[until()]?
Code: (EDL) [Select]
// Destroy the next gate we come near. It'll probably create effects in its destroy event.
when (distance_to_object(instance_nearest(x,y,gate))<32)

// Implement an alarm using only one local variable
local int do_explode = 0;
when (++do_explode == 30)
   // Alarm code

// Emit particles until not dizzy
local int dizzy = 100;
step {
} until not dizzy

...Sometimes I think you don't know what with() does...

Code: (GML) [Select]
for (i = 0; i < instance_count; i += 1) {
    if (instance_id[i].object_index == bomb_obj && distance_to_object(instance_id[i]) < 100)

Is apparently the same as, but much, much less efficient than
Code: (GML) [Select]
with (bomb_obj) if (distance_to_object(instance_id[i]) < 100)

The create event in GML is the equivalent of a constructor in C++. By logical dynamic, the create event must be the first event an instance can perform. Events.res has no control over the create event; it only lists it with an integer mapping to Mark's specification.

Proposals / Re: Editing Events Inside LGM
« on: December 21, 2010, 08:17:16 PM »
At present Ism doesn't obey events.res. And this is very Java-oriented, which pretty much leaves me out. So I guess we'll see.

Announcements / Re: Collisions update
« on: December 21, 2010, 08:15:09 PM »
I have indeed always been. If there is one thing in that forsaken program that Mark did right, it's collisions. In theory... Actually, I don't have much of a theory. I made sure that ENIGMA's instance and event systems were at least as efficient as his, so any slack he saves I'll be saving as well. What it comes down to is us keeping up with Mark in his own domain (it is my understanding that he teaches courses in collision system design).

General ENIGMA / Re: ENIGMA games on DS
« on: December 21, 2010, 08:12:01 PM »
Yes. Miky started a port for it an eternity ago, when developing for ENIGMA was difficult. By today's standard, ENIGMA for DS would be hundreds of times easier (soon to be thousands when I begin the Wii port later this month).

Trying to sort through you two's bickering is frustrating, so I'll just reply to everything I see without linking the posts together.

First, Poly's original post:

1. Referencing multiple instances

In Game Maker, the only way to do this is multiple inheritance. Most worthwhile scripting languages today offer multiple inheritance, but this isn't compatible with GM's system at face value due to ambiguity in event inheritance. I am still abstracting ideas on how to resolve this, but some of them depend on Ism. I've actually been thinking about this myself for my own purposes, and this is what I have so far:
  • Introduce weighted multiple inheritance. The objects are traversed from least important to most important, each overriding the code of the previous one so any conflicts are resolved by taking from the most important. (In any case, the current instance is given highest priority). In the case of empty objects used as groups, all instances of all objects inheriting from that group object are identifiable by the ID of that group object.
  • A separate "tag list" deal for grouping. Like objects, only with no wasted space in the object table (or what have you).
  • Varied object types. Game Maker games have a lot of controller instances and parent objects for the sole purpose of grouping. Being able to add an object of each kind could improve efficiency and organization in general, and also solve this problem (you reminded me of it). This strikes me as the ideal solution, but depends GREATLY on IsmAvatar, who may not be easily sold on the idea, as well as on a new format for ENIGMA games, which will eventually be necessary but is not yet implemented.
2. Referencing resources as strings

I've never thought of this. It could be implemented but is not in any plan thus far. As you may be aware, maps are much easier to use in ENIGMA, but if you feel this is beneficial, file a suggestion in the tracker and I'll see about implementing it.

3. Exiting Code

I've been chewing on this issue for tears. Presently, scripts and DND are homogeneous; one exit means all exit. And, game_end() is instantaneous at the moment because I've not standardized an exit method. I've been waiting for someone to complain about this behavior before I modified it; suggestions are always welcome. I may define "exit" as goto <label generated at end of this script> and leave "return" as an omnipotent breaker. I Intended to do this about the time I index the code for quick position lookup on C++ compile error.

4. get_real

Already implemented in GTK interface; will be implemented in WinAPI when the widget APIs are finished and made available.

5. Pausing The Game

In the beginning, when the earth was young, young me wanted a pause feature that would put that kind of functionality in the hands of the user. Back then, it was intended that ENIGMA would have its own interface, and I would have a special resource to implement draw code for the pause screen. I haven't even presented the idea to Ism, because I have enough things on my wish list for her. Do you suppose it will require more than a single script executed each paused step? And should it paused immediately, or just after the frame? (You mentioned this point in another issue on this list).

6. Multiple collisions issue

Good suggestion! When I was new to Game Maker, I had this problem. I wanted to play a sound when crashing into an instance. An abs(hspeed)>0 check wouldn't work, because I just set the hspeed every time you pressed an arrow. So I ended up just checking that the sound wasn't playing. Your example's an even better one, though. The problem hasn't occurred to me in a while, and I never thought up a solution in ENIGMA. I'm a bit tired to think one up now, but I'll put some thought into it over the next while and tell you if I come up with something. My first impulse is a flag called "collision_fresh" which is set to TRUE or FALSE according to whether or not a key exists in a 2D map with the IDs of both instances. I have no idea the implications of the efficiency or simplicity of use, so I'll have to think about it further.

7. Timers
Rusky got me thinking about this problem not long ago. His solution didn't strike me as practical because I didn't see how to implement it (especially in ENIGMA), but the idea is an instantiable event (his proposal involved closures). Presumably this could be resolved by having easily forged first-class functions, but with the current state of both C++ and GML this just doesn't seem practical in full scale. They're illegal inline in C++, and var doesn't allow storing anything but real and string. What I may end up doing is allowing in-place declaration of alarms, which would mean no less bloat, but an easier interface. Again when the earth was young, I was thinking it'd be neat to have a when() {} statement, but I hadn't the foggeiest how to implement it. I may as well use the same mechanism to do so.
Or I can simply implement when() to mimic for(), and it could be used like this:
Code: (EDL) [Select]
when (i=0; i==10; i++) {
  //Alarm code
But that's kind of ugly. What do you think? My original idea was just when(condition), but I'm not sure the typical user is smart enough to say timer_explode = 0; when (timer_explode++ == 10) explode();

Upon reading the rest of the replies, they seem to have resolved themselves or have already been answered above. I don't have an API to iterate instances other than rooms, which you can do in GML like so:
Code: (EDL) [Select]
for(r = room_first; r != -1; r=room_next(r)) map[room_get_name(r)] = r; I could add such an API for all resources, if you like.

Proposals / Re: Script Editor Improvements
« on: December 21, 2010, 07:46:55 PM »
I just wanted something more elegant than JEdit, which wasn't designed for much of anything by the looks of it (It doesn't seem to have an interface to number lines or highlight a certain line number, for example. Or if it does, Ism needs a good smack). I am not great with Java by any stretch, so I asked Ism to isolate JEdit's code so I could work with it to add some functionality specifically tailored to ENIGMA. She was unable to do so, so I dropped it. (thingsihateaboutjava++)