benryves wrote:
Yikes, .NET 1.x? Wink We've had generic dictionaries since .NET 2.0. (Dictionary<TKey, TValue>). Looking good, though!
Well crap, that'll clean up some casting, that's for sure. I didn't even really think of that. At first TValue would've just been an object, since it could be either a string or a hashtable, now it's an object array with a string and a hashtable. I could probably change that to a Tuple, though I'm not sure what the advantage there would be.

KermMartian wrote:
I agree documentation in the XML, but what about a link to live (frequently-updated, online) documentation in the XML as well?
That definitely seems like a good idea. At the very least have the root element point to the main page for documentation.

Also, quigibo's getting me a nicely formatted list of Axe commands, so once I get that, it should be pretty simple to make an Axe Tokens.xml.
Alright, so for a quick update, I cleaned up some code. Changed some objects, took some methods out of the Extensions class and into their own class, stuff like that.

I need some suggestions, though. Ideally, the icon editor will be able to try to predict the size of the sprite, which right now it doesn't (it just defaults to 8x8 and you adjust it from there). What I want to know, as someone who doesn't often make these sorts of things, what are common icon sizes and their corresponding lengths? 64 is probably 16x16, 16 is 8x8, 1024 is 64x64, but what are some others that I should include? Or, is there some math that'll get a pretty accurate guess? I'm not sure how these things are usually aligned. Byte aligned by width? Height? etc.
Well, they're almost always byte-aligned by width; you're going to have very VERY few programs that split rows in the middle of bytes. Of course, since you have no way of knowing if a 32-byte icon is 16x16 pixels or 8x32 pixels, I vote that you pick the nearest square approximation of the given icon (obviously, for 28 bytes, that's not possible), then let the user adjust either the height or width, and automatically adjust the width or height (the one they didn't touch) to match. Agreed, everyone?
Well, I wouldn't want the height/width to adjust automatically when the width/height adjust, in case you're starting from scratch and want to size it to however you want to size it (or you loaded a sprite, but want to add more to it or something). I could add a checkbox where you say if you want them to autoadjust, though. Getting the the nearest (larger) square approximation sounds like a good bet, though.
Fair enough, I didn't think of that case for the auto-adjusting. The checkbox is definitely something to consider, though. What if you make it auto-checked if someone just pasted in some text, but auto-un-checked otherwise?
I've added resizing on-load. Here's what I say in my git commit:
Before, when passed in a hex string, the user would have to adjust from an 8x8 sprite to make it look right. Now, the editor will find the closest square sprite that is at least the same size as the passed in hex, align the width with the closest byte (higher or lower), and then trim the height down until it's the right size. While this isn't always perfect, it will, for the most part, get close to the right dimensions.
Download here http://madigan.boldlygoingnowhere.org/Tokens.zip if you want. There are still some bugs, and it might be a little crashy. I think next will be the DCS GUI designer. This'll probably be a pretty big chunk of work.
merthsoft wrote:
I've added resizing on-load. Here's what I say in my git commit:
Before, when passed in a hex string, the user would have to adjust from an 8x8 sprite to make it look right. Now, the editor will find the closest square sprite that is at least the same size as the passed in hex, align the width with the closest byte (higher or lower), and then trim the height down until it's the right size. While this isn't always perfect, it will, for the most part, get close to the right dimensions.
Download here http://madigan.boldlygoingnowhere.org/Tokens.zip if you want. There are still some bugs, and it might be a little crashy. I think next will be the DCS GUI designer. This'll probably be a pretty big chunk of work.
Huzzah, congrats for adding that! I'm super-psyched about the DCS GUI designer; that's gonna be awesome
Actually, Kerm, do you have any suggestions of tips about that? Maybe how the calc is rendering it. Anything special I should know?
merthsoft wrote:
Actually, Kerm, do you have any suggestions of tips about that? Maybe how the calc is rendering it. Anything special I should know?
Eh, nothing that the Doors CS 7 SDK and the Doors CS wiki don't already detail in excrutiating detail. Perhaps it might be interesting to note that the coordinates of things with coordinates in GUIRLargeWin and GUIRSmallWin groupmaster elements are relative to the first pixel under the window titlebar, not the top of the titlebar, but I assume you already knew that. Hopefully you'll ask me questions if you start to get into the development and you're confused. Is there any chance that you might make this dump out ASM if the user so requests? Smile
I don't see that being much of an issue. Is it a pretty trivial formatting change? I really don't have much experience building DCS GUIs at all, so the first part of this will basically just be researching how it's done in BASIC.
merthsoft wrote:
I don't see that being much of an issue. Is it a pretty trivial formatting change? I really don't have much experience building DCS GUIs at all, so the first part of this will basically just be researching how it's done in BASIC.
Well, feel free to take a look at DCSQuad, or DCSBL Race, or Lights Out DE for examples, or ask me to make you contrived examples if you need specific help with one of the element types. Smile
So, I'm playing with the GUIMouse, and I have this:

Code:
:DCS
"1038140800427E00
If 1337 != DetectDCS(:Then
Disp "DCS7 IS NOT","INSTALLED!
Return:End
ClearScreen(,0
OpenGUIStack(
PushGUIStack(0,255
PushGUIStack(14,0,0,10,10
PushGUIStack(11,15,15,"",0,""
PushGUIStack(4,1,1,0,"Clickie clickie
{45,32,1
While 2 != Ans(3
GUIMouse(Ans(1),Ans(2),1
PopGUIStacks(,1
PushGUIStack(4,1,1,0,Str1
End
CloseGUIStack(
Basically, what I want to do, is see what's going on when you click, specifically I wanna see what happens when you click the checkbox. The thing is, it just checks and unchecks, it doesn't actually draw any text. What am I doing wrong?
Clicking checkboxes and radio buttons doesn't do anything from the point of view of the BASIC program until you click something else, like a button or scrollbar or WinButton, that is going to make the GUIMouse( call return. Once it returns, take a look at the contents of Str1 (in your case, since the third argument of GUIMouse() is 1).
Laaaaame
merthsoft wrote:
Laaaaame
Can you me more specific (and mature)? Rolling Eyes
Quote:
mature

Well, it'll be hard for me, that's for sure.

Returning from checking or unchecking a box would be pretty handy, I feel.
merthsoft wrote:
Quote:
mature

Well, it'll be hard for me, that's for sure.

Returning from checking or unchecking a box would be pretty handy, I feel.
Meh, I hear you, but there's not really a callback mechanism at all (for ASM or BASIC).
Hmm, well, that's ok. I don't mean to belittle the work you have done, I realize that it's been a huge endeavor.

Meanwhile, I've been messing around a little with DCS GUI stuff to get a feel for how one may design it. It seems straight forward enough, basically a container and some controls. I don't think, at least early on, that the designer'll be much more than just aligning things correctly. So it'll be able to output something like:

Code:
PushGUIStack(0,255
PushGUIStack(14,0,0,10,10
PushGUIStack(11,15,15,"",0,""
PushGUIStack(4,1,1,0,"Clickie clickie
But maybe not a 5x5 forloop type thing like you use in lights out, that may come later, though.
That's fine; I just did that because popping and pushing 25 (36?) checkboxes each time got slow and tedious. For normal operations, the normal type of checkboxes (and of course the other 24 types of GUI elements) would be more than sufficient in simple linear order. Once DCS7 is out the door and I've gotten room to breath for a bit, we'll need to discuss a SourceCoder2 API.
*bump* As per Merth's request, this post has been moved to Your Projects.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4 ... 30, 31, 32  Next
» View previous topic :: View next topic  
Page 3 of 32
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement