@25, again... that doesn't definitively prove anything.
How not? I have tested this on many BGT games, all returning the same result. VGStorm games do not return the same result, and it is a common thing with VGStorm games and no others.
@27, because that's just throwing accusations around. Just because the PE size is larger doesn't mean its a "special version". Wedon't even know if Phillip and VGStorms games are "friends" in the sense of the word. As I said a few posts back, the *only* evidence will prove it is if Phillip himself comes and tells us, publicly, that he did it.
Alright, before this turns into I don't know what.
The only reason BGT games by VG Storm cannot work under windows xp is because they specifically call on the Elias dll to work, and the Elias composer studio...you guessed it, produces the very same not a valid win32 application error. I've tried it, trust me. This also means that Elias-dependent games cannot run under wine, which is actually quite annoying if I can say so myself. Xp incompatibility I can deal with, but not being able to run them on wine is a drag.
#30 (edited by mahdi-abedi 2019-02-06 12:14:41)
@12, perhaps is the indentation? I can't help you if you don't tell me your problem.
well, if python have some engines to help me, it can be good: I cant understand the librory
sorry, whats PE
sorry, whats PE
PE stands for portable executable and describes the actual unit within an executable which gets loaded and executed by windows. In the case of BGT, this PE describes the utilities to further load and execute the byte code generated by bgt and stored within the executable beneath the actual PE.
Well, python is not like BGT if you are thinking so. It's an extensive language and you can't learn it, if you can't understand English well, you can translate python documentation which comes with the python program and then you can learn. It's good enough and will make you start up.
Don't forget to give me a thumbs up!
well yes, python is very more than one game
@ethin, you are clearly just making excuses now. You're not even giving me any arguments anymore.
#36 (edited by visualstudio 2019-02-06 17:47:48)
let me explain a bit:
the bytecode + packed data + a structure will be appended into the PE file without any sections. so, they are not part of any section, even they are not part of PE code.
this is the reason where anti virus softwares flag them.
also, checkout AngelScript's ChangeLog, even aaron baker reported some bugs there and the main author (andreas johnsen) fixed that!.
also, if you check manamon, psycho strike, etc, their cpu usage is lower than other bgt games.
now, it depends on you to think how you want.
can you please give me address of this script? where to check etc
#38 (edited by defender 2019-02-06 22:20:00)
From an outsider's perspective, it seems like everyone is saying BGT is terrible even though it's simpler to work with and still able to produce good games when used as it's meant to be used, by an actually experienced coder.
These people always strongly urge others to just switch already, then turn right around and bitch in the same breath about all the problems they are running into with out of date/overly complicated/feature poor libraries and closed source or unstable and hard to find rappers and highly resource intensive/highly technical to set up IDES and shit, especially when it comes to cross platform, which is supposed to be one of the many advantages of upgrading.
At least some of those people are actually trying to do something about it as well by providing resources and working on rappers, but it's still pretty iffy as compared to BGT.
I understand that many see it as a necessary evil and a growing pain that must be overcome if we want more complex titles and better coders, but if the reason you got into audio game development was always meant to be as a hobby and you only ever wanted to make simpler titles a la Super Deekout, Villains from beyond, Marina Breakout and the like in the first place, than why should this apply to you?
Yes, it'd be nice if they were, but not everyone is the next Dan Z or Liam Ervin or Phillip Bennefall or wants to be, and most of the people pushing for this haven't made anything of note them selves after upgrading either.
It's been said many times before but I guess it needs to be restated. It's not BGT's fault that all those clones happened, and most users are still computer literate enough to exclude their games from the grasping clutches of Windows Defender.
Do I think it's a bad idea to lock your self into a limited language even when it has some great convenience features? Yeah I do, but only if you had the ambition and knowledge to need something better anyway. And from what I've witnessed that particular Ven diagram has basically no overlap.
It's also pretty hypocritical that we're totally cool with certain developers using BGT for their games and not others. Just because a person happens to be a crap coder, it doesn't mean they are suddenly going to improve simply because they've gone more mainstream and have more resources.
See Sam, Mason, Steevo, phantom, and Gortholon for varying levels of this change in action.
Young Phillip Bennefall, Munawar Bajani, Liam Ervin, and Yukio Nazawa had plenty of failures too I'm sure, they just had the foresight to keep them quiet, where as now people seem more comfortable sharing unfinished stuff and we also seem to have a higher expectation of quality as compared to the Treasure Hunt or Tarzan Junior days.
I just don't think we should be so disingenuous in trying to boil it down to something as simple as (what's wrong with you! switch already!) when it's clearly more complicated than that.
Like are you really going to play TLW just because Mahdi rewrites it in Python? I think not.
Lets demonstrate this: stand still Thom...
@38 It's more about the language being out of date and no longer receiving updates, and as a result, a lot of people get virus warnings even though the games did not include viruses. It's also about the low barrier of entry in BGT, which makes it harder if someone does want to transition, because now they need to learn about dependencies and libraries and so on. It is also the case that you start developing a game in BGT, only to realize it's too complex for a single threaded application and now you're stuck, either you hit performance bottlenecks, or you port the entire thing over to another language, which is a painstaking process. Also, don't always expect to find manuals as detailed as BGT's manual is. You can find anything on MSDN, but you have to know what you're looking for. Often, a language's documentation is a hell of a lot more technical than BGT's, which seems to have been written for the layman to get into programming.
Yes we've had people transition out of BGT to other languages, but how much longer can BGT be supported if the engine is compiling code that defender is flagging.
Well, BSC games were flagged, and they were using VB/directx. Virus scans are getting to the point where they will pretty much flag anything that's unsigned, and in the windows world where software is commonly in the wild rather than regulated app stores (windows 10 is a start but there's a long way to go before devs unanimously adapt it) there's really no reason for a hobbiest developer to pay the hefty costs in signing. The only reason to sign these days is if you're a hardware vender making drivers, or you want to end up on download.com which I hate sites like that.
#41 (edited by Ethin 2019-02-06 19:20:19)
@lukas, no, I am not "throwing around excuses". Its you, really. If I give you two versions of an application, and one is a debug build and the other a release one, and the debug version is obviously larger, yet they both have the exact same C++ code with no modifications (but you don't know that), then by your own logic its a "special version" and I "added or removed" something. Yet, in truth, its not a special version at all. It is the exact same copy a user would have with the release version if they went and downloaded it. If I then take that debug build and add some optimizations to it 9but accidentally optimize it badly), ,and it only shrinks by a few hundred KB then by your own logic I "removed something" when in fact I removed nothing because "its smaller". Size of an application depends on a lot of factors, one of which is optimization. If you fail to optimize your application properly, you risk size increases or weird things happening. Its why most developers don't encourage optimizing at level 3 with GCC -- it produces code that has a much higher risk of executing and causing strange and hard to diagnose issues than level 2 does. I hope you now understand why I am saying that we will never know unless either (1) Phillip publicly admits it or (2) someone (somehow) attains the source code of the BGT that VGStorms games use and can peruse it.
@39, agreed with that one. Most documentation for other programming languages is far more technical. Some languages documentation actually contains the grammar for the language (which is neat and lets you find Easter eggs). Take for example this portion of the Python language reference, section 8.3, on the For statement:
The for statement is used to iterate over the elements of a sequence (such as a string, tuple or list) or other iterable object:
for_stmt ::= "for" target_list "in" expression_list ":" suite
["else" ":" suite]
The expression list is evaluated once; it should yield an iterable object. An iterator is created for the result of the expression_list. The suite is then executed once for each item provided by the iterator, in the order returned by the iterator. Each item in turn is assigned to the target list using the standard rules for assignments (see Assignment statements), and then the suite is executed. When the items are exhausted (which is immediately when the sequence is empty or an iterator raises a StopIteration exception), the suite in the else clause, if present, is executed, and the loop terminates.
A break statement executed in the first suite terminates the loop without executing the else clause’s suite. A continue statement executed in the first suite skips the rest of the suite and continues with the next item, or with the else clause if there is no next item.
The for-loop makes assignments to the variables(s) in the target list. This overwrites all previous assignments to those variables including those made in the suite of the for-loop:
for i in range(10): print(i) i = 5 # this will not affect the for-loop # because i will be overwritten with the next # index in the range
Names in the target list are not deleted when the loop is finished, but if the sequence is empty, they will not have been assigned to at all by the loop. Hint: the built-in function range() returns an iterator of integers suitable to emulate the effect of Pascal’s
for i := a to b do
; e.g., list(range(3)) returns the list [0,1,2].
There is a subtlety when the sequence is being modified by the loop (this can only occur for mutable sequences, e.g. lists). An internal counter is used to keep track of which item is used next, and this is incremented on each iteration. When this counter has reached the length of the sequence the loop terminates. This means that if the suite deletes the current (or a previous) item from the sequence, the next item will be skipped (since it gets the index of the current item which has already been treated). Likewise, if the suite inserts an item in the sequence before the current item, the current item will be treated again the next time through the loop. This can lead to nasty bugs that can be avoided by making a temporary copy using a slice of the whole sequence, e.g.,
for x in a[:]: if x < 0: a.remove(x)
So, now we learn that a for loop can take an "else" statement. That's something I didn't even know (unsurprising since I usually don't poke around in the language reference). Or take this one, section 8.5:
The with statement is used to wrap the execution of a block with methods defined by a context manager (see section With Statement Context Managers). This allows common try…except…finally usage patterns to be encapsulated for convenient reuse.
with_stmt ::= "with" with_item ("," with_item)* ":" suite with_item ::= expression ["as" target]
In other words, a with statement can have as many with items as you like. So you can do something like:
with open("table.dat", "wb") as sounds, open("config.cfg", "rb") as cfg: # code
BGT doesn't do this, so we have to look at angelscripts documentation to find these things. Almost every language out there does something like this, where you can look at the grammar and find unique things. Seriously, go through your favorite languages documentation (or through Python's, even) and look up things that might be interesting -- you might learn something knew. (The multiple with items was also something I didn't know was possible either.)
@jack, true though I haven't encountered most of the issues others have reported. BSC games were never flagged for me, and I've been able to play them fine. Malwarebytes has only gotten in my way when I've ran BGT games or have deliberately sandboxed an application to test it (where that does become an annoyance, but I still thank it for its aid).
I think the closest we have to a modern BGT is probably Quorum. It's heavily scripted (I can't imagine the time it took to make the engine understand logical sentences) but the developer says it's based on pure java and advanced users aren't necessarily limited by its beginner-friendly nature, so even with this in mind they can end up creating pretty sophisticated stuff. The offline ide looks to be a modified version of sodbeans, and there's a web interface as well which is used for the interactive tutorial. I think this was created in response to the bloated so-called beginner friendly languages that are drag-n-drop based, instead taking a bit more of a creative approach by making it understand sentences.
@42, yeah, I haven't played around with Quorum very much (I found Sodbeans quite clunky). I should probably take a look at again and see what's improved. I'm amazed it can understand logical sentences... now that's a huge leap.
#44 (edited by cartertemm 2019-02-06 19:37:07)
So he gives out different versions to others... Good for him, Precisely why is this an issue? What crime is being commited that is in direct harm to you, and in which way are you being offended. Please explain
If your gonna go around calling people idiots, please don't do so baselessly. If you'd like to call someone's ideas stupid, how about actually presenting better ones or at least showing where they went wrong? Lucas has provided technical explanations, to which you've done nothing but shrug off. So I'm apt to go with his assumptions.
Here I will do likewise in showing you that manamon is in fact using a different version of BGT, one not released publicly. If your still able to come to a conclusion as to how this proves nothing, and can back it up, I'll gladly listen.
1. Get BGT
2. Write a simple script, I'll call it game.bgt for simplicities sake
alert("test","this is a test");
3. Compile it.
4. Grab the stub, the following python script will do it assuming you have pefile installed.
with open("game.exe", "rb") as s:
r = s.read()
pe = pefile.PE("game.exe")
offset = pe.get_overlay_data_start_offset()
with open("stub.out", "wb") as t:
5. Run the same script on games such as manamon and make sure to examine the output in detail, specifically exposed functions and constants in the executible. I'd personally use strings.
You'll notice that there are, in fact, functions not present in the original stub. Hell, if your lazy, run a diff on both stubs to see what we're talking about.
You're even looking at a newer version of angelscript.
I might add, the only way one could improve upon the original version of BGT would involve intense reverse engineering and manipulation to such a point where it might be easier to just write your game in another language, or attempt but probably fail to mirror all BGT's functions.
edit: So you actually replied between the time I began writing this and clicked the post button. Interestingly enough, all the above applies and there's actually no reason to delete or modify anything.
Oh yeah, debug and release builds don't have any reason whatsoever to modify anything but the appended and encrypted angelscript bytecode
#45 (edited by Ethin 2019-02-06 21:08:32)
@44, I didn't see your post when I edited mine and submitted it. Weird.
OK... so, let's say your right. Let's assume for a moment that the version of BGT is different. So what does that prove? Yes, in this "assumption" he supposedly gives out versions of BGT to VGStorm (though I don't get why). That doesn't mean much, now does it? We don't know the circumstances behind the exchange. We don't know if it was because they were friends (which I doubt) or because Aaron paid him for it (which seems understandable, since companies do that too).
I shrugged off Lukas's evidence because I'm honestly curious if Phillip will admit it, and because debug/release builds of programs do alter their size (OK, minus BGT...). Didn't know about pefile, I'll look into that and play with it. OK... I already have it. Wonder which module installed it.
My "idiot" comment wasn't baseless, Simpter was actually looking like an idiot, throwing accusations around left and right as though what Phillip did was some kind of crime, which you already addressed.
Yeah, what's so great about BGT anyway? It provides no way to output visual information and it's not being maintained anymore unless it is true that people have newer private versions. I wonder why they're private in the first place ? Why not let everyone use them?
I'm sorry, but I don't agree with post 19. I want playable games that everyone can play together, but settling for playing mainstream games using OCR, memorizing menu positions, and other assorted workarounds is unacceptable!
You may access my NVDA Remote, Three-D Velocity, Sound RTS, and Road to Rage servers by using the address christopherw.me. Road to Rage uses the default 6789 port.
The size alterations are as I said purely commited to bytecode as far as I know, the stub already has everything it needs to. In debug, quite a bit of additional information is exposed such as variable names, file names, line numbers, and code to enhance the profiler.
You can test this by slightly modifying the last line of my python code above
You're now given the encrypted bytecode, or data appended to our executable. Try compiling as both debug and release.
@46, you find that "unacceptable"? Well, deal with it, its the real world. People aren't going to cater to your every whim and desire. We need to start integrating with the sited community -- have you noticed that only you have disagreed with me on that point? We can't even come close to making an FPS that even matches quake 3, let alone Mortal Kombat! Like I said, AHC tried and failed. Whether you find it unacceptable or acceptable is irrelevant. You'll just have to either suck it up and deal with it or stop gaming, because this attitude of yours (and probably others') of "Oh, let's stay isolated, we'll be fine" is going to result in most likely the complete destruction of this entire community because all the sited games are a million times better than anything we could ever make.
Update: Lukas, Carter: I cannot reproduce your results. Checking Manamon and a compiled BGT game yielded the same byte count for both (887 KB, 908288 bytes, with offsets 0xddc00 and 0xf9c00). I did, however, discover the following functions when I ran strings (with arguments -d -Tpe-i386) on Manamon. Didn't manage to figure out the different angelscript version though...
Line 6,739 (elias.dll is referenced on line 5,492 as well):
elias elias @f() bool load(const string& in, const string& in) bool start(int, int) bool pause() bool resume() bool set_level(int, int) bool request_change(int) bool silence() bool play_stinger(int) int@ get_keys() bool close() bool get_transitioning() bool get_immediately() void set_immediately(bool) bool get_rendezvous() void set_rendezvous(bool) int get_urgency() void set_urgency(int) int get_stinger() void set_stinger(int) int get_key() void set_key(int) int get_greatest_level() double get_volume() double get_pan() bool get_playing()
I also discovered this, line 7,947:
When opening bgt.exe in strings with the same arguments, that path is:
So, to those who I shrugged off and who I offended (if I did) I apologize. I was blinded by my own confidence and it took Carters help (along with me poking around it with strings) to know my folly. This does raise a few questions though:
1. What is the "STB Update"? Was it intended for others as well, not just VG?
2. Why did VG get this and no one else?
#50 (edited by defender 2019-02-13 17:01:58)
Sorry about my earlier post being all weird, it was a ruff draft I accidentally posted, but I fixed it up LOL.
Anyway, I see the point about us modernizing. We can't stay so insular... And even with the steps forward we make every few years, we're still far behind what we probably should be.
As consoles hopefully start adding more accessibility features, and as mainstream Indi devs keep making audio games more often, we'll need to stay abreast of that if we want to have our own say in how we're represented in those games, or have any chance of competing financially as members of our own market.
That eventuality may be a decade down the line, but it may still be something to keep in mind.
I still think that their is a value in smaller, high replayability, more simplistic titles and that we shouldn't be pushing so hard for every hobbyist to become a trailblazer or assume so much about what beginner coders want, but the visual thing especially is a pretty good point.
So far we haven't had much success with that, but it's mostly the way we go about it. Audio games meant for experienced blind players with low quality visuals tacked on, just as they'll make visual games meant for sighted players with audio and a blindness focus tacked on for us, plus a lack of contacts, organization, or funds for doing visual work.
I think the deficit in coders able to do PR properly or work well in a team is still our main problem, but we should be looking forward regardless, and BGT just isn't that.
Regarding the BGT version thing, I guess I get it because he's not selling it any more, hasn't been for years, and publically closed the project for ever. and maybe he doesn't want to get people thinking he's willing to ramp up full development again by releasing it as a paid upgrade, especially when it has such a bad rep now.
He just did some tinkering is all and didn't fix any major underlying issues as far as I kno, so he probably also doesn't want twenty teens spamming his inbox and creating new threads demanding new features and upgrades.
It's shitty for the handful of people still making good stuff with BGT, but I bet you if they asked him he'd possibly provide it to them, and maybe he already has and they just didn't say anything as to not stir things up.
I'm not personally sure why he even bothered to update it, and he's probably regretting it now, but it was likely just a (why not since I can) sorta deal.
Lets demonstrate this: stand still Thom...