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

General ENIGMA / Re: How to get the C++ sourc code of my game?
« on: June 11, 2013, 12:16:35 PM »
That isn't where the objects are built. You'll find them under enigma-dev/ENIGMAsystem/SHELL/Preprocessor_Environment_Editable.

General ENIGMA / Re: How to get the C++ sourc code of my game?
« on: June 11, 2013, 09:45:14 AM »
ENIGMA does not delete the headers it generates when it is finished; we frequently ask people for copies or segments of them when something goes wrong during compile. Are you sure you're checking the right directory?

Proposals / Re: Improving the rooms editor
« on: June 11, 2013, 09:43:44 AM »
You can also move tiles by holding control and dragging them, if I recall correctly. Holding control and right clicking lets you set other options, such as the creation code.

Still, having multiple modes might make it less confusing.

Off-Topic / Re: Commercial Investment
« on: June 09, 2013, 02:44:06 PM »
Pretty easy to just brute force characters in a single div with the same color. :P

General ENIGMA / Re: Thanks a lot !
« on: June 09, 2013, 01:56:43 PM »
Sure. Good to have you! Good luck on your game.

Ideas and Design / Re: Add subimages from files
« on: June 09, 2013, 01:55:32 PM »
I believe Robert has added that to his latest LateralGM build. You can download it from his topic, here.


Off-Topic / Re: Commercial Investment
« on: June 09, 2013, 01:21:56 PM »
More nontrivial questions. But if you do a Google search for "The highest US court is the US * Court", the answer is so easy to filter that even a bot could do it. But if it's doing that, how'd it break ours?

It's hard to say, really; the bot would have to be good at matching keywords in questions and brute-forcing the answer by any means.

Or, maybe it's just a human paid to go through a big list of sites. Oh well.

Off-Topic / Re: Commercial Investment
« on: June 09, 2013, 12:13:21 PM »
Username: DeparDan
Posts: 1 (N/A per day)
Age: N/A
Date Registered: Today at 10:17:48 AM

Spam: Posted link to a realty-related domain.

On another note, I'm interested as to whether this was a paid human, or a really good bot. It apparently got through all three anti-spam questions, then navigated to the off-topic board to post the link. Pretty good, for a bot; it would have to actually try all words on each page forward and backward to guess correctly. So either lots of time, or a human.

If we get more of these AI-powered bots, I'll have to up the question difficulty.

General ENIGMA / Re: How to get the C++ sourc code of my game?
« on: June 08, 2013, 05:09:25 PM »
You can place your own C++ functions in your game by going to ENIGMA settings -> Definitions. Just declare the C++ functions you need in there, and you will be able to use them in your game.

Let me weigh in, here. Bear in mind my opinion on this matter is not final, but I believe some third-party perspective in this argument will help.

I am not opposed to having HaRRi's AA in the engine, but I wish that we could mark these functions in a way that made it exceedingly clear that they are not available in other graphics systems. OpenGL is portable; this means that you can at least compile your code on each platform, even if the function ultimately fails out. If you try to switch to DX, though, the function will either have to be implemented to do nothing, be emulated using similar DirectX offerings (which I believe has been stated to not be possible). If neither of those are options, then the function call will simply cause compile failure, pissing people off.

One of the best concepts of ENIGMA is the ability to switch systems out and compile your game, regardless of platform. Having a lot of empty functions does not create an environment wherein people feel secure in doing that. Letting a function that works in one system fail in another also is not conducive to that. It would be good if we could provide warnings for functions that do that, at very least, or maybe pack them into extensions so users have to consciously make the decision to use that extension, even though that isn't what I originally intended the extension system to be used for. Originally, the extension system was for functions requiring additional libraries (ie, more dependencies than the user may have already met), or functions which require local variables to be added to objects.

There are two classifications of "correct," here. Mathematically correct, or "True" anti-aliasing, is extremely computationally intensive. Trying to support it software side would be fallacy, and so despite being mathematically correct, is not implementation-correct.

