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

226
Developing ENIGMA / Re: Graphics system compatiblity
« on: July 31, 2014, 08:20:15 PM »
> I like the E_ANNO idea, and I can put anything in it, not only "Graphics system specific", but maybe even on how to replicate the functionality in other systems?
Try to be consistent, but yes.

> Then it will get bloated though. But if I got you correctly, then JDI would use this to throw errors?
Correct. I will have to modify JDI to support these annotations, but that has already been on my radar. I expect to get a lot of use out of that ability.

> And you said I have to do this in headers - so I put all platform specific functions in their own headers inside the graphics systems folder and do it there?
In this case, yes. These annotations don't typically belong in shared headers unless the headers are to be shared between small numbers of systems which both implement non-uniform functionality. This should be unlikely.

> So that the function doesn't even appear in the code editor unless the correct graphics system is enabled?
> Because right now many system specific functions are in General, and they just have empty implementations. I guess I will have to clean that up.

Right. I'm generally opposed to empty function bodies; I really hate linker errors, though. I'd prefer they just not be declared in systems that don't do anything for them, unless they're still applicable for a system. For instance, it's OK if d3d_enable didn't do anything on some embedded system, as long as you could do everything you'd be able to do after calling that function.

227
Off-Topic / Re: MacOS Counter-intuitive?
« on: July 30, 2014, 10:31:48 PM »
It comes down to a matter of philosophy. What could be simpler than one giant button?



This philosophy continues to be a big part of Apple's R&D:


You shouldn't be mad at them for running off with BSD, though; BSD devs aren't. They do give back, as needed. They just don't help with, eg, X11's huge set of ancient problems. In fact, they've ruined X11 on OS X. Rather than write wrappers for it and GTK (assuming that'd even be needed if they offered a full X11 API), they've decided to just write a shitty window adapter, which has to be run as a separate process any time you want to open anything GTK.

From a structure standpoint, OS X is vastly superior to Windows. For example, creating a button is not a kernel operation in OS X. From a usability standpoint... well, Snow Leopard is an improvement over Leopard which is a MASSIVE improvement over Tiger, which made my unfortunate existence a living hell with its astounding unintuitiveness and general brokenness. Of course, I was the tech guy, so all of everyone's problems were my problems and so I am likely to hold some kind of bias. As someone who is particularly picky about my windowing environment, I also find Tiger's window manager to be worthless, featureless garbage. Leopard vastly improved on that, but the whole system still leaves a lot to be desired. I'd put Snow Leopard < Windows 7 < Unity < Every other Linux DE < GNOME 3 < Cinnamon < XFCE < GNOME 2 (Note that in general XFCE is the best due to its extreme customizability, but I really loved the features available in a default GNOME 2 install).

228
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]
#ifndef E_ANNOTATIONS_H
#define E_ANNOTATIONS_H

#ifndef JUST_DEFINE_IT_RUN
#define E_ANNO(x)
#else
#define E_ANNO(x) // TODO: Someone actually handle this in JDI
#endif

#endif

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

E_ANNO("SYSTEM_SPECIFIC")
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).

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

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

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

232
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

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

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

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

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

237
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?

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

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

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