Hello all!

Given the general need for a more robust tool to edit maps, and my previous work on a CHR editor, I would like to start on an editor that edits maps, sprites, tilesets, obstructions, scripts (VC files) etc. However, I would also like to incorporate text definition files for things like syntax and file formats of the sprites, maps, etc. I have a few reasons for this:

1) Support more than Verge, like Sphere and ika formats
2) RPG Engines like Verge update their files every so often, and it would be nice to have a program that you can just update a definition file for to make it the most up to date editor for that engine

Why tell you this? Because I'm RECRUITING! I want able-minded individuals to help me make this a reality. I am looking for help in the following areas:

1) At least two (2) coders other than myself on the project
2) User interface ideas and implementation
3) Definition file ideas and implementation
4) General testing and bug reporting (requires serious dedication to testing nearly every build)

My intent is to use wxWidgets and C++ to implement this. I will not accept anything slower than this (that includes .NET and wxPython). I say this because I want to make the editor work for people with not-so-up-to-date machines. Even on my up to date machine, Maped3 runs slow. I would be happy to entertain suggestions that will make the program's regular usage fast, including using a different windowing toolkit or language. All project members who code for the project will need to have competent knowledge in whatever we decide on. I will not be using platform specific code such as Win32 or DirectX, except with regard to spiffy useful things like file associations in windows. Those languages are pretty difficult anyway. I would be happy to use Python to do the specification files if someone else wants to help implement that. Otherwise the definition files will probably be some form of plain text.

Just to be clear:

It will be impossible to do this project without the help I have asked for. Also this will be a closed source project at least until it is usable and relatively bug free, so if you want to bugtest the program, you WILL have to sign up to use it. I will only accept a certain number of testers and though it will be mostly first come first serve, any non dedicated testers will be dropped for the next applicant.

This is a SERIOUS PROJECT. Please only apply if you are serious about helping at least one hour a week. I would like to make a regular meeting time that most or all of us can agree on, or a messageboard we can all use. Such a messageboard would have email notification.

To apply, post here or email me at tomt64 AT tomt64 DOT com. Please include what you want to help with, and any suggestions you may have regarding the project.

EDIT: If you don't have an avatar yet, being part of this project (not a tester) is almost a sure way to get one. I can't see McGrue not rewarding a successful member of the team that made the most awesome editor for Verge ever.

Well that certainly shows a number of things that the map editor would be able to do after incorporating the Verge 3 format. This does not, however, stop me from wanting to make an editor that includes map, tile, AND sprite and text editing, all in one.

