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

Announcements / Re: Update
« on: March 31, 2010, 01:14:59 pm »
*chuckles a bit and commits*

Proposals / Re: Instance System 3
« on: March 31, 2010, 10:38:35 am »
Certainly. The behavior will be the same in ENIGMA.
On construct, the instance will add its draw event to the container at [depth]. It will be at the end of this list, and so will be executed last, as in your "last touched" method.

That's all that really defines this behavior. It'll perform the same, aesthetically.

Announcements / Re: Update
« on: March 31, 2010, 10:31:30 am »
I wondered why you were answering yes to that, then I saw second line. Haha.

Yes, I'll make sure collaborative debugging is an option, but note that as long as you need to be debugging things, the symbol table needs stored along with the game. This means the EXE's will be massive, as above (okay, so smaller than GM, but still pretty huge XD), and if a really, really determined hacker wanted to decompile your game, he'd have all the variable names :O (inb4 who cares; this was a fucking joke. No one is that determined anyway, especially over a game acquired in DEBUG MODE).

Proposals / Re: Tierable Systems
« on: March 31, 2010, 10:25:34 am »
What happens when I remove the draw tier and the pointer to the collision tier is a DWord shorter than it's supposed to be? Or do I just leave a NULL pointer in there anyway and maybe optimize it out on full compile? I'd rather try to keep the quick compile and optimized compile at least vaguely close, if only for the sake of games running in debug mode.

Though, I think you keep missing the point of a demonstration. Most of what I say is demonstrative of a system I assumed doesn't need explained. That particle demo isn't the only neat particle system you can do with a bunch of lines. The entire point of that demo was to show not that ENIGMA can run a massive particle system faster than GM, which is obvious, but to show that graphics-heavy (specifically of the code-drawn variety since most of the sprite work can be done with compiled code in GM) effects code can actually start to be employed now. ENIGMA could draw four of that which GM couldn't render one, and do so at full FPS rather than GM's 7fps. That wasn't meant to incinuate that everything about ENIGMA is so much faster (though I'm fine with everyone believing that); it was meant to imply that new options are available as far as designing effects for games.
Serprex in particular has always been big on not including sprites in his games; he either creates them at load time or draws them procedurally the entire time. Most of his games don't have a single sprite. Is this extreme? Probably. Did I respect him for it? Hell yes.

The same can be said about ENIGMA. I'm scrutinizing absolutely everything to make sure all this code works efficiently at run time. There comes a problem of increased compile times along with that sometimes, but I'm personally willing to sacrifice a little compile time to make room for a lot of run time, and I imagine most here would agree with me on that. As nice as a quick compile is, I prefer a quick game.

A problem with this tier system, as you know, is the inability to just use multiple inheritance and hope that the compiler sorts everything out for us. This shot down one of my main hopes for the system; I wanted users to be able to decide that they no longer wished for their locals to be var, but to use int or even double instead where applicable. No system here, including my own, will allow doing that without recompile; we would have to try using a void* to everything and then a global to specify the type, which goes against the point of just using var anyway (though memory saving from string and global would be sizable, speed savings would be none or less).

Swapping systems out for other-sized systems is also a possibility, but is unlikely: The goal of most of the systems was to implement the same variables from GM for the sake of compatibility. Granted, later on we may add support for other locals due to one system, but then it will be a goal to get the same new variables working in all the other systems to achieve the same performance no matter what platform. That was one of the reasons I still liked supporting GML; 1. A huge audience knows it, 2. Those who don't can learn a few functions and guess at the rest, 3. When they want to compile for a different OS, even as different as the Wii, their code will not require modification (or will require very little).

That said, it would seem against at least my philosophy to have two systems requiring a local structure of different sizes where a new tier shouldn't have been added.

Announcements / Re: Update
« on: March 31, 2010, 02:32:55 am »
Okay, as an update/clarification:

Simple test run varies within about this range:

Code: [Select]
Compiling: SHELLmain.cpp
Linking executable: ENIGMAengine.exe
Output size is 1005.33 KB
Process terminated with status 0 (0 minutes, 3 seconds)
0 errors, 0 warnings


Compiling: SHELLmain.cpp
Linking executable: ENIGMAengine.exe
Output size is 2.24 MB
Process terminated with status 0 (0 minutes, 3 seconds)
0 errors, 0 warnings[/code]

When you are done debugging your game and would like to build it, you'll have a compile time that I estimate to look like this rebuild time:

