[Retitled] Amalgam of vaguely related questions.

This forum is currently in read-only mode.
  • EDIT: Rather than make a whole new thread, it seemed like a better idea to keep all my silly little questions to one thread as they come. No point in me clogging up the forum.

    _______________________________________________

    Hello. First time poster, so be gentle. :]

    I've been looking at Construct for a while, and have been tinkering with it for a few days. Thusfar, I've found it more enjoyable than MMF1.5 (which had its merits, but Construct has some indescribable facets I prefer already), but there's one thing that I just stumbled on while teaching myself how to make use of Arrays, Edit Boxes, and the Text Object.

    You see, when I make a Text Object in the Layout Editor, it misrepresents the font size. I'm guessing by a factor of about 2 or so. While I can eyeball it to compensate as I putter with my little project, it's just kind of this little gremlin that nags at me.

    Here's an example of what I mean, with the layout on the left and the runtime preview on the right:

    <img src="http://largeangryrobot.webs.com/Constructtext.jpg">

    As you can see, the font is a proper Size 10 in the Runtime, but significantly smaller in the editor. I've tried this on two different PCs (one cruddy old XP laptop, one shiny new W7 desktop) and the results are the same, even on a fresh project. All I can tell so far is that it seems possibly tied to the choice of Application or DirectX runtime. Picking Application shows the reduced size font in the Editor, and the normal size in the runtime preview. Picking DirectX shows reduced size in both the editor and the runtime.

    Is there something I can do? Should I just work around this, or is there a tweak/setting that I've missed in order to get the editor to show the proper font size with the Text Object? I can provide a CAP if needed, but it seems to happen on entirely different PCs, whether I use a new file or my current project file.

  • Text objects change size in the layout editor when you zoom in or out. Maybe that's what's happening here? It's been fixed in C2, btw.

  • Hm. I see what you mean about the Zoom. It appears to be controlled by Ctrl+Wheel Up/Down (standard). That said, I'm working at 100% size, and interestingly the text remains at the same size on the screen despite what the Zoom level is at -- it's the same pixel size on my screen if I blow it up to 200% or shrink to 50%.

    Further tinkering suggests it may have to do with specific fonts. Arial and TNR demonstrate the misrepresented size, but Courier does not (perhaps because it's a system font?).

    Edit: MS Sans Serif also appears to display normal sizes. Hrm...

    Edit 2: Okay, rather than Courier and MSSS displaying normal sizes, they're displaying the reduced size (again, a font size reduction of 2) in both the editor/runtime. Well, at least MSSS is a relatively readable font. I think I can work with that, need be.

  • The editor isn't always entirely intuitive at times, so you might just have to work around this. I'm not an expert of course, so a solution might exist somewhere out there.

    Welcome to Construct, by the way.

  • Thanks for the welcome. This program is bounds ahead of ol' MMF1.5 in terms of both function and the fact that it doesn't max out your CPU cycles when a simple text application is at idle. :]

    I can work with MS Sans Serif since it's at least consistent. Courier is a bit unappealing to the eye, but MSSS is fine.

  • Right, so. Some hours of tinkering and reading later, I'm getting to learn things. For one, I've opted to go with the DX runtime for the application, as I can use it to make quickly swappable color blocks, which appears to not be an option for Application runtime (understandable). The DX runtime also lacks the problems with misrepresented font sizes, making layout setup much easier.

    There's now a new question. Is there a way to move the text cursor (rather than the entire mouse cursor) between the edit boxes? Let's say I have 3 EditBox objects, which we'll call Edit01, Edit02, and Edit 03. Normally, I would Tab (which I can read for with the Keyboard & Mouse object) and then the cursor would move from Edit01 to Edit02. If this can be done, then presumably reading for the combination of Shift+Tab can make it go in reverse, including Edit01 to Edit03.

    I'm not seeing any particular condition to move the text cursor between edit boxes, and I've not seen it mentioned in my searches on the forum (though there was a handy post on rigging colorable edit boxes using multiple objects). Possible? Impossible? Again, not a dealbreaker, just a matter of UI refinement.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • The edit box has two actions called "Focus on" and "Focus off", they set and clear the focus (set the text cursor to the specified edit box, or clear it)

    One tip: Often objects are not documented very well. A way to at least get a hint if some functionality exists, is to right-click the object in the object list (while the layout editor is active) and select "Object information". This lists all ACE of the object and helps sometimes.

  • Thanks for the heads up. After checking out the Object Information window, there really is a heap of undocumented features in there for some of the objects!

    The Focus on/off is doing the trick, and I can now put the focus onto any given EditBox. An If/Else block with a hidden variable to keep track of which edit box is on seems like a reasonable approach. While working on that, I hit another snafu. I can't seem to find any condition that detects whether an edit box has focus, so I could lose track of which one has it.

    Then again, maybe I can just keep track of it by detecting when the object is clicked with the mouse! I think that's doable, since there are conditions for objects being clicked, through the KB&M object.

    Ironically, after all this talk of tabbing, it seems that the edit boxes inherently have command over the tab key to make an indent that can't be overridden. It still moves between boxes, but puts indents in on the previous box.

    Really, this is a job best suited for a simple spreadsheet, but it seemed like a good way to learn about some of the basics in Construct, so I will press on anyway. Thank you again for the assistance. :]

    EDIT: On further thought, I can just reassign the tab function to a different key. Probably one of the Function # keys. Construct certainly does lend itself to clever solutions!

  • I read your tutorial on Arrays, Tulamide. That was very informative, and perhaps I'll look into whether I can/should use hash tables as things go on. :]

    So, to end the guessing games, what I'm putting together is a (very Spartan looking) character profiler. Name, age, height, all the details. Neatly storable in an array.

    My next question is more a matter of the "proper" way to do something. In this case, array maintenance. There is a possibility that characters would be deleted from the array, which would leave a host of blank cells. Keeping the array from becoming bloated with blank chunks means that there will have to be some form of maintenance since it can't always be assumed that the deleted character will be the last one in the Array.

    The format is X is a column that contains all the relevant information for a single character, and Y is each item of info (currently at 16, but it'll get larger).

    As far as maintenance goes, I can think of a few ways.

    A) When a character is deleted, set all their column values to 0/Empty/Null, what have you. To minimize wasted space, when saving a new character the application could search for empty columns to dump said new character into. This could still result in multiple unused columns if more are deleted than added, and would still require some kind of maintenance function. It doesn't really seem like a good idea.

    B) When a character is deleted from the list, the maintenance function automatically begins to copy over the data from any columns that follow to the empty one, in a loop. When the final column is the empty one, it truncates by reducing the array size by a factor of one. This ensure that no matter how many characters you delete in succession, there won't be any empty columns. It seems like the better solution for tidiness.

    My concern with approach (B) is the time it will take. I expect the array's final size to be something like 50x35x1, but it could be larger still. It's not monumental in size, but what kind of processing time are we looking at if the character in column 2 gets deleted, meaning that the remaining 48 columns need to be shifted over? I'm sure part of that will have to do with the efficiency of the loop, but I'm still curious. My (limited and decrepitly rusty) C++ experience from college tells me that I should always keep on top of maintenance, as in approach B.

  • You shouldn't notice a performance impact with a 50x35 array and leaving entries blank. However, one way to do it would be to have a hashtable hold your characters with the value an index into the array. That way you would always get really quick access to your array info without any searching or sorting. When you delete a character, the hashtable entry would be deleted (the hashtable is an automatically sized list) and the index could go into a deleted index hashtable for use later if you add a character back.

  • I'd always prefer maintenance over speed. You never know how much issues you will get with too much wasted RAM or illogical code.

    You shouldn't be too afraid of maintenance slowing your app down, though. I tested an array with 10000 cells, moving the contents of 9999 by one to the left. I could do this on every tick without touching the v-synced framerate of 60 fps. In your app you will never experience a situation, where you would constantly move 10000 cells per tick.

    If you are interested, how actual events would look like (and behave), have a look at Verve!

    The sorting algorithm featured there works simultaneously on 4 arrays, moving the contens of cells, deleting entries, inserting data, etc.

    If you can find a way of identifying your objects with keys, then you could use a hash table and place all data as a tokenized string for the values of the keys. It would cost you another routine to pack and extract the data from the strings, but you would never have gaps in your hash table, no matter how often you delete or add something.

    You could also setup your own array structures (like arrays storing other arrays or sub-arrays) by using the 's'-plugin.

    Python would also allow for custom classes. You could create something like:

    class Profile(object):
        def __init__(self):
            self.name = None
            self.age = None
            self.height = None
    
    class Group(object):
        def __init__(self):
            self.profiles = []
    
        def create(self):
            self.profiles.append(Profile())
    
        def delete(self, index=None):
            if index == None:
                del self.profiles[-1]
            else:
                del self.profiles[index]
    
        def set_age(self, index=None, age=0):
            if index == None:
                self.profiles[-1].age = age
            else:
                self.profiles[index].age = age
    
        def get_age(self, index=None):
            if index == None:
                return self.profiles[-1].age
            else:
                return self.profiles[index][/code:ep387qqo]
    
    You would then use it this way:
    [code:ep387qqo]#Your array
    ProfileArray = Group()
    
    #Create a new profile
    ProfileArray.Create()
    
    #Set the age in the newly created profile to 18
    ProfileArray.set_age(None, 18)[/code:ep387qqo]
    
    Saving the data is as simple as using file.write() after having prepared the values. (Won't go into details here, but it really isn't much effort.)
    
    You see, there are many ways, it is up to you to decide which way to go
  • Again, I appreciate all the ideas. For now, I think I will go with the simple and brutish approach to get it up and running for my friend and I. As we'll be using it for some time, I do plan on refining it both visually and functionally, so it will likely go through some under-the-hood revisions (likely in the veins you've both suggested) to make it smoother and easier to handle.

  • Edit: Using the debugger informs me that event 5 is attempting to add a string to an integer. Looking into it.

    Edit 2: Solved the Integer/String conflict. Apparently only part of the problem. I'll look into it more tomorrow...for now, bed.

    Edit 3: Fresh morning! Fresh mind! It appears to be working properly now. After fixing the Integer/String conflict, it ended up being a conditional fallacy in the blocks and a mistyped variable. I can now save new characters and it will properly seek out and overwrite existing characters with new information. Thank you for your patience!

    Next up, the delete function. That should be delightful.

    Also, the debugger in this is great. It's so clear in listing everything that you're looking at. No more archaic C++ debuggers. <3

  • Hello again!

    After many days, things are looking good. The profiler is in a functional condition, although it still lacks things like failsafes against common user errors and has a few quirks left to iron out. Still, it does the most basic things that will allow us to start using it and storing character data. I'm having a friend put it through the ringer, since another pair of eyes always finds something I've overlooked.

    One such case was brought to my attention. I'm using the Box Object to allow the display of a particular color, selected by the user. The color is set by means of the Windows Color Picker via the Common Dialog Object.

    The problem is that if you cancel out of picking a color, instead of leaving the color in the Box in question alone, it will set it to the previously selected color.

    Rather than include the entire profiler (which is still a mess and needs intense optimization and reworking in many areas), I have distilled the problem down to a tiny .CAP with just a few events. It allows accurate reproduction of the error. If anyone can figure this one out, I'd be much obliged. As it stands, a simple misclick could cause loss of your selected color, and that's no good.

    CAP File:

    http://largeangryrobot.webs.com/ColorBoxes.cap

  • I feel like I've committed some kind of sin for quadruple posting, but I still haven't figured out the color box matter.

    I tried using the "On Colour Dialog OK" event condition, but it produces another strange result. Particularly that it has a full one event cycle delay before applying the color to the box. So, the first time you hit OK it applies a blackish color to the box, even if you selected red. If you repeat the action, it would apply red to the box, even if you picked orange.

    With the help of the other posters, the search function, and the wiki, and some thoughtful workarounds most problems thusfar have been conquered. I just can't seem to trample the Colour Dialog problem, though. :[

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)