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

2191
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

To

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.

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

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

2194
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."

2195
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 *.

2196
Proposals / Re: Tierable Systems
« on: March 30, 2010, 07:41:38 PM »
"SOMETHING THAT WASTS A CPU CYCLE "
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.

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

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

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

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

2201
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:
Quote
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. ;_;

2202
Proposals / Re: execute_string via Google V8
« on: March 29, 2010, 11:24:53 PM »
I can see it being helpful; I can't see me using it.

2203
Proposals / Re: Tierable Systems
« on: March 29, 2010, 11:22:27 PM »
That's a bit bold a statement on all counts. Your missing the point; you just suggested that I reduce the speed of the lookup of needed locals by >75%. The few cycles it once took to look up X are now repeated more than three additional times to successfully make a call to that un-inlined function. We're quadrupling the work that needs done. And now you're justifying it with "a cycle is small, therefore all the cycles you will be throwing out the window with this method are small" (That's the fallacy of composition, just as a fun side-note. And it doesn't apply to mathematically distributing a 4x cycle factor to all processes, by the by).

All I need to do is take advice like that on a dozen or so more systems, and I can successfully reduce the speed of the project by a quarter, and then I can render those lined-flames like GM8 does. At seven frames per second for some 250 of them (That was a slippery slope fallacy. It's pretty commonly used in court cases).

I'm not even starting down that road. I don't care how relatively small the change is compared to the rest of the project; this isn't the first such change you've suggested and I highly doubt it will be the last.

2204
Proposals / Re: Tierable Systems
« on: March 29, 2010, 11:00:25 PM »
*shrug* I don't see that as a problem.

2205
Announcements / Re: Update
« on: March 29, 2010, 10:56:02 PM »
Best. Grammar. Mistake. Ever.
...Nah, mediocre, but I'm leaving it.