ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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

Going to need more context here. Where is asteroidParent being used that it isn't declared?

Yes and no.

For things you create arbitrarily, you are right—these could be greatly benefited by classes. I would probably have it that var would not be allowed to represent these classes, except possibly through the C# approach. There's no denying how extremely useful it would be to have object-oriented file, UI, and data structure code.

Instances, you are beginning to push the limit. It is useful to be able to say, at very least for the purpose of static analysis, that other is  an obj_wall, or that instance_nearest(x, y, obj_missile) is an obj_missile. But do we really want to have you check inst instanceOf obj_missile, then cast? I'd hear an argument either way.

Resources, you have hit the limit. There is little reason to ever have spr_some_guy be anything but an integer. Let's choose a raw, gaping sore in GML as an example: sounds. Users have always been plagued by how large their audio resources end up being in GM. In the golden days, large audio files corrupted game files left and right, and even when they did not, insane save times kicked in. Pissed-off users would eventually be driven to store their sounds externally. We just recently got bitten in the ass by Round II of this issue as it became clear that optimizing sound storage for insert instead of access was the better move. This is wrong on so many levels.

The beauty of the resource tree is that your resources are managed for you—you don't need to know anything about where, when, or how sound0 was loaded. You just play it and it works. On your side, it's an integer; you can't get any simpler an opaque pointer than that. Behind the scenes, that sound may or may not be loaded, or actually even exist. We can replace this mechanism with some sort of weak reference class, but why would we? An integer serves the purpose fine.

I wouldn't argue against the use of, eg, typedef size_t sprite_t; to allow us to offer object-oriented features for these resources. But then, does spr.exists() really make any sense?

Just some considerations. I would be fine with a statically typed var of some sort, honestly.

General ENIGMA / Re: Fun with imge_single
« on: July 25, 2014, 08:36:29 PM »
As I said, accessing the caller's image_index is already an ugly operation. When it happens, usually the access is one add+dereference (which we're replacing with two and a conditional) followed by shitloads of additional data moves or comparisons that actually work with the image data. The loss from this overhead is negligible compared to what is done with the image data. I'd probably use an inline function to handle it (as opposed to an accessor).

The code you gave works in the current system; I'm going to assume that what you meant was this:
Code: (EDL) [Select]
image_index = 2;
image_single = 4;
show_message(stsring(image_index)); // Prints "4"
image_single = -1;
show_message(stsring(image_index)); // Prints "2"

In this case, you're right; the obvious solution is to give image_single a special accessor, but then, you're also right that I have no interest in pulling this into upstream ENIGMA. :P

Programming Help / Re: C++ short delay when using CIN
« on: July 23, 2014, 10:13:19 PM »
Write a custom terminal emulator that, upon printing a character, deletes the entire content of the terminal by filling it with spaces, then re-prints everything, including the new character. That might get it to be as slow. Probably not worth the effort, though.

Disclaimer: Not implying that's what Windows does. I can't conceive of why the Windows command prompt is that damn slow. Especially since it takes so many disgusting shortcuts.

Developing ENIGMA / Re: Android
« on: July 23, 2014, 10:11:42 PM »
So, the point of ENIGMA's multiple makefiles is just to let systems specify the source files they include and the libraries they depend on. They operate under two assumptions:

1. You will be compiling some C++ sources into object files in order to build the C++ engine.
2. You will be linking the objects you have compiled into a standalone executable when finished.

Presently, (2) also assumes that the binary you use for linking is the same one you use for compiling. That can be changed. You can also inject additional dependencies and provide targets for them in Android-specific makefiles.

The big issue is, from what we discussed, that Android seems to compile sources into object files, but then there's some nebulous form of magic used to link those objects into a shared object to be loaded by the operating system (namely, through JNI). Unfortunately, I can't make you any recommendations until I can figure out (or someone tells me) what the hell that operation is.

Programming Help / Re: C++ short delay when using CIN
« on: July 23, 2014, 10:00:50 PM »
He's on Windows. The console is GOING to be terribly slow.

