No worries TabloidA,

I want to figure out a way to make this work for you, if I can.

So I did some comparisons to your screenshot, and for some reason the whole program is being scaled up by exactly 1.5x. I'm not sure why. Initially I thought it might be a "Device Pixel Ratio" (DPR) related thing, where the hardware scales all web content by a fixed amount. I've never heard of DPR on a TV before though, usually it's a tablet and smartphone thing, as far as I know.

As I was writing up that above paragraph I realized that you also had a picture of the TV showing the edit-post page from the Scirra website. So I figured, if I can perspective crop that image and scale it up to 1920x1080, then I can compare it to the same edit-post page on my computer, to see if the Scirra website is also getting scaled up. So I did, and it was, by exactly 1.5 again. Since the Scirra website is also getting scaled up by 1.5, whatever is going on doesn't seem to be unique to the theme editor.

Now the weird thing is that I don't think your TV is doing the scaling, because in your screenshot, the vector fonts all look super sharp, and so your computer is sending a legit 1920x1080 display feed to your TV, and it looks like it's your computer that's doing the 1.5x scaling. The fact that the fonts are scaled up, but still rendered at native screen-pixel resolution, seems to indicate that web content is being told to render larger at a software level, rather than the display feed being scaled up as pixel data.

Though I'm not sure if your computer is doing the scaling because there's just a system setting forcing it to, or if it's because the TV is telling the computer it should use a 1.5-DPR when rendering web content. And of course C2 programs are all HTML5-based, so they all count as web content as far as devices that use DPR are concerned.

That said, I'm working on some features in the upcoming version of the theme editor (r3) that may provide a workaround, in case there's no way to change the scaling factor for your setup.

I should have r3 up later today.

Hey TabloidA,

I made a more compact version of the program for you. I meant to finish it and get it to you earlier, but it turned out to be a bit trickier than I expected.

C2 Theme Editor - r3beta Compact (win32)

The program is normally, 1208 x 952, and this compact version is 1208 x 882, which is just about the absolute smallest I can make it before I'd need to redesign the palette system.

Fortunately, from what you described, it sounds like you're monitor might be 1600 x 900, so the 882 height should fit inside the 900 vertical res.

Now the 882 is the inside-size of the program window, and that doesn't count the exterior windows boarder. So, I also added a full-screen mode that should solve the window boarder problem if there is one.

You toggle full-screen with F1, tilda "~", or slash "/".

In addition, because this version is built from the update I haven't released yet, there are some other new features in it as well.

* XML preview now updates in realtime.

* Undo / Redo system added. (200 levels)

* Arrow keys move the swatch selector around the swatches.

* You can now click directly on the preview to select elements to edit.

(Just remember that not all elements are shown in the preview, namely the action and condition boarders when selected, and the deactivated group comment.)

I haven't bug-tested everything fully, which is why I haven't put out the 3rd release yet, so there may be some issues with this compact version I haven't seen. Feel free to let me know if you encounter any weird behavior.

Let me know if it works okay on your computer. Also, what is your monitor resolution, out of curiosity?

Anyway, hope this helps out.

(edit: Oh, also I bundled a bunch of themes I made which you can open as examples. There are also preview images for all of them.)

Thanks for the replies and feedback lemo, Lordshiva1948 , and TabloidA ,

Sorry it took a while to respond, but I wanted to wait until I had time to give more than a superficial reply. I really do appreciate it when anyone takes time to give me any kind of comments or feedback, so thanks again. :)

Lordshiva1948

Looks really good Best one I like is Amiga

Thanks Lordshiva1948. The Amiga series of computers were pretty awesome, it's amazing how far some of it's influences have spread. Digital music composition is certainly one such area, but interestingly, Construct 2 itself actually has some distant tangential connection to the Amiga as well.

There was an Amiga programming system called AMOS, that had a focus on making multimedia programming (like 2D games) much easier than in traditional languages. The creator of AMOS went on to make a spiritual successor of sorts on the early PC in the mid 90s, and some of the design decisions made in that program laid the foundation for an event-based visual programming concept that was refined through several generations of successor software, but which was ultimately best realized (in my opinion at least) by Scirra, in Construct Classic, and later Construct 2.

Very interesting bio by the way. Happy to have you in the C2 community.

TabloidA

I honestly adore this program. And I think the fact that it's built in C2 doubles it's charm!

Awe, thanks TabloidA. :3

