Teaser: Map editor screenshot

Post by **Lucifer** » Thu Oct 13, 2005 8:43 pm

Here's another teaser screenshot with the toolbar partially implemented.

Post by **Lucifer** » Thu Oct 13, 2005 11:17 pm

Waa. Decided to rewrite the internal coordinate system, broke everything. Heh. (Actually, I just factored the base widget class, which I needed to do pretty badly)

New screenshot showing a new widget, a panel! (another source tarball if anyone's screwing with it)

Post by **Lucifer** » Fri Oct 14, 2005 4:11 am

Toolbars are neat. This one doesn't work yet (still have to hook up the event handlers), but here you go.

Post by **Lucifer** » Fri Oct 14, 2005 5:59 am

Ok, I am definitely ready to put this thing into cvs. So what's the consensus?

I'm counting one "i don't care", one "why isn't it in cvs yet?", and zero "nos". If y'all decide "no", who wants to join the map editor project when I stick it somewhere (probably sourceforge, since y'all already have accounts there)?

It's now got a toolbar that runs the length of the right-hand part of the window with three tools on it, the tools highlight when you hover over them, and the toggles are right (i.e. if you toggle one while the other is toggled, the one that's already toggled will be turned off). It also shows the armagetronad icon in the window title bar.

I'm happy with the widget API and am ready to turn it loose on programmers-at-large.

To release it for all to use, it still needs a file dialog and an eraser, and a little bit more feedback from the save button (a short animation will suffice). It also needs to be kept updated with changes to the map file format.

Lyx · Post by **Lyx** » Fri Oct 14, 2005 6:34 am

Minor cosmetic issue:
I'd propose to either make the background more bright, or make the grid-background more dark..... as it is now, the overall contrast between the app-background and the grid-background is so strong, that its visually fatiguing.

Besides of that, looks great to me :)

Post by **Lucifer** » Fri Oct 14, 2005 6:39 am

How's this? (wondering if the grid lines are too bright now, but the green ones got submerged by the darker background)

Post by **Lucifer** » Fri Oct 14, 2005 7:30 am

Haha, this might be a dumb question, but I'm at a loss. Probably basic algebra and I'll feel dumb with the answer.

Given a point and a list of line segments, how do I determine which, if any, of the line segments contains that point?

Nevermind, I was right twice, it's both a simple algebra problem and a stupid question.

Jonathan · Post by **Jonathan** » Fri Oct 14, 2005 7:46 am

Edit:

philippeqc · Post by **philippeqc** » Fri Oct 14, 2005 7:49 am

Ownership of a point by a line segments
Determine the shortest distance between said point and the mathematical line of a segment. Find the coordinate on the line that is the closest to the point. If this coordinate is withing the start and end point of the segment AND the distance is smaller than epsilon, then the point should be part of the segment.
There may be better algos out there. This one is a "distance between a line and a point" with home-brewed considerations for segments.

Are you planning to tackle the grid locking behavior that Lyx described?

I really love the icon for the Wall.

-ph

Post by **Lucifer** » Fri Oct 14, 2005 8:51 am

Sorry Jonathan. Now I'd like to see your post again.

I used slope, and the selection algorithm is really, um, picky? It also won't pick certain walls on certain maps.

So much for using slope, anyway. I'll probably need the same algorithm to cut a wall whenever someone (me?) makes that feature.

Of course, if I just made every wall two points, things might get simpler, but who wants to do that?

In other news, I've implemented erasing, but selecting isn't quite working well.

Website · Post by **Z-Man** » Fri Oct 14, 2005 8:54 am

Small feature request: add "category" along with author, name and version.

Where to put it? The only criterion I have to offer is that IF it is supposed to become THE official map editor, it definitely belongs into our CVS. Even if it's not and it's just ONE editor, there is no reason not to put in into AA CVS. I think you should only keep it out if you want to prevent some of the other developers from messing with it

Post by **Lucifer** » Fri Oct 14, 2005 9:20 am

Not shy here. I'll make another module for it in a few minutes.

Figured out how to select walls. Duh. Just check if you're near a known point on the wall (which will be a corner). It doesn't have to be that hard.

So I can erase walls and spawn points now, and I've added category as you asked, z-man. There is one minor feature I keep forgetting to mention, and one bug I haven't been able to fix yet. Spawn points don't actually point in the right directions, but that's ok because you can't set spawn point directions anyway.

Post by **Lucifer** » Fri Oct 14, 2005 10:01 am

Ok, it's in cvs now, module "acme".

Edit: All the stuff is there for a Windows build. You need py2exe and NSIS to make a windows build, then you need to make sure the path to NSIS is correct in setup.py. If you have all that, then you can run setup.py with a commandline option that I have temporarily forgotten (and with the newest version of py2exe, I might add) and when it's done you'll have a self-installer.

(yeah, I usually do all that stuff either right before release or right after first cvs import, whichever I feel like when I do it)

Edit2: To build in Windows, do something like this:

Code: Select all

c:\python24\python setup.py py2exe --bundle 2

Requires the newest version of py2exe because only the newest version supports bundling. It runs in Windows, but won't actually execute without a file dialog (because I used the commandline for that). So make a file dialog and people in Windows can run it.

(in case you're wondering, the only windows-specific code needed is in libacme/paths.py, and I ripped that file from mathguy which already ran in windows. That is probably the only file you'll need to modify to make it work in Mac OS X as well)

Lyx · Post by **Lyx** » Fri Oct 14, 2005 4:45 pm

contrast looks okay to me now - but that brought me to another idea..... maybe make the grid-background dark-grey and the gridlines bright-grey...... and everything else in non-greyscale-colors. That way, it would be easily visible which of the lines are gridlines, and which are real polygons, spawns, etc.

Post by **Tank Program** » Fri Oct 14, 2005 8:45 pm

How about grid colors like that of the actual game grid?