General ENIGMA / Re: Fun with imge_single
« on: July 23, 2014, 09:53:59 PM »
The behavior you describe is much simpler than you appear to be modeling it. It's a symptom of having two variables. Instead of using caller->image_index, and having image_single influence image_index directly, the following are happening:

Instead of if (image_single != -1) image_index = image_single; else { /* image_speed logic... */ }, you would simply put if (image_single == -1) { /* image_speed logic... */ }, doing nothing otherwise.

Then in place of caller->image_index, you use caller->image_single == -1? caller->image_index : caller->image_single.

This method is a little slower, yes, but not by enough for anyone to ever really notice. Having functions use the caller's state is dirty, anyway. I wouldn't mind pulling such a patch.

General ENIGMA / Re: Indentation Styles
« on: July 20, 2014, 09:44:22 PM »
My aversion to tabs is that they have not been assigned a logical width. People individually choose how big they want their tabs. While that's great for personalization, it's bad for consistency. You can't align variables easily, or use half-indentations or double-indentations without explosion (my double is 4 spaces; some are 16). The biggest offender is when people try to line up variables after "int" or "var." It's not really my style, but it happens; exactly four spaces of indent are required to pad the next line so that all the identifiers line up. You can use spaces to do exclusively the non-indentation alignment, of course, assuming your editor lets you, but I've never seen anyone pull that off.

The lack of size agreement leads to more solid problems, in my case. GNU style seems to be two-space indent, but any leading eight spaces of indent are replaced with a single tab character. This means for me to correctly view anything GNU, I have to set my tab width to eight. My preferred tab width is two. When you send me a file and every fucking line is indented eight tabs, I flip shit. I find lately that I leave my tab widths both at two and manually replace "\t" with "        " in GNU sources.

So yes, in a perfect world, everyone agrees, and we all use tabs. In this world, tabs are any multiple of 1 in size (even that's not playing it safe—some people don't use fixed-width editors, but no one cares what they think). Spaces, however, I have never noticed to be rendered as anything other than a single space of width, with or without special coloring or symbolage to denote that there's actually a character there. So I use two spaces, and my code looks the same whether it's loaded in emacs, in vim, in MS fucking Notepad, or in an actual code editor.

inb4 gr8 b8 m8

Off-Topic / Re: Religious wars in the programming community
« on: July 20, 2014, 01:14:28 PM »
This whole topic is really TL;DR; am I supposed to be doing something about it? I don't see any 72-point type, so it's looking tame enough.

Off-Topic / Re: On a distant future
« on: July 20, 2014, 01:12:02 PM »
I was mostly teasing. But no, I don't particularly like Facebook.

Off-Topic / Re: On a distant future
« on: July 19, 2014, 05:13:34 PM »
Fuck no; Facebook bought Oculus. VR is poisoned forever. AR is the new VR.

Works in Progress / Re: Norse Adventures planing stage
« on: July 19, 2014, 11:41:23 AM »
I find the ability to draw assets for video games by hand breaks down at about the point you need small, animated sprites. :P

Issues Help Desk / Re: Issues on WinXP
« on: July 17, 2014, 10:50:47 PM »
Perhaps Oracle has managed to get the JVM to ignore segmentation faults in library code. Are your repository and copy of LateralGM both up to date?

Programming Help / Re: Make sprite run through a loop (like sonic)
« on: July 17, 2014, 10:36:25 PM »
If you are looking to calculate the speed you must be going, you can do that by comparing the centripetal acceleration to your gravitational constant. The centripetal acceleration is given by sqr(speed) / loop.radius. So assuming you're using a gravity constant of one pixel per frame per frame, all you want is if (sqr(speed) / loop.radius < 1) path_end(loop.path);, or whatever logic you need to stop following the loop.

You'll probably find that this calculation is too realistic for your actual game to be able to use it, (it turns out you have to be moving pretty damn fast to stay on a loop by your own force), so feel free to tone down the gravitational constant for that equation. :P

Issues Help Desk / Re: Issues on WinXP
« on: July 17, 2014, 10:26:53 PM »
You get that error every time LGM starts? It sounds as though something that was supposed to be loaded was not, but you should have received a report much earlier in that case. Does the program crash? That's usually a sign that the invalid memory access was actually in the native code (ENIGMA).