If you get a chance to make a theme, or have a suggestion for a type of theme, like an idea or a link to an image or something, feel free to post it here.

Actually I hadn't thought about it until now, but it might be kind of fun to try building a theme based on a suggestion.

Anyway, thanks again. Hope to see you around. :)

lemo

Looks really good, I like how you went into the detail with the slight background textures and animations

I didn't have any plan to make a theme, but maybe I'll spend some time on one later

Hey lemo, thanks for the comments and suggestions. :)

I know my reply is slightly out of chronological order, but if you scroll down I think you'll see why. :)

Feel free to post anything you make here, even if it's just a test theme. I'd love to see anything you come up with.

[quote:5v7ewf9z]For suggestions, maybe you could optimize the preview event sheet to show even more types of elements

Or you could either make the window bigger or just have a scroll bar to show more events

All good suggestions. There are certainly some kinds of color contrast problems that are easier to spot in an actual event sheet than in the preview, so I think you're right, that extending the preview might help with that. Though another thing I'd need to bear in mind if, extending the preview, is how much my particular style of laying out events is representative of what other people would see when using the same theme on their event sheets. Basically I wonder how much personal layout style differs between users, and if the best test ultimately is field testing on the users actual event sheets. Even so, I think you're right, that more layout variants would be useful.

I believe at the moment the only event-sheet elements not pictured in the preview, are the Selection boarders for Conditions and Actions, which I should really add in at some point, and the Inactive Group Comment, which ... I would have to change the preview image to add. The thing is, the preview image is actually a bunch of stacked sprites, one for each individually color-able element. And to make that image set I needed to cut apart the whole thing in Photoshop and mask out the different text types and then create from that a bunch of correctly aligned images to stack together and recreate the little event sheet scene. It's definitely not impossible to change it, but it takes a fair amount of effort.

I actually kind of wonder if I could make a special element-extraction theme that a user could apply to their own event sheet, screenshot it, and then load the screenshot into an extractor program to analyze the screenshot and build a custom preview image set from it, or just apply custom theme colors to it directly. That could be cool, but potentially pretty tricky.

[quote:5v7ewf9z]Would be perfect if you could click anywhere on the preview and be directed to the matching color option

This I think would be a really good addition, as it would make the element picking a lot faster and more intuitive. I've been trying to think of a way to do this, and the main issue is that I basically need a way to make a per-pixel mapping from the preview zone to a related element. I think I might be able to make an image where each color in the image is an ID number for a related element. I could put the image over the preview area, make it invisible, and then pick colors out of it when the user clicks to get the ID of the element to look up. It's just crazy enough to work/make me crazy implementing it. (... but I totally want to try that.) :)

[quote:5v7ewf9z]PS: Maybe you should move this to the Tools/Resources forum

That's a good idea. I'll need to look into that.

[quote:5v7ewf9z]How did you make this neat color picker btw?

Uh oh ... you asked about the color picker ...

I apologize for what is to come ... *Solemn gaze*

:]

The color picker is actually based on an idea I've had for a picker for a while, that I'd always wanted to try out.

So I'll explain it in two parts. The design, and the implementation in C2.

Color Picker - Design

I had a few goals in mind when designing it.

Continuous Hue Strip:

(The top rainbow box is the "hue" picker.)

I wanted a hue picker that lets you scrub side to side over any hue. This desire arose from something that bugs me in a lot of pickers. Usually you have a hue picking strip that goes from Red through the rainbow, back to Red. And this means that you can scroll over any color ... except Red. You can't scroll over Red, because it's split at both ends of the strip. So on my picker, for any hue, there's guaranteed to be a place in the picker where that hue has a margin on either side, so you can always scroll over it in either direction while trying to settle on a specific color.

All Possible Hues Pickable:

I wanted a hue picker that lets you pick every possible hue that a 24bit color monitor can display. (24bit color is the standard 8bits-for-Red, 8bits-for-Green, 8bits-for-Blue system.) For instance, from pure Red to pure Yellow, color values go from ¦ ( 255, 0, 0 ) to ¦ ( 255, 255, 0 ). In this 6th of the color wheel, only the Red value changes, and transitions through 256 values, ranging from 0 to 255. These 256 steps get you 60 degrees around the color wheel, (1/6th of the way).

So going from

¦Red to ¦Yellow

¦Yellow, to ¦Green

¦Green, to ¦Cyan

