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

2206
Proposals / Re: Tierable Systems
« on: March 29, 2010, 05:54:04 PM »
No, not anyobject.anyarbitraryvar: I'm replacing that with a hard-coded accessor of my own device. One should not be implemented for compiled code; compiled code is just that. Since anyobject is an integer rather than a structure, it will have O(log n) lookup, fetch ID, add to array to get lookup pointer, fetch lookup pointer, dereference lookup pointer, return. All that is necessary because I have no idea what the structure it points to will be.

When I said the point was to avoid recompilation, I figured it was implied I didn't want the load put on the run instead. I make it a point to have the compiler make sure as little has to happen at runtime as possible.

V8 accessors work the same as my integer referencer, except those who include the interpreter will be subject to size increase due to lookup tables.

2207
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 05:48:10 PM »
I revise, then; if Epigram can catch that bounds error compile time, I'm impressed. I very sincerely doubt it could without tracing hundreds of steps. Even if it was just checking for any limiters, it wouldn't be accurate enough.

I don't care what "real" programmers use, I use C++.

Yes, probably. It would do the same if it was being divided by one.

Ultimately, there is no Magic language. I'm happy with C.

No one's being forced to do anything; if they think they can find a better GM compiler, they can go looking.

2208
Proposals / Re: Tierable Systems
« on: March 29, 2010, 05:37:41 PM »
Components will still require either recompile or your accessors. Accessors are out of the question. The point of this system is to avoid recompile.

Also, instance_change isn't a difficult function to implement. I already have to list all the variables local to each object. Implementing instance_change is as simple as writing a block of code to copy matching variables over for the set of {objects that call instance_change}x{all objects}. Granted, it could largely increase the filesize if every object used instance_change somewhere in their events, but the function will have no tax on performance outside of itself.

Switching rendering engines is lousy. If it runs Windows, it has better DX support than GL support, A Priori. Otherwise, it either supports GL or requires its own rendering system.

I'm not looking for a resume; I'm looking to weed out a suggestion I can dismiss right off the bat as having consequences requiring >10x the number cycles to execute as its alternatives.

2209
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:52:14 PM »
Remove all those #ifdef #define pairs I can't find another explanation for. If they were so other systems could check if the variable has been implemented, that goes against the purpose of tiering (we'd have to go back over everything and recompile).

Rusky--
And every third instruction would be CALL. Not happening.
Furthermore, "wouldn't have any speed problems..." Do you have ANY research to back this up? Hello, you want me to throw in a function call every time I want object.x? When object is already a pointer? What the FUCK? I'm to the point where I'm unhappy about busing a DWORD back and forth from the RAM, and you want me to make a CALL for it instead. We're talking 6x the number of clocks, easily. That statement genuinely pissed me off this time.

If you want a text-based game with a collision system operating in a terminal window, I'm not programming for you.
Same for if you want to change your fucking mind about what operating system the game is for at runtime. Jesus.

2210
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 01:45:43 PM »
> Just because you can't think of a way to solve something doesn't mean it's impossible.
My last bounds related segfault was on that demo game I released. If Haskell could find that at compile time, and then verify that it was fixed in the newer one, I'm impressed.

Also, danger is my middle name.
Was going to pull a C# / Java in debug mode, but gut it for final build.

Let's look at new C++ standard:
auto a = 2;
a /= 3;
cout << a;

I'm not sure how Haskell would go about solving that one. Probably defaulting to some bloaty type all the time. But I'll bet anything C++ prints zero.

2211
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:41:28 PM »
> Anything invisible that affects the collision system.
"visible" is part of the graphics tier.

retep:
extern is a great keyword

2212
Proposals / Re: Tierable Systems
« on: March 29, 2010, 01:33:17 PM »
Well, that settles that, then.

2213
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 01:11:53 PM »
> So much better than compile-time checks.
I can't think of any good compile-time checks for any segfaults I've had.

> Umm what?
Yes, if you want to disregard your actions and leave it to the compiler, I'm sure Haskell will perform better than C++.

> If an expression's type is ambiguous, you can specify it. Nobody's stopping you from specifying all your types in Haskell. I don't see what an odd behavior in PHP has to do with that.
Which is why I always would. And PHP was just an example of how shit goes bad when you don't know absolutely everything about something's behavior.


> dynamic_cast<T> is mostly runtime. I used it to implement instanceof in an ancient version of PineDL.
I never use that. Almost used it once, before I realized I couldn't even think of a time I'd need it for ENIGMA. Maybe later for instance_change.
I can't see removing the need for runtime checks on if a dynamic allocation returned NULL.

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

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

2216
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,"
lolwut
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...

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

Solution:

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]
#if USE_GRAPHICS
  #if USE_COLLIGMA
    #define high_tier inherit_collisions_colligma
  #else
    #define high_tier inherit_graphics_GL
  #endif
#else
  #define high_tier parent_basic
#endif

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.

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

2219
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. <_<"

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