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

1516
Proposals / Re: Welcome PM
« on: December 26, 2010, 10:58:40 AM »
Good point. We'll probably set something up like that when ENIGMA's Windows installer is tailored to beginners.

1517
Proposals / Re: Introduction / Profile Forum?
« on: December 26, 2010, 10:51:49 AM »
That's why I implemented our current policy on bullshit. People make up nonsense about what they need to know about a system, and the developer fills it in.

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

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

1520
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.

1521
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.

1522
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.

1523
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.

1524
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.

1525
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.

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

when/step:
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.

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

Quote
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)
{
  instance_destroy(instance_nearest(x,y,gate));
}

// 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 {
   instance_create(x,y,dizzy_spiral);
   dizzy--;
} until not dizzy

Rusky:
...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)
        instance_destroy()
}

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)
        instance_destroy()

Freezway/Ism:
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.

1528
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.

1529
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).

1530
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).