Code: [Select]
Linking executable: ENIGMAengine.exe
Output size is 315.00 KB
Process terminated with status 0 (0 minutes, 23 seconds)
0 errors, 0 warnings

Note the difference in compile time vs output size. Definitely a tradeoff.

Proposals / Instance System 3
« on: March 31, 2010, 12:38:30 am »
R4's new instance system is going to require a slight amount of -further- rethinking.

Over R3's system, the new system is intended to implement a few things that probably should have been done from square one, honestly. The highlights of these are as follows.

For the first revision, a few half-contemplated changes were implemented:
  • Depth was accounted for by mapping/listing draw events by depth, then in a second, subset container by ID.
  • Events were added to their own lists, one for each event classification.
  • An option was added to determine the return type of instance_* functions.

The implications and philosophies of each are this:
Depth: This was a reasonably poor idea, though it seemed like the best thing to do at the time. The newer system was floating about in my head, but I rejected it for the time due to lack of apparent need.
Events: Storing events in their own linked lists allows for iteration and execution that will not slow down based on a number of empty particles. Tests on Game Maker seem to indicate that it does the same thing. Overall, one of Mark's better ideas, IMO.
Option: In theory, this will allow for constant-time member access with return values from the instance_* functions. Note that instance_nearest and the like will still require O(N) iteration (details outlined in newer proposals below).

Further thought, especially on how to handle GM inheritance, was given since, leading to further ideas:
  • Depth should be determined not by the order of instances in the main map, but rather by the order of pointers in the draw event queue.
  • Instances will instead (of being sorted by depth) be stored in separate arrays by object_index. This array will be static, so defrag-IDs will be your friend.

The former revision will free organization method for the latter.
This will vastly improve performance of, for example, instance_nearest(x,y,object0), since only one list will need iterated for object0. The entirety can still be iterated at little cost. What's more, heredity can be achieved using this method by having each object, on instantiation, add itself to all concerned lists.

For example, a call to instance_nearest(x,y,someparent) will iterate the list of objects having ID "someparent," which will contain a pointer to all children of "someparent" as well.

I can only imagine this is what Game Maker does. However, if you think you have an instance where this method (referencing all children in a list of the parent) would break some form of compatibility with GM, please verify it and inform me.

Potential problems with any of the above:

- A problem could result from treating too many scenarios as pointers instead of GM-IDs. The most obvious of thees is in room-given instance IDs. Many room create codes reference other objects in the room by integer-index ID. Failing to store the IDs and to offer a look-up by them could break that system. As such, it should certainly be kept as an option and defaulted to false.

- A problem could result from storing by object_index: redundancy in iterating all objects as a whole. For this reason, a separate container may be needed to store a continuous list.

Tips, Tutorials, Examples / Re: Which should I use?
« on: March 30, 2010, 08:18:36 pm »
Well, that is, but Array[][] isn't if array is just int.

Proposals / Re: Tierable Systems
« on: March 30, 2010, 08:13:23 pm »
"you could pick any graphics system including a lack of one, same with any other system, and you would be able to build your own reusable systems"
That's the intention of this system as well. I'm taking a different approach, attempting to reduce everything to organized tiers assuming a chain of previous tiers.

"Josh thinks that would be too slow because he has no concept of scale, he hasn't run any benchmarks"
Josh asserts that this is slow relative to the system in place, due to the factor by which the necessary number of cycles will be multiplied. Josh would rather remove those cycles, pushing the excess time consumption on the compile process rather than the running engine.

"unrealistic particle system examples"
250 * 20 = 5000. If that's an unrealistic number of lines, I can't wait to see your responses when I'm running a 1,000,000 pixel-particle shader. And yes, yes, shaders are so much different. Only not really; they're a great way to speed up heavy procedural particles. Which that example was. Something is not "unrealistic" just because Game Maker can't pull it off at >10 fps.

"Circular logic was you excusing your lack of examples of my suggestions by just assuming they must exist."
I'll grant it again due to laziness. But now I'm starting a list.

"There are plenty of nice-running games in GM. That was the lie."
There are plenty of nice-running games for DOS. Therefore Portal requires an unrealistic system to run. (inb4 portal for DOS)
Try making anything 3D in Game Maker. Oh, but GM isn't for 3D? Well, it's not for decent game creation either.

You suggested yourself that the accessors be virtual, and then verified yourself that virtual and inline were exclusive. The workarounds to make everything non-virtual would be the same as those when working with this simple tiered system. So leaving them non-virtual comes down to me not seeing the point, other than that you suggest it makes more "sense."

