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: New Interests
« on: April 01, 2010, 01:30:00 pm »
"ENIGMA will make sure that you don't accidentally add anything to obtain "1""

Well, it's the only way, since GM doesn't offer any method to distinguish between integer and pointer, only loosely between instance and object.
Also, Java doesn't have pointers, and C# makes you ask sternly for them.

Announcements / New Interests
« on: April 01, 2010, 12:48:16 pm »
As you can plainly see, the interests of this community have changed from software and game development to unicorns. As such, the ENIGMA project has been discontinued, effective immediately. For the third year in a row.

Okay, enough of that now. On to serious matters.

Upon further consideration, it has appeared to me that C++ just isn't right for ENIGMA; despite my best efforts, I don't think I can pull off all the things Game Maker does without a better system. Specifically, one with such goodies as dependent typing and a good garbage collector, so users can use ds_list_create and just forget they did so without worry, and so late at night when it's hard to keep track of what I'm doing, I'll be fine. I won't have to fear that I've made a mistake in my coding; something else will let me know or just take care of it for me. We all want that, right? Switching to a better language could definitely improve development speed, in that respect.

Besides, it's time to give the project's organization some serious rethinking. POD has become, though efficient, too confusing when looking at the bigger picture: we're better off calling things by reference. Doing so makes sense, and will help the garbage collector and any debugging implementations as well.

I was looking at C# or Java, maybe even with some Haskell. All of those languages are gaining popularity quite quickly; chances are they'll work on all the platforms we want ENIGMA to compile for within the next ten years. Those languages don't each offer all of the features I mentioned above, but they'll make mine and users' lives easier.

Think about it:  With their garbage collectors and referencing systems working for us, you can just create a ds_list, forget about it, and in a few steps, it'll just be gone! To ensure that users don't accidentally reuse a destroyed list, the integer-id (probably between 0 and 20) will cease to exist along with it, meaning you can no longer set any variables to it. So, if you said, for example:

a = ds_list_create();

But then just stopped using "a"'s list for a while (like if you had it in an alarm that was taking a really long time to execute and so probably never would), list 1 would be freed. So what would happen if you were to pass "1" to ds_list_find again? That's the beauty: You can't! When list "1" is freed, so is the constant "1" from the game. That means that from now on, you can't use "1" anywhere in your code, and ENIGMA will make sure that you don't accidentally add anything to obtain "1". Also, make sure not to divide by it, as doing so may cause an error (don't worry though, each of these languages has great exception handling).

This can be accomplished by keeping everything stored as pointers, especially constants. Instead of "1" just being an integer in memory, it will be an integer pointing to an integer, and then another integer to verify that our integer points to an integer. Simple, yes? Efficient, too: modern processors are making it so no one will even notice the effects of doing so.

I haven't seen any Java games for Wii, yet, but maybe they could be played through the Wii's browser. On the other hand, I have seen one C# program for the Wii, and I'm sure it has reached shelves of hard-core gaming fanatics everywhere; just look at it. Although I don't think development with C# for non-Windows systems will be supported by Microsoft, they have agreed not to sue for it.

Because of that, C# is looking like a really good option. Plus, using C# would give us access to Microsoft's powerful .NET framework on Windows, which end users would simply have to download. It's only a few hundred megabytes. The Mono team has been working very hard to get that framework running on other operating systems, too; it should be mostly supported.

I can't wait to hear your comments on this. I feel we'll need a new logo to go along with it, possible something with gears and happy faces.

something about unicorns

Proposals / Re: Tierable Systems
« on: April 01, 2010, 12:07:29 pm »
The hope behind adding a new graphics system (such as GX for the DS and Wii) is that doing so doesn't change any of the tiers; we're striving to allow lossless cross-compilation. Obviously we'll be sacrificing some things between consoles and the PC (namely the keyboard, at least for the DS) and we will be adding some functionality (such as managing viewports with the DS; I'm not sure how it handles multiple screens). Fortunately, most of that will not have to do with locals and will not even need to interface with the tier system.

I do see where components would be handy; I don't think ENIGMA is such a case.

As for debugging, many of the projects I've seen let you compile a debug configuration and a release configuration. Storing a separate object file for each is an option. If I need a notification on write to a variable, I will add such a directive to "var," which, unfortunately, is the tiers' default type. That will require the recompilation (or storing of a second object file) of one source. Two for types such as hspeed, vspeed, direction, and speed, whose assignments are already special-cased to interact with one another. Making the decision to leave var behind can indeed end up being costly of compile time; the hope is to make that happen only the first time and to keep the object files from there.

I'd also like to point out that the tiers are not to be included by most files; only those that truly need to interface with local variables. For example, that includes a good deal of the collision system, but not the collision testing code. Ludamad won't even include a tier, because his system will operate independently of them. There will be a go-between file that I intend to author that will make calls to his system based on active instances.

Proposals / Re: Tierable Systems
« on: March 31, 2010, 10:09:47 pm »
Your instance_change argument had me reconsidering the implications of your proposal for a few seconds before I remembered what it would look like for an event to access any of your component-ized locals. I assume this is where your proposed accessor comes in, which I said before wouldn't really be needed: I could parse in a "componentname->" before each local. However, I don't want to do so, and I don't believe anyone else does either. I was discussing this with Luda; he asked what the point was. I referred him to your independence and instance_change arguments (those were your good ones; coincidentally, they were your only two that were worth a second glance). He then remembered that instance_change existed, he decided it was ugly. I agree, of course. It looks great from a distance when you start forgetting about the lower components you're cursing.

