Specifications & Features of a New Torque Mapping Tool

#61 Yes, Indeed, help will be appreciated and rewarded. By the way I just updated to Cobind Desktop 0.2 best Distro i've been on yet! I just got my dvd player working, my audio/mp3s working now i'm working on my dev stuff :D.

Edit: Clearification

#62 This has already been mentioned several times in this thread, so I won't belabour the point, but using C# and VB.Net severely reduces the number of people who would be able to help.

#63

Quote:Any help would be gratefully appreciated

just an observation and a comment. I have been following this thread and the other related thread and I believe the direction you are taking and the focus of this project (at it's present time) is going to severely limit the number of people interested in helping out.

#64

Quote:just an observation and a comment. I have been following this thread and the other related thread and I believe the direction you are taking and the focus of this project (at it's present time) is going to severely limit the number of people interested in helping out.

In what way Joe? What do you see as the problem areas and how would you solve them?
I'm getting more and more disillusioned with on-line communities and their general sniping attitude. Everybody is prepared to offer an opinion but no-one will step up to the plate. If we could find people who were prepared to help in whatever form we would adapt to accomodate them. All we seem to be getting is sniping for various reasons. If people want to help by coding in c++, then thats great! If they can offer coding or file format advice that is great too.
What is wrong with trying to create a modern editor that is user friendly and object based? Everytime some-one mentions anything new people always seem to start picking holes in it rather than looking at it as if it was their project. If you can see major problems with a project, offer advice or a possible solution. Imagine you are doing it, how would you address the issue?
It's a shame that because people are always so negative, many projects get killed before they get off the ground because of this attitude.
Programmers are by nature involved in one-upmanship and 'I can do it better' We're like cats, we expect to be right, do what we want when we want, and we hate having to do what we don't want to.

#65 Not beign negative, just posting my observation in the hopes that it might be useful to you. It was not a snipe, it was an observation that I think you may not be seeing because you are too close to the situation.

I posted because I don't want you to throw 5000 hours at something that, in my opinion, and from my perspective, is not going to succeed. I would also suggest that the resistance you see if not resistance to the idea, but resistance to the approach you are taking from people who have a really good idea of the difficulty of what you are attempting to accomplish.

The advice I would offer(as others have offered before) is to use the TGE to do this. You are making a tool for the TGE.. why not use the TGE?

The choice of tools stated to me seems to have made a lot of people walk away from it, and the approach you are taking, to me, makes no sense.

Seems like the priorities are out of order. The choice of language is based on what the developers feel comfortable working with, and not one that will lead to project success. I know that this may not seem like it to you, and I understand why you think the approach you are taking is sound, and it may be, but it is one that will lead to lack of support from others that 'might' be inclined to help.

Problem areas I see are: It is supposed to work in the TGE and be a replacement for the interior system presently in place. So, it is clear to me that to be of any use as and end user tool that can replace or work with the present format, it has to be as optimized as that format. This requires a knowledge of the inner workings of the engine that it appears that the key members of this team do not possess (yet).

Some features wanted my be unfeasible to support in terms of making a format that is compatible with the system. This is a key problem. The present interior formats are consider clunky and 'limiting' because they, by design, limit what a user can do. They do not allow the end user to create geometry the format will not support.

having a feature wishlist is great, but if the implementation of a feature becomes unfeasible due to the format, you will end up discarding whole feature sets because they are ultimately unworkable.

The lack of an approach that will lead to easy cross platform porting means that GarageGames is not going to offer much in the way of support or help.

#66 I think what you are attempting is great. Based on what has been put forth, my personal perscpecitve is that it will go on for a while and you will give up because of the complexity of the project and lack of community support and help.

Since you have chosen a development platform that has pretty much made the heavy hitters walk away, when the going gets tough, you will have a hard time getting people that can answer the hard questions to pitch in.

If you do end up with a working prototype, and it needs to be ported and hard issues solved.. I think you will met with no one willing to pitch in. I can see the request for help. Wanted: programmer experienced in 3d graphics needed to make port of our code to c++. Includes rewriting a bunch of interface code. I fail to see how this would be exciting or appealing to anyone.

If it were me:

I'd start with the TGE and c++. It is obvious to me. You eventually are going to need to know the 'guts' of the TGE and make it work in TGE (and TSE). Bite the bullet, make this decision, and move to the next step.

Next step.. define what the technical issues are. The interior format is like it is for a reason, and that is performance. This is one of the #1 concerns and it should be a cheif focus of the team. If the end product does not offer a suitable replacment for what exists now, no matter how good the interface is, it will end up being a neat toy and not a truely useful application.

Then, ask those that know the 'guts' of the engine their opinion on how to approach it and listen to what they are saying instead of accusing them of sniping. It is far more likley that they will get on -board if they are convinced that the project has a chance of success.

listen to what GarageGames is asking for. They have been listening to the artists since the site opened, and they have some opinions on what they think is needed based on their knowledge of the format and the user requests they have been getting for 3+ years. Taking into account what they are asking for will also lead to support from GarageGames, which may be key to answer key questions for you, make subtle changes to the engine to allow for what you are doing, and rally others to the cause.

After all this is done, start thinking about what sort of features to support and design an appropriate interface. It is key that you get some experienced artists giving input on this, as well as get someone on board who knows what each and every feature means in terms of implementation complexity AND how it will impact performace in the engine.

Again, not trying to be nagative.. a new tool is needed. It will not be easy. If it were easy to make such a tool, we would see far more of them then we presntly do.

Again, I want to see this succeed, and I would hate to see this turn into a waste of time for you. If you continue to accuse me of sniping and fail to heed any of my well intentioned advice, that is your business.

#67 I was asked to come over and check out this thread by someone because I had posted another thread related to this. My posting was this:

Quote:I have been following several threads lately about basically with the same idea "making a one complete tool for Torque". Everyone has their own ideas on what and how it should be. I recently purchased FarCry...and not for the game but to check out the CryEngine Sandbox. This is a nice all in one tool for their engine. It was really easy to start making mods with in a couple of hours. Basically I think alot of people are wanting something like this for Torque... I know I would.
What languages to use, what features to have... that may be a debate for years. One feature I know alot of people would like to see is a new .map program or a direct to .dif other than QUARK. I also noticed a free tool getting alot of work on it... that is Blender. Blender has some of the features that the CryEngine Sandbox has... maybe not as good, but they are there. Blender is multi-platform and work is being done with it for other engines as well. Could modifying Blender be a better start than starting a new tool from scratch? You already have people working on the dts and dif exporting. I have been writting my Torque scripts with the text editor it has in it. Guess my question is:
Would it be possible for Blender to be a real-time game editor offering "What you see is what you PLAY" feedback with the Torque Game Engine?"

original thread.

I have also been researching alot of things and also talking to different people about this. I printed this thread out and took my time reading it. Great ideas and concerns have been posted. I think the one thing that stood out in this post to me the most was Jeff Tunnel's posting on June 20, 2004 14:30 EDT. With all this info I still go back to my original question from my posting and see that it is possible. My questions to you is:
1.)What kind of time frame are you looking to complete this by?
2.) With question one in mind. Would you guys be willing to try to do this with Blender instead of starting from scratch? It has alot of the features you/others are wanting... they just need improving. People are already working on dts and dif exporters for it. It is cross platform. It uses C/C++ and python. It has plugin support. Import/Export of other file formats are being worked on or complete. Currently people are working on intergrating it with other game engine.Over 250,000 community members and it is open source... allows alot more people to be interested in helping out. The main thing is that you wouldn't have to recreate things already made...just improve them and saving time. Just add the things missing or wanting.