¦Cyan, to ¦Blue

¦Blue, to ¦Magenta

¦Magenta, to ¦Red

is 6 of those 60 degree spans. (360 degrees around the color wheel). With 6 spans to cover, and 256 steps in each span, that's a 1536 pixel strip. To avoid making a really long color picker strip, I chopped it into the 6 spans mentioned earlier, and since each of those spans can be a 256 pixel strip, with 1 step per pixel, I just stacked them in a square texture that's 256 pixels wide.

Giving me 6 stacked strips that look like this

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

Now you may have noticed that in my actual picker there are more than 6 strips. There are 12 strips. This goes back to the first design goal, that there are no hues in my picker that are split so that you can't scroll over them. So, for every hue at an edge of my 256 pixel texture, I created one more copy of it, but offset by half a strip length (128 steps or pixels) to bring the split edge hue to the center of the picker.

So now in addition to the 6 original strips,

with Red, Yellow, Green etc at the edges,

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

I now have 6 halfway offset strips,

with Red, Yellow, Green etc in the center of each strip,

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

And so I interleaved them together like this:

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

¦...¦...¦

That's also why if you pick a hue in the left or right-most quarter of the picker square, when you come back to it later (i.e. click back on a palette block later) the hue you picked will always be moved up or down a row to the identical hue on a strip where that hue is located more centrally.

Color Picker - Implementation in C2

This is actually a lot easier to explain.

I use a "Canvas" object (created by R0J0hound) for my Hue picker (the rainbow square), because I need to be able to get the color under the mouse pointer when the user clicks in it.

I use a regular Sprite for the Saturation-and-Lightness square, which I'll call the "Shade" square. (This is the square below the Hue picker square) The Sprite texture for the Shade square is actually just Red fading into Gray, Black, and White, in the HSL color space.

When the user clicks in the Hue square, the RGB color under the pointer is captured. I use this color to set the RGB of a color overlay effect on the Shade picker square, altering it's natural Red hue to match the hue picked.

When a user clicks in the Shade picker square I just use the X and Y coord inside the square to determine the Saturation and lightness value being picked. The image is just a visual aid for the user, but isn't directly sampled the way the Hue picker is.

I use a custom color math and utility plugin I made to convert the RGB (from the Hue picker) and the Saturation and Lightness values (from the Shade picker) to the chosen RGB values in the final picked color.

The only other tricky thing is converting those RGB values back into Hue square coordinates and Shade square coordinates. Remember when a user clicks on a color, or enters one in the Hex code box, I need to position the color marks in the picker boxes to indicate the resulting color. The Shade square is actually pretty easy, because the coordinates are just the converted Saturation and Lightness values of the RGB color. The Hue square is harder because I basically have to convert a Hue value ranging from 0 to 1 to a location on that weirdly organized 12 strip hue texture I described in the design section. To do that, I used a variety of math shortcuts in a custom math plugin I made a while back. Basically I split the 0 to 1 range into 12 spans (1 for mid section of each of the 12 stacked color strips) and then lerp() it to the right X coordinate and quantize (snap) it to the right Y coordinate.

... and that's the story of how all the universe's landmasses, assorted festive ceremonies, and the color picker were made. :]

Hey Ruskul, <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

The short answer is that I now always use

instanceProto.onCreate

My reasoning

As I understand it, anything in "instanceProto.onCreate" will get run on a per instance creation basis. and so the creation of instance related stuffs should go there.

If you knew in advance that you'd only ever have one instance of your pluggin (e.g. the Keyboard plugin), in theory you could use the "pluginProto.Instance" instead, ... but ...

If there's only ever going to be one instance, you can still use "instanceProto.onCreate", and it will just get called once for your one instance. So "onCreate" seems to work just fine regardless of the situation.

Also, I have now created single-instance-only plugins using both methods, and they both work, so I use "onCreate" exclusively now. When I say "single-instance-only" I mean things like a math utility library, which you can literally only create a single instance of, again much like the Keyboard plugin.

My modified SDK

Here is a download for my modified version of the plugin SDK, with additional comments and a more graphical style of dividing up the different sections of the runtime and edit files. I'm hoping to make a pluggin creation tutorial using this version of the SDK at some point, but in the meantime you're welcome to use it for pluggin making or just reference if it helps out in either respect.

!fi_plugin_template.zip

JS structure video

