@25, speaking of for loops, I remember an old test that a friend and I ran to determine iteration times for BGT and C++. The code did pretty much the same thing in both languages: iterated a million times and generated an array holding 1000000 integers from 0-1000000. Then it did another for that wrote that to a file, to attempt to add latency. (Yes, you read that right, I deliberately added latency... most of the time I'm trying to eliminate that while keeping resource usages low, though that... usually doesn't work the way I intend it to.) And the winner was C++ hands down. If I remember right, BGT took about a minute to generate a million numbers and write them to a text file, and C++ took less than 3 seconds. That could've been due to the fact that it was on an SSD, but if I remember right both of us were using SSDs. I still have the program laying around here. Rofl
I spent like two months last year trying to track down the source of seemingly random lag, and the results can be summed up as "lol does there have to be a reason?". The best I could find was that BGT does not do well with garbage collection, which is to say, I had to try lots of probably-not-thread-safe memory-saving tricks to get the Infant Mortality Rate down. This only marginally improved things. I also found that it really struggles with audio, but only if there's been a lot of garbage-collection just before, and no, preloading didn't help. I finally concluded my computer is a jerk that freaks out when it goes into Internet Withdrawal, and just kinda gave up.
Judging by what I know about bigger, more complex games and how they're programmed, this was almost certainly a combination of BGT and my system. It's a little funny, in that, when I first started with BGT, it felt like there was less latency in some situations as compared to Java, running as close to the same code as feasible. But that's presumably due to the different bottlenecks in the code then vs the code now.
Re: PyOpenAL, is there anything I can do with BGT that I can't do with PyOpenAL? Ex, pan, volume, pitch, is the sound currently playing, seek, stream vs load, and what about sample rates and file formats? And what about latency (BGT can change these properties instantly)?
@26, in bgt for loops are not fast because bgt execute's AngelScript's byte-code while C++ is compiled into native code
also another problem is, bgt uses older versions of AngelScript, but the newer versions were optimized which made it faster (for philip, he can at least update the AngelScript in it and recompile it and the performance will become really really better)
Could this be moved to the developers room? There's hardly anything in this topic concerning existing games, it's more about observations of various languages used to develop them.
If you like what you're reading, please give a thumbs-up.
@28, I know. You'd think though that Bytecode compilers, being what they are these days, would be almost as fast as native code. (Java developers have asserted the claim that compiled java bytecode is supposedly faster than native code... I honestly find that hard to believe, since I've never done exact benchmarks, and benchmarks aren't exactly trustworthy since there are so many variables to keep track of.) Philip isn't going to update BGT an more; I doubt he's even got the source code.
#31 (edited by kianoosh 2018-07-10 11:02:27)
at C A E jones: You can do all of the things you mentioned. Changing pitch, pan, volume, I think getting the sample rates, file formats, hrtf which bgt doesn't have it, and even much much more things that bgt doesn't have
Or follow me on twitter @kianoosh shakeri
I am curious, what part of BGT is it that causes the AV to freek out? I wonder if it can be coded around, for example, if it is how BGT creates an input field, that can be coded around with relative ease.
Managing Director of Nathan Tech
It's not disability
@32, nope. The way BGT compiles executables (its not really even "compiling") is it converts your script code into angelscript bytecode, then embeds a particular file (I think its bgt.bin or something) into that compiled bytecode. Though I've theorized that its embedded the entire application plus the .bin file into the application too. Not sure which is actually correct. Either way, the way it embeds itself is exactly the same way a Trojan horse is created, so AV programs freak out. I'd say its the way a templated metasploit virus too but templated metasploit viruses run in a separate thread, which BGT doesn't do.
Although it would require an extra step, I wonder if using something like UPX or PKLite, or some other executable compressor would be a way to avoid the false positives. Heck, I'd even try a DRM system like ExecCrypt or Armadillo, just set them up to not need registration to run the program. In Armadillo you'd just create a default certificate that never expires and you're done.
#35 (edited by Ethin 2018-07-10 19:59:59)
@34, maybe, though UPX has produced invalid executables for me, and I've used it correctly. I doubt it would help anyway. AV programs will just unpack the compressed data to see what it actually is. I'll quote a book that I've got that explains it far better than I can:
A packer is a type of software that is commonly used by malware authors and hackers to compress or encrypt an executable in order to obfuscate its code and data. One very common packer is named UPX (http://upx.sourceforge.net) and is available as a package on most Linux distributions. The original purpose of this type of packer was to compress an executable and make it smaller.
Since the code is compressed, it must have a way to decompress itself before executing in memory—this is where things get interesting, and we will discuss how this works in the Stub mechanics and the userland exec section. At any rate, malware authors have realized that compressing their malware-infected files would evade AV detection due to obfuscation. This led malware/antivirus researchers to develop automated unpackers, which are now used in most, if not all, modern AV products.
Nowadays, the term "packed binary" refers not only to compressed binaries but also to encrypted binaries or binaries that are shielded with an obfuscation layer of any kind. Since the early 2000s, there have been several remarkable ELF binary protectors that have shaped the future of binary protection in Linux. We will explore each one of these and use them to model the different techniques used to protect ELF binaries. Beforehand, however, let's look at how stubs work to load and execute a compressed or encrypted binary.
Small passage from Learning Linux Binary analysis, by Ryan "elfmaster" O'Neill, ISBN 978-1-78216-710-5, chapter 5, "Linux Binary Protection".
In that case I'd try a DRM system with the registration part disabled.
Lol too bad we can't play with Armadillo without getting that trial message. That might actually do the trick, you never know.
I have been keeping this a secret because of the generally negative view most people have about DRM, and a bad experience that occurred when I inadvertently let the secret slip.
Not including the one other time I told this to someone here on these forums, the last time I let it slip that my last job was developing and maintaining the Armadillo DRM system,, I was insulted and verbally abused by many of the forum's other members and was eventually banned by the moderators, not for the way I responded to the assaults, I was still thinking about how to respond when I was banned, but because it was easier to ban one person, than it was to ban a bunch of other members, it was all pretty upsetting. That is why I've been reluctant to reveal any specifics about my last job.
Of the various jobs and projects I've worked on, Armadillo was my favorite, I enjoyed the hell out of that job and often when home after the office closed and kept right on working, there wasn't a whole lot else to do, so why not?
The only difference between the trial version and the registered version is that message about being protected with the trial version. Everything else is the same, so the trial version could be used to test if it could be used to keep anti virus programs from falsely flagging BGT games.
I have the ability to generate keys to register Armadillo, but out of respect for my last employer and the creator of Armadillo, who is a friend, I'll want to think about that before I offer to generate any keys.
If you want to play with it, you can get it here:
This is the 32 bit edition of version 8.60, since BGT produces 32 bit executables, it's all you need. There was also a 64 bit edition too. Which edition you use doesn't depend on which edition of Windows you are running but on the executable you want to protect.
Have fun, and if you have question that aren't answered by the help file, I'll try to help, though it's been a while, so I'm no doubt pretty rusty.
@38, nice info. I just have a feeling that app protection just might get AV programs more suspicious than they already are with BGT games.
#40 (edited by Orko 2018-07-11 14:14:03)
I'm not so sure as Armadillo was used by a lot of software vendors, many of them not so small and quite well known, and none of them have any false positive problems.
But that was five years or more ago and things may have changed, but then again, I have several Armadillo protected programs on my system and they never get flagged either.
Anyway, it's just an idea I thought I'd throw out there.
I generally don't like DRM but its not like I'm gonna hate on the people for making it. I don't like it generally because it can get in the way of you using the product you bought. I know a lot of people here might see that as the norm, but I grew up and remember you just went out and bought a CD, and put the key in and used the thing. Even before keys, some software just came on a CD and that's all you had. Now, obviously, those were getting pirated lefft right and center, so something had to be done. But you really do get some intrusive DRM these days. The number of installs thing bugs me, because I get burned, not because I use them on more than one machine, butt because I reformat, reinstall and so forth then forget to deactivate the thing. I kind of feel that's the developer's responsibility to manage who's using what and if its being used on more than one machine concurrently, and if its not, what do you, as the developer / publisher, care how many times its installed, because its not being abused. If its not being run on more than one machine at a time, that just means people are either reinstalling their systems, or throwing away and buying new. Of course though, upgrades to your machine make them think its another PC, so you have that issue. But let's say if you don't see it being used from that old PC in a month's time, have it automatically removed from active status, and give that user back their install. So if he had 3 installs, used one to install it currently, then the thing thought he was running it on another computer when he wasn't, he'd have 1 left, but if that one wasn't used for a month or so, then he should get one back, leaving him with 2.
is preferable to
I felt the passing of your wind
#42 (edited by Orko 2018-07-11 14:20:45)
Exactly my point, DRM itself isn't bad or a bad thing, neither are guns robbers and murderers. It's the people or companies that misuse or abuse them thatmakes them look bad. They're just tools.
Unfortunately, some people just don't see it that way.
@42, true. I've received emails that badmouth DRM and all that, claiming things like, "DRM is bad!" or "DRM is evil! We must eliminate it!" In truth, the only DRM that is evil is the companies that use it to force things onto their customers.
I have no problem with DRM that phones home to validate your registration key with the company or developer that issued it, it's a way to thwart illegal key generators, but that should be it. This needing to phone home every month to check your license says nothing but that you don't trust your customers and would rather treat them as thieves rather than be thankful for their support and respect them.
Code factory is a good example of this. I don't mind that they protect Eloquence with DRM, and I don't mind that activation requires an online connection, but I do mind they're always needing to verify your license online. That's just a slap in the face for buying their product.
Yeah, there is this mentality you should always have to be online to use products, which I whole-heartedly disagree with.
is preferable to
I felt the passing of your wind
#46 (edited by Ethin 2018-07-11 18:52:44)
@44-45, definitely. I'd gladly set up a DRM system that phones home when you activate it; hell, even phone home every once and a while (i.e. every 3-4 years or so to make sure the activation key is still valid and that the server is still up), but if no response is received, you shouldn't be deactivated, or if you are, you should be given the chance to get a new license if you're accidentally deactivated because the server happened to be down that day. But you shouldn't be required to order a hole new license.
My feeling is, that if you really feel that your product needs periodic online license checks, be considerate about it. Lets's say you want monthly license checks, OK, built into that should be a one month grace period such that when the online license check is due, the user has an additional month to be online for that check to complete before your software is deactivated. That way, if you are somewhere where you can't be online when the license check is due, you won't immediately loose access to your software.
Apparently Code Factory isn't so thoughtful or considerate, a while back I went to play a game that uses SAPI, but was unaware that my internet connection had gone down. As luck would have it, Themedia decided that it was time to do an online check of my license for Eloquence for Windows, the attempt failed because my internet was down, as a result, Eloquence just kep repeating the last phrase it had spoken. No grace period at all.
I keep hoping some smart cookie will successfully strip Themedia off of Eloquence for Windows so I won't have to be bothered by such stupidity again.
the problem with upx or packers is, the packers remove the embedded byte-code from the end of the executable file as they are not stored in a section in the executable
@48, the problem I stated in post 33 and 35 would still apply too.
With that being the case, to anyone who decides to try using Armadillo, when the trial message pops up asking which version of Armadillo you want to try, you'll need to choose the pro version, because you'll more than likely need to adjust the data after program setting to get the protected BGT program to work and those settings are available only in the pro version.