I am not trying to be negative toward your project. I just want to see it go in the right direction. If possible with the Blender option, I think it would be good for the Torque and Blender communities. Maybe GG would make it a community project as well. As for me I am going the route of Blender option. Thanks for asking me to check this thread out...it has made my idea even stronger.
-Mark
edit: typos

#68 Blender has been an option in my mind, i'll have to play with it, but just a little bit ago, I was thinking about blender. It sounds awsome, and i've heard lots of praise. Maybe we'll check it out.

#69 Hi there everyone. I'm Dave, the guy who created and is developing SharpGL. It's cool to see that people are considering using it for a project, you know if there's anything you want me to do to it or add to it, just ask. I've just finished school now and have alot more free time. I've not updated SharpGL in a while but am about to start building it again, mainly to make it faster (the parts of it that use GDI are slow).

If you've got any ideas or suggestions for it i'll happily give them a try.

Cheers

Dave

#70 Dave Kerr, if it is at any way feasable, would you like to help us on the project?

Edit: By the way, thats a freaking awsome job you did on it!

#71

Quote:
5. System.Windows.Forms
5.1. Can I use System.Windows.Forms with DotGNU Portable.NET?
Yes, since version 0.5.8 of DotGNU Portable.NET.

An advantage of our implementation of System.Windows.Forms is that we don't try to wrap up third party widget sets like Gtk, Qt, Wine, etc. Instead, we provide a basic drawing layer and then render the controls ourselves. The approach is similar to Java Swing, in that all controls are implemented in pure C#.

This approach should allow us to emulate the Windows visual appearance and behaviour more closely and portably than other approaches because we don't need to work around the quirks in foreign toolkits. Our implementation has been known to run on x86, PPC, and ARM based GNU/Linux systems, as well as MacOS X. See the DotGNU web site for current screenshots.

However, there are likely to be some strange Windows quirks that can only be provided by a Wine-based approach. The Mono project is taking this route, and it is likely that their implementation will eventually work with DotGNU Portable.NET also.

