For the moment, not much work is being done with Avatar Core. There are two main reasons 1) Busy with my day job (really busy) and 2) I'm not entirely sure where I want to go with the API.
The API is particularly important as JavaScript comes into play. There's two sides of Avatar Core with JavaScript. One side is the ability to provide a JavaScript API for talking with Avatar Core in SWF form (as seen in My Avatar Editor). The other side is being able to port the entire Avatar Core framework to JavaScript allowing for it to be used without the Flash dependency. And really, in general, it is good to have a solid, simple API for working with frameworks like this. The question is, how good is it now, and can it be "down-ported" to a less-capable environment gracefully. At the moment, I'm not sure, which is why I'm going to think about API direction for a bit before movin forward much more with improvements and other fixes, particularly what it means in terms of having a JavaScript implementation.
Showing posts with label compatibility. Show all posts
Showing posts with label compatibility. Show all posts
Friday, May 22, 2009
Thursday, January 29, 2009
Beta 2 Posted [Update 2]
The current transitional beta page has been updated with beta 2 of My Avatar Editor. Changes include (but may not necessarily be limited to):
Update:
As noted by Tommy, the eyebrow rotations in the latest editor beta were off. This was the result of a copy-and-paste typo where I accidentally had the maximum number of possible rotation values set to the number of possible colors ;). This should now be fixed. The new build version is 1.0.1.31t which you can check for in the top right of the File menu. If your number is lower, clear your cache and reload the page.
Update 2:
As reported by Mapi, I've included a known issue that users using IE and Vista might have troubles saving files.
- Fixed lower hair for 8th style (row 3, column 2) on page 6
- Some interface reshuffling (tab reordering)
- Titles over avatar characteristics/options
- Shadow is a semi-transparent solid; this should cause less problems exporting
- Option to remove shadow from export
- Transparent backgrounds for exports show as a checkerboard
- Client-based (as opposed to server-based) save/load
- Binary files saved with the extension .mae
- New XML format (NOT finalized, see this note)
- New randomizer algorithm
- Flash Player 10 required
- and a whole, heck of a lot of code re-writing
- The avatar link will not work
- Users may experience problems saving using Internet Explorer on Windows Vista
Update:
As noted by Tommy, the eyebrow rotations in the latest editor beta were off. This was the result of a copy-and-paste typo where I accidentally had the maximum number of possible rotation values set to the number of possible colors ;). This should now be fixed. The new build version is 1.0.1.31t which you can check for in the top right of the File menu. If your number is lower, clear your cache and reload the page.
Update 2:
As reported by Mapi, I've included a known issue that users using IE and Vista might have troubles saving files.
Tuesday, January 27, 2009
Changes in Avatar XML [Updated]
Its likely the pre-proposed will more or less stick. However, in the code redesign, I'm also re-evaluating how the data in that format is presented. I brought up the xml format values before, and how they should be "readable" in the sense of their data (not the hierarchy format) and decided to go back on that. The idea before was that the values themselves should make sense when editing them by hand. However, in working with those values directly, I've found that the trickery there was more confusing - and maybe that's just my perspective as a developer. But, additionally (also as a developer), it will be much easier to manage that data if how its presented in XML mirrors how its presented in the binary.
Particular cases include:
Update:
I think I've decided to go back on what I've said here. While most of the values will remain unchanged (relating to the format), I think there will continue to be one exception. This exception, however, is a new exception - not one listed above. It's for colors. Instead of an integer ID specifying which number of a pre-defined set of colors is to be used, I figured it would be better, moving forward, that a standard hex color be specified instead. This goes back to extensions and adding more functionality/possibilities than that which is possible for current-day Mii characters. If you're going to eventually allow specifying any color, some random number isn't going to cut it given how colors themselves are represented as numbers (in hex). So, for example, instead of having a favorite color of "10", it would be 0xFFFFFF (or #FFFFFF), meaning white.
Particular cases include:
- eyeY: inverted
- glassesY: inverted
- moleY: inverted
- mouthY: inverted
- mustacheY: inverted
- noseY: inverted
- eyebrowY: inverted, offset by 3 (it's minimum value is 3, unlike the others which are 0)
- mingles: inverted
- eyeType: value converted to order presented in interface
- eyebrowType: value converted to order presented in interface
- hairType: value converted to order presented in interface
- noseType: value converted to order presented in interface
- mouthType: value converted to order presented in interface
Update:
I think I've decided to go back on what I've said here. While most of the values will remain unchanged (relating to the format), I think there will continue to be one exception. This exception, however, is a new exception - not one listed above. It's for colors. Instead of an integer ID specifying which number of a pre-defined set of colors is to be used, I figured it would be better, moving forward, that a standard hex color be specified instead. This goes back to extensions and adding more functionality/possibilities than that which is possible for current-day Mii characters. If you're going to eventually allow specifying any color, some random number isn't going to cut it given how colors themselves are represented as numbers (in hex). So, for example, instead of having a favorite color of "10", it would be 0xFFFFFF (or #FFFFFF), meaning white.
Monday, January 26, 2009
Status Update; Plan Changes
Originally, I had intended on completely overhauling the editor interface for a new and unique look that not only changed what you saw, but how you interacted with the various features of an avatar to change them. Those plans have been dropped. Due to time constraints and the already delayed release, I instead decided to leave the editor much as it is now, as seen in the Transitional Beta.

But interface isn't everything. There is still a lot of work to be done under the hood.
So far, all Big N references have been removed. Additionally, the new Flash Player 10 save and load features have been implemented allowing for the editor to save and load avatar files without requiring an interaction with the server (making it easier to use on your own site or when offline). I have taken some time to do some code refactoring, but it's still very messy.
In fact a lot of what's left is cleaning up the mess. When I first started the editor, focus was put entirely on parsing the Mii character binary files as saved on a Wii remote. Providing a preview was an afterthought (and by far, the hardest and most time consuming portion). Since the preview was built around the Mii file parsing, there really isn't much wiggle-room in terms of extending the editor to do more than what's supported by the Wii. And I can't tell you how many times people have requested to add a hat, or a new hair style, or something else that is not Wii Mii-compatible. In order for the editor to be useful outside of editing Miis, that will need to change. And it is on that which I'm currently working.
Oh, and I haven't done anything new with the XML format I proposed earlier. I guess I'll have to work on that too ;)

