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

1741
General ENIGMA / Re: GML
« on: September 07, 2010, 01:58:58 PM »
*shrug*
I wish I could have finished that C parser a bit faster.
Anyway, watch what happens next, Game_boy. Don't blink.

1742
Issues Help Desk / Re: Needed ENIGMA functions
« on: September 07, 2010, 11:59:16 AM »
Luis: The beauty of the new instance system is that none of the engine functions require an object_get_parent().
Regarding your syntax error; if you open the file it mentions and press the syntax check button, it will highlight the place it occurs as well as print the line number and such in the status bar.

This is an implementation of instance_position, returning the first instance AT x,y.

Code: (C) [Select]
// Copyright Josh Ventura, etc.
int instance_place(int x,int y,int obj)
{
  for (enigma::inst_iter *it = enigma::fetch_inst_iter_by_int(obj); it != NULL; it = it->next)
  {
    if (x == ((enigma::object_planar*)it->inst)->x
    and y == ((enigma::object_planar*)it->inst)->y)
      return it->inst->id;
  }

  return noone;
}

I've already added it, of course. Look for it in the next revision.

1743
Announcements / Re: Where do we stand?
« on: September 06, 2010, 10:05:54 PM »
polygone: I've been riding Ism for weeks about implementing saving one resource so we can release with a clean conscious, but she's still not done it. As soon as she's done with that, I'm releasing.

1744
Tips, Tutorials, Examples / Re: Which should I use?
« on: September 05, 2010, 09:00:09 PM »
-sigh-
Yes, I suppose if you take all optimizations away, and are using a non-scalar object, then yes, a pre-increment is more efficient.

1745
General ENIGMA / Re: GML
« on: September 05, 2010, 08:28:59 PM »
ENIGMA supports all of that, Luis.

1746
Tips, Tutorials, Examples / Re: Which should I use?
« on: September 05, 2010, 09:55:16 AM »
Quote
Moreover, some people suggest ++i instead of i++. Does the same thing, but is more efficient,
and is safer for recursive functions.

I'm getting a bit tired of that myth.

int i = 0;
cout << i++ << endl;
cout << ++i << endl;

The above prints 0 2. If we were to look at the micro operations, i++ would send to RAM, then increment; ++i would increment, then send to RAM. I.e., the same process, but with the order changed. Neither is more efficient. I've never heard that one is safer than the other for recursive functions. It's a matter of understanding which one will behave in the best manner for the current algorithm.

1747
General ENIGMA / Re: GML
« on: September 05, 2010, 09:48:43 AM »
Those two functions, game_save and game_load, have been giving me a headache. There doesn't seem to be a good way to implement them in an established C++ environment. I have no idea why Mark doesn't save ds_*'s. That was the -ONLY- reason I thought an ID based data structure system would have any place in ENIGMA. Knowing that he doesn't save them, though... Erg.

Anyway, my plan for game_save and game_load was basically to require that all variables that are to be saved be given a type with one of the following properties:
1) An overload for operator<<(ofstream::operator&, class&) and likewise for operator>>()
2) A member called _game_save(FILE*) and _game_load(FILE*)
3) An overload for enigma::game_save_putter(class&) and enigma::game_save_setter(class&)
4) A structure containing only types meeting the above
5) An overload for a pointer to a type meeting any of the above and a size_t length(void)
6) A standard iterator system (begin(), end(), operator++(int)) returning any of the above as a scalar or an std::pair.

If all types meet those specifications, the entire game can be saved. Is that great, or what?

1748
Announcements / Re: Mini Progress Feed
« on: September 05, 2010, 07:00:25 AM »
Well, I did fix var[,] as well as hexadecimal (which no one even missed yet). I also fixed a problem with abs(), string(), and possibly the Bessel functions. I've not tested the Bessel functions for some reason; they either work or error at compile time. Fixed some bugs with the new accessor system and the new type resolution system, but I know of a bug that has not yet been reported regarding a.b.c access potentially failing where b is not an integer (in cases such as object0.name.length()). I have a generic idea of how to solve that, but I need to get :: working in the syntax check and parser first.

I've also been working a lot with TGMG to try to work out the rest of the parse errors on Apple. It's astounding. I got macro unrolled-versions of all the headers from TGMG to debug here on Linux where my tools all work, and ran the parser on it... No error. This means one of two things:
1) The macros somehow interfere with the parsing
2) The parser is misbehaving in some other way on Apple
The former is unlikely due to the fact that there are no macros even near the code in question. The latter would be a horrific realization.

Looking at implementing build mode, it seems I'll be going with my original plan to incorporate cross-platforming: A window system similar to GM systems. Basically, the API will look like this:

Code: [Select]
int win = gui_window_create(0,0,640,480);
int pan = gui_panel_create(win,0,0,640,480);
int but = gui_button_create(pan,8,8,120,24,"Press Me");

gui_window_step(win);
if (gui_button_pressed(but))
  game_end();

1749
General ENIGMA / Re: GML
« on: September 04, 2010, 12:42:57 PM »
Most of this has been said by now, but I'll reiterate and ad lib.
I'm not sure where Brett got the idea that tile IDs start at 1,000,000... I believe that may be where tile depth starts.

Anyway, resources (sprites, scripts, objects, etc) start at zero and never reset under normal GM situations. Ism added a function to LGM that can defragment them, but basically, the first resource you create is zero, and any resource after that will just keep counting.

Based on the idea that a game will never have gone through 100000 objects, instance IDs start at 100001. Each instance placed in a room has a "hard-coded" (tongue and cheek in a runner) ID. This means that no matter how many times you visit the room, the instances in there at load time will be given the same ID.