This is a really good video that describes why the basic structure OOP in JavaScript looks the way it does, and the philosophy behind JavaScript's prototypal inheritance. It has an awesome side-by-side code and visual diagram approach to explaining everything.

JS Video:

(youtube - 27 min)

The video is also a companion to a website that lets you type JS code and see a visual diagram representation of the inheritance structure as you go, and it uses exactly the same diagram system shown in the videos.

JS real-time diagram Site: http://www.objectplayground.com/

JS online sandbox

And finally, there's an online JS coding environment, that I use for testing functions and code snippets while working on pluggin projects, and it has been indispensable as a JS sandbox.

It's just nice to open a webpage and be instantly able to program anything, and have that code print anything out to a console.

JS sandbox: https://repl.it/languages

Hope that helps out. <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

I just finished an update of my theme editor, and put it up as release-2 . :)

Color Theme Editor for C2 - release 2

Below are a few of the themes I've created with the new version, so far.

Themes

fi_Gallium.xml

When selected:

fi_Hydrogen.xml

fi_Hydrogen_selC2.xml (same, but uses C2 orange color for selection.)

When selected:

When selected: (fi_Hydrogen_selC2.xml version)

fi_SedonaCandyShop.xml

A weird ice cream looking theme, because why not.

When selected:

fi_AmigaWB.xml

Just for fun I tried making a theme based on the classic Amiga Workbench OS colors.

Google images - Amiga Workbench

The original OS used just 4 colors for the UI, Black, White, Orange, and Blue.

The cursor could use 4 of it's own colors as well, usually Black, Red, Tan, and transparent.

I used the cursor Red color as the insert marker.

The version below uses the 4 colors as a base, but has a few shades for differentiation. I tried making the entire theme using only the exact 4 colors, and it's possible, but it's a bit harsh.

(That said, even with the more lax approach to color authenticity taken below, the result isn't exactly a UI design masterpiece.)

When selected:

Release 2 of my Construct 2 color theme editor :)

Updated UI

Added xml import among other features, reorganized the interface, and fixed some bugs.

New themes

Theme base colors with selection colors side-by-side.

Download & info thread

Color Theme Editor for C2 - release 2

Update - Release 2

New features:

* C2 Theme Editor can now open xml theme files directly.

* You can now easily save preview images in both normal-color and selection-color modes.

* There's a preview mode switch button right beside the "Save Preview" button on the top bar.

* All buttons now give tool tips when you hover your mouse over them.

* Hex color code text box now applies it's color the instant it's changed to any valid hex code.

* Interface has been rearranged to group some features for clarity.

* Each group has an icon, Palette, XML, Preview, Reset.

* Icon for taskbar and window title added.

* Bunch of small bugs fixed in color updating, and preview display.

All screenshots and downloads in the first post have been updated.

Downloads

(see first post for latest release)

Updated interface

Across the top you can see the Palette, XML,Preview, and Reset sections.

For more screenshots of the updated UI, see the updated first post.

Themes

Here are some of the themes I've created with it so far.

fi_Gallium.xml

When selected:

fi_Hydrogen.xml

fi_Hydrogen_selC2.xml (same, but uses C2 orange color for selection.)

When selected:

When selected: (fi_Hydrogen_selC2.xml version)

fi_SedonaCandyShop.xml

A weird ice cream looking theme, because why not.

When selected:

fi_AmigaWB.xml

Just for fun I tried making a theme based on the classic Amiga Workbench OS colors.

Google images - Amiga Workbench

The original OS used just 4 colors for the UI, Black, White, Orange, and Blue.

The cursor could use 4 of it's own colors as well, usually Black, Red, Tan, and transparent.

I used the cursor Red color as the insert marker.

The version below uses the 4 colors as a base, but has a few shades for differentiation. I tried making the entire theme using only the exact 4 colors, and it's possible, but it's a bit harsh.

(That said, even with the more lax approach to color authenticity taken below, the result isn't exactly a UI design masterpiece.)

When selected:

Thanks for the reply MadSpy, :)

Yeah, the afterLast() and beforeLast() functions are kind of a shorthand for stuff that can certainly be done with more functions.

One of my main reasons for incorporating them into my plugin, is to make certain expressions a bit easier to understand at a glance.

The afterLast() function especially is pretty straightforward to recreate with built-in text expressions.

I may not have explained the beforeLast() that clearly, but it returns everything before the last slicer string found, rather than just the previous token.

So I think