But interface isn't everything. There is still a lot of work to be done under the hood.
So far, all Big N references have been removed. Additionally, the new Flash Player 10 save and load features have been implemented allowing for the editor to save and load avatar files without requiring an interaction with the server (making it easier to use on your own site or when offline). I have taken some time to do some code refactoring, but it's still very messy.
In fact a lot of what's left is cleaning up the mess. When I first started the editor, focus was put entirely on parsing the Mii character binary files as saved on a Wii remote. Providing a preview was an afterthought (and by far, the hardest and most time consuming portion). Since the preview was built around the Mii file parsing, there really isn't much wiggle-room in terms of extending the editor to do more than what's supported by the Wii. And I can't tell you how many times people have requested to add a hat, or a new hair style, or something else that is not Wii Mii-compatible. In order for the editor to be useful outside of editing Miis, that will need to change. And it is on that which I'm currently working.
Oh, and I haven't done anything new with the XML format I proposed earlier. I guess I'll have to work on that too ;)
Saturday, July 19, 2008
My Avatar Editor - Transitional Beta
For those of you who haven't already noticed, a transitional beta of My Avatar Editor is now online. This is not what My Avatar Editor will ultimately look like, but its different enough from the Wii's™ Mii™ Channel to get it back on the streets (methinks).

Some of the GUI changes include:
There's no telling when this new version will be released, but it will be a while. I'm currently going through a code review now cleaning things up and taking out the aforementioned hacks where necessary. There will be some other architectural changes that could delay this process not to mention the fact that I still have to figure out how to implement Mii™ compatibility within the new feature sets that are to be added. I might provide more detail on that situation at a later time.
Some of the GUI changes include:
- A change in the color scheme
- A change in the button (and other control) styles
- Characteristic buttons (tabs) have been moved to the bottom of the screen
- All characteristic tabs are represented at the bottom rather than having some in sub-tabs (for example face shapes and facial features now are each given their own tab)
- Arrows for paging through characteristic variations have been moved to the bottom
- There is no longer an avatar URL
- The character shadow is now correctly behind/below the character's feet
- The eyes on Page 4 Col 1 Row 2 were given the missing eyelashes (the icon preview had them but they were not seen when on the avatar)
- Character names should now end when a null character is reached; this prevents new short names possibly revealing characters from long names used before the short name was set
- Fixed mole size range. It was incorrectly going to 15 (steps) when it should have stopped at 8
There's no telling when this new version will be released, but it will be a while. I'm currently going through a code review now cleaning things up and taking out the aforementioned hacks where necessary. There will be some other architectural changes that could delay this process not to mention the fact that I still have to figure out how to implement Mii™ compatibility within the new feature sets that are to be added. I might provide more detail on that situation at a later time.
Labels:
10,
compatibility,
editor,
features,
flash player,
new,
save,
update
Tuesday, June 24, 2008
XML Revision 1
Here is a sample format for a proposal of the new XML format. As a reminder, old XML files will still be valid. The new editor will not be able to produce those files, but it would be able to still read them. The purpose of this new format is to make the XML more structured and readable, and to help provide the flexibility needed for escaping the limitations of the Mii™ character format.
This proposal is not final and suggestions are welcome.
<avatars>
<Avatar>
<code></code>
<id></id>
<name></name>
<author></author>
<client-id></client-id>
<birth-day></birth-day>
<birth-month></birth-month>
<gender></gender>
<mingles></mingles>
<height></height>
<weight></weight>
<Head>
<type></type>
</Head>
<Hair>
<type></type>
<color></color>
<part></part>
</Hair>
<Skin>
<color></color>
</Skin>
<Face>
<type></type>
</Face>
<Eye>
<type></type>
<color></color>
<x></x>
<y></y>
<size></size>
<rotation></rotation>
</Eye>
<Eyebrow>
<type></type>
<color></color>
<x></x>
<y></y>
<size></size>
<rotation></rotation>
</Eyebrow>
<Glasses>
<type></type>
<color></color>
<y></y>
<size></size>
</Glasses>
<Nose>
<type></type>
<y></y>
<size></size>
</Nose>
<Mouth>
<type></type>
<color></color>
<y></y>
<size></size>
</Mouth>
<Mustache>
<type></type>
<color></color>
<y></y>
<size></size>
</Mustache>
<Beard>
<type></type>
<color></color>
</Beard>
<Mole>
<type></type>
<x></x>
<y></y>
<size></size>
</Mole>
<Shirt>
<color></color>
</Shirt>
<Pants>
<color></color>
</Pants>
</Avatar>
</avatars>Each object is separated into its own node with its own set of characteristics that relate to that object. This (mostly) follows the actual programmed representation within the character model of the editor itself. Though, the original format actually fit better because of the abstraction I provided to easily modify any of these properties directly off a single object (this could take some additional effort on the backend to have these sync up).This proposal is not final and suggestions are welcome.
Wednesday, June 4, 2008
Beyond the Mii™
There are some obvious limitations to the Nintendo Mii™ characters. These limitations are all the result of the constraints on how much any one character can be changed. And much of those limitations are a result of (I imagine) the fact that Mii™ characters have to be able to be represented through a very small file.
Mii™ characters themselves are saved as a series of flags and simple numeric values that represent a particular characteristic. Contrary to some popular belief, they are not saved in their entirety as a 3D mesh and collection of textures. To visualize a Mii™ you have to read in a value that corresponds to a trait and build your own version of that trait to display the character.
For example, given a Mii™ binary file, you may find that the hair trait has a value of 12. From that, you would go through your own custom graphics (3D or otherwise), find the 12th variation of that trait, and display it on the screen. The Wii™ has all of these graphics stored locally as 3D. My Avatar Editor (and Mii Editor before it) stores all of its custom graphics in 2D.

