Game Tools Development

Started by
50 comments, last by Frank Taylor 12 years, 8 months ago

Forms feels faster and more similar to the way RAD software has been for the last 15 years..



I'm talking about this part, which (in other words) you say that it feels more stable, faster and similar to what people use.... or at least, this sentence seems this to me. That's what i meant when saying about standard.

"It doesn't matter how slow you go - as long as you don't stop"

"Declare variables, not war"

"There are only 10 types of people: those who understand binary and those who don't"
Advertisement

But, C++/CLI is a whole another sintax compared to pure C++, and it would kind of act like a wrapper, but it will be like a "middle class" that interacts between the C++ code and C# code? am i right?


The syntax is basically the same, they just add a few extra symbols to allow the 'unmanaged' and 'managed' world to be bridged.

For example in C++ you have the pointer syntax Entity * for instances on the unmanaged heap, in C++/CLI this has been extended so that you have Entity ^ which is a pointer/handle to an object on the managed heap. Which you select depends on where the object exists and who needs to use it.

There is a bit of learning involved of course, but it's surprisingly simple and MS have done a good job with the language.

As for WinForms vs WPF that's very much a depends.

Last project I was on, all the GUI tools were WinForm based; this project they are WPF based.

WinForms are fast to throw together, however WPF does allow you to do more (such as skinning) but as to if you need it only you will know.

The only issues I know about regarding D3D and WPF is that WPF can only be used to draw to D3D10 textures, not D3D11. However this is only a problem if you intend to use WPF to render INSIDE your D3D app. I don't know of any issues when it comes to having D3D rendering to a control inside a WPF app, nor would I expect there to be any.

[quote name='Mauricio Cinelli' timestamp='1311613948' post='4840062']
But, C++/CLI is a whole another sintax compared to pure C++, and it would kind of act like a wrapper, but it will be like a "middle class" that interacts between the C++ code and C# code? am i right?


The syntax is basically the same, they just add a few extra symbols to allow the 'unmanaged' and 'managed' world to be bridged.

For example in C++ you have the pointer syntax Entity * for instances on the unmanaged heap, in C++/CLI this has been extended so that you have Entity ^ which is a pointer/handle to an object on the managed heap. Which you select depends on where the object exists and who needs to use it.

There is a bit of learning involved of course, but it's surprisingly simple and MS have done a good job with the language.

As for WinForms vs WPF that's very much a depends.

Last project I was on, all the GUI tools were WinForm based; this project they are WPF based.

WinForms are fast to throw together, however WPF does allow you to do more (such as skinning) but as to if you need it only you will know.

The only issues I know about regarding D3D and WPF is that WPF can only be used to draw to D3D10 textures, not D3D11. However this is only a problem if you intend to use WPF to render INSIDE your D3D app. I don't know of any issues when it comes to having D3D rendering to a control inside a WPF app, nor would I expect there to be any.
[/quote]

The issues that I saw related to D3D were from a earlier version of WPF and C# itself, i think it was 2 or 3, don't remember. So the problem using WPF with D3D in when i try to render using WPF? IF I have a GUI made in WPF that wraps, let's say, a game engine, I should have no problems? ( as long as the function calls are correct between C++ and C#)

Regarding the C++/CLI, I saw the ^ thing earlier and found it interesting though.
"It doesn't matter how slow you go - as long as you don't stop"

"Declare variables, not war"

"There are only 10 types of people: those who understand binary and those who don't"
Try XNA for C# gaming.
Well, XNA is exactly for what you said, to make games. But we're talking about tools development, which is different than game developmen, but essential, specially on big companies.
"It doesn't matter how slow you go - as long as you don't stop"

"Declare variables, not war"

"There are only 10 types of people: those who understand binary and those who don't"
Tools don't have to run within the game.

At one of my former companies we had tools that were written in C# that ran independently. The artist would typically be running the game, usually on a different machine or on a console dev box. Changes would be made to some art asset, and the artist would choose to send those changes to the game, which would then update itself accordingly.

Tools don't have to run within the game.

At one of my former companies we had tools that were written in C# that ran independently. The artist would typically be running the game, usually on a different machine or on a console dev box. Changes would be made to some art asset, and the artist would choose to send those changes to the game, which would then update itself accordingly.


Wow, this looks awesome! and yeah, i know tools usually don't run inside the game...

Content pipeline tools are great.

But a question just popped on my head, regarding some earler answers. Ok, I do the UI in C# or whatever language, and the game engine guy makes the engine in C++, who writes the wrapper, in this case in C++/CLI? Me or the game engine guy?

Thank you for your time and answers so far
"It doesn't matter how slow you go - as long as you don't stop"

"Declare variables, not war"

"There are only 10 types of people: those who understand binary and those who don't"

Tools don't have to run within the game.

At one of my former companies we had tools that were written in C# that ran independently. The artist would typically be running the game, usually on a different machine or on a console dev box. Changes would be made to some art asset, and the artist would choose to send those changes to the game, which would then update itself accordingly.


True, this is ideal for tools like asset editors and such, but when it comes to scene editing I could see it become a real pain to separate the editor from the actual scene view, or am I not considering something?

I gets all your texture budgets!


But a question just popped on my head, regarding some earler answers. Ok, I do the UI in C# or whatever language, and the game engine guy makes the engine in C++, who writes the wrapper, in this case in C++/CLI? Me or the game engine guy?



You're in a restaurant, and you order a salad. Which chef prepares it?


Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


[quote name='Mauricio Cinelli' timestamp='1311631752' post='4840218']
But a question just popped on my head, regarding some earler answers. Ok, I do the UI in C# or whatever language, and the game engine guy makes the engine in C++, who writes the wrapper, in this case in C++/CLI? Me or the game engine guy?



You're in a restaurant, and you order a salad. Which chef prepares it?



[/quote]

I hate metaphors.... anyway, so the game engine guy makes the wrapper(hope so) . Sorry if I don't understand you right....
"It doesn't matter how slow you go - as long as you don't stop"

"Declare variables, not war"

"There are only 10 types of people: those who understand binary and those who don't"

This topic is closed to new replies.

Advertisement