Needless to say, we encourage programmers to write C# code in a portable fashion, avoiding quirky features of particular platforms.

5.2. How is the System.Windows.Forms implementation structured?
The DotGNU Portable.NET Forms implementation is structured into three layers, which are found in the source directories "System.Drawing", "System.Drawing/Toolkit", and "System.Windows.Forms".

System.Drawing
Provides the basic drawing functionality, emulating the Windows GDI layer as faithfully as possible. When drawing to a control, use the definitions in "System.Drawing.Graphics".
System.Drawing/Toolkit
Defines an interface to primitive drawing toolkits. Toolkits provide simple line/text/etc drawing (IToolkitGraphics), plus a simple window mechanism (IToolkitWindow).

There may be multiple toolkits in the system, each providing drawing functionality in a different manner. The current toolkits include "System.Drawing.Xsharp", which wraps around the DotGNU Portable.NET "Xsharp" library; and "System.Drawing.Win32", which wraps up the native Win32 API under Windows.
System.Windows.Forms
Builds upon the primitive drawing and window facilities from "System.Drawing" and "System.Drawing/Toolkit" to implement the various controls, forms, dialogs, etc, that are defined by the Forms API.

The file "pnetlib/System.Windows.Forms/HACKING" in the source code contains more information on developing for our implementation of System.Windows.Forms.

Sure hope it means what I think it means
http://dotgnu.org

#72 Hi again. Sure I'll help on the project, but probably the best thing I can do is anything that needs to be done on SharpGL, just cause I know my way around it very well.

At the moment me and FruitBatInShades are going over the library with a profiler to get it up to a decent speed before I update it any more.

#73 Hi again. Sure I'll help on the project, but probably the best thing I can do is anything that needs to be done on SharpGL, just cause I know my way around it very well.

At the moment me and FruitBatInShades are going over the library with a profiler to get it up to a decent speed before I update it any more.

#74 Sounds like a plan, thats what I wanted you to work on ;)

#75 The major thing I would list as the #1 issue is the fact that as a Torque Game Engine developer, we have to know so many different tools just to get off the ground. The list of tools can reach almost 8.

This is way to many interfaces for us to learn, memorize and use.


This is the #1 issue!

If Torque is to move to the next level, this is something we all should be working to achieve...create a single tool for all phases of the development of a game.

#76 @Brian I agree with you 100%. I was looking at a different angle using blender... but making sure that no code violations it would be as better writing one from scratch in the Torque engine itself. The main thing keeping it with the Torque code is that you would use the same languages as Torque does and have cross platform. As you buy other addons as TSE, you could download it and the editor/interface would recognize it. Also allow your favorite modeling package to plug in.

As for a map program to replace Quark... I know that they are rewriting the engine for Cartography Shop and will have dif exporting. I would think it would be better to make a dif editor in the Torque engine.

So my question is(yes another one): Would it be better to have a map/dif editor built into Torque? Could be good and could have a nice prefab setup as well. No code violations. Click a function button... map editor window pops up...build interior ...and click apply.

#77 Hey guys a question for all coders.
Is it easier todo a standalone editor versus a integrated editor in torque.

#78 I don't know about anyone else, but I'd welcome a setup similar to that of 3D GameStudio.

Currently, a startup developer has too many software packages to gather together before they can even begin - especially if they also purchased a license.

There's the TGE source, a compiler, text editor, QuArK or Hammer/Worldcraft and a modelling package (Blender, MilkShape, 3DStudio Max or Maya).

You may also need Java, Python, various plugins and a 2D image editor (such as Adobe Photoshop, the GIMP or Paint Shop Pro) if they aren't already on your system.

(That's another reason I'm adverse to the idea of requiring .Net software too.)

I'm not saying that every single one of those packages should be rebuilt from scratch. Some sort of IDE that links them all together would be handy though - especially if all the software was available in a single download.

Maybe custom macro or plugin options could be included so that people had a choice of packages they could use. i.e. Blender or MilkShape (or both).

As for why you've had so few volunteers to help with the project, well that's probably because so many are busy with other tasks, don't know enough about programming or are using C++ instead.

#79 Build the standalone editor, then incorperate it into a sinle *.dll file. Then the torque editor can create a window, initialise the dll, pass the window handle. The dll then subclasses the window and uses it as the output for the editor. If the two programs expose enough fairly simple functionality to each other this should not be hard to do.

It would be easier to have the editor standalone though- at least until it's finished.

#80 Did you guys see the GUI's that Lightwave Dave put into his new Show Tool? The Torque GUI library is totally up to the job of creating this editor suite. It is very easy to add new controls in C++, and the editor itself really does work. I have performance proof of this because we are doing it in-house for a project that we cannot talk about.

-Jeff Tunnell GG