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

Developing ENIGMA / Re: Graphics system compatiblity
« on: July 29, 2014, 08:35:30 PM »
> Should we create graphics system specific functions?
Absolutely. I avoid actively encouraging this because doing so is a bad habit, but there is no reason to tax the performance of a system to try to be completely compatible with another. Please document or otherwise annotate functions that are specific to your system. By annotate, I mean use a flag that gets preprocessed away. I suggest creating a top-level annotations.h:
Code: (C++) [Select]

#define E_ANNO(x)
#define E_ANNO(x) // TODO: Someone actually handle this in JDI


Then you would just use, eg,
Code: (C++) [Select]
void draw_enable_dither(bool enable);

void draw_enable_stipple(bool enable); // How the hell was this ever a thing?

You can be as creative as you want. Eg, feel free to use E_SYSTEM_SPECIFIC as a full annotation, or name the annotation function something witty and descriptive, like $. I don't care how you annotate it, just be consistent and make sure it's easy to swap that shit out. You only need to annotate the headers that are included from the main source.

In the GNU implementation, shit is annotated with __attribute__, which I believe has a relative coming to the C++ specification in short order. Don't quote me.

As for your other proposals, I agree with keeping GL1.1 more GM-like; GM was raised around GL1.1 capabilities. I am also inclined to agree with (2), but don't want to commit to it because people can't seem to grasp what "compatibility when convenient" entails. You have my remarks on (3).

Graphics and Video / Re: Gifs for my top-down scrolling shooter
« on: July 29, 2014, 08:21:25 PM »
You can just draw the four propellers over top of the image, if you're really looking to save memory. I'd suggest keeping it how you have it, though, unless you're programming for embedded systems. If you're going to be drawing shitloads of planes, drawing fewer polygons will be much better for you. (You still have to draw the whole plane; you'll actually just be drawing more pixels and more polygons to sew the propellers on over top.)

So yeah, unless graphics memory is a huge concern, leave it how you have it. It's better for performance and for code quality.

Okay, the parser's being pretty stupid. But you left the original var iID = in there; all you did was add another declaration above it. Remove var from that second line entirely.

Developing ENIGMA / Re: Android
« on: July 28, 2014, 09:48:35 PM »
Isn't there a guide anywhere on building manually? Or by any other mechanism than .mk? I mean, I believe I remember you reporting that you have it building all the object files, except some that had libstdc conflicts. Did you get that resolved? That's *most* of the battle. Linking should be the easy part, and whatever goes into it can be accomplished in the ENIGMA makefile using a custom rule, as I described earlier.

Developing ENIGMA / Re: Two sets of icons in LateralGm
« on: July 28, 2014, 09:45:10 PM »
The Swing icons are all from a repository somewhere; did Ism offer where to find the missing ones? I imagine it can't be hard to track down, otherwise. Worst case: just copy over the Calico icons that are missing that set. :P

Developing ENIGMA / Re: Redundancy
« on: July 28, 2014, 09:41:44 PM »
Oh my. EGMenable.h is from like 1904. Please delete it. :P

It is good to offer functions similar to those; I like offering the user control over as much as possible. In GL3, that's done with shaders. In GL1, we should find a better way of offering these features. Perhaps offering these will be prettier if and when ENIGMA can mark functions as system-specific. I've been doing some thinking, and perhaps a good way to handle this is to offer shader generation methods. I'll explore the possibility a bit more, later on. Basically, a shader factory with the ability to set those parameters could just call glEnable in GL1, and actually generate appropriate shader code in GL3. Just a consideration.

I should also point out that a more concise way of writing that is (enable? glEnable : glDisable)(GL_WHATEVER);. Just for what it's worth.

Off-Topic / Re: Freakin' Ouch
« on: July 28, 2014, 09:27:18 PM »
I still have four wisdom teeth left, if that counts.

Programming Help / Re: Good tutorial?
« on: July 26, 2014, 10:23:10 AM »
Unfortunately, I'm not aware of any; I learned to use GM back in 2004, and the tutorial at the time would look quite different from the one now. We're quite possibly between IDEs, so writing a custom one now would not be a good move. I believe you mentioned being familiar with coding but new to Game Maker and ENIGMA. Basically, all you need to know is that LGM, the IDE, allows you to manage your resources visually. Sprites are animated image resources; you can create a new one by pressing the pacman icon. Objects are where your code goes; they are event-driven, and handle a lot of the nitty-gritty game logic for you. You can create one by pressing the little ball icon a few icons right of the pacman icon. Rooms are how you organize your objects visually; they give the start state of each scene, which few games change significantly over time.

I could create a brief video tutorial, if that would help you.

Okay, that's strange. Could you separate var iID = to var iID; iID = and see if that fixes it? The current parser seems to only check the first parameter of functions for variables.

Off-Topic / Re: Freakin' Ouch
« on: July 26, 2014, 09:49:06 AM »
What. I had one of my wisdom teeth pulled a while back. I was given a whole stack of gauze to shove in the hole as needed, and I couldn't eat solid food for six hours. Did you fly out to some third-world country to have yours yanked by an elephant pulling some string? Or is my dentist just magical?

Pointers are just sparse integers. Yes, it's easy to obtain the next sprite given the current one, because usually you just add one. Well, let's say we handed around raw pointers. Now you can usually obtain the next sprite given the current one by adding sizeof spritestruct. The only difference is that you'll get an access violation and kill your program if you're wrong in the pointer case. As I stated, I'm fine with having a typedef of size_t for each resource kind. This would be a hint to the compiler that it is not to be used in arithmetic. It could also be used to allow object-oriented programming around that type; eg, replace spr_whatever.draw(0, x, y) with draw_sprite(spr_whatever, 0, x, y). There only difference is that this "pointer" is small, dense, and managed by us.

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.