I wonder, Beier, why does your compiler enforce to convert code that is already valid galaxy code? For instance, that a += b becomes a = a + b, *= or for loops and similar.
So I wonder, what happend with the last if-else? My compiler settings does not remove unused things, and inline optimization is turned off.
The -= operator seems to be irrelevant as well, since writing += instead there for instance is yielding the same result.
Edit: The issue appears to lie in that local variables fail to be compiled properly in a such way that it is not detected that the variable is used later on in the function. I fixed it temporarily by setting acceleration to a struct member variable instead.
Oh, what? When I create a new project now and test that, it works like it should, but in my older, larger project it doesn't. I'll get back into if I can replicate it later.
I have a suggestion as well. Right now there's one thing that is slightly annoying regarding the autocompleting popup window. How can I force this to show up without having to write anything? There has been a few times where I write something that it doesn't autocomplete at once, which I then want to force a popup to show up, without having to write the next letter. A suggestion could be (for instance like they have in visual studio) to have the autocompletion popup visible if you press ctrl+space (as that now seem to result in writing a space character now anyway).
Indeed, unfortunantly typedefs got broken with this patch.
Take for instance:
typedefpointvector;
Throws the error (in my example file typedeftest):
typedeftest[1, 9]: Found multiple types matching point
typedeftest[1, 9]: Matches primitive point
typedeftest[1, 1]: Matching typedef
This is probably also the underlying reason of why I can't enrich the desired typedef anymore.
Edit: I did also take a look at the documentation regarding namespace nesting. There's a misspell of the word "reference" (it now says "refference"). I also recall this was an error in the editor itself before, but I haven't seen it recently so I guess you already fixed that by now. Anyway, not trying to be a grammar police or anything:P
There's also an issue that you can't "right-click" warnings such as "unused struct: MyStruct", as that activates the error box which says it is unable to open the file. The label stating where the struct is declared seems to not be set properly either, as it says "Library file[1, 8]: Unused struct: MyStruct" when my struct isn't originating from any library.
Well actually, I thought it would be more convenient that you could introduce enums instead of having a struct with the convention of the naming prefixes (for the case I was thinking, encapsulating a block of static variables and use them more like enums.)
Also, I would not say namespaces exists just for the naming prefix - it is more often I find myself writing "using" if I want to use a namespace. But indeed, nested namespaces is something I would like either way (however, in C# as you pointed out above, you don't actually have to nest namespaces that way - what you wrote could be replaced by "namespace Foo.Bar { } "). It does really help organizing the code and make it more modular, more like packages.
Speaking of which, there seems to be a compiler error with namespaces if you exclude using the "using" keyword.
Your code above for instance, does not work properly.
If I try to access Foo.Bar.Derp, it thows the error "Unable to find anything matching Bar.Derp". If I add "using Foo" it will work, with both Foo.Bar.Derp and Bar.Derp.
But that explanation you gave gives a better argument to have nested scopes:P What I meant with my code was:
structFoo{Barbar;}structBar{intderp;}Foofoo;
And then when being accessed, write foo.bar.derp. Though this is only a faked way of what I would want Foo.Bar.Derp to be using statics and nested scopes. And these do differ when processed and compiled.
I never meant that the first code was valid either (since it was what I was requesting as implementation, with a given example), only what I found reasonably fair that the compiler could give in return from it.
I would actually preper nestings, in particular since I want to make a conversion of the galaxy standard library into a neater scope format like in g++. The namespaces in particular or nested struct implementation would have been more desirable there.
As it is now, the implementation of:
struct Foo
{
struct Bar
{
static int Derp = 0;
}
}
Could easily be converted to Foo_Bar_Derp when compiled, instead of:
struct Foo
{
Bar bar;
}
struct Bar
{
static int Derp;
}
Not only does that create less readable code, but also a longer time to write the code, and would be compiled differently (would it not? Assuming we talk about no level of optimization right now)?
Would there per chance in the near future be added support for nested namespaces and structs/classes?
(or else, if it already exist, provide documentation of the proper syntax)
Edit:
After the latest patch(es) my project doesn't compile anymore. I know what's causing the issue, but I hope you will correct it as it was before.
This compiled in the past but does now throw the error:
"To refference a static field/property , you must type Foo.Bar" (Also fix that spelling error, it should be reference)
The problem with this is, that now I always have to write the struct name before I access the static variables when I'm inside the struct scope. It shouldn't be required. It makes sense that you need to type the scope name from outside, but not from the inside :p
Edit2:
It would be conveninent if one could copy and paste error messages as text to the clipboard, as one can't do that now.
A pretty frustrating error:
Collapsed sections, (eg if elses, /* */ comments etc.) messes up scrolling and the lines you should write on completely. The marker get positioned awkvard and writes on lines you don't want to write on.
I hope you still have some time available to work on the editor, I have seen no updates in a while.
Oh, and also, what's up with the server? I wasn't able to send an error report through the editor, and the link on the first thread seems invalid now.
That's very interesting, the only one I seem to have had problems with, is Darken (for some reason I got the alpha wrong)
Taken pretty much directly from that thread, here's what I had for mine:
// There are blendstates (blend modes)publicstaticclassBlendStateExtra{publicstaticBlendStateSubtract=newBlendState{ColorSourceBlend=Blend.SourceAlpha,ColorDestinationBlend=Blend.One,ColorBlendFunction=BlendFunction.ReverseSubtract,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.One,AlphaBlendFunction=BlendFunction.ReverseSubtract};publicstaticBlendStateMultiply=newBlendState{ColorSourceBlend=Blend.DestinationColor,ColorDestinationBlend=Blend.InverseSourceAlpha,ColorBlendFunction=BlendFunction.Add,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha};publicstaticBlendStateScreen=newBlendState{ColorSourceBlend=Blend.InverseDestinationColor,ColorDestinationBlend=Blend.InverseSourceAlpha,ColorBlendFunction=BlendFunction.Add,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha};// Darken seems to fail and draw black where it's supposingly transparancy.publicstaticBlendStateDarken=newBlendState{ColorSourceBlend=Blend.One,ColorDestinationBlend=Blend.One,ColorBlendFunction=BlendFunction.Min,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha,};publicstaticBlendStateLighten=newBlendState{ColorSourceBlend=Blend.One,ColorDestinationBlend=Blend.One,ColorBlendFunction=BlendFunction.Max,AlphaSourceBlend=Blend.SourceAlpha,AlphaDestinationBlend=Blend.InverseSourceAlpha};}
As for restarting the map, Mindy (MindWorX) told me that they made it in the sparsile project, but he never told me exactly how. Try to contact him (and I could also let him know to respond in this thread) to find out.
I just have to set GraphicsDevice.RenderState.SourceBlend, GraphicsDevice.RenderState.DestinationBlend and GraphicsDevice.RenderState.BlendFunction to the right stuff.. There are some examples here http://forums.create.msdn.com/forums/p/75039/457237.aspx
It's not that much work.
Haha yeah, I know that article, I've been using it myself. It's still only valid for XNA 4.0. Point was anyway, that in 3.1 you'll have so many more things to set, if you compare the versions. Be prepared that they might not work right from the start though (I had troubles with some of them), but oh well.
Edit: I have a request by the way. It would be very very convenient if you added the option to test the map even though starcraft is already running. There is a restart argument as far as I know, which you can send to the game. As such, it allows you to test the map much faster since reloading will take much lesser time, for the compensation of memory usage.
Ah, I see :) , not that I think using Draw multiply times to compose the dialog or item is going to yield any huge performance difference (since, (depending on mode ofcourse) a draw call is effectivily between a spritebatch draw and a spritebatch end, hence it still is the same amount of draw calls as yours), yours seem very convenient. Oh yeah, though, like you said, the arithmetic is on the gpu, so that is nicer.
Regarding the blendmodes, I looked up the compatibility with xna 3.1. Looks like you'll have to do much more things more manually using the RenderState class, rather than the BlendStates already easily supported for 4.0.
There, the new version seems to work much better :).
Another question, why did you decide to use a custom shader/fx for the dialogs? You would be able to basically do the same thing with solely a SpriteBatch. Or perhaps you're using them both combined?
Sorry if I aquestion you too much :P
I'll report back for other bugs/feedback later, if I come across any, as usual.
Out of curiosity, why did you pick XNA 3.1 over 4.0? You're using .NET 4.0 anyways. As far as I know, XNA 4.0 has much better support when it comes to fonts, for instance.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Yeah, bytes can't be used as indexes. Another easy way to fix it (yet looking stupid) is to add 0 to the expression (eg. array[i + 0])
I wonder, Beier, why does your compiler enforce to convert code that is already valid galaxy code? For instance, that a += b becomes a = a + b, *= or for loops and similar.
There seems to be some new issues which halted my project abit again:>
I'll include what's relevant, if you need more code, I could provide so.
This is my usecase.
There seems to be an error at the compiling, as that transforms to_
So I wonder, what happend with the last if-else? My compiler settings does not remove unused things, and inline optimization is turned off. The -= operator seems to be irrelevant as well, since writing += instead there for instance is yielding the same result.
Edit: The issue appears to lie in that local variables fail to be compiled properly in a such way that it is not detected that the variable is used later on in the function. I fixed it temporarily by setting acceleration to a struct member variable instead.
Oh, what? When I create a new project now and test that, it works like it should, but in my older, larger project it doesn't. I'll get back into if I can replicate it later.
I have a suggestion as well. Right now there's one thing that is slightly annoying regarding the autocompleting popup window. How can I force this to show up without having to write anything? There has been a few times where I write something that it doesn't autocomplete at once, which I then want to force a popup to show up, without having to write the next letter. A suggestion could be (for instance like they have in visual studio) to have the autocompletion popup visible if you press ctrl+space (as that now seem to result in writing a space character now anyway).
Indeed, unfortunantly typedefs got broken with this patch.
Take for instance:
Throws the error (in my example file typedeftest):
typedeftest[1, 9]: Found multiple types matching point typedeftest[1, 9]: Matches primitive point typedeftest[1, 1]: Matching typedef
This is probably also the underlying reason of why I can't enrich the desired typedef anymore.
Edit: I did also take a look at the documentation regarding namespace nesting. There's a misspell of the word "reference" (it now says "refference"). I also recall this was an error in the editor itself before, but I haven't seen it recently so I guess you already fixed that by now. Anyway, not trying to be a grammar police or anything:P
There's also an issue that you can't "right-click" warnings such as "unused struct: MyStruct", as that activates the error box which says it is unable to open the file. The label stating where the struct is declared seems to not be set properly either, as it says "Library file[1, 8]: Unused struct: MyStruct" when my struct isn't originating from any library.
Well actually, I thought it would be more convenient that you could introduce enums instead of having a struct with the convention of the naming prefixes (for the case I was thinking, encapsulating a block of static variables and use them more like enums.)
Also, I would not say namespaces exists just for the naming prefix - it is more often I find myself writing "using" if I want to use a namespace. But indeed, nested namespaces is something I would like either way (however, in C# as you pointed out above, you don't actually have to nest namespaces that way - what you wrote could be replaced by "namespace Foo.Bar { } "). It does really help organizing the code and make it more modular, more like packages.
Speaking of which, there seems to be a compiler error with namespaces if you exclude using the "using" keyword. Your code above for instance, does not work properly.
If I try to access Foo.Bar.Derp, it thows the error "Unable to find anything matching Bar.Derp". If I add "using Foo" it will work, with both Foo.Bar.Derp and Bar.Derp.
Ah, my mistake.
But that explanation you gave gives a better argument to have nested scopes:P What I meant with my code was:
And then when being accessed, write foo.bar.derp. Though this is only a faked way of what I would want Foo.Bar.Derp to be using statics and nested scopes. And these do differ when processed and compiled.
I never meant that the first code was valid either (since it was what I was requesting as implementation, with a given example), only what I found reasonably fair that the compiler could give in return from it.
I would actually preper nestings, in particular since I want to make a conversion of the galaxy standard library into a neater scope format like in g
++
. The namespaces in particular or nested struct implementation would have been more desirable there.As it is now, the implementation of: struct Foo { struct Bar { static int Derp = 0; } }
Could easily be converted to Foo_Bar_Derp when compiled, instead of:
struct Foo { Bar bar; }
struct Bar { static int Derp; }
Not only does that create less readable code, but also a longer time to write the code, and would be compiled differently (would it not? Assuming we talk about no level of optimization right now)?
Would there per chance in the near future be added support for nested namespaces and structs/classes? (or else, if it already exist, provide documentation of the proper syntax)
Edit: After the latest patch(es) my project doesn't compile anymore. I know what's causing the issue, but I hope you will correct it as it was before.
consider the following code:
This compiled in the past but does now throw the error: "To refference a static field/property , you must type Foo.Bar" (Also fix that spelling error, it should be reference) The problem with this is, that now I always have to write the struct name before I access the static variables when I'm inside the struct scope. It shouldn't be required. It makes sense that you need to type the scope name from outside, but not from the inside :p
Edit2: It would be conveninent if one could copy and paste error messages as text to the clipboard, as one can't do that now.
A pretty frustrating error: Collapsed sections, (eg if elses, /* */ comments etc.) messes up scrolling and the lines you should write on completely. The marker get positioned awkvard and writes on lines you don't want to write on.
I hope you still have some time available to work on the editor, I have seen no updates in a while.
Oh, and also, what's up with the server? I wasn't able to send an error report through the editor, and the link on the first thread seems invalid now.
//
MexaThat's very interesting, the only one I seem to have had problems with, is Darken (for some reason I got the alpha wrong)
Taken pretty much directly from that thread, here's what I had for mine:
But unfortunantly it requires XNA 4.0, and also the "Reach"´graphics profile only available there as well. The rest of the blendfunctions (alpha, additive) was already included in XNA 4.0 as static blend states ( http://www.innovativegames.net/blog/blog/2010/07/13/xna-4-0-blend-states/ )
-------
As for restarting the map, Mindy (MindWorX) told me that they made it in the sparsile project, but he never told me exactly how. Try to contact him (and I could also let him know to respond in this thread) to find out.
Haha yeah, I know that article, I've been using it myself. It's still only valid for XNA 4.0. Point was anyway, that in 3.1 you'll have so many more things to set, if you compare the versions. Be prepared that they might not work right from the start though (I had troubles with some of them), but oh well.
Edit: I have a request by the way. It would be very very convenient if you added the option to test the map even though starcraft is already running. There is a restart argument as far as I know, which you can send to the game. As such, it allows you to test the map much faster since reloading will take much lesser time, for the compensation of memory usage.
Ah, I see :) , not that I think using Draw multiply times to compose the dialog or item is going to yield any huge performance difference (since, (depending on mode ofcourse) a draw call is effectivily between a spritebatch draw and a spritebatch end, hence it still is the same amount of draw calls as yours), yours seem very convenient. Oh yeah, though, like you said, the arithmetic is on the gpu, so that is nicer.
Regarding the blendmodes, I looked up the compatibility with xna 3.1. Looks like you'll have to do much more things more manually using the RenderState class, rather than the BlendStates already easily supported for 4.0.
@SBeier: Go
There, the new version seems to work much better :). Another question, why did you decide to use a custom shader/fx for the dialogs? You would be able to basically do the same thing with solely a SpriteBatch. Or perhaps you're using them both combined? Sorry if I aquestion you too much :P
I'll report back for other bugs/feedback later, if I come across any, as usual.
Out of curiosity, why did you pick XNA 3.1 over 4.0? You're using .NET 4.0 anyways. As far as I know, XNA 4.0 has much better support when it comes to fonts, for instance.