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

Function Peer Review / Re: Function Peer Review Board
« on: September 25, 2010, 09:09:17 PM »
Also, console_show_message().

I'm not sure about where to get a really good script for that. The typical strategy for working with rectangles is storing a center point and some lengthdir params.

I don't think the Wild Magic people were trying to act smart. Though it makes me wonder what compiler they were using, since it clearly wasn't VStudio or GCC. (GCC -does- offer an export template extension, but it's explicit).

Anyway, the sources you linked to only have a fraction of the code. They inherit the rest. It's like Rusky's dream system. So if you want to see everything that's going on in the code... well, have fun tracking down all the classes you inherit from.

A quick Google search will find thousands of capable geometric collision examples. Here's one. But collisions are one place I don't even trust my own math skills to generate the most efficient test function, let alone some stranger's from Or that of some group using Compiler from Hell.

I also don't understand why you needed it converted to GML; are you trying to get it to work in Game Maker as well? G++ compatible C++ can just be copied into WhiteSpace in ENIGMA and used like any other function. Including the code on that link I gave above. Right now, the syntax checker has problems with variable.function(), but I will have that working sometime this week.

When the fix is in the stable repo, I will let you know how to use his code.

No, Josh went to college and abandoned everyone. Twice.

Don't worry Ism, that's not even what I'd consider "good" C++. I'm sure someone out there appreciates it. Rusky probably does. But I'm not a fan of making a template to do a regular class's job. Especially when it makes that many assumptions about what class Real contains.

They seem to have, however, circumvented my biggest beef with templates, being the lack of extern-ability. How did they do this? wellfuckifiknowillbetitwontevencompileinenigma

Furthermore, I can't retrieve the first .cpp file, or I'd tell you what it did. As for the second source, the first thing I notice is that it won't compile with -pedantic. Not that I make ENIGMA do so, but I've found that serious collaborations compile with -Wall -Werror -pedantic, meaning if the compiler even glances at anything funny, compile fails.

My synopsis is that they whore everything new unceremoniously. I doubt it'll compile in GCC or VStudio due to the lack of extern template in either of them. Not that they explicitly denoted that, anyway. "Wild Magic" is about the size of it.

As far as distance calculations go, the math is like all others. Except encased in uncompilable filth. I would sooner get GLibC to compile in G++ than this project.

Proposals / Re: new Build mode
« on: September 22, 2010, 09:46:35 PM »
First, for those who don't know, the original Build mode was designed for live-action development. For one thing, it was made to be largely hot-key based. Imagine you are one of the brave ones developing Sonic clones in Game Maker. Sonic is running through the course at 50 miles an hour, then he hits a springboard and goes flying. He's about to fall off the screen, but right before he does, the user presses Ctrl-Space and places a new springboard. Or a new piece of earth. Or a new anything.

Design mode, the new, less-ambiguously named Build mode, was meant to incorporate features that the IDE component simply couldn't offer; the simplest example of that is non-orthographic design. And I chose to say non-orthographic instead of 3D to imply that even in 2D games (which are, yes, technically orthographic), some trait of the game could make it exceedingly difficult to accurately place objects, such as rapidly changing levels or simulated 3D layers. In perspective 3D, this problem becomes even more apparent.

Now, TGMG's proposal appears to be to keep the outputted game in communication with LGM via JNI. We run into a number of problems if we want to try that, particularly;
  • As Ism hinted, JNI is a little bitch. So she's using JNA. I'm not a Java person, so this is out of my scope and falls entirely on Ism. However, the same principle applies in the end for the callback functions TGMG mentioned; ENIGMA has such callbacks as JNI offers provided via JNA. So we could work around this, for the most part. Rendering inside the LGM window, however, wouldn't work.
  • Even if rendering in the LGM window were possible via JNA (or if we got JNI working), we're also assuming that all VMs by which ENIGMA can be emulated (Android and iPhone included) would be capable of accessing thread information from the running operating system, which I think is highly unlikely. Not to mention, an emulator will not always be available, where writing the data to a file is -always- an option as the game will -never- be on ROM (Honestly, how would the typical user put it there? [Okay, yes, discs, but those are totally unnecessary]). I have a very special plan in store for build mode that would not be able to work alongside LGM.
  • If the user doesn't like the changes (s)he made, there will be a lot of backtracking involved to revert them. A file makes it easy to say "Accept Changes?": if they say no, the file is ignored and deleted.
  • I would like build mode to offer a tile and instance creation API. For example, instead of dynamic rendering of "tiles" for auto-generated levels, the user could make calls to an API to remove them all, then re-create them according to their surroundings instead of drawing them as they do in Game Maker. I am unsure of the implications of allowing users to make calls to JNA willy-nilly; perhaps there are no further implications than having them do so with the file interface.

Basically, to get the most out of cross-compilation with this mode, the game needs to be dependent on the smallest number of items possible. Including the IDE. The two should shake hands after the fact, and not rely on each other in the mean time.

Function Peer Review / Re: Function Peer Review Board
« on: September 20, 2010, 09:11:38 AM »
If they work when added as a function in Whitespace, or are really worth porting, I don't see why not.

Proposals / Re: LGM themes
« on: September 18, 2010, 09:50:47 AM »
I figure LGM may as well adopt its own style, and swing default will suffice. I do have a sort of affinity for the folder icons in your first one, though. It reminds me of a simpler time...

Off-Topic / Re: Some guy working since 1987 SPEAKS OUT!!!!!!
« on: September 17, 2010, 06:16:15 PM »
Aware. The compilation speed issues definitely fall on GCC. And such is indeed out of my power to fix. It doesn't help that I don't ship ENIGMA with precompiled object files. That much needs to be improved on, and will need to be very shortly as people start compiling for more platforms. I need to keep a folder of objects for each device, at very least.

Eventually I will need to invest in precompiled headers, as well.

For now, though, I've tried to use few GNU extensions that would inhibit faster compilers from being incorporated. Right now, the only function that comes to mind is lrint(), but compiler support for that seems to be good. Serp used some GNU #defines in his #ifs in various functions, which should only fail to optimize correctly on faster compilers.

Ultimately, though, GCC must do the final compilation of all projects. Despite its slower compile times, it has the widest support by those who work towards cross-compilation, and is quite consistent between platforms with its #defines and its type sizes. It is by that saving grace that I managed to compile all the audio codecs natively without huge recode.

Anyway, something about tacos.

Off-Topic / Re: What licence for my open source project?
« on: September 13, 2010, 09:22:44 PM »
Sometimes I swear those people are writing in another language.
</OffTopic> , though I'm not a proponent of CC for code.
Really, I'd just write my own license, in your position.

Proposals / Re: Add a place for extra returns.
« on: September 13, 2010, 09:15:38 PM »
Var has a overload for cast to double&, so that would be the more accommodating choice.

Announcements / Re: What's happening now
« on: September 13, 2010, 05:40:13 PM »
I'd rather wait for Ism to finish her work now, on which there is no ETA (She describes this as 'new territory,' as I was sure it would be). She hopes to have something ready this week, though. For now, I the previous file seems to be holding up.

Announcements / Re: What's happening now
« on: September 13, 2010, 12:13:22 PM »
I can do backgrounds as soon as I finish this, I guess.
I'm also renaming Windows to Win32, so this could get messy pretty quick.

Proposals / Re: Add a place for extra returns.
« on: September 13, 2010, 12:00:18 PM »
Then the exe size would skyrocket if it was actually used with multiple types. If a function absolutely needs to take double&, then it should. But these solutions seem a little overcomplicated for a simple multivalue return.

Announcements / Re: What's happening now
« on: September 13, 2010, 09:42:26 AM »
I can't control where the installer places OpenAL. And apparently, I can't just pack the DLLs with it, because they seem to vary from computer to computer (Most likely just from 32bit to 64bit, but I can't pack 2MB worth of Audio DLL into each game). That's why I intend to create a DirectX version of the audio system.

Sure you can participate. In fact, I kind of need you to, since yours is one of the computers with the differently named Program Files directories.

I'll tell a2h about the edit page next I see him (if he's not already fixed it by then).

I don't really need an AL wrapper; just some better way of taking AL with ENIGMA. But AL's support isn't that great right now, so I can't just assume anyone on Windows has it installed.

Proposals / Re: Add a place for extra returns.
« on: September 13, 2010, 09:25:54 AM »
Code: (EDL) [Select]
struct collision_result { double x, y; };
collision_result collision_line_ext(x,y,x2,y2,obj);


collision_result xy = collision_line_ext(x,y,o.x,o.y,wall);
x = xy.x; y = xy.y;

What luis was suggesting is passing x and y to be modified by reference. The problem with luis's idea is that now, the arguments MUST be double or var, they can't be int or anything or it'll throw a compile error.

Announcements / What's happening now
« on: September 13, 2010, 12:13:25 AM »
Since I put out that zip file to test who can install ENIGMA, I've been getting feedback from all angles. Basically, a couple serious issues were corrected or are being corrected, in the order they likely surfaced:

1. ENIGMA.exe could not recognize the Program Files directory on foreign (Non-English) Windows systems. This meant that it simply couldn't find Java to run it for the user. Since %programfiles% is evidently not interpreted correctly by CreateProcess, this was fixed (in theory; I've not tested but assume it to work) by fetching the environment variable manually.