I could help with the coding and planning parts of it. It might take me a bit to get back into programming in C++ (I haven't programmed in that in years) but souldn't be too hard.

I understand your reasons for wanting to stick with C++, and that's cool and all. But humor me for a minute while I invite you to consider .NET again.

.NET got off to a slow and slightly rocky start, but I am telling you that NET is the future. Hell, it apparently seems that even when maped3 was written we didn't really understand all of the awesomeness of .NET/C#, because we clearly are not making use of it enough. But MS is investing heavily in .NET and that will become quite apparent when Longhorn finally comes out.

Now I realize that you are concerned about slower machines, and really, when I talk about Longhorn, we are definitely not talking about slow machines. But the main reason maped3 is slow has nothing to do with NET, its due entirely to the fact that it uses pure software rendering, as opposed to acceleration via DirectX or OpenGL or, later, Avalon.

The advantages of using NET are numerous. Windows.Forms has a few quirks, but overall its a solid framework, and if you dont like it, you can use GTK# instead. Via Mono you can get crossplatformness whether you use GTK# or Winforms.

The project I am spending most of my time these days on is a NET based database app, and one of the huge advantages that I see in my app and that would also factor in greatly in this kind of project is the fact that it's so Damn Easy to do plugins. My database has like everything as a plugin. I make things pluginnable that I don't know why anyone would ever want to plugin, just because it's so easy. In maped3 we don't make nearly enough use of plugins, but the selectable editor tools like floodfill, line, and copy/paste are all a plugin system. No one has really taken advantage of that and thats probably because we haven't really documented that ability or the interfaces that one needs to implement, but the ability to 'plugin' editor components would obviously be pretty handy in an application like this. You can implement your 'multi-engine' system this way too; implement a common Map object architecture, and make import/exporters simply be a matter of writing a plugin.

Now, you can do plugins in C++ as well, obviously. But its less easy and intuitive, and there's another advantage: When you write plugins in NET, the skill required to actually WRITE a plugin is drastically reduced. Anyone who has been able to successfully create something not-completely-trivial in V3 has enough programming talent to make a functional and useful plugin in C#. Your pool of possible viable contributors goes up. You don't have to worry about the plugin causing memory leaks or crashing the editor. It's still possible to leak resources, but at least since C# has actual destructors that are guaranteed to get called, unlike java's finalizers (C# has finalizers too), that makes it a bit easier to make sure you don't leak 'unmanaged' resources.

And you just get the benefit of a much more developer friendly, RAD-friendly, and fault-tolerant language than using C++, not to mention something that will be easier to maintain. And really, when you're looking at a project with a limited number of developers and a limited number of resources, the importance of easy to maintain, easy to modify, easy to debug, code with a powerful language is hard to underestimate.

Well anyway, I'll wrap this up, but let me just suggest what I would do. My database app is setup so that the core logic and architecture and classes are setup in a DLL as a core library. The IDE 'exe' then is really just a bunch of interface code to expose the ability to manipulate and use that base library. The plugin DLLs only have to reference the core library. Aside from having several structural/extensibility advantages, it provides a natural division between logic/data and interface code, which is always a good thing.

So yeah. If you're at all interested I can elaborate. But if you decide to stick with C++ I understand; NET still isn't 100% 'there', but I am telling you, I envision it not being that far off in the future when people bother to write code in C/C++ about as often as we now bother to write code in Assembly. People predicted the same with Java, but java really was sort of an aborted idea, there are many subtle and technical things that make .NET/C# an actual viable 'replacement' for C++ in ways that Java never was, and not the least of which is the backing of MS and the fact that Longhorn will be basically expecting you to write apps for it in managed code.

vecna said: But the main reason maped3 is slow has nothing to do with NET, its due entirely to the fact that it uses pure software rendering, as opposed to acceleration via DirectX or OpenGL or, later, Avalon.

If this is indeed true, that may explain the speed qwirkiness involved in VOpenCHR (to a degree, for some reason there's a random one-time-only freeze on low end machines as it loads the first CHR). I would like a solution that perhaps does not involve OpenGL necessarily, or anything that demands video card support. DirectX is a nice option but is Windows only.

.NET is not bad as a language, I grant you that. I know though that .NET doesn't work fast on low end machines. At least, this is the case using Microsoft's .NET runtimes. Have you had experience using other runtimes? Any benchmarks floating around? I guess .NET would be a good choice if it could run reasonably fast.

No one has really taken advantage of that and thats probably because we haven't really documented that ability or the interfaces that one needs to implement...

Do it, and I can practically promise you some plugins. I'll learn .NET for that for sure.

You can implement your 'multi-engine' system this way too; implement a common Map object architecture, and make import/exporters simply be a matter of writing a plugin.

This was a thought I had, though I was planning to use Python for that particular part if I could manage it.

I envision it not being that far off in the future when people bother to write code in C/C++ about as often as we now bother to write code in Assembly.

No doubt you're right about this, but which language will be the dominant one is only guesswork. In fact maybe no language will be dominant. Microsoft may have invested a lot in .NET, but I think we all know that doesn't mean it's going to dominate for sure. High level languages are the future, though. They certainly will come to prominence more and more as time goes on.

No one seems to be putting the effort into making things work fast anymore, probably due to the fast pace of processor speed increases. However I think this is highly short sighted, especially since it's sloppy and causes problems on even high end machines. There is no direct correlation between sales of new computers and the salaries of developers, so there is no reason not to do this, except for a few things. Companies expect results and don't care if its slow sometimes, as long as it works. Add to that the impossible demands on some developers and you have a recipe for the sloppiness. But this is a complaint that can't be fixed just by talking about it.

Given your suggestions above, I'm likely to go the with the Python/C++ options, or straight Python. I would have no problem using .NET at all if it could possibly run faster on lower end machines, say 500MHz and up. If you can give me some info on this being the case, I would like to see it. I suspect Python will be a little better, probably simply because it is more mature. But I would like to see more speed data and perhaps interfaces with crossplatform software/hardware rendering.

Also, janus, what would you recommend instead of wx if I use Python?

What if it were only used to define the loading and saving of files?

Quote:Originally posted by TomT64

Great! Send me an email so we can work out some details.

Uh, me, him or both?