New Editor Source Code Repositories

[Niemand]

As I'm no longer the only one working on the 3D Editor and the SourceForge project is for all practical purposes dead, I have created a pair of new source code repositories on my website.

 

The Macintosh Editor

The Windows Editor

 

They are publicly accessible for browsing via the web and for anonymous, read-only subversion access.

 

This won't yet affect most designers as we're just getting started, but our current primary goal is to bring the Windows editor up to feature and bug fix parity with the Mac editor. This will take some time, so please continue to be patient!

[Ishad Nha]

Now I will need to take out to read the Tortoise manual.

[Celtic Minstrel]

But why are there two separate repositories?

[Niemand]

They could have been a single repository containing two projects, but I personally prefer to keep a single project in each repository. (For one thing this way revision numbers don't jump oddly for one project when the other project has been changed.) Even if both projects were in the same repository their code is still, and for the time being will continue to be, totally disjoint. One day we may be able to merge the projects to properly share code, at which time these repositories will be deprecated in favor of a new unified one.

[Dintiradan]

Originally Posted By: Ishad Nha

Now I will need to take out to read the Tortoise manual.

TortoiseSVN is a great shell extension. Makes the most common SVN task incredibly easy, and you can view the status of files with an icon overlay. The diff that comes with it is my favourite feature; it helps immensely when viewing a file's log, and makes merging conflicted files much easier (you are, of course, on your own with merging binary files, but them's the breaks).

If it's your first time using Subversion (or any version control system), I'd suggest you read the book on it. It's huge, so don't read it all, but the first few chapters give a great overview of version control in general.

Originally Posted By: Celtic Minstrel

But why are there two separate repositories?

Probably because it's the simplest way of doing things right now. Ideally, you'd like to split the code into three packages: Windows-only code, Macintosh-only code, and the common code, which (again, ideally) performs all the logic and delegates resource loading and whatnot appropriately. Then you'd have two 'workspace' projects in svn, one for Windows and one for Macintosh. With the magic of svn externals, each would reference the necessary packages, as well as contain the needed build scripts.

[Kelandon]

By the way, how hard would it be to integrate AScript and Graphic Adjuster into the 3D Editor? People have wanted an integrated design program for some time, and that would be one way to make it.

[Niemand]

I have thought a lot about creating a BoA IDE, and while you're right that those are the features that such an IDE should have, they can't very well be put together like blocks. The 3D Editor is old and crufty, with unsuitable limitations like only being able to manipulate a single town at a time. Graphic Adjuster is mostly built of code that needs to be thrown away; I hacked together whatever I could to get it to work, so there's virtually nothing there that could or should be reused. AScript has code that's good enough to reuse, but is written in a different language than the other two, and what's worse is built on a totally different set of (Mac OS only) libraries.

 