From there, created instances use the same methodology as normal resources; adding constantly to the current highest ID.

ds_stacks, lists, maps... files, surfaces, etc., are all given the same system.

As far as GM is concerned, object0 == sprite0 == instance0-100000 == surface0 == file0 == list0.

This was all just Mark's method of removing pointers.

1750
Proposals / Re: GM Function Implementations
« on: August 31, 2010, 01:46:40 PM »
I try to avoid things that make threading a bad idea, because a method of moving instances between threads would be nice, eventually.

Anyway, I have to admit to liking your _ENIGMA_VARARGS idea. I think such an implementation would be quite useful, and I know how I'd do it.

typedef double *_ENIGMA_DOUBLEARGS
typedef varant *_ENIGMA_VARARGS

When the parser sees a function taking parameter typedef _ENIGMA_VARARGS, it does something like what you said, but inline:
min(1,2,3)      becomes       min((variant[]){3,1,2,3})

I was looking for an excuse to track parameter types more closely, and this has given it to me.

1751
Announcements / Re: Mini Progress Feed
« on: August 31, 2010, 03:29:19 AM »
Okay, as of now, OBJECT.variablename works for everything but global, which some part of me is still deciding what to do with. As I mentioned earlier that such would effect, with() now works again as well.  The list of things from R3 not yet implemented is quickly shrinking.

var[,] and build mode are the two remaining big ones.

1752
Proposals / Re: GM Function Implementations
« on: August 30, 2010, 01:50:18 PM »
r9k: Indeed, I've been looking for the best way to provide unlimited arguments to the function. It seems my only choice is to parse it that way.

1753
Announcements / Re: Mini Progress Feed
« on: August 30, 2010, 12:21:03 AM »
Listen. To. Me.
I. Do. NOT. Call. ANYTHING. In. The. Program. Files.

Again,
I. Do. NOT. Call. ANYTHING. In. The. Program. Files.

I don't care if you know what happens when you type text into the black box Microsoft calls a terminal. I do not make calls to system(), because system() incorrectly parses quotes on Windows, ignoring them. Instead, I call CreateProcess, of which parameter0 is an unquoted path to the module to be loaded.

If you listened in the damn IRC, you would have heard that the error still persists when Make is called manually by the user. Meaning one of two things
1) The unescaped string is in the makefiles (unlikely)
2) The MinGW configuration being called is invalid (very likely in your case: using Code::Blocks' custom MinGW shipment)

I have no idea why Rusky is experiencing that problem, since his MinGW has no affiliation with the Program Files, either, but you two are the only Windows users experiencing this issue.

1754
Announcements / Re: Mini Progress Feed
« on: August 29, 2010, 02:18:41 PM »
Ah, yes. That was just me being tired at two in the morning. I didn't feel like intercepting parse output between the part where self. is added and OBJ.varname is replaced. :P

1755
Announcements / Re: Mini Progress Feed
« on: August 29, 2010, 01:12:57 AM »
Retro: I asked you ages ago to test file_find_first on your system. The only explanation I have is that ENIGMA cannot read the YAML files defining those locals on your platform. I have a hunch it has to do with access() rather than opendir().

Progress:
Haven't seen Ism all bloody day. Worked with TGMG and resolved a few more Mac issues, but there seems to be a problem with one of the compatibility macros on that platform. We'll look into it tomorrow.

Fixed the parsing of `OBJECT.variable`. Its functionality, however, is not yet finished. I may finish it before I fall asleep, but I can't promise that. It will be finished sometime today, though.

Annoyed at a problem retep and Rusky are experiencing. For some reason, their MinGW configurations are trying to access something from the Program Files, but only manage to call C:Program. Talk about annoying.

Further update:

Code: (C) [Select]
int cfp;
cfp.x = 0;
cfp.y = 0;
cfp.randomness = 0;
cfp.bliss = 0;
cfp.speed = 0;
cfp.health = 0;
string xfp;
xfp.length = 0;

instance_nearest(x,y,0).r = 0

er.ar.bar = car;

string *xstr;
xstr.length = 0;


//=======================================\\
// P a r s e s   t o
//=======================================//

int cfp;
int cfp;
enigma::glaccess(cfp)-> x = 0;
enigma::glaccess(cfp)-> y = 0;
enigma::varaccess_randomness(int(cfp))= 0;
enigma::varaccess_bliss(int(cfp))= 0;
enigma::glaccess(cfp)-> speed = 0;
enigma::glaccess(cfp)-> health = 0;
string<> xfp;
xfp.length = 0;
with(enigma::varaccess_nigr(int(anus)))
  enigma::varaccess_arse(int(self))= enigma::varaccess_tits(int(self));
enigma::varaccess_r(int(instance_nearest(x, y, 0)))= 0;
enigma::varaccess_bar(int(enigma::varaccess_ar(int(er))))= car;
string<> * xstr;
xstr -> length = 0;

What that means is as follows:
1) string is incorrect until I remove the template flag when typedef'd with zero unfilled parameters
2) OBJ.x will operate more efficiently than OBJ.randomness, because x is guaranteed to exist.
3) Operator <dot> is now universal. Pointer.Member === Pointer->Member.  StructInst.Member is left alone. Instance.Member is parsed correctly to allow lookup.

With() has one remaining bug, being that this code:
Code: (GML) [Select]
with (a) b.c = d;Intermediately parses to
Code: (GML) [Select]
with (a) self.b.self.c = d;Instead of just self.b.c, as it should.

The reason self is added at all is because the system recognizes self (-3 or whatever it is) as [the currently active object], which with() modifies.