Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
It's progress log update time. Work is going on, I've written the specification for the command-line interface, which is subject to change so I'm no revealing it, except this point: it will be incompatible with the one of the original proof of concept posted to this topic, as it will be able to merge as many levels as you like, so the output file name will be specified by a preceding -o, omitting it is an error, and unadorned file names are assumed to be input files (however many of them there are). Also, I dropped the implicit extension rules, as it was actually pretty useless (just tab once you have a partial name big enough to avoid any ambiguity). Users won't have trouble adapting to this, this is more directed to any wrapping program that invokes this tool (this means you cheleball).
Also, for better use, here are some design rules when making sketches: first, the center of the whole critter must be at or at least near the 0,0 point (this is to rotate and place them more easily), if you're not sure at least move the parent until it says it's at position 0,0, which means its upper left corner is at 0,0 (well, more or less, placement is actually more complicated than that, at least if the parent isn't too big this will be good enough). Also, the parent should be named the same way as the Sketch file (without the extension .Sketch, of course), to best avoid namespace collisions (as for when copies of the same critter are added, the mass move feature will append an index); if ever the critter needs to be named "Boss" or whatever else, the rename feature will be able to handle that.
As a treat while you wait, here is another sketch of mine, on bit on the same principle as the other one, except this one rotates in-game. It's pretty complex, so you'd better add it using the proof of concept release earlier (and yes, this sketch respects the design rules posted earlier; I'll release an updated version of TrickyEnemy that respects these rules with the new version of SketchMapMerge).
Enjoy!
I haven't been able to consistently recreate it, but your TrickierEnemy goes through walls occasionally.
Okay, the command-line client is now feature-complete. Now, I've said that I would only release a complete product, including a GUI, with as I promised a preview feature (specific to the GUI version, doesn't make sense for the CLI client), so I'm not officially releasing it. That being said, the merging and transform engine, as well as the CLI-specific code, would benefit from some testing, so I'm making the current CLI version available for the hardy folks who would want to beta test it. Though feature-complete (though if you have suggestions for features that make damn sense, I can still add them, I'll have to add stuff to the engine anyway for the GUI version, if only the preview feature), it is a barely tested beta, though it is otherwise designed to be as user-friendly as it can be (you wouldn't believe the number of errors it catches and the warnings it can give...), the fact it deals gracefully with all kind of weird errors should be tested too. It comes with a ReadMe that only describes the command-line syntax so that you can use it, nothing more, it's not a definitive ReadMe (though consistency between the syntax it describes and what the tool accepts should be checked, too); it also comes with TrickierEnemy.Sketch and an updated TrickyEnemy.Sketch.
Without further ado, here it is: http://perso.orange....erge1.0.0b1.dmg.
@gray-shirt-ninja, on Feb 9 2007, 06:02 AM, said in SketchMapMerge:
Strange... I've put many of them in a closed room and none of them escaped.
I've put one of them in a big room and it keeps disappearing.
OK. I've been using SMM extensively in my area for Project Multisketch, and I'm very impressed with its robustness and usefulness. It's enabled me to do things that I never would have even considered attempting without it. I therefore have little to report in the way of bugs, but I will try anyway.
skmm -i someSketchMap -n 'Something' -n 'Something Else' 'Sprite'
It will apparently attempt to parse 'Something' as an input file. Or at least, that's the error it returns. Also, if you have a bad option in the midst of good -n options, the same thing happens:
skmm -i someSketchMap -n 'Something' 'Sprite' -d -n 'Something Else' 'Sprite'
...will try to parse 'Something Else' as an input file.
Also, I merged my 1.0.1 (converted from 1.0.0 by the editor) map a few times while SMM was still set to use version 1.0.0 (which I kept--turned out that was a good idea). I then realized this, corrected it, and merged the map a few more times.
That's it for bugs--just two. I do, however, have some feature requests.
รขยห It would be very nice to be able to specify a specific offset for multiplied merges (-m). This would make creating repeating elements, like walls composed of complex sprite groups, much easier. An auto-tiling option (vertical, horizontal, or both) would also be amazing, but I don't want to push my luck here.
รขยห I think the output is too verbose and hard to read. For example:
SketchMapMerge version 1.0.0b1 Capable of merging SketchMap files version 1 (and earlier) ล 2007 Pierre "Zacha Pedro" Lebeaupin, all rights reserved
Set to use /Applications/Games/SketchFighter 4000 Alpha/SketchFighter 4000 Alpha.app for the SketchFighter app. Now transforming input file number 1 /Applications/Games/SketchFighter 4000 Alpha/Custom Levels/Project Multi Sketch .SketchMap... Now transforming input file number 2 /Users/ryos/Documents/Sketchfighter/Project Multisketch/Freeway Rotated.SketchMap... Now merging the transformed input file number 2 /Users/ryos/Documents/Sketchfighter/Project Multisketch/Freeway Rotated.SketchMap into the result data... /Applications/Games/SketchFighter 4000 Alpha/Custom Levels/Project Multi Sketch .SketchMap has been successfully filled with the merger of all input files!
...is very hard to parse for salient details. I would suggest something like the following:
Transforming input file 1: Project Multi Sketch .SketchMap . . . . Done. Transforming input file 2: Freeway Rotated.SketchMap . . . . Done. Merging transformed map data . . . . Done. ------------------------------------------------------ Successfully merged Project Multi Sketch .SketchMap with all input files!
Here's what I changed, in a nutshell:
Deleted the copyright and version string; I see no reason to print these out every time as they just clutter things up. That's what -v options are for.
Omitted full pathnames of files for readability. If the user values this information they should be able to specify a verbose flag to get it.
Omitted all unnecessary words from the output.
Provided ongoing progress meters (in the form of dots) for operations. Not a big deal since SMM has been extremely fast for all operations I've done with it.
Added delimiters and separators where appropriate to draw attention to salient details
Added bold formatting (not a big deal, not many commands do it) to highlight the current operation
Squashed the passive voice in the success message.
The result is a much cleaner, briefer, easier to read, and more useful. Please take it for what you will.
รขยห Finally, a flag to specify which input file to use for metadata would be a nice if nonessential touch.
That's all I've got for now. Thanks for listening, and for making such an awesome tool!
This post has been edited by cheleball : 08 March 2007 - 03:36 AM
Thanks for the feedback (I was about to think I would never get any, and that the tool was too perfect ). Anyway, first the bugs:
For both, this is the normal behavior (except it is 'Sprite' which is interpreted as an input file in the second case when I tried, you sure it is actually 'Something Else'?). For the first invocation, there is not even any problem (besides, of course, the lack of any input file), it just reads that it needs to rename 'Something' into "-n", and then finds something that's not an option, so for it it is an input file. As for the second invocation, it sets aside the two words that follow "-d" apart to interpret them as numbers, fails to do so and warns you about that, then goes on with the word after these two consumer words, in other words (no pun intended), 'Sprite'. Here this may not necessarily be the best behavior, but at the same time most of the time when there will be a failure when parsing -d parameters, it will be because the user made a mistake when writing at least on of the two numbers following it, not because there is none, so it makes better sense to skip them anyway.
Strange. Very strange. Next time this happens (if it does), try to check your Terminal history to see what the sequence that would trigger this be. By the way, normally if you trash your 1.0.0 install and replace it by 1.0.1, since the filenames are the same, it should automagically use the new SketchFighter version (if you don't trash 1.0.0, but just move it, it will keep using 1.0.0 and you'll have to set to use 1.0.1 manually, makes best sense I think).
Now, for the feature requests:
Multiplication offset: Excellent idea, I will definitely add it. I just need to find a letter for the option to trigger this (perhaps I'll add some multi-letter options, I can easily add them as the options parser does not assume one-letter options). Tiling, however, is too far from the purpose of this tool.
Verbosity: This output is here only because it's a beta, it's for potential debugging purposes (for instance so that you can know to which file the lower-end debug messages from the merging engine apply, as the merging engine does not have any idea of the file name of the file it is merging so it does not print the file name in its messages), it will be gone in the release version (unless you indeed specify a future -v option). Regardless of any -v option, I won't put any progress indicator, as even when merging SketchMaps weighing 10 MB it was fast enough (yes, I tested that, to check that my code was fast enough), even when taking into account the fact I have a fast Mac. I will indeed take your suggestions into account for any output enabled for -v (I don't really know what that will enable)
Metadata flag: perhaps; not that useful though.
Besides that -v option, I intend to add -w flags that will enable low-level warnings (for now, there are two I can think of: checking that there isn't any name collision between parents in the result, and checking that the same Extra2 value isn't used in two different input files, I'm welcome to any suggestion for other things to warn about). Also, would there be an interest of having the possibility to merge the changes of two files from a base ancestor (to merge in the work of two people who worked independantly on a base map, like the "merge" command, as it happens)? While instead of having text file lines (which are ordered on top of that), I just have a bunch of sprites, it could be done by simply merging the two modified files, then removing from the result the sprites of the ancestor, giving a warning (and adding it in red in the result so that the conflict can be resolved by hand) if a sprite from the ancestor isn't found in the result (because that means both people moved or deleted it).
OK, I can see that the tool does the best it possibly can with malformed input. And yeah, I'm sure what I wrote isn't accurate--that's what I get for reporting bugs at 2AM.
As for the terminal output, I'm not sure if it will help, but I'd left my window open so here it is.
Random update: I was bored yesterday, I was waiting on Linux for a long and complex task scheduling application to complete its application->architecture matching (it's electronics for school, don't worry), and since it didn't even use the second core I could do stuff without slowing it down. So on a whim, I took the SketchMapMerge source code, put some stuff that required Carbon and CoreFoundation under #ifdefs (they are only used for pref saving), and compiled it with GNUStep. It works (well, except for getting stuff from the SketchFighter bundle, as GNUstep and MacOS X have different ideas on bundle anatomy). I know, this is completely useless, but there was basically not much else to do on this comp Notice the plist header:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//GNUstep//DTD plist 0.9//EN" "http://www.gnustep.org/plist-0_9.xml"> <plist version="0.9"> <dict> <key>Creator</key> <string>Zacha Pedro</string> <key>Description</key> <string>A much more terrifying Forest Boss. Can you destroy it?</string> <key>Format version</key> <integer>1</integer>
(remainder removed for brevity)
(by the way, my energy is currently more focused on Rezilla plugins, I'll go back to really working on SketchMapMerge soon)
Heh, that's funny.
I have another suggestion/request, for when you do go back to working on SMM: the ability to specify the color of the merged sprites. This is quite useless for merging levels together, but for creating scripted effects it's pure gold. I have in the past worked around this by using multiple source files with different pre-set colors, but you can't do really subtle things like gradients.
Although, maybe I should lay off the SketchMapMerge a bit, since it's gotten me in trouble. My area of Project Multisketch could easily be described as "The House that SketchMapMerge Built," and at times the framerate suffers from the sheer number of sprites (not to mention the disproportionately large file size) that this tool enables you to quickly pack into an area.
It's occured to me that I should download this, and so I have. Interesting stuff, ZP.
As much as this is going to disappoint you Cheleball, I'm not going to put the possibility to change the color of merged-in sprites. Why? Well, I firmly believe that each tool should have its job, and each job should have its tool. The job of SketchMapMerge is to enable to merge SketchMaps, and while the transorm features it implements (renaming, rotation, etc ) can be useful by themselves, they are there to allow merging to be reasonably useful (as you've all, except Mack of course who was rather busy at the time :p, seen when using the first proof of concept, only having the possibility to merge as-is without any of these options is rather useless). There could be another tool whose job would be to make all kind of transformation on SketchMaps (say, rotate color hue, double all enemies hit points, replace all instance of one sprite with another, allow to extract one sprite which got stuck and can't be selected anymore in the editor, etc ), but I don't think I'll be the one writing it. In fact, the amount of things people could want to do to a SketchMap is perhaps a bit too much for one tool to handle, and perhaps instead one would be better off implementing a tool that could take a SketchMap and expand it into a tabbed-field text document that could then be handled by a spreadsheet to do whatever the user wants, and then put it back into a SketchMap. Hmm that suddenly sounds a familiar concept (see ConText/ ResStore, though it's of course for Nova plug-ins and not SketchMaps)
That's cool, man.
I must admit though that I very rarely see the need to merge two sketchmaps together, but I do very frequently wish for a way to duplicate more than one sprite at once, and this is my greatest use for SMM. It is only natural, then, for me to wish for SketchMapMerge to fill another gaping hole in the editor's feature set: editing properties of multiple sprites at once. But I suppose if it's not to be it's not to be.
Still, I long for the coolness of effects that could be accomplished with a tool that can set the properties of sprites...
Back to work on SMM
After releasing a proper version of Rezilla, and a real version of RLEPlugin, I'm now back to work on SketchMap Merger: the GUI version of SketchMapMerge (and what most of you will know it as). Understand that I'm new to Cocoa, and this is my first time programming a Cocoa GUI (I could have done it in Carbon, interfacing a Carbon GUI with the Cocoa merging engine wouldn't have been a problem, but I'm learning Cocoa with SketchMapMerge and I intend to keep doing so with GUI stuff), so I have to learn at the same time I write the code, but it isn't too bad: after reading the docs a thousand times to make sure I really understand how things work, when I write the code it mostly works the way I expect it to. I have done a first mockup of SketchMap Merger which allows to pick files and specify a rotation, and which can output the merger; it's a bit like the first proof-of concept I posted: it's unbelievably limited, full of ugly code, but it works and now I'm a lot more confident with bindings and target-action. The roadmap from now on is this:
1: implement a crude GUI but which can actually use all features of the merging engine 2: implement the few remaining requested features in the engine, and modify the GUI and CLI clients to allow to use them 3: work on the GUI for it to be actually able to be used by anybody (error checking and reporting, drag and drop, etc ), and once done send it for beta testing 4: Fix the bugs reported by the testers, and finalise the app by doing some extra touches like an icon for the app and for .Sketch files, manual, etc 5: release! 6: fix reported bugs 7: release an update 8: goto 6 9: ??? 10: PROFIT!
It's progress log update time
I am proud to report that I reached stage 1. That is, I now have a complete GUI, quite crude but which allows access to all the features of the merging engine and perhaps even others: (note for those of you who may be worried: the end product will make sure not to take up so much vertical place so as to be usable on 800*600 screens, if necessary)
This took some deal of time as I had to discover some things the hard way ("What do you mean I can't set a checkbox to mixed state, even automatically, unless I enable mixed state mode which causes the checkbox to go in mixed state if clicked when it is off?! Argh!" and "How the heck does a NSTableView work?!" and "But what the heck is going on with this binding?!"), and I had to redesign the internal data structures (designed at the time of the CLI client) to accomodate the Cocoa GUI framework and bindings. Also, I spent some time on little interesting features, like the fact that once you have picked a file to merge, you can move it all you want on the hard drive and it will still be located when merging is actually done; in fact if you rename it in the Finder the name will change in SketchMap Merger too.
At any rate, this basically works (at least as long as I'm the one using it, it's not user-friendly at all: there is no check that the values are correct, and some inputs can trip the underlying code), so now I can "eat my own dog food": I'm going to work on features of the merging engine, like the warnings and preview, and I'll force myself to access and test these features only through this crude GUI: this will force myself to make it actually usable (in case it isn't usable enough) and will probably uncover some bugs in the GUI. By the time I'm finished implementing the features, the GUI should have improved from the process, and I'll implement access for the features (well, except for preview ) in the CLI client. Then stage 2 will be complete. But right now it's only at the beginning of this stage (the buttons for these new features in the GUI aren't actually connected to anything and thus don't do anything).
Hey, nice! Good work!
A lot of the usability issues are less like usability issues than they are discoverability issues. IOW, people would be hard-pressed to decipher what each feature does without reading the manual. (In the case of SMM, that may be a good thing).
However, most of that can be fixed with some organization, grouping and labeling. The interface is currently somewhat crowded and could use some whitespace to clearly delimit which features are associated with each other.
Tooltips are great too if you've time and inclination.
Might I also suggest a horizontal layout? As in, the columns of options for the two files would be side-by-side. That would solve your vertical space issue and also make a little more sense. You could also save some vertical space by moving the SF locater to a menu item. This is something that is used infrequently enough that it doesn't need to always be visible, nor does it need such prominent placement.
Warning! Spoiler for Hard Start Star Quest (but honestly, who hasn't played it back and forth by now?)
http://perso.orange....reviewTease.png
Neat! Can you zoom the preview (so, for example, you can preview whether a structure you're merging in will match up like you thought it ought)?
Right now, preview is only at the proof-of-concept stage. Currently it only takes a source file and previews it. The plan is to transform both files, but instead of merging the resulting parts, preview the transform of the base file as black and the the transform of the second file as green, in the same window. The preview drawing by itself is quite simple (though I'll have to change the context a bit so that I wrap it in a view instead of drawing once directly in the window), it just draws a rectangle the size of the contact box for each sprite with solidity solid or enemy. That's it. Of course, due to the different coordinate system and complicated placement algorithm of sprites, it still took some time to implement, but there is nothing really fundamentally complex here (drawing a rectangle is just about the most basic operation of a drawing library, though a bit less so for a rotated rectangle).
Well, I'm afraid I'm not going to put zooming and all that. I could draw the same rectangles zoomed, that's not the problem (I maintain a rectangle that surrounds the whole scene, and use it to scale the drawing to fit in the currently 300x300 window, Quartz makes this pretty easy), the problem is implementing the whole UI for zooming, dezooming, scrolling, zooming to a rectangle, etc I'm not sure it would be that useful anyway due to the limited usefulness of such a preview method for finely checking that the structures connect perfectly, might as well open the result with the editor to check that. What I do intend to do however, is allow the preview window to be resized and the preview drawing to scale accordingly. For more detailed checking, you can use the editor, there will always be a point where it will be necessary to use it or I'll end up reimplementing the editor.
I realise I haven't updated this in some time unfortunately, I've just started an internship which makes me work all day, plus 45 minutes of commute, so I only really have time left to work on this in the weekends, and the lack of update is simply that there hasn't been much to report. Anyway, this saturday, after trying to understand how drawing works in Cocoa, how to create windows and subclass views (you can't draw directly in the window, it would be too easy ), after fighting with coordinate systems and bounds and frame rectangles (including getting a behavior opposite of what's documented grr ), after tinkering with modality until it wouldn't crash when closing the window anymore, I am proud to present you this:
Most obviously, the base file is in black, while the addendum is in green. The window wasn't created that big, I scaled it up to that size (notice the resize handle in the corner ), causing the contents to grow bigger themselves. This is enough for approximate placement; for accurate placement, well, I'm afraid there is nothing better than actually merging and checking the result with the editor, as there is no way I could provide the same kind of precision (especially with my blocky colored rectangles), short of reimplementing the editor myself.
Now, on to implementing the warnings. Hurray!
This post has been edited by Zacha Pedro : 07 July 2007 - 05:05 PM
Wow, looking good ZP! I can't let on to understand what half of that means, but considering all the terms I'm not familiar with I gather it's allot of hard work, hehe. The Merger Setup window in most impressive.