Now, a common question is, can I do more with my Mii™ than the Wii™ allows me to? The simple answer is no, you can't. This is because you do not have access to the graphics that the Wii™ has stored on its system. Those are the graphics that define the Mii™ characters and as far as I know, you have complete access to those graphics via the Mii™ channel.
Of course here, on the world wide web, from the comfort of your home and with the capabilities of your desktop (or laptop) computer, those limitations shouldn't be a factor. Instead, the limitations fall on me to create whatever graphics you might want to use with your avatar. Because My Avatar Editor will no longer be confined to the limitations of Mii™ characters, there is more flexibility in what can be done.
What this means is that you should expect more from My Avatar Editor - more editing capabilities and more variations of characteristics, etc. However, these features will come later down the road. And I will want to, of course, maintain Mii™ compatibility when necessary. Making sure that can happen among a slew of new features might be a little difficult. So the first release will probably remain Mii™ only until a suitable solution for new features can be devised.
Mii™ characters themselves are saved as a series of flags and simple numeric values that represent a particular characteristic. Contrary to some popular belief, they are not saved in their entirety as a 3D mesh and collection of textures. To visualize a Mii™ you have to read in a value that corresponds to a trait and build your own version of that trait to display the character.
For example, given a Mii™ binary file, you may find that the hair trait has a value of 12. From that, you would go through your own custom graphics (3D or otherwise), find the 12th variation of that trait, and display it on the screen. The Wii™ has all of these graphics stored locally as 3D. My Avatar Editor (and Mii Editor before it) stores all of its custom graphics in 2D.

Now, a common question is, can I do more with my Mii™ than the Wii™ allows me to? The simple answer is no, you can't. This is because you do not have access to the graphics that the Wii™ has stored on its system. Those are the graphics that define the Mii™ characters and as far as I know, you have complete access to those graphics via the Mii™ channel.
Of course here, on the world wide web, from the comfort of your home and with the capabilities of your desktop (or laptop) computer, those limitations shouldn't be a factor. Instead, the limitations fall on me to create whatever graphics you might want to use with your avatar. Because My Avatar Editor will no longer be confined to the limitations of Mii™ characters, there is more flexibility in what can be done.
What this means is that you should expect more from My Avatar Editor - more editing capabilities and more variations of characteristics, etc. However, these features will come later down the road. And I will want to, of course, maintain Mii™ compatibility when necessary. Making sure that can happen among a slew of new features might be a little difficult. So the first release will probably remain Mii™ only until a suitable solution for new features can be devised.
Subscribe to:
Posts (Atom)