Tips, Tutorials, Examples / Re: Which should I use?
« on: March 30, 2010, 07:58:08 pm »
You meant int** for the first parameter to the first function?
Anyway, yes, there is a difference between all of those.

In a function parameter,
int a; specifies that "a" is one integer, local to this function. The memory is copied (not a very costly procedure; there's no improving it) for use by the function.
int &a; signifies that "a" is passed as a reference, but treated like an integer all the same. This time, the address is copied, which can be of equal or lesser size than the actual integer. This allows the function to edit the contents of "a" in the scope from which it was passed. This is the only time you should use & in parameters.
int *a; is pointer to int; it's an integer marking an integer in memory, and must be dereferenced explicitly with * or implicitly with [] for use.
int **a; is a pointer to a pointer to an int; it's an integer that points to the address of the integer you want. You can dereference it with any combination of [] and *.

Proposals / Re: Tierable Systems
« on: March 30, 2010, 07:41:38 pm »
Something that quadruples (probably more accurately decatuples, but I didn't want to assert a too-outlandish figure, after all) the number of clock cycles necessary to look up a fucking variable in a class I have a pointer to?

"Slippery slope, circular logic and outright lies."
I pointed out the slippery slope myself, with a slight satisfaction I might add ("That was a slippery slope fallacy. It's pretty commonly used in court cases"). There was no circular reasoning as far as I can discern, and I assure you none of it was a lie.

"If you want to build a bad system, go ahead, but don't come asking for suggestions."
A "bad system" in the opinion of one who would multiply the number of cycles necessary to look up a fucking x value, in a class to which I have a pointer, by at least four. In my opinion, and in the opinion of everyone else on the team who didn't feel you were worth responding to, it's better not to waste the cycles on something like x.

Also, I didn't even explicitly ask for a suggestion, I simply welcomed them. I didn't explicitly ask you, either. You gave a suggestion, I declined it. You continued to defend it, I continued to decline it. If you can't cope with me declining a suggestion, quit offering them.

Proposals / Re: execute_string via Google V8
« on: March 30, 2010, 07:34:38 pm »
In response to...?

Proposals / Re: execute_string via Google V8
« on: March 30, 2010, 06:01:04 pm »
Not without recursion.

Proposals / Re: Tierable Systems
« on: March 30, 2010, 05:57:16 pm »
Yes, yes. But we'll start with inherited member access and then it'll progress to something in draw_line I can't even fathom your improvement for. Or maybe ENIGMA's calling convention in general, who knows; the net result somehow being GM's 7fps rate.

Also, I can't really tell your suggestions apart from anti-C++ propaganda. :troll:
In actuality, I'm too lazy to go read through our other four page debates.

Proposals / Re: execute_string via Google V8
« on: March 30, 2010, 05:44:15 pm »
See this.

Announcements / Re: Update
« on: March 29, 2010, 11:29:07 pm »
My main todo list was just checked off. What's left after Ism and I have that damn plug-in working is getting with() to work again, and as time permits, implementing that new instance system I wrote a decade ago.

The todo list I was referring to is composed of some 10 "TODO:"s throughout the ENIGMA source. Here are eight of them:
Graphics_Systems\OpenGL\GSscreen.cpp|38|#include "../../Universal_System/key_game_globals.h" //TODO: Replace this with a tier-level header in ../|
Graphics_Systems\OpenGL\GSscreen.cpp|76|//TODO: Replace this once instances are sorted by object index as well|
Graphics_Systems\OpenGL\OPENGLStd.cpp|43|#include "../../Universal_System/key_game_globals.h" //TODO: Replace this with a tier-level header in ../|
Platforms\windows\WINDOWSmain.cpp|31|namespace enigma //TODO: Find where this belongs|
Platforms\windows\WINDOWSshow_error.cpp|31|/*namespace enigma //TODO: find the original declaration of the contents of this namespace and erradicate it|
Platforms\windows\WINDOWSshow_error.cpp|38|namespace enigma //TODO: This is from events.h: fix according to TODO pointed to by above TODO|
Universal_System\instance.h|135|//TODO: Move these to an instance_planar|
Universal_System\instance.h|158|//TODO: replace all these fucking enigma::instance_iterators with enigma::institer_t i or something|

Some of the headers under Universal_System are also still plug-ugly. I'll fix those as I make with() work again (most of them center around that category).
But first I'd like the IDE to communicate again so I can actually make several objects. ;_;