|
Reviving EQIA editor
Now that I'm to a point where I have time to work on it again, I'm reviving my old EQInterfaceArchitect project. The goal is to create a WYSIWYG editor that complies with modern EQUI.
Progress: - Wrote my own xml (de)serializer to avoid the pitfalls I encountered in my past attempts, as well as to make it more customizable. - Have the basic look of the xml editor complete with syntax highlighting and block folding. This is disabled for now, focusing on drawing code. - Have the core drawing code in place in textures and animations. - Starting on drawing code for draw templates, so far have ButtonDrawTemplate Requirements (subject to change later): - Microsoft .NET Framework 4.5 and 3.5 - Microsoft XNA Framework 3.1 To compile: - SVN client to download source, see google code page for repository address - Visual Studio 2012 (express is fine) - XNA Game Studio 3.1 (may require Visual Studio 2008, express is fine) Currently it's only safe to load the default UI with it, I make no garuntees yet that it'll load a custom UI. There is no editing functionality yet. To open a UI just try to open any XML file in the appropriate folder, it should find a suitable equi.xml file. EQInterfaceArchitect on GoogleCode Preview will be updated later when I have something better than random textures, animations, and button draw templates to show. If anyone would like to work with me on this. The serializer is pretty much automatic, as long as a type is derived from EqElement and is marked up with EqX attributes, it will figure out how to read/write it. As far as what I could use help on, that'd be implementing all of the EQUI elements. |
Got an update coming sometime this coming week. I have text editing working and it updating the preview every chance it gets that the xml your working is able to be deserialized. But currently it's a very hackish first draft code that needs to be cleaned up before I'll commit it.
|
Great work Shillingworth. Looking forward to using it.
:) |
Hey, great job so far!
This would be something new to me to use and im excited to see what all it can do! |
Had a bit of a setback due to a tooth infection that started about a week ago. It's starting to clear up thanks to the antibiotics the ER prescribed when I finally gave in, but I have to focus on finding jobs to pay for a dentist appointment to fix the problem before it gets that bad again.
Been getting a little done here and there as I can, but it far from my normal pace. |
Shill! Just saw your thread, very very happy you have decided to go further with this. You will truly make the community, as well as myself, a very happy gamer :)
|
Working on moving it over to VS2012. After finally installing the copy of VS2012 I got from early testing I was very impressed. First time since VS2008 I don't have to fight the IDE to make it do what I want it to do. The improved support for threading helps too, especially with a project like this where I have to use no less than two threads at a time. To be fair VS2010 had half decent threading support, but debugging one thread at a time made it hard to see the big picture.
But this puts me with updating Avalon for proper .Net 4.5 support. I can use some tricks with config files to wedge it in. I don't like that option since it requires end-users to have multiple versions of .Net installed just to run the program and produces vague error messages if any of the required libraries are missing from the machine running it. Considering I rely on Avalon almost as much as .Net/Mono in most of my projects, it's in my best interest to update it. |
Finally had time to really focus on it today (been real busy lately with odd jobs). Managed to get about 8 hours in which allowed me to move almost everything over to VS2012, as well as work out a few things that I only had shoddy temp code in place.
Googlecode was being really temperamental when I tried to commit the code, so that'll come a bit later. Stopped using SVN because I got fed up with the sorts of problems it's giving, guess I'll go back to that since at least I know it inside-out. |
I appreciate all the effort and time you are putting into this my friend. :)
|
Decided to just come back to text editor side later an focus on graphic side of things, so been working on drawing code for everything. I'd really like a time machine to travel back and punch younger me in the face for not being meticulous with backups.
If anyone has a copy of the old demo I put together that loaded the default UI's inventory screen I would appreciate it if you could upload it somewhere (hint: mediafire and dropbox are free and easy to use). I have tools I can use to reverse the code back out of it, of course it'd be a tad outdated but not by much. A couple things ya'll can work on for me if ya feel like it: Icons for each UI element. Design em yourself or locate some online that have free licenses for non-commercial or open-source software. Same size as the icons next to websites in modern browsers would be awesome. Data file with all of the EqType and ScreenID listed in a format that can be parsed easily. Be sure to include names and what type of UI elements it can be used in. XML and YAML are my idea choices, but text is fine as long as you use a visible delimiter (commas, colons, semi-colons, pipes, etc). Play with various conflicting layout parameters on elements to figure out what priority they have. For example if MaxHSize or MaxVSize is set does it limit Size or ignore Max sizes. I had a lot of these figured out at one point but can't find the note book I had them written down in. |
15000 Android style Icons
It's a free sign up. Enter an email address and they will email the link with the download. No gimmicks. There's all kinds of nifty freebie web and graphic design downloads on this site. |
Quote:
Are you going to make this a dynamic feature? In other words, SIDLWIDL had it so there was a Toolbox Templates file that could be edited to keep up with future UI Changes and could be manually updated. I have not updated it in quite a while, but here is the link to the one I was working: SidlWidl v2.9 and You (Part 2 - The Toolbox) |
Ah no Sparxx, close but not exactly what I had in mind. The idea is to pull the EqTypes from a config file and into a context sensitive combo box. Although the template idea does sound a lot more noob friendly.
|
EQ Devs give me a headache:
Code:
Code:
|
Wh00psie! :p
|
I am really looking forward to the end result of your work. I use SidlWidl currently, and it still is fairly useful.
One thing that you could keep in mind that would be very helpful is the fact that the EQ parser interprets <Style_Border>True</Style_Border> as false. It is case sensative, and SidlWidl always makes "true"s capitalized. I always have to edit it in a text editor after to make them all lower case. If you could make sure that is correct, it would be totally awesome. |
Had a (Nvidia) driver update screw up so badly that I was unable to figure out a sane solution. Spent 8 hours trying to clean up the mess it made, was unable to install any video drivers (not even Windows compatibility drivers). Not going to be using Nvidia's automatic update again.
In the end I had to reinstall Windows, which means I get the joy of reconfiguring everything how I like it. I used a Windows disc with most of my software, but that disc is two years old, and a lot has changed in my workflow since then. Probably be a couple days before I get everything set up well enough that I feel comfortable coding again. |
Quote:
Yeah, that's already handled by the way it's set up to output XML code. Wasn't intentional, just kinda worked out on it's own. |
Sorry to hear that Shill :( I remember I had a similar issue and I had used "Driver Sweeper" to uninstall the nvidia drivers, which....If I remember right....found all of the leftover files and I was good to go with the previous version. The program is now replaced with "Driver Fusion", now that I google'd it. The other way that had worked for me was just rolling back the driver right from device manager. All null and void now for you though....but hope you get back on your feet soon!
|
Yeah that was the first thing I tried Drakah. I spent about an hour or two after that figuring out how to get a command prompt into kernel mode to get rid of some files that not even admin could delete. I was very obstinate about not reinstalling Windows, but well couldn't avoid it.
|
Well as it turned out, wasn't the driver update, that just a side effect of the real problem. Was playing Mass Effect series again, sure enough after I installed part three the problems came back. It turned out to be EA's client software, once I got rid of that the problems went away, but sadly it crippled the game (had to use a cheat to keep readiness up without it).
|
Could use some help in determining the precedence of the following settings, as well as any strange behavior different combinations of settings on them has.
Location, Size, Min/Max Size, AutoStretch, AutoStretchHorizontal, AutoStretchVertical, RelativePosition, XAnchorToY, and AnchorOffsets to determine which direction positive and negative is from the respective edge they control. I have a vague idea on how those should behave, but this is EQ we're talking about, it's loaded with strangeness and contradictions. |
The only thing I can tell you is what they "do" (how they act in code) but I doubt that is what you are requesting to know.
|
This is my best explanation. First, AutoStretch would have to be first because it determines whether size/location is used, or Anchors/Offsets are used. I have not specifically used the AutostretchVerticle/Horizontal, but I feel sure it is the same.
If AutoStretch is set to false, then values in the anchors and offsets are ignored and only size/location is evaluated. If it is true, then the opposite is true; size and location are ignored and the anchors and offsets are evaluated. Autostretch is used to determine if an object within the window resizes with the parent container, or is fixed regardless of how the parent is resized. Autostretch=false means the object is fixed in position and size. To understand the anchors and offsets you have to realize that all objects have 4 sides (I know, duh :) ) and each side can be set separately. Starting with the top (I don't think EQ cares which is evaluated first) first you determine if you want the top edge of the object to 'hook' to the top of the parent container or to the bottom. TopAnchorToTop=true 'hooks' the top edge of the parent container. False 'hooks' it to the bottom edge. Next you use ToAnchorOffest to determine how far away (in pixels) the edge you just hooked is away from the edge you just hooked it to. One thing to keep in mind is that even though Autostretch may be on, you can define the anchors and offsets to make things appears as if they are fixed positioned. You often find this with buttons. Min/Max size is probably last, as it is only used when the container is actually resized. I have never set them, so I am not sure of their exact behavior. A couple of other things to remember; all objects are rendered bottom to top based on their order in the <pieces> list. Also remember that anchors are fixed to their parent container and not the main window. Lastly, any property that is omitted, but indicated will be defaulted to false. So, if the xml for TopAnchorToTop is not present], but Autostretch=true, then TopAnchorToTop will be false meaning it will be 'hooked' to the bottom edge. And of course as I mentioned before, TopAnchorToTop=True (capital 'T') then it is actually interpretted by EQ to be false thereby 'hooking' it to the bottom edge. Oh, one other thing, if you try and render something 'inside-out' it will not appear at all. By inside-out I mean that the top edge is below the bottom edge or the right edge is to the left of the left edge. This is only achievable by setting AutoStretch=true. Hopefully this isn't a recap of stuff you already knew and it is actually useful. |
Pretty much explained what it should work like val. You did provide a useful piece of info, that inverting the coordinates results in nothing being drawn. That makes sense given unless you tell Direct3D you want two-sided rendering, it will only draw the front side (which is determined by winding order). So that piece of info tells me EQ is drawing the entire UI with one-side rendering, which save me from having to dig through a graphics debug spew to find the UI draw calls and what state they have set.
Here's the code as it stands now in EQIA for dealing with the size/location. It's the order I'm most worried about. Just so you can read this, I use short-hand if's in this code which have the format 'condition ? true-side : false-side' Code:
|
I have never used the AutoStretchHorizontal/Vertical, so I can't say if they take precident over AutoStretch, but approaching it logically, your order seems the most correct.
I don't know if your psuedo-code is comprehensive, but don't forget to factor in the property RelativePositioning. True behaves just as we have been talking about. False, however, ignores the parent container. I have never observed the behavior of an element within another container and having RelativePositioning set to false, but I have accidently done it for top level elements. I have on many occassions placed buttons at 0,0, only to find them at the top-left corner of EQ. Honestly, I can't even imagine why anyone would not use relative postioning for elements. As a note, I am a coder for a living, so unless you're writing this in Delphi or Fortran, I can most likely read any code you paste :) |
That's not psuedo-code, that's actual C# code. The RelativePosition stuff is in the else clause of AutoStretchHorizontal and AutoStretchVertical, my assumption is AutoStretch trumps Location/Size but does nothing if RelativePosition is false.
|
RelativePostion is independent of Autostretch. Normally, if you set the location for an element at a position outside the current window size, it will be hidden (for example 100, 100 when the window is 50,50). However, relativePositioning=false ignores the current container, but still applies Autostretch.
So, for example, if I have a button in the GroupWind and: <Autostretch>false</Autostretch> <relativeposition>true<RelativePostion> <Location> <CX>0</CX> <CY>0</CY> </Location> the button will appear in the top left corner of the GroupWnd. However, if I have: <Autostretch>false</Autostretch> <relativeposition>false<RelativePostion> <Location> <CX>0</CX> <CY>0</CY> </Location> that button will be in the top-left corner of the screen (up where the latency meter shows when you hit F12). It doesn't matter where you place the GroupWnd, it will stay in the top-left corner of the screen. Setting Autostretch to true, and say you anchor the button to the right and bottom, but have RelativePositioning=false, then it will hook to the right side of the screen, not the GroupWnd. If you are playimg in windowed mode, and resize EQ, that button will anchor to the right and bottom. In other words, that button will 'float' in no-mans land. I realize that when you are in a GUI, you are dealing with a specific window, and technically everything is relative to it. But, I use SIDLWIDL now, and if I accidently set relativepositioning to false, it shows in the window in the GUI, but when I load EQ it is MIA (in that window piece anyway). Sometimes it takes a while to discover where the element has gone because there is no indication in SIDLWIDL that the element will render outside the window. Not sure how you want to handle that property. I did recognize the C# (it technically could be C++ or Java as well). I didn't want to make any assumptions though :) |
Thanks val, the examples you gave made it clear how EQ is handling the anchors in relation to RelativePosition.
Now onto the part I was dreading. Filling in the drawing code on all the templates. FrameTemplate is a real PITA to get right, think last time I took a shot at making an editor that alone took me a couple weeks to get the behavior spot on with how EQ does it. |
Well I think I have it how the FrameTemplate works but not certain.
What the FrameTemplate is doing currently is: - Draw TopLeft and TopRight while measure their rectangles, then fill the space between with Top. Use the maximum height out of those three (if present) to adjust the Middle rectangle's top edge downward. - Draw the BottomLeft and BottomRight while measure their rectangles, then fill the space between with Bottom. Use the maximum height out of those three (if present) to adjust the Middle rectangle's bottom edge upward. - Draw the LeftTop and LeftBottom while measure their rectangles, then fill the space between with Left. Use the maximum width out of those three (if present) to adjust the Middle rectangle's left edge rightward. - Draw the RightTop and RightBottom while measure their rectangles, then fill the space between with Right. Use the maximum width out of those three (if present) to adjust the Middle rectangle's right edge leftward. - Adjust the Middle rectangle edges based on the four Overlap values, then fill the rectangle with Middle. - Return that rectangle to the UI piece being drawn as it's area for it's contents to draw into. The part I'm not sure about: - The Right pieces start at the right-most edge, then move leftward based on their Width. This means if any of the right pieces are smaller (width-wise) than the others, it'll be aligned on the right edge. - Same as above with the Bottom pieces against the bottom-most edge. I couldn't remember if the Right pieces align to the right edge of the middle or right edge of the frame. Nor whether the Bottom pieces align to the bottom edge of middle or bottom edge of frame. |
| All times are GMT -5. The time now is 04:14 AM. |
vBulletin Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.