2. An invalid handle (as far as DuplicateHandle is concerned) to stdin was passed to make.exe when no console window was open. This caused make to bail for no rea reason (It doesn't actually use stdin in ENIGMA's process, or in any process of which I'm aware). Combined with the previous error, this means that if ENIGMA.exe can't find Java.exe, you can't use ENIGMA at all. This error was resolved by requesting a new (also either NULL or INVALID) handle to CONIN$, which placates make.exe (again, for no good reason).

3. D:C:\ Was an issue that surfaced when I threw kkg and some others on the IRC a fix for (1). This error lived a total of ten minutes, and was fixed by adding a NOT.

4. LateralGM exception: Cannot find ENIGMA's class. This error can only be explained by blaming the update sequence. It can be remedied simply by restarting LGM without it updating. Ism is working on a fix for it now.

5. LateralGM constantly pesters for update: Fixed.
5.5: LateralGM frequently pesters for update: This is due to a number of factors, the common ones being, as Ism said, as follow:
- An update is in fact available.
- A file has changed that is under strict version control (aka, everything that downloads when you run LGM for the first time).
- An update exists for one of the other branches. This should certainly not be notified on.

What else I've fixed/am working on:
- Fixed a couple small but annoying bugs, mostly reported by polygone. The most severe of them was a crash on missing closing comment, which originally I was going to have error, but then remembered that GML allows it and removed the check for it in syntax without taxing the parser to do that check as well.
- Am currently working on the network of flag files ENIGMA will use to identify different platforms that can be compiled for. The basic gist of them is this:

Code: ( (Unknown Language)) [Select]
%e-yaml---Name: Mac OS XIdentifier: CocoaRepresents: MacOSXDescription: Run on Apple Mac OS X, or other Cocoa-enabled Apple systems.Author: TGMGBuild-Platforms: MacOSXRun-Program: openRun-Params: $game
That file contains everything (so far) needed to describe OS X as a platform for which ENIGMA can compile. It is located under ENIGMAsystem/SHELL/Platforms/Cocoa/. Three other files almost identical to that one exist under the other three folders. Android is not presently supported in the repository version; TGMG will likely add it after this flagging system is finished.

Wish us luck. Especially Ism. She has a lot of crap to sort through due to such road blocks as Java lacking a "delete."
*mutters something under breath*

When all of the bugs above are fixed and re-tested by my group of victims, we will re-release the zip file. If all comes back positive, the zip will be uploaded to SourceForge, as well as the other zips/packages.