UI Design Help?

123457»

Comments

  • edited May 2016
    Relay won't be able to see the background image since they use the whole screen. Since Relay turns it on, how will they see what the status is currently? To them it will always be off.

    Also, what about the Main screen?
  • my proposition was to change the color of the UI.

    Would it be easy to have all the countours of the boxes and text show in the color of the Alert ?
  • @Capt_Lapadite I LOVE the most recent version you posted!

    Additionally, the Relay and Science will probably need an alternate version, but that's not a total deal-breaker. I'd propose that we use the same "stripe" style except split it and put it at the top and bottom of the display for the main screen.
  • edited May 2016

    my proposition was to change the color of the UI.

    Would it be easy to have all the countours of the boxes and text show in the color of the Alert ?

    What about the boxes & text that's already changed, like Helm and overheated systems, and those with no power?


    Additionally, the Relay and Science will probably need an alternate version, but that's not a total deal-breaker. I'd propose that we use the same "stripe" style except split it and put it at the top and bottom of the display for the main screen.

    Not a deal breaker. Just bringing it up to be aware of it.
  • Currently I still overlay the final GUI with a red or yellow "multiply" making everything red or yellow tinted.

    Only relay has this problem btw, science still has a round radar view.
  • daid said:

    Only relay has this problem btw, science still has a round radar view.

    True, but the radar is offset, it's not on center like the other stations.
  • I'm not sure I like the design in the background idea. I think I'd be happy with just changing the color of the interface from white to yellow or red. More than that just seems distracting. Maybe there can be color bars on the to and bottom of the main screen display.
  • I've also been a fan of Artemis for a long time, but there are a few bugs and usability issues with it that annoy me (a thread for another board), so before I started writing my own, I went looking for an alternative and found EE.

    I love that the game is OSS, and would love to throw in my 2-bits (32-bits? 64?)

    To get my feet wet, and make sure that I could compile everything, I made a quick mod to the Power Management screen so that when you tap/click on the power / coolant sliders, the slider will show the desired setting immediately, and a bar will grow or shrink as the system slowly adjusts the power / coolant level.

    Like This (imgur link).

    I don't know if the Power Management screen is a commonly used one, but I'll submit a pull request -- feel free to decline :-)

    Now that I've had a chance to look around the code, I'd really like to help in any way that I can.

    Quick CV: Self-taught programmer for 20+ years, C/C++/C#/perl/python/lua etc., Gave a talk on Lua and games at XGDC in the early 2000's before it was cool :-), Author of several video game emulators from the early days of emulation (KEM, Retrocade, contracted for a couple of commercial ventures). My day job is writing python, C# and perl code for DevOps/automation type tasks.

    One of the things that I'd love to see with EE is to convert all of the menu/UI code over to LUA so that it will be VERY moddable -- folks like Interesting John or Capt_Lapadite could mod nearly the entire UI without having to recompile (even to the point of creating whole new screens). I've got a few back-of-the-envelope ideas, but I don't want to step on anyone's toes if there are already plans in that direction! Also, I'm well aware that daid is BDFL, and I really admire the work he and his team have done.

    -- pryankster
  • I've also been a fan of Artemis for a long time, but there are a few bugs and usability issues with it that annoy me (a thread for another board), so before I started writing my own, I went looking for an alternative and found EE.

    I love that the game is OSS, and would love to throw in my 2-bits (32-bits? 64?)

    To get my feet wet, and make sure that I could compile everything, I made a quick mod to the Power Management screen so that when you tap/click on the power / coolant sliders, the slider will show the desired setting immediately, and a bar will grow or shrink as the system slowly adjusts the power / coolant level.

    Like This (imgur link).

    I don't know if the Power Management screen is a commonly used one, but I'll submit a pull request -- feel free to decline :-)

    Now that I've had a chance to look around the code, I'd really like to help in any way that I can.

    Quick CV: Self-taught programmer for 20+ years, C/C++/C#/perl/python/lua etc., Gave a talk on Lua and games at XGDC in the early 2000's before it was cool :-), Author of several video game emulators from the early days of emulation (KEM, Retrocade, contracted for a couple of commercial ventures). My day job is writing python, C# and perl code for DevOps/automation type tasks.

    One of the things that I'd love to see with EE is to convert all of the menu/UI code over to LUA so that it will be VERY moddable -- folks like Interesting John or Capt_Lapadite could mod nearly the entire UI without having to recompile (even to the point of creating whole new screens). I've got a few back-of-the-envelope ideas, but I don't want to step on anyone's toes if there are already plans in that direction! Also, I'm well aware that daid is BDFL, and I really admire the work he and his team have done.

    -- pryankster

    I don't know any LUA (yet) but I'm intrigued.
  • Changing the UI over to LUA will be a shitload of work. So there is currently no plan to do this. The basics sound easy, but the devil is in the details. The code is pretty much setup in a way that it quick for me to work with :blush:
    So, if you want to go this route, I think a proof of concept or some design details will be good first. Just to see if the BDFL (me) likes it or not.

    EE is my pet project, so it contains a lot of experiments (which is why it's a bit of mixup of different methods of solving things)

    I do like your changes for the power management screen, feel free to pull request. It's currently not that commonly used. But it would be good to give it some attention.
  • daid said:

    Changing the UI over to LUA will be a shitload of work. So there is currently no plan to do this. The basics sound easy, but the devil is in the details. The code is pretty much setup in a way that it quick for me to work with :blush:
    So, if you want to go this route, I think a proof of concept or some design details will be good first. Just to see if the BDFL (me) likes it or not.

    Cool. I'll try to rough out some stuff this weekend.
    daid said:

    EE is my pet project, so it contains a lot of experiments (which is why it's a bit of mixup of different methods of solving things)

    i certainly understand pet projects... my 'src' directory is full of them... EE is a very cool piece of code, dragons and all :-)
    daid said:

    I do like your changes for the power management screen, feel free to pull request. It's currently not that commonly used. But it would be good to give it some attention.

    Pull request submitted.

    --pryankster
  • i certainly understand pet projects... my 'src' directory is full of them... EE is a very cool piece of code, dragons and all :-)
    For the biggest dragons, look at the ScriptInterface code. Messy mess of templates without any documentation :) After that comes most likely the multiplayer code, which is also a bit of a mess, but works great without much fuss.

    The UI is actually the bit that was completely re-written a year ago or so. As the old code was really giving a ton of problems :-)
  • daid said:

    For the biggest dragons, look at the ScriptInterface code. Messy mess of templates without any documentation :) After that comes most likely the multiplayer code, which is also a bit of a mess, but works great without much fuss.

    The scriptinterface code is actually pretty clever--once I figured out what was going on. Binding to Lua is always a pain and a maintenance nightmare -- I think your solution is a pretty good answer, since C++ doesn't have runtime introspection.

    I haven't really looked at the Multiplayer code much, yet -- it seems to "just work", and that's good enough for me at this juncture!
    daid said:

    The UI is actually the bit that was completely re-written a year ago or so. As the old code was really giving a ton of problems :-)

    The UI code does look like "YAGNI" was applied -- my adding of the don't-show-background helper, for example -- I was surprised that something like that wasn't there, but if you hadn't needed it yet, there was no reason to code it :-)

    I took today to port the code over to VC++ 2015 -- I've tried to love codeblocks, but I just can't do it :-| Most of the code ported over pretty trivailly, there are two main GCC'ims that don't work with VC; the first is Dynamic Allocation. can't do this:
    char buffer[bufsize+1]; fread(&buffer,filename_size,1,f)
    The other one was a doozy, and I had to do a bit of research to figure it out. VC++ won't instantiate template specializations across translation units. So I broke out the specializations into '.hpp' files. It's debatable whether it's strictly a VC++ bug that it doesn't work, or whether it's an extra "feature" in GCC that it DOES work :-)

    All of the visual studio project information is in a separate directory, which reaches-around to the EE and SP git directories to keep the MS pollution to a minimum. I know that you've said in other posts that you're not interested in a VC++ port, so I'm happy to just keep it to myself for now, unless you want me to submit the pull request.

    --pryankster
  • Note, that I included the code::blocks project for my own convenience. The proper way to compile the source is with CMake. And then you can pretty much use any IDE you want.
    I wouldn't mind simple patches for VC++ compatibility, but know that I will break it in the future. As I work exclusively with gcc (both hobby and professionally)
    And the code contains a lot of C++11 features, as I use the codebase to play around and experiment with those features.

    I'm not sure which part of the template specialization goes wrong with VC++, got an example of which part broke?

    All the code has YAGNI applied. Except for some bits of the script functions, which I added because I know the scenario scripting has more hackers then the rest of the code.
  • daid said:

    Note, that I included the code::blocks project for my own convenience. The proper way to compile the source is with CMake. And then you can pretty much use any IDE you want.

    Yeah, I should look into cmake -- it seems to be all-the-rage these days (though it brings up flashbacks of the old X-Windows "IMakefile" :-/ )

    I don't think I'd have so much of a problem with code::blocks if I could get a VI emu plugin (I found one, but it was for a much older version of code::blocks)
    daid said:

    I wouldn't mind simple patches for VC++ compatibility, but know that I will break it in the future. As I work exclusively with gcc (both hobby and professionally)
    And the code contains a lot of C++11 features, as I use the codebase to play around and experiment with those features.

    VC2015 is pretty good with C++11 features, but MS made a decision a long time ago, before template specialization was fully fleshed out in the standard about where instantiation happens, and they backed the wrong horse :-( With too much code (both internal and customer code) relying on the old behavior, they were left with no choice but to keep it the same. Annoyingly, that means that GCC code which relies on the behavior breaks.

    That said, I don't mind "keeping up with the Joneses", owning the MSDEV changes and re-fixing it if/when it breaks.
    daid said:

    I'm not sure which part of the template specialization goes wrong with VC++, got an example of which part broke?

    The problem rears its head when you DECLARE a specialization of a template function in a header file and then later DEFINE it in a .cpp file. gcc will see the declaration, and generate the specializations at link time, but template specializations originally had to be defined in the same translation unit (i.e.: .obj) so that the compiler would have all of the information (they were originally a kind of hack that only involved the compiler, not the linker). MS implemented template specialization the same way as "normal" templates, and requires the body of the specialization to be available at compile time for every translation unit that uses the template (it turns out, that later, at link time, it should coalesce the functions when it realizes that it's generated 100 copies of the same function).

    The problem seems simple on the surface, but there's also some juju around "two phase lookup" which apparently nobody gets right, and has implications for templates in namespaces, etc. Big dragons -- but all hiding in weird little corner cases.

    My change is simple enough: move the specialized functions to an .hpp file which is #include'd in the .cpp file when _MSC_VER is not defined and in the .h file when _MSC_VER is defined. There were about 9 source files affected.

    I will say that it's been fun scrubbing the rust off of my C++ skills ... most of my day-job is C#, python and perl.

    In other news -- I discovered a little bug in SeriousProton/engine.cpp where it would write to array index -1 if it got an undefined key back from sfml (which happened to me -- I honestly don't know how the Undefined key happened, it may have been one of the media keys on my laptop)

    I suppose I've hijacked this thread enough... :-)
    -- pryankster
  • wopot said:

    bumb

    Tip. Posting "bumb" is a great way to piss people off on forums.
  • i know
Sign In or Register to comment.