beforeLast( src , separator )

is not quite the same as

tokenat( src , tokencount( src , separator ) - 2 , separator )

for instance, given

var src = "root/trunk/branch.jpg"

var separator = "/"

beforeLast( src , separator ) // returns "root/trunk"

tokenat( src , tokencount( src , separator ) - 2 , separator ) // returns "trunk"

This is actually the same issue I ran into when trying to create that functionality with the built-in text expressions, and the reason I thought it might be handy to have a beforeLast() in particular. Otherwise you have to either get the index of the last token, (which can be tricky with "find()" if there's another identical token elsewhere), and crop from the start of the src string to it's index; or you have to recombine all but the last token, reinserting the separators back in-between the remaining tokens. Both of those are doable, but they start getting a bit convoluted looking compared to the beforeLast() expression.

I'm working on a text utility plugin, and just wanted to get feedback on some function (C2-expression) names I'm planning to use.

Expressions

beforeLast( source , slicer )

afterLast( source , slicer )

These return the portion of the source string before or after (respectively) the last occurrence of the slicer substring. If slicer is not found, the source is returned unmodified.

I think it might be a little more niche than what usually shows up in generic text libraries, but I'm not sure, so I just wanted to double check on the forums to see if anyone knew if there was a conventional name for this functionality. Or if anyone has a suggestion for a better name.

Examples

afterLast( "root/trunk/branch.jpg" , "/" )

// Slices on: root/trunk / branch.jpg

// Returns: "branch.jpg"

beforeLast( "branch.jpg" , "." )

// Slices on: branch . jpg

// Returns: "branch"

Happy to help.

And yeah the C2 forums and community are pretty awesome. Everyone I've encountered has been really nice and helpful.

I can make a Value/Brightness blend effect shader for you, though it may be a day or two before I can get to it, if that's okay.

Let me know if you need it sooner.

Hey Zathan,

I'm not positive, but I think the blend mode shown in the image is a "Value" (aka Brightness) preserving blend, based on the HSV color space.

I think the Luminosity blend mode in C2 is a "Lightness" preserving blend, based on the HSL color space.

HSL & HSV

HSL and HSV are similar, but ...

In HSL, setting "Lightness" (L) to 100% will turn any color pure White, regardless of what it was to begin with. That's likely why the Luminosity blend didn't recreate the effect you were looking for.

In HSV setting the "Value" (V) to 100% will turn pure Black to pure White and will turn any color to the brightest possible version of that color which preserves the RGB ratios, thus preserving hue.

I've used a lot of image processing tools and in my experience a "Value" based blend is a pretty uncommon thing which is why C2 likely doesn't have one built in. That said, it can definitely be added thanks to C2's extensibility.

Here is an example in which I "Value" blend white rectangles into the same image you provided.

The results appear to be essentially identical.

What's going on

Because the white square has a "Value" of 100%, it turns black to white, and boosts the colored areas such that for every pixel, the largest RGB component is maxed and the other components are scaled up proportionally preserving the original hue.

This makes sense if you think about how it affects black. For black, the RGB values are all the same (0,0,0), so the maximum among them is "0". If you slide the "max" value of 0 up to 100%, and then slide the other values up (also zeros) to maintain the same ratio of RGB amounts, then all the values will now be 100%.

Likewise, for a color like a dark orange ( 50%, 25%, 0% ), setting it's "Value" to 100%, will make it a bright orange. The max among the RGB components is the 50% red. If you slide that 50% up to 100% (maxing it out) we have doubled it, and so to preserve the relative RGB ratios we double the other values as well. So we go from dark orange ( 50%, 25%, 0% ), to bright orange ( 100%, 50%, 0% ), and voila, we've maxed out the brightness ("Value") without changing the RGB ratios.

A side effect of the HSV formula is that colors will never get blown out, or clipped, the way they will if you use an addition-based formula.

Seeing it in HSV color space

Finally, here I've taken your original image and broken it into individual channels in the HSV color space.

H: hue

S: saturation

V: value

As you can see, the "Value" channel has your white square simply pasted directly into the channel data, perfectly overwriting everything it overlaps with the "HSV Value" of white, which is 100%. However, the hue and saturation data from the background image are preserved.

So in summary. I think its "Value" blend.

Thanks Eren,

Feel free to post anything you make with it in this thread if you like.

I also added a link to the dedicated Share your C2 themes thread, in the main post.