The 2nd dying of AIME

[dschungltiga]

Oh hai Pfhorums!

Well, it has been a while since my last visit here (not that I would give so much to the community, but I mean visiting in general, without login) and Im sure going to be even less active here than I already was. No, dont worry the reason is not because I would think like the community is dying blah blah... nah, I pretty much just lost interest in Marathon. Kind of, at least.

Now, for those asking themselves who I even am, I am the one having tried to finally give the Marathon community a some-kind modern Map editor, called Another Interesting Map Editor. And guess what, I FAILED.

This was before anything like Weland was even thought of (at least I guess), there's no reason to make another Map editor besides it anymore. But with my switch from REALbasic (which AIME was written in before, lol) to Cocoa/C++ (oh god, finally), I tried again.

The result was pretty, uhm, pretty. AIME now sure looked modern, Mac OS X-worthy even. But I again lost interest half way through, and stopped developement in mid-2010, I think. It became unnecessary with the appearance of Weland anyway.

It lacks the ability to save anything, and it won't do much.

Here are some screenshots of how it looks like:

[attachment=4775:Bild_1.png]
This is the main map window, showing all maps in the merged map, kinda like a project window.
I planned to make single map files obsolete, by writing maps directly into the opened/created merged map. By code, this is kind of already put into practice. Every single map is stored as offset position, pointing to where it is stored in the merged file. It is loaded into RAM and constructed only as soon as the user chooses to "edit" (say, double clicks) it. It then stays in RAM (purposely) even if the editor windows is closed, and would have beend freed as soon as the map got saved.

I also planned to list all the resources (title/terminal images/sounds) under the "Resources" entry, allowing an easy add/change/removal of merged map resources.

[attachment=4778:Bild_3.png]
That's the "map inspector", giving you the information you would have set in the "Level Parameters" window in Forge for the currently edited map (that is, the map that is edited in the front-most editor window, or the map you have selected in the front-most "merged map" window) on the fly. The Landscape-thingy doesn't work yet.

[attachment=4776:Bild_2.png] [attachment=4777:Bild_5.png]
That's the map editor window, in draw mode. Note how it says "This text field shows some pretty neat information" without doing so...
There's not really much to say about it, it is what you expect it to be. Oh except for one thing: it has an "undo/redo history", meaning that you can undo and/or redo your actions way back to the first click you made since the editor has opened.

