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

2341
Announcements / Re: Encryption
« on: March 02, 2010, 10:12:23 PM »
Sometimes one bites off more than one can chew. Like including windows.h. It introduced a few concepts I saw in Boost but was afraid of. So those have been implemented. Other than that, it's going pretty swell. :P

Anyway, it's nice to see that those who hang around these boards are more down-to-earth.

2342
Announcements / Re: Encryption
« on: March 02, 2010, 07:04:56 PM »
I'm afraid to reread my topic considering the replies are exactly what I was trying to convey. ;_;

Really, my biggest fear is room tampering.

2343
Announcements / Encryption
« on: March 02, 2010, 09:04:44 AM »
Despite what I'd like to believe (and maybe even what I'd like you to believe), making something in C++ doesn't mean it can't have its resources modified or even stolen. ENIGMA (being C++) makes sure that code isn't such a resource. No one can decompile your game. However, we do have a problem.

Because ENIGMA will be a regular system, unoptimized output executables will have the same basic format. Furthermore, because it is open source, an encryption algorithm is even more futile than it was in Game Maker. I can't just hide a seed and expect everyone to give up before finding it.

Now, in R3, rooms were stored as an array in the source code. This means that it would take a good amount of skill to modify them, but it's still feasible. Someone with a decent knowledge of how GCC handles such could probably make a tool to do it. If ENIGMA were to inherit GM's better disassemblers, we could possibly face problems with such (the hope is that since no one can get all of it, no one will write a tool to get some of it).

Fortunately, as long as you let GCC optimize your code, it should be too irregular to be removable by an automated tool. (Even if it was removed, it couldn't be decompiled other than manually, don't worry.) However, I'm not sure about unoptimized code. It would be far too much work to decompile it back to EDL (especially with the C++ goodness that gets thrown in), but it may be possible to remove entire events and replace them (making games easy to mod or cheat).

What's more, unified sprite and sound encryption is worthless. Pidgin doesn't encrypt passwords it stores for users because the developers understand that in an open source project--and for that matter, in any other project--doing so accomplishes nothing. So ENIGMA can not have a unified encryption system to protect non-code resources.

Personally I don't see this as a problem. However, I know one of the reasons people are in awe of the idea of C++ is that they think it will protect such resources. I can't think of a decent game whose resources aren't an open book (there are many Windows resource extractors. Not to mention, you Valve fans, think Garry's Mod). But, I can think of a way to fix this.

R4, as some of you are aware, will allow you to define C++ functions for use in your game. This is a great way to do with DLLs (but do note that external_define has been done for months). I could allow the implementation of a function called resource_encrypt (and one called resource_decrypt) to allow users to define their own algorithms. This would be done with the hopes that such an algorithm would not be in a uniform position in the executable every time. :eng99: If it was, it'd be as simple as writing a tool to look for like bits of code and extract the new stuff. Though they could still not decompile your code (and I am talking about the algorithm), they could call the decryption algorithm themselves, right where it sits, on whatever resources they extracted. Frankly, I think our better bet is to not waste time on encryption.

To protect room tampering, ENIGMA could hard code their creations in a large function (which would be optimized hopefully to un-uniform gobbledy... but it could still be replaced by a determined expert).

The function could be implemented conditionally; only executing if it has been defined by the user. This is just an idea I'm putting out, thoughts welcome. Especially from assembly people.

TL;DR: Paranoia resulting from the idea of really talented people wasting their time hacking games. Mods are inevitable, resource extraction is hard to stop, decompilation highly unlikely (as in, no one will waste their time on a huge game, and automation is impossible).

2344
Announcements / Re: Rejoice
« on: February 26, 2010, 07:16:50 PM »
#if is how I was going to do it. But that's compile time, so it means we can't have such a function anyway.

2345
Announcements / Re: Rejoice
« on: February 26, 2010, 01:12:24 PM »
...Nothing error related functions can do to stop or resume errors can ever make the code more efficient. Easy way is to use if's, copying code logically doubles size and makes inlining impossible.

