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.
76
Announcements / Re: Another choice.
« on: March 14, 2010, 12:19:31 pm »
OK. I think I understand.
My main principle is that whatever Josh does shouldn't break a single line of GM, not even in odd cases no one uses. So:
"a" should work exactly like GM
"var a" should work exactly like GM
"globalvar a" should work exactly like GM
Everything else should work like "local int, int" because that's how C++ should work.
And the manual/website should go out of its way to point that out, with examples, because it'll be the first Enigma-specific feature a GM user adopts. Whereas the C++ users will get used more easily to the idea that GM is backwards with var.
My main principle is that whatever Josh does shouldn't break a single line of GM, not even in odd cases no one uses. So:
"a" should work exactly like GM
"var a" should work exactly like GM
"globalvar a" should work exactly like GM
Everything else should work like "local int, int" because that's how C++ should work.
And the manual/website should go out of its way to point that out, with examples, because it'll be the first Enigma-specific feature a GM user adopts. Whereas the C++ users will get used more easily to the idea that GM is backwards with var.
77
Announcements / Re: Another choice.
« on: March 14, 2010, 08:51:22 am »
"Game_boy: when you think about "var" as a class rather than simply a keyword, does it seem more logical? Or less?"
*head explodes*
So var and int are like GM objects now? Is that what you mean? And they can have their own variables?
If so, I can see why 'int, var int' makes no sense. But why do int and var being GM objects mean that their scope is in the script only?
I'm confused by the terminology here. I'm not really sure what you mean by 'class', 'keyword', 'type' or what 'local' would be (keyword? class?).
*head explodes*
So var and int are like GM objects now? Is that what you mean? And they can have their own variables?
If so, I can see why 'int, var int' makes no sense. But why do int and var being GM objects mean that their scope is in the script only?
I'm confused by the terminology here. I'm not really sure what you mean by 'class', 'keyword', 'type' or what 'local' would be (keyword? class?).
78
Announcements / Re: Another choice.
« on: March 13, 2010, 03:33:55 pm »
@Josh
I think GM users would expect (certainly I would) anything to be object-scope unless it has var or globalvar in it. So 'int a' being object-scope. 'int a' also changing the scope as well as type would not be expected. I didn't know, before reading these posts, that var was a type itself nor that 'int a' in C/C++ would be local-scope. That's the initial mindset of a GM user.
But then, no one would use 'int' in Enigma if they didn't know what it was for. So as long as it's clear in the manual / wherever they learn that Enigma allows you to use "int" that it also changes scope unless you say local int or whatever, you don't have to be overly concerned.
Basically, anything a GM user could currently write should behave 100% like GM for better or worse. Anything Enigma does extra can behave how you want it to as long as you make it clear in the place where they'll learn you can.
I think GM users would expect (certainly I would) anything to be object-scope unless it has var or globalvar in it. So 'int a' being object-scope. 'int a' also changing the scope as well as type would not be expected. I didn't know, before reading these posts, that var was a type itself nor that 'int a' in C/C++ would be local-scope. That's the initial mindset of a GM user.
But then, no one would use 'int' in Enigma if they didn't know what it was for. So as long as it's clear in the manual / wherever they learn that Enigma allows you to use "int" that it also changes scope unless you say local int or whatever, you don't have to be overly concerned.
Basically, anything a GM user could currently write should behave 100% like GM for better or worse. Anything Enigma does extra can behave how you want it to as long as you make it clear in the place where they'll learn you can.
79
Announcements / Re: Another choice.
« on: March 13, 2010, 06:16:00 am »
I'd prefer "int a" to mean object-local int, and "local int a" to mean script-local. So none of the options on the poll, but if it was there it would be "int, local int". But to make it compatible with GM, "var int" should be a script-local var type. Since "a" is declaring an object-local variable, and by saying "int a" I only want to change its type to integer, not to make it script-local as well.
So:
a (object-local var type)
int a (object-local int type)
local int a (script-local int type)
var a (script-local var type)
Result: compatible with GM, but declaring a type doesn't make it script-local automatically, which I would call unexpected behaviour.
So:
a (object-local var type)
int a (object-local int type)
local int a (script-local int type)
var a (script-local var type)
Result: compatible with GM, but declaring a type doesn't make it script-local automatically, which I would call unexpected behaviour.
80
Announcements / Re: Quick Poll
« on: March 08, 2010, 11:52:20 am »
Just to clarify: the outcome of this poll won't affect games if you don't use that resource?
81
Announcements / Re: Rejoice
« on: February 20, 2010, 07:44:11 am »Quote from: Fede-lasse
Tremendous size? I thought ENIGMA was supposed to make them small, and, in particular, fast, and not fast by GM standards. 0_o
I think he means in testing mode, not when you compile it for release. Actually I think this way is a very good idea, since in GM you could test you game, make a change on one line and test it again in under a minute (whereas that's never been possible in C/C++ for large projects).
So when you need compile speed to be minimal (during testing), it compiles really fast and you don't need to care about size or performance since you're only testing a tiny fraction of gameplay.
And when it compiles for real you get almost the speed of actual C/C++, with a long compile time (but that only needs to be done once) and small executable size.
Is that what you meant Josh?
82
Announcements / Re: Domain Name Provider Transfer
« on: February 12, 2010, 03:04:53 pm »
No. Eight is probably good, I was thinking you'd go too high. I'm not sure about relative features/performance, I'm only thinking about userbase considerations with that.
Since you're trying to support at least everything that GM does, DX8 may be preferable.
Since you're trying to support at least everything that GM does, DX8 may be preferable.
83
Announcements / Re: Domain Name Provider Transfer
« on: February 12, 2010, 11:57:06 am »
@Retro
It's AMD's driver. They are working on a fix.
http://www.tomshardware.com/reviews/2d-windows-gdi,2539.html
http://www.tomshardware.com/reviews/2d-windows-gdi,2539-8.html
AMD's response:
* Tom’s Hardware has tripped over a workload area (2D lines, etc.) that we have not optimized yet.
* Until this new benchmark, we have not seen any other applications that are bottlenecked by this path, and hence have not focused on it until now.
* Our initial analysis has shown that we have no hardware limitations in this area.
* We now have our driver team engaged to optimize this path and will release a new driver to address this workload as soon as possible.
* We have already found an easy way of increasing our performance greatly, and are now going to try and schedule this in a future Catalyst (need to code in production, validate, ensure it doesn’t break anything else, etc.).
--
@Josh
Definitely use a DX9 backend first, if you plan to use DX at all. The percentage of PCs with both Vista or 7 and a DX10 card isn't that great. The percentage with a DX10.1/11 card and Vista or 7 is almost none, since Nvidia doesn't even have any DX11 cards and only did DX10.1 cards two years after AMD did.
It's AMD's driver. They are working on a fix.
http://www.tomshardware.com/reviews/2d-windows-gdi,2539.html
http://www.tomshardware.com/reviews/2d-windows-gdi,2539-8.html
AMD's response:
* Tom’s Hardware has tripped over a workload area (2D lines, etc.) that we have not optimized yet.
* Until this new benchmark, we have not seen any other applications that are bottlenecked by this path, and hence have not focused on it until now.
* Our initial analysis has shown that we have no hardware limitations in this area.
* We now have our driver team engaged to optimize this path and will release a new driver to address this workload as soon as possible.
* We have already found an easy way of increasing our performance greatly, and are now going to try and schedule this in a future Catalyst (need to code in production, validate, ensure it doesn’t break anything else, etc.).
--
@Josh
Definitely use a DX9 backend first, if you plan to use DX at all. The percentage of PCs with both Vista or 7 and a DX10 card isn't that great. The percentage with a DX10.1/11 card and Vista or 7 is almost none, since Nvidia doesn't even have any DX11 cards and only did DX10.1 cards two years after AMD did.
85
Announcements / Re: Hats
« on: December 23, 2009, 02:36:50 pm »Language implementation is interesting in its own right. Though Luda and I converse of such more than I do with Josh. But there's simply frustration in how inefficient GM is. There's no reason for it to be that way. The type system is too simple to really be called dynamic
I understand why GM can be improved.
What I don't understand is why Josh and anyone else who has helped would spend their time trying to do so, when they are capable C/C++ programmers who could create what they needed without GM. What personal need motivated the project?
86
Announcements / Re: Hats
« on: December 23, 2009, 02:05:24 pm »
I don't think my reason is representative of why most people will use Enigma.
The knowledge the project is open and, even if Softwrap breaks, Yoyo goes away or new OSs break support, it can continue with minor patching is reassuring too.
Can I ask, Josh, why you are making it? I can understand why GM users would want it, but if you can make games in pure C/C++ with all of its advantages why would you spend a few years trying to remake GM?
The knowledge the project is open and, even if Softwrap breaks, Yoyo goes away or new OSs break support, it can continue with minor patching is reassuring too.
Can I ask, Josh, why you are making it? I can understand why GM users would want it, but if you can make games in pure C/C++ with all of its advantages why would you spend a few years trying to remake GM?
87
Announcements / Re: Hats
« on: December 23, 2009, 09:41:59 am »
My problem with Softwrap/GM7 is that I do a few Windows reinstalls per year, on my desktop and laptop. Each time, I have to ask Softwrap to give me new reinstalls. Now, I'm not using it any more than someone who is still on their first reinstall since they bought GM5.3a, but last time they refused to give me any more reinstalls. So I can't reinstall Windows any more, which as you know means that it slows down over time.
I need Enigma to carry on using something I bought. Any speedup, C++ compatibility, build mode or similar bonuses are great, but I just want to continue on using what I paid for. I don't want to pay Yoyo for another GM7 license or a GM8 license because I'm not requesting any more features or parallel usage than my original license represented.
I need Enigma to carry on using something I bought. Any speedup, C++ compatibility, build mode or similar bonuses are great, but I just want to continue on using what I paid for. I don't want to pay Yoyo for another GM7 license or a GM8 license because I'm not requesting any more features or parallel usage than my original license represented.
88
Announcements / Re: R3 isn't dead
« on: December 13, 2009, 03:22:32 pm »
What will be the long-term difference between the two? If Josh's branch is a superset of yours then there won't be a reason to stay there.
If this is a temporary effort to get something useful out there while Josh gets the R4 branch completely perfect, then that's good.
If this is a temporary effort to get something useful out there while Josh gets the R4 branch completely perfect, then that's good.
89
Announcements / Re: Trunkification (svn rearranged)
« on: November 30, 2009, 05:11:43 pm »SVN != Trac.
SVN is versioning. Trac includes bug tracker, etc.
So does the lack of activity on Trac mean lack of activity on LGM?
90
Announcements / Re: Trunkification (svn rearranged)
« on: November 30, 2009, 11:42:44 am »
Are you doing the LGM development in that svn now? There's been no updates to your Trac page in months.