Rick

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/context/contextdrawtext-r731

fyi the last presenter in that video was classic!

Because developers must not be using cross platform libraries I'm guessing? With something like RakNet and LE it shouldn't be an issue though.

Ah very cool. I'm really hoping the 3D planes that I'm working with work out with the other aspects of a GUI because it is nice that it handles all of this scaling automatically. I hate dealing with that ****

TL;DR I'll assume you're doing cool things with terrain textures. Will there be any way to query what's under our feet on the terrain? ie could we tell if we are standing on the smiley face?

+1

I am interested in how you handled different aspect ratios when %'s are used for scaling and positioning as that's where I was unable to easily come up with a way when I was doing my GUI. I had separate config files for different aspect ratios, which is tedious to setup at GUI for.

Is positioning and scale using % of the screen or absolute? I love what you are doing here, but with 2D, I have a fear that resolution and aspect ratio independence is going to be an issue. Different resolutions within the same aspect ratio, positioning and scaling can be solved by using %'s of the screen instead of absolute, but I've found different aspect ratios generally cause issues. A set of %'s for positioning and scaling for 1 aspect ratio doesn't work with another. Unless there is some formula to alter those %'s by aspect ratio, I've had to do it the brute force way of defining different %'s for different aspect ratios. If there was some math you could do on the %'s for different aspect ratios then it would be all good, but using %'s for positioning and scaling is the key starting out. For most video games I don't think absolute positioning/sizing works. I don't want to discourage you but instead to think about the possible pitfalls and maybe start a dialog about it. This has been my experience but maybe I missed something when I was doing it, but this is why I'm looking more into 3D (textured planes) UI. Even if there was a mathimatical way to adjust for aspect ratio when using % for positioning/sizing the scaling of 3D textures on objects seem to look much better than 2D scaling of textures. Not sure why that is or if it can be overcome. These are very important aspects of a GUI though because nothing would be worse than making an entire game using only 1 screen resolution and then when you go to allow various others, or making mobile game which automatically has many different resolutions, running into this problem then.

If another script had a KeyHit() on the same key that could do it since KeyHit() will only register once in a cycle. Maybe it was registering that key in the other script and never making it into the if check in this script? @Andy this is one of the reasons to sometimes do what beo6 mention with using KeyDown(). You can make a modified KeyHit() where you use KeyDown() and a boolean check in the script so it only fires once per frame, but if 2 scripts use this method they will at least both get into the if check of their scripts.

If it's very small you might have to check that sweeping collision checkbox.

Make sure the ground is set to collision type "scene", and make sure your character box is set to character type "character" and has a mass. Also make sure the Physics Mode is Rigid Body for the ground and Character for the character. You might have to select Shape to Box and click Fit Shape for the ground also.

General seems more like properties that EVERY entity has. Range is a light thing. There is another tab called Light that has range, however in your screenshot it seems your properties window isn't wide enough, but there is a scroll button there that you can click on to show you the other tabs. I also disagree that the scale tool should change the range, but either way I guess. Not a big deal in my mide.

Got it to work. My plane was rotated in the editor to start with which screwed it up. I got all of the edges anchorable now. I have a hard time thinking in 3D though. So anchoring on some other edges requires different combinations of positioning the pivot and what point is unprojected? Like I can unproject (0,0) or (contextWidth, 0) or (0, contextHeight) or (contextWidth, contextHeight), or even 1/2 contextWidth and height, etc? Thanks for the help and good idea of the pivot!

I don't think this would work as I want to be able to anchor to any side the same plane so setting the base at the top/left would work for the top/left screen but not the bottom/right is I want to anchor a widget plane there. I'd be in the same boat. Maybe there is a way to change this dynamically in LE though. Will check that out as that might be the easiest. I put in that code but got a funky result.

That doesn't work for me. The center of the plane ends up in the top right corner. I would want the top right of the plane to be in the top right corner of the window. This is why I'm confused some why 0, 0 puts the top left corner of the plane at the top left corner of the window instead of the center of the plane at the top left corner of the window as I assume the local 0,0 of the plane would be it's center. If this was 2D you'd have to subtract the width of the image from the right edge to "anchor" it on the right side. However because it's a 3D plane I'm not sure how you'd do this. I think you'd have to convert width of the plane from 3D space to 2D space and then subtract that number by the context width before sending it to UnProject(). Not sure how to do that 3D to 2D conversion of a size. [edit] Actually I was incorrect. (0,0,1) does put the plane at the center point of the plane in the top/left instead of the top/left corner of the plane. So on all edges I'll have to account for 1/2 the plane width/height and adjust somehow. The texture I was using didn't make this obvious but I switched textures and now I can see that. Thinking out loud. Let's say we have a plane, 2 units in width, total, and 1 unit away from the camera. Would need to see how wide in pixels that is given the current screen resolution. Maybe I could get the scale and subtract 1/2 the scale from the position and unproject that value, then add 1/2 the scale to the position and unproject that value, then find the difference between those 2 values to get the size in pixels and then add that to the screen space I want to unproject. hmm will give it a go.

