ID:2396981
 
As a few already know, I've been working on a successor to SByIo (which was my input/output library that continued development until I decided to free it into the public domain). There were at least two prior attempts at this and didn't quite make the cut. The first was a webclient oriented library called "InOut Screen Web". How this worked was the fact it relied on HTML5's capabilities to provide input/output support, though it was never fully completed.

Due to the fact it would've been dependent on the webclient; that project is under hiatus. My second attempt some already know was my ImageIO library. Few actually remember this one being based off the concept of using image objects for creating entire HUDs. Unfortunately, I had hit a number of development issues that prevented any successful work on it. This attempt has since then been declared obsolete due to the introduction of vis_contents.

However, not all was lost as this marks my most recent and third attempt at making a successor to SByIo. In order to do that, I decided to scrap ImageIO (though I did transfer some code and even fonts to the new project) and start work on IOdine. Thought it would be clever to name it after an element (and an important nutrient :P) for this next successor. Unlike previous attempts, this one actually leverages the power of vis_contents. I actually attempted the same demo for bitmap font demonstration as ImageIO, but utilizing vis_contents instead. That was a complete success as I was able to get scaling to work properly on entire text using transform instead of having to do it character-by-character.

My goal is to bring back the great things about SByIo in regards to input and output, but in a much more modern fashion as well as being considerably faster. There is no indication of when it will be ready for release yet as I don't give dates, but instead give clues. Plus, there is a very good chance this library will be open sourced on the onset. I plan on pushing this library to greater heights than what was done previously on SByIo.

One thing I plan to do is make it more programmer friendly as a number did find certain releases of SByIo a bit tedious to work with. I will simplify the workload and ensure great performance at the same time. ;)

I might dedicate this thread for keeping track on IOdine's progress. I'll let y'all know when I have updates.
Since I haven't created a hub yet until there is something to show for, I'll go ahead and give a first update of what I've been doing.

Where do I start? Ah yes, I've been working on improving style object design to make it more accessible to anyone who uses the library. For starters, all /atom-based objects now start with a basic style object. One benefit of v512 is the ability to utilize operator overloading. For that reason, style objects are now actually useful by utilizing attributes through the overloaded [] operator.

Here's an example of utilizing a style attribute:
TextObj1.style["filters"] = filter(type="outline", size=2, color="#007F00")


Yes, even filters are now supported as an official style attribute. Style attributes for the most part wraparound known variables with the exception of a few specialized attributes. One good example is the of 'use_pixel_scaling' attribute, which is designed to control the PIXEL_SCALING appearance flag. It was introduced as I have discovered pixel scaling is not suitable for all instances. A few other interesting attributes have been introduced such as the ability to control animation states. These are 'animation_states' and 'current_animation_state'.

That's what I'm going to discuss next. The concept of animation states actually dates back to SByIo when v500 was first introduced and before SPanimScript was designed. Not too long after v500 came to the public eye, I went ahead and decided to work on a system (in fact, I already worked with a prior system that was prerendered) where you can utilize animate in interesting ways. That involved the concept of animation states consisting of stages (which could very well be considered it's own set of frames). How this worked is each state contains multiple stages/frames where the first frame often included the object being animated. Different variables/settings were specified much like you do in animate. In fact, this was basically a wrapper around animate, but in a method akin to being a movie director or scriptwriter. Thanks to conveniences of newer releases, I even added support to utilize JSON files in a special object for providing (so far) one useful utility function.

Here's an example of a JSON file for Demo1 (which is bound to change as I introduce more things):
{
"anim_state_groups":
{
"textobj1_animstates":
{
"anim_state1":
[
{
"color": "#808000",
"time": 5,
"loop": -1
},
{
"color": "#00C000",
"time": 5
}
],
"anim_state2":
[
{
"scale":
{
"x": 1.1,
"y": 1.1
},
"translate":
{
"x": 0.0,
"y": -18.0
},
"time": 10,
"loop": -1
},
{
"scale":
{
"x": 0.9,
"y": 0.9
},
"translate":
{
"x": 0.0,
"y": 18.0
},
"time": 10
}
]
}
}
}


This is the current design when used in a JSON fashion. To make sure you're loading a compatible JSON file, you must currently specify an "anim_state_groups" variable and store whatever groups of animation states you provide. However, this could change as I improve the design. One neat advantage is you don't need another scripting language, but instead use a known standard. In an animation frame/stage, you can specify variables normally compatible with animate. However, you also gain the benefit of newer ones that wraparound the functionality such as 'translate' and 'scale'. You can actually use both to modify the transform in a single frame/stage.

Once you have animation states setup, you can change the "current_animation_state" attribute for any /atom-based object. When the default style handler is used for the style object found in /atom-based objects, it will automatically animate. This should make it much more convenient to switch in between states.

There are more things I must add, but feel free to provide any constructive feedback. My primary goal is to make it more accessible to DM programmers and create an excellent input/output library similar to what SByIo.