[attachment=4779:Bild_4.png] [attachment=4780:Bild_6.png]
And that's the map editor in "visual" mode. I put that in quote because it isn't really visual.
All the textures are missing (there's no code yet to load Shapes files) and the renderer is based off BSP (Binary Space Partitioning), that's where I lost interest in continueing it. The BSP-thing of course doesn't make sence at all, that's not how Marathon renders it's maps (AFAIK). Thus, polygons might be rendered in wrong order at times; 5D space isn't working either. Collision detection already works, but is in a really early/buggy/untrue-to-the-original-engine stage. In other words: not useful. There is no real physics, as soon as you enter another polygon, you'll be at its floor's height.

The box you see beneath the visual mode view in the first picture is where I planned to put the texture list (just like in Forge) to choose the texture/light source you want to paste onto the walls. That's why there are two scrollers. You are already able to resize it (the horizontal line between both views).

And that is pretty much it.

I also planned to make cross-platform porting as easy as possible. The user interface (windows, buttons, etc) is written in Cocoa (Mac OS X), but the very core (loading maps, drawing lines, filling polygons, etc) is written in C++ (wihout any platform depedencies... well, maybe OpenGL headers...). I was still pretty new to this Cocoa-to-C++-to-Cocoa relationship, which is why things aren't done as well as it could have been.

AIME executable (requires at least Mac OS X 10.3.9, it's Universal but I couldn't test it on an Intel-machine)
And the Source Code

Oh, and to coders trying to decode that mess I've done there:
Prepare to be overrun by glory Engrish comments.
I was quite lazy when spell-checking comments, which actually should have helped you understanding the source code. :/
Im actually not even sure if all the comments are English. There may be some comments still in German.

Greeting to every Marathoner out there!
tiga

EDIT:
Oh great... way to present its death; by providing an older version.
I admit, I should have checked it more well, but I just found out that the version I posted here isn't the newest.

The draw mode was up to 99% done in the newer version. You could actually fill polygons, and intersect lines (even of filled polygons).
But I thinks that's about it.

I have currently no chance of getting the newer version (to make a long story short: my main computer is out of reach ATM) and it might take some time. But I will post the newer version as soon as I get the chance.

EDIT #2:
I fixed the issues this version had. Filling polygons and intersecting lines is now possible again. Also, I found out that undoing a creation of an entity (e.g. drawing a line, filling a polygon) and making this action unredoable, the entities weren't freed from memory. Fixed.

[Switch]

Thank you for open-sourcing your work There are so many projects out there with fantastic code lost to the ages. It takes a lot of guts to put your work out there for others to see, but in the end it benefits everyone. Again, thank you.

[thermoplyae]

r.i.p

[dschungltiga]

You're welcome!

I just found out that the version I posted isn't the newest (I already updated my first post).

Well, I thought it might as well rotten on someone else's hard disk, and maybe will somehow benefit someone.

[treellama]

and intersect lines (even of filled polygons).

Weland can't even do this. Does ZA2 (Zombie A.I.M.E. 2) handle textures and sides correctly when it does this?

[Lawstiker]

Now, for those asking themselves who I even am, I am the one having tried to finally give the Marathon community a some-kind modern Map editor, called Another Interesting Map Editor. And guess what, I FAILED.

Would you happen to still have any of those older versions of AIME originally posted in the older thread?

[dschungltiga]

@Treellama
I guess you're talking about the ability to intersect lines of filled polygons? Well, as far as I remember, handling textures wasn't really taken care of. In fact, the reason why intersecting lines and filling polygons isn't possible in this version is because I forgot to implement this whole sides-thing, which I had to do (and did) afterwards. As implementing new objects isn't that simple - objects stored in the map need to be retained and released to make undoing/redoing as simple as possible - I just commented out both whole functions.

Sigh, you make me take a look into the source code again...

I remember to handle sides just like that: copy the source side and give it to the new line.

@Lawstiker
Yes and no. I still have the source, but it too is on my main computer. I really don't know when I get the chance to lay my hands on it again.
But other than that, you really wouldn't want to run the older version. It's abilities are almost as limited as the new version, plus it has a quite decent memory leak, sucking all your computer's RAM until you eventually have to restart your OS.

[dschungltiga]

I uploaded the fixed version, because I couldn't stand my fail of uploading an older version. It's now up-to-date with the newest one.

[Lawstiker]

Yes and no. I still have the source, but it too is on my main computer. I really don't know when I get the chance to lay my hands on it again.
But other than that, you really wouldn't want to run the older version. It's abilities are almost as limited as the new version, plus it has a quite decent memory leak, sucking all your computer's RAM until you eventually have to restart your OS.

Well if you ever get on your main computer and wouldn't mind, I'd like to take a look at that source regardless.

[lpetrich]

As to using BSP's, that's not recommended for the Marathon engine, because it may get confused by 5D space. For the Marathon Map Viewer I wrote long ago, I wrote a portal-based visibility scheme, something like what the Marathon engine itself uses.

I'd included the source code with the app, I think. But here is how it works.

To get from one map polygon to another, one has to go through a portal, and I use these portals for finding which polygons are visible. The portal I start with, however, is the 3D-rendering viewport. I also make the viewpoint's polygon the first visible polygon, and I make it the polygon that I'll be checking on.

For the checked-on polygon, I look for all portals to connected polygons that satisfy:
1: must be outward from the viewpoint
2: must be visible through all the portals all the way back to the viewport portal

If it is visible, then I make its other polygon the next polygon to check on. If I can no longer find a visible portal, I back up to the previous portal and continue checking on it. I cannot back up to the previous polygon from the viewpoint polygon, so when I try to do that, I'm done with this step.

It's a sort of depth-first tree search, and it's possible to go through the same polygon more than once with different search branches.

I now have a set of polygons, each one with a previous polygon, and I sort them so they can be rendered back to front.

[dschungltiga]

I actually remember kind of having made use of the same technique (in the source that is gone now), but I wasn't able to sort them in the correct way. The polygons overlapped most of the time.

[lpetrich]

What sort of overlap problems had you gotten? In my approach, the nearer polygons' surfaces overlapped the farther ones' surfaces, but that was no problem, because I'd render back-to-front or else use z-buffering.

[Nobody1707]

I don't suppose you could send me a link to your map viewer + source? I can't seem to find it anywhere.