brushfe's Comments

  • C2 turned the dream of creating games into a daily activity. It's changed how I think, what I want to achieve, and brought all those little sketchbook ideas back in school to life. I owe you and the team a great deal! Thanks so much for everything over the last decade. It's incredible that you've managed to make something like programming accessible for us all out here.

  • Ah sorry! I didn't see that! Thank you very much for the flexibility. It's a tough one, I'm definitely on your side from a logic perspective - the 255 system makes no sense - but it's how the tools speak. Hopefully it'll change to normative one day. Anyways, thanks again. Very much appreciated.

  • For sure, that makes total sense from the engineering perspective. The trouble is that most image editing software works in 255, and that's where our initial colour choices are made — regardless of the image's bit depth.

    So from the game designer POV, 245 or whatever 255-based number becomes the value. Translating it back to 100-base is extra work, serious disruption in the workflow, and potentially problematic (imagine forgetting to convert 84 from 255-base to normalized).

    As a game designer, I'm really hoping you can remove translating values at all for the R, G, or B channel value. If the designer's colours are chosen in 255-base, then they should be able to stay that way throughout the design process. Most colour interfaces give you option to use whatever system you prefer (hex, rgb, etc). I think it should be the case here.

    I really do understand your case from the programming principle, but really think it's the wrong principle to base the construct experience on.

  • I totally appreciate how this benefits construct, the code, looks tidier, etc. But it's more work for your users. Photoshop and gimp both work in 255, and that's a huge chunk of the artist community. Now you're asking us those who are building palettes, sprites, etc in one system to keep converting to another every time they bring their work in construct.

    Think about the huge impact this would have on the Replace Colour effect, for example, in a pixel-based game. Applying any kind of colour changing effects requires translation of every value.

    It just seems like this translation from 255 to 100 could either be optional or certainly behind the scenes.

    It's just hard to imagine anyone was troubled by opacity being in percentage and color being in 255. I think the pursuit of internal consistency is making your user experience considerably worse.

  • True, but this is a change that adds work to a workflow for arguably minimal benefit. People aren't designing in 10 bit. Nor are they picking colours to suit their GPUs preferences. This just adds work.

  • 100% agree. This is definitely a decision made outside of an artist's workflow. It should definitely be an option. Mandating makes no sense.

brushfe's avatar

brushfe

Member since 21 Jul, 2013

Twitter
brushfe has 2 followers

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • Enduring Visitor Visited Construct.net 90 days in a row
  • Unrelenting Visitor Visited Construct.net 180 days in a row
  • RTFM Read the fabulous manual
  • x10
    Quick Draw First 5 people to up-vote a new Construct 3 release
  • x3
    Lightning Draw First person to up-vote a new Construct 3 release
  • x2
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

21/44
How to earn trophies