The reason I don't want to parse in componentname-> is not even to do with the amount of work. First off, Luda thought dynamic allocation was ugly; I think requiring a list of what's in each component is ugly. To add that in before the correct variables, I'd need to know what variable is in what component. We have no C++ way of signifying what's a component, so I'd need to keep a list of locals again, or read them from some messy INI. I refuse to do that.

I wanted the system to be extensible from the low level more than the high, really; easy to add more systems to using C++. I have been doing some serious reorganization towards that in every system.

And again, my tier hierarchy is designed to try to emulate true dependence. Consider this; In order to check collisions (the highest tier in my system), I require the following:
- IDs and Object Indexes from object_basic (tier 0)
- Coordinates on the screen from object_planar (tier 1)
- Image Index (to tell which mask to use) from object_graphics (tier 2)
- Bounding boxes and bit masks from object_collisions (tier 3)

That's every tier. If you want to use a DLL like Ultimate3D instead of the built-in drawing systems, but utilize Ludamad's collision system as well, that doesn't really make a bit of sense; Luda uses bitmasks based on sprites. Mutually exclusive tiers can be included just that way, and a source file only has to utilize the one it was designed for. For example, it'd make more sense to use some physics library like Newton instead of Colligma to accompany Ultimate3D. So, a Newton tier could be engineered to only require the first two tiers. This'd be a total of two combinations, really; I'll bet you can't really afford to swap out the planar system if you know how many coordinates you need.

Anyway, I'm proceeding with the tier system until further notice. If you can convince Luda, serp, Ism, ...anyone other than your brother, really, I'll investigate it a bit further. Until then it's better I stick with what's now implemented.

We also discussed how instance_change isn't really used a lot. Normally I'd hate to use that as an excuse, but the function is an oddball. You picked up on that as well. It's one of the very few functions that approached justifying an interpreted language. Also, it's one of the few things R3 randomly lacked that no one even asked about. Despite me not thinking highly of it, I would include an option to employ a component system just to improve any game seriously whoring that function (though neither Luda nor I can think of a good reason for a game to do so), but the choice for this system has far too deep-rooted consequences. It's one of the new backbones of the project; perhaps that's why you're so avidly proposing the components.

Ultimately, too, most of the flexibility issues with removing tiers from my system would manifest as similar problems in moving them from a component system; except we'd just be removing one pointer rather than changing entire chunks of data. The size of the change really doesn't matter; it's that it changed that throws off other systems.

Proposals / Re: Tierable Systems
« on: March 31, 2010, 07:13:32 pm »
More precise code reuse-
Shouldn't matter in a compiled system; anything unused that's declared in a structure will simply be ignored. Just include the highest tier you need shit from.

Minimal recompilation-
As I said, I'd rather double or even triple the compile time when a recompile is necessary (it will be necessary at about the same time for both systems) than double the clocks needed to look up a local. Even if doubling it is as little as one more dereference. :P

Better organization-
No, the tiers do that, too. Each tier gets its own header and, if necessary, source file.

Possibility of runtime configuration-
Not even slightly interested. I don't see how it helps instance_change, either: with the tier system, instance change is a memcpy(y,x,sizeof(highest tier)) followed by more specific code that the component system wouldn't avoid. In fact, component system makes instance_change slightly more complicated (The compiler would likely take care of the complications, though, if we had a method in each one that could be inlined).

What could possibly stop me from doing that with the tier system?

It seems the key difference between us is that you want to move as much as possible to run time, where I want to do just the opposite.

Announcements / Re: Hello
« on: March 31, 2010, 06:03:20 pm »

Proposals / Re: Tierable Systems
« on: March 31, 2010, 05:27:54 pm »
How can you specify a blank draw component? Just a pointer to a dummy?
In either case, the tier system is implemented and doing a fabulous job. Rebuild for an additional tier or two isn't much to ask when you already have to rebuild one, especially considering the total build time for the entire project, fully optimized, isn't far past 20 seconds. At this point, I don't see much to gain, even at the cost of only a pointer (That system shouldn't require an accessor if it's including its own structure; I'm still not even considering accessors).

Also, I never claimed that GM games all run at 7fps. I showed that that's what can happen. 5,000 isn't an unreasonable number of lines; GM couldn't manage it 10 fps, ENIGMA wasn't even phased by it. It doesn't matter how they'd be accomplished in GM; GM users are used to working around its incapability. I started a 3D Metroid clone once; couldn't import my model; found a way to, but it ran at 2FPS because of it (where it rendered at 60 in the editor). Ended up rendering it ahead of time and drawing it as a cheap overlay. Looked horrible. All the walls had to be flat... It was sad. But I was happy with it, because it was the best I could do in GM.

The way I see it, the amount of flexibility I'd gain from this system over the tier system isn't really enough to justify any sort of speed loss whatsoever. Maybe the extra pointer dereference if it really brought anything to the table in the long run. I'd much rather put the doubling of workload on the compiler.

Proposals / Re: Tierable Systems
« on: March 31, 2010, 04:58:37 pm »
"Maybe you should pay a little more attention to things before you start mouthing off in defense of your big brother."

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.