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

Off-Topic / Re: Religious wars in the programming community
« on: July 17, 2014, 10:23:47 PM »
I myself am a JavaScript evangelist, and make regular sacrifices to C++. I also hold the belief that Windows users are headed for hell, and Mac users are already there.

Off-Topic / Re: Enigma as only Enigma
« on: July 15, 2014, 06:49:37 PM »
I understand the concern. It may hold some developers back, but those are the developers who would otherwise not be interested in ENIGMA, so the gain wouldn't be there.

Off-Topic / Re: Enigma as only Enigma
« on: July 15, 2014, 05:35:26 PM »
Thinking of ENIGMA in terms of GM is not useful. The goal of ENIGMA is to be a decent game engine first, and compatible with Game Maker second. If you can produce a good argument as to why the latter is bad for ENIGMA, then I am happy to hear it, but I believe you'll find that the cases you present are exactly the cases where we drop compatibility. There are many compatibility requests on the tracker marked as "Will not fix" for such reasons.

We maintain compatibility with Game Maker for a few key reasons.
  • First and foremost, Game Maker is a proven product. It's not the greatest, but it works, and we can learn from its successes as well as its failures. There are high counts of both, I promise.
  • Further, it's incredibly simple for children to learn. Developers here know this firsthand. I learned to write games in Game Maker 5 when I was around 12 years old. This goes for many others, here. There's just astoundingly little barrier to entry.
  • The API is virtually self-documenting. I know this isn't saying much when Robert has gone and documented all the functions on the Wiki, but did you really need to look up what draw_sprite(spr, subimg, x, y) does if you actually know what a sprite is? It's profoundly obvious.
  • One of the most critical selling points of ENIGMA is also one of the least relevant to ENIGMA; I'm speaking of the way in which resources are presented visually. This behavior is where the bulk of functional similarity with GM originates, and it has nothing to do with ENIGMA. The only reason no one has coded an alternative is that no one here has the time required to dedicate to a new interface on top of the engine.
  • Lastly, Game Maker has a large following. By keeping compatibility where possible, we enable those users to not only switch over easily, but to contribute easily. We're an obvious choice for an upgrade.

That's all I really have to say on the matter. You could argue that conforming to GM's library is holding us back, but it isn't. We are free to add as many functions as we like on top of its own, and we do with some frequency. I could say more on that, but it's better to let people discover new limits on their own. Though... there technically aren't any.

Developing ENIGMA / Re: Command Line Interface
« on: July 15, 2014, 05:23:11 PM »
He is developing it on Windows, bgordebak.