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: Additions to new platform system
« on: December 28, 2010, 11:28:14 PM »
C:\MinGW\bin\
/usr/bin/
fuk:i:r:apple:xcode:fuck:stuffthatsworthitssize:stuffwestolefromgnu:bin
C:\DevKitPRO\DevKitPPC\bin\

1517
Proposals / Re: Additions to new platform system
« on: December 27, 2010, 03:56:54 PM »
TGMG:
Please extend this: http://enigma-dev.org/docs/wiki/index.php?title=Compilers/
And this: http://enigma-dev.org/docs/wiki/index.php?title=Module_hierarchy

I'm not opposed to having a Makefiles/ folder of the same design under SHELL/.

1518
Function Peer Review / Re: distance_to_object
« on: December 26, 2010, 06:16:01 PM »
Not to mention, enigma::fetch_inst_iter_by_int(object) is literally as efficient as can be. It is, in fact, the function that composes with(). It is set up such that there is no way to make it any faster; the iterator it returns accounts for all aspects of instance iteration, including ID, object index with heredity, and keywords such as all, other, or noone.

1519
Proposals / Re: Introduction / Profile Forum?
« on: December 26, 2010, 11:03:23 AM »
Oh, haha. I thought you were talking about docs in general. I saw something about replies being useful, and figured you were thinking that discussion on a particular piece of ENIGMA would promote understanding for future readers.

Anyway, what you're describing is what SourceForge has. A competency level for each language. We could tailor it to ENIGMA, giving a competency level for each system or function set, I suppose. And by "we," I mean someone who isn't me. I despise PHP.

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

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

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

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

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

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

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

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

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

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

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