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

As long as he has installed ENIGMA somewhere in his home folder, he does not need sudo. Windows is the only platform on which ENIGMA needs elevated privileges to function.

It's sounding like multiple games are working fine for you. What problem are you having right now, and how can someone reproduce it?

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.

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

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: (cpp) [Select]

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


Then you would just use, eg,
Code: (cpp) [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 [snip]var iID =[/snip] 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 [snip=cpp](enable? glEnable : glDisable)(GL_WHATEVER);[/snip]. 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 [snip]var iID =[/snip] to [snip]var iID; iID =[/snip] 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 [snip=edl]spr_whatever.draw(0, x, y)[/snip] with [snip=edl]draw_sprite(spr_whatever, 0, x, y)[/snip]. 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?