MSAA is the implementation-correct way to do anti-aliasing. From what I gather, NVidia thought that cards would one day provide AA for users. NVidia and other vendors have succeeded in setting graphical precedents in the past; even the new C++ ISO is based largely on features of existing C++ implementations that people came to rely on over time. Apparently, that is not what ended up happening, this time. I guess it was too expensive in terms of hardware density to offer AA on top of existing features. I don't have a figure for actual support, but MSAA is not implementation specific; it uses only standard methodologies.

That said, HaRRi, I wish you'd embrace MSAA over the mostly NVidia functions currently implemented, unless you can show that support for them is still large and that DX offers some way of simulating that function.

If, however, HaRRi's functions incorporate mathematically correct AA hardware-side, they are invaluable; it would be worth offering them (and preferably a function to test if they are supported) JUST to have it on a handful of cards. On DirectX, the supported check function could just return false, and the AA functions could do nothing. This wouldn't bother me a fucking bit, as it would mean that user games could have mathematically correct, true anti-aliasing for dirt cheap on some cards, and then make it a point to use MSAA on cards that do not support those functions.

Third Party / Re: notepad++ linux GPL
« on: June 08, 2013, 07:54:02 AM »
I'm rather happy with Geany, personally. Though I doubt someone's made a GML highlighter for it.

Announcements / Re: LateralGM Update
« on: June 06, 2013, 08:59:49 AM »
We could rename that field from "Author" to "Maintainer" to avoid confusion.

Off-Topic / Re: Interview with Bjarne Stroustrup on C++11 and C++14
« on: June 06, 2013, 08:58:29 AM »
I've got some required reading to do with regard to both specifications. I didn't realize how bad it'd gotten until someone was using an rvalue reference and I had no idea what I was looking at.

It's sad, too; a lot of JDI was written to work around the fact that there were no rvalue references in the previous spec. I'll probably revisit those particular sections of it while I'm fixing templates.

Anyway, thanks for the link.

I didn't say that the issue ruined anyone's day (Even though I strongly implied it ruined mine). I said it was an issue. An issue that could have been easily avoided by using a branch. Four steps here:
  • Create a branch. git checkout -b ima_break_some_shit_to_move_mouse_x_and_y
  • Implement fix. This is the hard part, that you were going to do anyway.
  • Commit and push your fix. git commit -m "i fixd the shit on winblowx and brok it on evry1 els" git push origin ima_break_some_shit_to_move_mouse_x_and_y
  • Tell people on Linux and Mac to check out your branch and fix the shit on Linux and Mac, respectively.

From there, all anyone has to do is check out your branch, implement a fix, and merge the branch back into master. Now no one ever has to incur a problem.

polyfuck: How important a particular feature is does not pertain to the issue at hand. The issue is that the tracker is overflowing with little shit, the IRC is full of people who can't get the installer working, and amid all of that chaos, someone mentions, "Oh hey, mouse_x and _y aren't working."

Anyway, thanks much for the post, forthevin.
What I'm personally thinking is that we should do what we did on the SVN, only a little cleaner. I propose that everything in master be deemed "stable"; that is, no changes are made to it which have not been tested. Changes for testing are merged into the "testing" branch, from the "development" branch, when it's deemed that it might be a good time to push to stable.

Bug reports should be fixed in the most stable branch exhibiting the bug. That is, a bug should be fixed in master if it exists in master, otherwise it should be fixed in testing, or otherwise in development. If a bug is fixed in master, the fix is then merged into testing and development. If a bug is fixed in testing, it is merged into development. Bugs fixed in development, as stated, should have only been fixed there because they are absent from master and testing.

What I've just described is so simple, it's probably standard. The only reason we *aren't* doing that is because we failed miserably at it with the SVN, because no one ever remembered, "Hey, this would be a good revision to mark for (testing|stable)!"

If I thought we were responsible enough not to have a three-month-dead master branch on that system, I'd be interested in pursuing it.