2346
Tips, Tutorials, Examples / Re: lol streams
« on: February 25, 2010, 08:23:50 AM »
Duly noted.

2347
Tips, Tutorials, Examples / Re: lol streams
« on: February 24, 2010, 07:38:55 PM »
Does... that work? It should error that your function should be a member of std::ostream rather than declared in the global scope...

2348
Announcements / Re: Rejoice
« on: February 24, 2010, 06:58:36 AM »
Boy, I can't wait to add that.

2349
Announcements / Re: Rejoice
« on: February 23, 2010, 05:21:34 PM »
BAHAHAHAHAHAHAHAHAHAHHAHAHAHA
How'd the documentation for that look?

2350
Announcements / Re: Rejoice
« on: February 23, 2010, 05:17:23 PM »
Oh yes, that's funny. I'm dyslexic, asshole. ...haha.
Fine, maybe I just can't spell old dead people.

2351
Announcements / Re: Rejoice
« on: February 21, 2010, 12:38:37 PM »
Quote
Well, I meant more like being able to check functions only in certain moments where the user would want it using the functions, hopefully without too major speed loss. E.g. you could call "error_start()" to start being error checking session and "error_stop()" to stop it, or perhaps "error_object(obj, true)" to check for errors that occur within a certain object and "error_object(obj, false)". Just suggesting...

The former (error_start) leaves two options.
1) Have an if() to check if it's enabled, which wastes the same a mount of time as just doing the damn error checking
2) Use function pointers that can be swapped on error_start(), which removes any chance of inlining.

The latter (error_object) is a terrible idea by any standard. Now instead of one if(), we're looking up whether we are supposed to be generating errors for that object in a... map? Array? Either of them are awful in one way or another (map's lookup time, array's allocation time).

I'd be better off just leaving the errors than to add functions for them, but I'd rather not have them when they aren't needed.

2352
Issues Help Desk / Re: A replacement for draw_text
« on: February 20, 2010, 11:09:09 PM »
The GM6 doesn't store font glyphs as bitmap, they store it by font name. EXE stores the bitmaps.

2353
Announcements / Re: Rejoice
« on: February 20, 2010, 11:00:32 PM »
A bounds check every time a sprite is drawn? That's just one of them that really sticks in my mind. I might prevent the untimely death of the game by modding the index by the number of sprites, but aside from that... Hell, I wouldn't even just mod it. I'd waste another ((1 << ceil(log2(sprite_count))) - sprite_count) * sizeof(sprite_struct*) bytes (as in, wrap the sprites to a greater power of two) and use an & instead.

It's the little, "oh, this won't really hurt anything" ideas that end up in projects behaving like GM. "Oh, all those local variables are negligible." "Oh, using a map to store array elements won't slow anything." Whatever I can save, I will, or it'll all build up into slow gunk.

Also, score_, I'm not sure if all structs are compile-only in the sense that they will not affect size if unused. I'm thinking vtables might be stored regardless (Not a C thing).

2354
Issues Help Desk / Re: A replacement for draw_text
« on: February 20, 2010, 12:53:20 PM »
Quote
GM's loading screen cannot be eliminated by compilation. What on earth gave you that idea?
The fact that at present, ENIGMA doesn't have one. Most things that compile in ENIGMA have presently not been big enough to have a noticeable load time, so no one has really missed a loading bar. That will likely change in the future, so I'll have to install one that's on by default. Click the Clown should never require a loading bar. <_<"

And no, Game Maker uses the font the game was compiled with, whether it exists on the new computer or not.

2355
Announcements / Re: Rejoice
« on: February 20, 2010, 10:15:42 AM »
Game_Boy--
Precisely.

Everyone else--
Listen to Game_Boy.

@"Perhaps you could implement a function set ... to make his/her application look out for errors"
The point of removing error checking is to save on multiple ifs each call. That's part of the reason GM is slow; the runner can never be recompiled to your needs. I would be no more happy to find that a user of my finished game had it throw an error on them (especially one that could be ignored) than to find that it had just acted funny or died (in the case that ignoring the error was inevitable).

@"you/the team has to work more on the error messages"
That's been a goal since the beginning.