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: Tierable Systems
« on: March 29, 2010, 01:07:19 pm »
> Virtual accessor functions?
Could work, then I'd have to hope they were always inlined. I'll look into it if I need. They won't help much since they'll need to be given a certain type as well, but they could allow for multiple inheritance. I'll see if they come in handy.

> What about invisible walls?
Not sure what you're referring to.

Proposals / Re: Tierable Systems
« on: March 29, 2010, 09:44:29 am »
I considered it (it was in fact my first thought), but then indexes could end up different between files, and thus a file could end up reading the wrong block of memory to fetch its variable.

Like using int vs a variant type for x and y: changing the size based on multiple inheritance could totally fuck up collision code, as it would suddenly be reading 12 bytes further than where it should be for each variant that became an int.

The solution would be to include the settings file to understand which size it was looking at, but doing so would require recompile, and that is exactly what this tier system is designed to avoid.

Edit: let me clarify.
Each new step in the tier must assume as few sizes as possible from the previous ones. We want systems to be removable or swappable, but allowing a system to be changed can likely impact the behavior of other parts of the system. In this hierarchy, the affected parts will all be lower tiers. For instance, if you removed graphics, the assumption is that you'd have no further need for collisions.

The instance functions can make use of tier one, needing only ID and object index. They'll never even notice if the collision system is removed or changed.

There is still some need for recompile, but with completely linear tiers it becomes seldom or trivial enough to where a new source file can be made to accommodate each change to a lower tier. Multiple inheritance could vastly screw that up.

Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 09:41:48 am »
> since you need less runtime checks to be safe
Last I checked, C++ doesn't make any of those, either.

> "Compile-time verification has nothing to do with runtime performance. In fact, it can enhance it,"
And yes, it can enhance performance for you if you've paid attention to nothing you've been doing with your types.

>PHP is a horrible example of a type system.
I was talking only of PHP's continue behaving entirely different than in other languages. I expect the same to happen with compiler-determined types. Like when Dylan templated fuck-everything in ENIGMA and we started getting problems when dividing int/int. I would hope Haskell is a little better at resolving a type for that, being less afraid to waste memory, but I don't really want to give it a chance to make life hard for me. Explicitly stating types has never caused me grief. Now, array bounds are another story...

Proposals / Tierable Systems
« on: March 28, 2010, 10:16:04 pm »
Some people don't want a huge-ass graphics system or collisions system. Different systems can require more variables to operate than others. Switching out systems means incorporating different variables.


Code: [Select]
struct parent_basic {
  const unsigned id;
  const int object_index;
  parent_basic(): id(0), object_index(noone) {}
  parent_basic(unsigned x, int y): id(x), object_index(y) {};

In the local directory of each graphics system:
Code: [Select]
struct inherit_graphics_GL : parent_basic  {
  int sprite_index;
  int image_index;
  inherit_graphics_GL() {}
  inherit_graphics_GL(int x, int y) parent_basic(x,y) {}

Of the collision system, which we assume to require graphics system:
Code: [Select]
struct inherit_collisions_colligma : inherit_graphics_GL   {
  int mask_index;
  inherit_collisions_colligma() {}
  inherit_collisions_colligma(int x, int y) inherit_graphics_GL(x,y) {}

Then finally, in the IDE Editable headers in which code is stored:

struct parent_locals :
Code: [Select]
    #define high_tier inherit_collisions_colligma
    #define high_tier inherit_graphics_GL
  #define high_tier parent_basic

struct parent_locals: high_tier
  var health;
  var lives;
  var otherworthlessthings;
  parent_locals() {}
  parent_locals(unsigned my_id, int my_object_index): high_tier(my_id,my_object_index) {}

This is being implemented for testing *now.*

Note: I left out X and Y for brevity. They will be assumed to be needed before collisions but after graphics.

Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 07:56:14 pm »
Not perfect, just beautiful. I like explicitly stating things; it shows me I'm still in control of something. The modern movement is towards throwing performance to the wind and letting the compiler do everything for you. That was the spark of so many errors in GM, I decided to avoid it entirely. Not to mention it's the little 'helpful' things like that which end up seeming unintuitive, at least to me.

I remember the first time I wrote anything useful in PHP. I didn't know continue; was the same as break; in a switch statement. Well, learned that one the hard way.

The only reason I don't have a type-related example of how I got really burned on not seeing a certain behavior coming is that I never gave it the chance.

To me, C++'s types are beautiful because they do my work for me in a manner I could predict from a coma. I never have the surprise, pleasant or otherwise, of a new feature. That to me, is beautiful. If you want to explain to me how that isn't beautiful or shouldn't be beautiful to me, go ahead.

Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 07:25:27 pm »
Oh, but they're just universally fleeting in the eyes of any beholder who has experienced a functional language?
Certainly I'd hate them if I ever got an amazing implicit list type.

It's wonderful if you like other languages. Please quit pretending that everyone does/will accordingly. <_<"

Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 12:57:29 pm »
The idea is for this to require very little effort. It'd be almost entirely code-generated code. But yes, I could find better things to spend time on.

Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 12:28:42 pm »
Hah, true. Don't worry though, this isn't to be implemented yet. I added that C compiler because I don't want more mediocrity; GM users are content with that for now, but I want my beautiful C++ types. And I like the idea of structures. So I just went all-out.

This, however, does not appeal to me. So I will let it sit here until it gets eroded smooth by anyone who posts on the matter.

Announcements / Re: Collisions
« on: March 28, 2010, 10:04:10 am »
Actually, are you sure that casting that initializer as var will properly allocate them? (I'd cast as variant anyway, but...)

Proposals / Re: Idea for var
« on: March 28, 2010, 09:58:29 am »
I want the new var to offer casts to all scalars, optional overloads for iostream and fstream, and a copy-on-write system for arrays (allowing arrays to be passed as function parameters and script arguments).

To preserve speed, we sacrifice memory. It's always been that way with ENIGMA since I found a clue what I was doing. I thought of methods that would make var eight bytes, but I don't want to implement them as they waste instructions.

Proposals / Re: execute_string via Google V8
« on: March 28, 2010, 09:54:25 am »
Only on C++ things that aren't in GML. Since execute_string is more for compatibility, I'm not concerned with having it support C, really.

Announcements / Re: Collisions
« on: March 27, 2010, 10:09:54 pm »
Man, that's hackish even by my standards. I'll do it.

Proposals / Re: Collaboration by Timestamps
« on: March 27, 2010, 05:58:50 pm »

Announcements / Re: Collisions
« on: March 27, 2010, 12:32:18 pm »
Bahaha, yes, all of those things.

Announcements / Re: Collisions
« on: March 27, 2010, 09:06:24 am »
Not at present; I could generate one, but I don't think some of the systems I coded are all in there. Like text file manipulation and DLL's.

The 11th plague of Egypt:
Assuming you're talking about ds_lists, they are global. Don't worry, this new system won't break ds_list; it'll supply an alternative to them. Lists are stored somewhat like sprites; a global array of things GM users don't understand, which they can access by an integer from absolutely anywhere. So, a=ds_list_create() will add to that list, "list a;" won't.