A number of the projects or sub-projects that I'm working on or thinking about are with an eye toward reuse in such an IDE. I've done some work separating the useful, reusable bits of Graphic Adjuster from the rest, which would support loading, saving and manipulating PICT resources. Building a new file format specification and I/O library would make handling operations like opening multiple zones for concurrent editing and rearranging zones far more natural (The BoAEdRemake team did create a library they named Remembrance which would replace the existing one, but it is enormous, depends heavily on Boost, and as far as I can tell is designed only to support the existing format. Add to that the fact that all the people who created it have wandered away, and I'd rather just start over.) There is a good deal of the code in the 3D Editor which is needed, at least as a template for rebuilding the same features, in particular Isaac's 3D drawing algorithms, and we can move in the right direction by sorting out the code that is currently mixed together in the to separate versions of the Editor.

 

Then there's work whose beginning isn't even in sight. For instance, the graphics layer should be separated out into its own module and rewritten based on something like OpenGL. The dialog display layer is already platform abstracted, but the Mac version at least is very finicky, out-dated, and needs to be replaced.

 

Another problem is that it would be hard to build an IDE that both works well on both platforms and shares very much code between them above the layer of things like the file I/O library and so on. I can imagine how I would sketch out much of it using Objective-C and Cocoa for Mac OS, but that would be completely non-portable and I have no notion how to build something equivalent on Windows. There are various cross platform libraries upon which an IDE might be built, but the alternatives are things like Java (it sucks and we wouldn't be able to reuse a single line of existing code) or wxWidgets (the choice of the BoAEdRemake team, but with which I have no experience). My observation has been that for the same program to work well on multiple platforms, it really needs to make the entire GUI layer wholly specialized for each platform, and in the case of an IDE, once we had ready the supporting modules, nearly all of the work would be in the GUI layer (for instance, this is virtually all there is to AScript; the only portable bits of it are the syntax coloring engine and Alint).

 

Basically what it comes down to is that it could be done, but to do it at all could take years for multiple people, and that's to say nothing of doing it well.

[Kelandon]

Originally Posted By: Niemand

Basically what it comes down to is that it could be done, but to do it at all could take years for multiple people, and that's to say nothing of doing it well.

Right, so, that's why I asked what I asked. Screw doing it right. I'm wondering if it would be possible to put together a crappily-coded, Mac-only program that basically just linked those three programs: place a special rectangle and up comes the town script at that particular state, or find a menu option that says, "Edit custom graphics," and the custom graphics sheet pops up.

It would be painfully clunky, of course, but could it be done?

[Niemand]

Even if you wanted it done wrong it would take a long time. Now, there was a feature I was working on a while back to let the Editor know about the locations of other editors and be able to launch them, so that you could do something like: 'Open town script in text editor', but there was some kind of difficulty I ran into that caused me to give up and scrap it.

[Niemand]

Sigh. I just wanted to make note that repositories are currently down. The data's still there, it's just mysteriously become impossible to access. This may take me a little while to sort out, as, to the best of my knowledge, I didn't even do anything to cause this.

[tridash]

Are there currently any plans to move the editor's graphics rendering over to OpenGL? Would certainly make it easier to get nice zooming / resizing of the view etc. done (or so I'd think). If no one's doing anything I'd be interested having a go at tackling that (though I have no great experience with opengl).

 

Will you be eventually moving the os x version over to cocoa?

[Niemand]

I would love to do those very things, but there are a number of major pieces of work that would need to be done. As you may already know, all of the existing drawing code is a mire of Quickdraw stuff, which would have to be thrown out and built from scratch. Likewise to port the editor's look-and-feel at all faithfully to Cocoa will require a good deal of work. I've been tinkering a bit with this latter, but progress is slow, as the old code does a number of things which are either poor ideas, difficult to replicate with a different library, or both. Lastly, there is the concern that a Cocoa rewrite will break all connection with the Windows version of the editor. On the other hand, this might be no bad thing as it would free maintainers of the Windows side to pursue rebuilding their version with the most appropriate and up-to-date technologies as well. (The original BoAEdRemake team was pursuing a route of using a cross platform graphics library, wxWidgets, but they're all gone by now, and frankly I've never seen such a thing come out looking all that good on any platform, so I'm interested in trying different methods.)

 

As far as OpenGL drawing goes, I had only barely begun researching the necessary techniques, as I have very little experience with OpenGL myself. So, if you want to take a stab at it, I would be very excited to give you all the support I could. As quick remark, I would suggest worrying only about drawing the 2 and 3D terrain views with OpenGL, rather than trying to build the whole UI that way. I think that with a bit of work we can build the other controls and so forth using custom, native Cocoa controls, and do a better job than i've typically seen from wholely custom OpenGL 'pseudo' controls. If of course I've been working on building a new layer of data structures, file I/O, and file formats as described in this thread, but I've been too busy to really get very far into it yet, and a new and extended Avernumscript Interpreter, as described here, which while fun project to work on, is admittedly of very little utility to the editor itself.

[tridash]

I won't be starting on it for a while (exams coming up sadly), but just drawing the terrain views with openGL seems sensible.

 

Are there any features that the views should gain? I can see zooming in/out would be nice, but anything else?

[Niemand]

I can't think of any new features off of the top of my head, but I'll be thinking about it.

[Niemand]

Rejoicing is in order! Through no action on my part, both repositories are once again functioning correctly. (This is in some sense good, since it was also through no action on my part that they broke.)

[tridash]

Good to hear that. I'm still busy with exams currently, but I've been reading through the existing code a bit.

 

Is there a particular direction that the editor's going to go in? You mentioned editing multiple towns a while back, and it would be nice to, for example, separate the town window from the terrains&tools window to make this easier.

[Niemand]

I personally consider the current editor code a dead end. I will continue fixing it when bugs are found and adding features when they can reasonably fit in, but I think that a virtually complete rewrite is really the goal to work towards. However, I'm trying to avoid being hasty about this, thinking and developing pieces before trying to dive head-first into building the editor anew. It's worthwhile to continue putting energy into the already working editor which actually helps designers get work done. However, I don't have any large scale plans for the existing editor, with the possible exception of teaching it to use a new file format.

[Celtic Minstrel]

But wouldn't a new file format be problematic for actually playing the scenarios it makes?

[Niemand]

No, not at all, in the same way that it isn't problematic that no computer can actually run the source code of most programs. One format is used for ease of manipulation, and when desired it is rendered down to another format for final consumption.

[keira]

So the editoor would basically 'compile' senario source code? Sweet.

[King InuYasha]

Originally Posted By: Niemand

I have thought a lot about creating a BoA IDE, and while you're right that those are the features that such an IDE should have, they can't very well be put together like blocks. The 3D Editor is old and crufty, with unsuitable limitations like only being able to manipulate a single town at a time. Graphic Adjuster is mostly built of code that needs to be thrown away; I hacked together whatever I could to get it to work, so there's virtually nothing there that could or should be reused. AScript has code that's good enough to reuse, but is written in a different language than the other two, and what's worse is built on a totally different set of (Mac OS only) libraries.

A number of the projects or sub-projects that I'm working on or thinking about are with an eye toward reuse in such an IDE. I've done some work separating the useful, reusable bits of Graphic Adjuster from the rest, which would support loading, saving and manipulating PICT resources. Building a new file format specification and I/O library would make handling operations like opening multiple zones for concurrent editing and rearranging zones far more natural (The BoAEdRemake team did create a library they named Remembrance which would replace the existing one, but it is enormous, depends heavily on Boost, and as far as I can tell is designed only to support the existing format. Add to that the fact that all the people who created it have wandered away, and I'd rather just start over.) There is a good deal of the code in the 3D Editor which is needed, at least as a template for rebuilding the same features, in particular Isaac's 3D drawing algorithms, and we can move in the right direction by sorting out the code that is currently mixed together in the to separate versions of the Editor.

Then there's work whose beginning isn't even in sight. For instance, the graphics layer should be separated out into its own module and rewritten based on something like OpenGL. The dialog display layer is already platform abstracted, but the Mac version at least is very finicky, out-dated, and needs to be replaced.

Another problem is that it would be hard to build an IDE that both works well on both platforms and shares very much code between them above the layer of things like the file I/O library and so on. I can imagine how I would sketch out much of it using Objective-C and Cocoa for Mac OS, but that would be completely non-portable and I have no notion how to build something equivalent on Windows. There are various cross platform libraries upon which an IDE might be built, but the alternatives are things like Java (it sucks and we wouldn't be able to reuse a single line of existing code) or wxWidgets (the choice of the BoAEdRemake team, but with which I have no experience). My observation has been that for the same program to work well on multiple platforms, it really needs to make the entire GUI layer wholly specialized for each platform, and in the case of an IDE, once we had ready the supporting modules, nearly all of the work would be in the GUI layer (for instance, this is virtually all there is to AScript; the only portable bits of it are the syntax coloring engine and Alint).

Basically what it comes down to is that it could be done, but to do it at all could take years for multiple people, and that's to say nothing of doing it well.

You could use Qt, which would use Cocoa on OS X, Win32 on Windows, and the proper stuff on Linux even though it would be written totally in C++. Qt is pretty complete, covering pretty much all levels of code.

What is AScript? Is it AppleScript, AngelScript, or what?

[Niemand]

It would certainly be possible to use Qt, since it has improved greatly in recent releases (it used to lead to second-class applications on Mac OS that existed inside of the X11 application, as I recall). This will of course require thinking more about, as while I've formed an opinion, my conviction is not so great that I won't consider alternatives before starting to code something.

 

AScript is a text editor specifically suited to writing Avernumscript.

[King InuYasha]

Originally Posted By: Niemand

It would certainly be possible to use Qt, since it has improved greatly in recent releases (it used to lead to second-class applications on Mac OS that existed inside of the X11 application, as I recall). This will of course require thinking more about, as while I've formed an opinion, my conviction is not so great that I won't consider alternatives before starting to code something.

AScript is a text editor specifically suited to writing Avernumscript.

Qt requiring X11 on OS X was a long time ago, way back in Qt 3. At Qt 4.5, you can make 64-bit aware Cocoa applications without actually using Cocoa directly or Obj-C/C++. Meaning you could recompile the same source to be 32-bit Cocoa or 64-bit Cocoa applications on OS X, without editing the source at all, if you are careful enough.

Another option that lends itself to native on Windows, Mac OS X, and Linux would be wxWidgets. Unlike Qt, wxWidgets has supported bindings for many languages other than C++. The only problem with wxWidgets is that its more like MFC than a complete abstracting library. MFC does abstract some of it, but not all. This is also true for wxWidgets. So for each platform, little tweaks at lower level code would probably be required. Given that of the three major platforms, only Windows is non-POSIX, it would probably only require two sets of tweaks at lower levels, one for UNIX and one for Windows.