That does work thanks. I'm a little confused though. If I unproject (800, 600, 1) then the center of the plane is in the bottom right. I guess I would expect then (0,0,1) would have the center of the plane in the top/left (since I'm guessing that's the center of the plane model), but it's not the center of the plane it's actually the top/left of the plane. Basically, I'm looking to anchor the plane to any edge of the 2D screen. Trying to do this against the right edges seems like I'll need to convert the scale of the plane to pixels on the screen so I can subtract that difference by what I send to UnProject? Not really sure how I'd do this. Man I wish I was better at math :/

I have a plane model that I'm using for a gui widget. I want to have options to anchor these to top, bottom, left, right edges of the screen. I'm just testing top left (0,0) atm so I have the following code: local pos = self.camera:UnProject(Vec3(0, 0, 1)) -- always face the camera self.entity:SetPosition(self.camera:GetPosition()) self.entity:SetRotation(self.camera:GetRotation()) self.entity:Move((pos.x / 2), (pos.y / 2), 1, false) self.entity:Turn(270, 0, 0) However this doesn't align the plane exactly to the top left edge. For a screen resolution of 1024x768 if I change the Move() code to self.entity:Move((pos.x / 2) + .018, (pos.y / 2) - .15, 1) it lines up perfectly, but for other resolutions that doesn't line up. I'm using the plane model that comes with LE Models/Primitives/plane.mdl Why is self.camera:UnProject(Vec3(0, 0, 1)) not producing a point that would be exactly in the center of the plane at the 2D space 0,0? How can I do this to be more consistent with any resolution?

Would be nice to have a checkbox or something that let's us tell the editor/engine that a dragged in model is to be treated as either an instance or a copy/one that can have a new material. I know we can do this via code so would be nice if available via the editor as well.

The problem is the default Lua app creates a camera in code (App.lua) so if you drag in a camera your scene now has 2 cameras and it seems to by default take the one created in App.lua. Kind of strange flow there, not sure how best to handle that.

Does that even run without error for you when placed in an entity script and attached to anything? self.window doesn't exist in entity scripts. If I change self.window to App.window then it runs for me but I notice it doesn't move the camera. Will see what's up. [EDIT] I assume this is a Lua game. Go into Scripts/App.lua and comment out the line that has self.camera=Camera:Create() and it should work then. The problem is the default Lua app creates a camera in code (App.lua) so if you drag in a camera your scene now has 2 cameras and it seems to by default take the one created in App.lua. Your other option would be NOT to drag in a camera entity into your scene and in code access the global camera created in App.lua via App.camera.

I place a camera in my scene via the objects->misc->camera and I don't do anything with it via code. It seems the starting position is always 0,0,0 even if the camera entity/widget in the scene is placed somewhere else.

This is a dangerous thread My view is that the rules and guidelines for OOP are put in place for a reason. Not following them will come back and get you at some point in your development. It may be manageable in your eyes and then that's fine. However, it's important to know why these rules exist. Experiencing them first hand will often have you an advocate for them. Not experiencing them will often have you fighting against them because of the extra code you have to write. That's pretty insulting to people who know why these guidelines exist and choose to use them. If a big studio buys LE 3 and has the word entities list (as just an example) accessed and use all over their code and then you realize you need to change that variable or expose it differently for 3.1 because you missed something or changed a process or whatever, and you do an upgrade that breaks this usage and the studio has to spend time and money to fix that in their code, and they write you a nasty email, then you'll experience why it's better to not expose variables directly and to not break your interface if you can absolutely help it. Maybe that'll never happen. Maybe it will and their confidence in LE will be out the window. Who knows. It's important one knows the risks and they decide if it's worth taking or not. That's all it come down too really in anything in life.

If we create more than 1 world how do we set it as the current world? I'm playing around 3D planes as an inventory system GUI, but I'm using LE 2 as my reference and in that we could create models in other worlds so that it was always drawn on top of the current game world and had it's own lighting. With LE 3 and lighting I could just make the plane lightmapped to handle the lighting but how can I set worlds and make it so everything is drawn on top of the game world in LE 3? Thanks [edit] Nevermind. I was able to use "Always on top" for the materials to get the effect I wanted. Thanks Aggror for helping with that.

So they can be planes? Is that what you are basically meaning with 3D rectangles? So you are doing like an entity pick vs a 2D screen check for those?

No need to use the center screen even. Just pick like (100, 100) or something like that All you're looking for in this case is the change in mouse position from a given location anyway. You'll never have a resolution lower then 100 so you'll always have a 100,100 location and it greatly simplifies the situation. Especially for newbies trying to understand the code.