MasteR

That is a solid point, anyone else? For me I like the UI to display consistency regardless of resolution. I found (for my implementation) setting a base scale of 1.0f and rendering all UI elements at this scale handled the best of both worlds as it was easy to add functionality which calculated an alternate scale based on window resolution. That way if you like squinting you'll ignore the scale function and if not, you could set a base resolution via the function and properly scale UI elements.

What are some Pros/Cons/Opinions on using: Cursor coordinates and picking Vs. Cursor coordinates comparison (testing) to widget screen coordinates. Lets justify our answers. For me I'm unsure hence the question, both have merits, one is significantly easier to program (option 2, IMO) but using this method always leaves me feeling a little...something.

OK, I devised a solution whilst nodding off last night. Initial tests have been a success. THEORY/PSEUDOCODE: (my needs are for 2D drawing, but the theory is the same for 3D) Create a new buffer the same size as the graphics window. (we only need a colour component so keep memory consumption down) Make your new colour buffer the current buffer Set the buffers drawing colour to something hideous like hot pink (or any other colour that you'll never actually use in your rendering) Render the entities to the buffer Read the pixel colour at the cursors position and store it Set the back buffer as the current buffer Render the entities to the buffer (this time to the back buffer so we can get some actual visuals) Now when you camera pick an entity at position MouseX() and MouseY(), you can check the pixel colour you stored previously (which also relates to MouseX() and MouseY()). If the pixel colour is a hideous hot pink then you know that... Even though the camera pick "hit" the entity, that specific pixel is transparent and the pick should in fact be ignored. Make sense? I'll neaten things up a bit and post an example in a few days, in the C++ section.

Nifty command, Unsuccessful however, it did give me an idea but that didn't succeed either. The problem there is that a surface's vertex colour is unaffected by the surface material or texture, it will always return the draw colour. Anyone done this before? Surely ignoring transparency is required by many

That’s cool, I'm aware. You have however sparked a new idea for 2d drawing and testing transparent pixels. Back to the question at hand: I create a simple mesh, I paint it with a material which includes transparent pixels, say the image is of a window and the glass panes are transparent. If I camera pick the mesh, I'm trying to get the pick to ignore the transparent pixels, so in effect the pick will return true only when performed on the window frame. Ideas?

That's the one, cheers. Blog entry not a forum post, explains why I could not locate it. Indeed you're right, transparent pixels are not ignored, so much for my memory. Well lets focus on the second line of thought, what is a good method (or theory) that allows picks to ignore transparent pixels.

A while back someone on the forum was working on a GUI, they posted a few video updates, but for the life of me I can't locate the threads. The video demonstrated simple rollover and clicking (visual only) functionality, the controls they had rendered to the screen were circular and the video showcased the cursor ignoring what I assume to be the transparent pixels from the texture/material. (either that or the controls were circular meshes, but I doubt it) Does anyone know the thread I'm talking about, I'd very much like to speak with the forum member responsible. As an interim or second line of thought, how would one go about ignoring transparent (alpha) pixels when camera picking, I've trialed a few approaches but need some external input.

Clearly I'm drumming up a little design discussion to capture peers GUI requirements as I’m currently developing one. I finalised the design and prototype for AGUI (Artists GUI) for a University assessment 2 weeks ago. The final version is planned for completion by the end of October 2010. The implementation is cross platform and LE independent, I'd be happy to PM the design specification. On a more thread specific note: I'm very interested in the community’s opinions on what functionality a GUI should contain, and the way widgets should be implemented. The thread has not quite gotten there yet. I have a GUI design spec but I'm just 1 programmer, its hard to think outside the box, as robust as I may think my design and implementation is, I’m sure its limited by my own GUI needs. Lets keep the discussion cracking. If Josh is after a GUI then let’s (as a community) brainstorm its design and specification, it will help us all out.

I agree with event driven GUIs, an OO implementation makes this easy This was achieved and determined by the player at runtime? My opinion is that a GUI's design should be art driven. Trial and error based GUIs implemented by a programmer at design time really limits the idea of a GUI. So I think the ability to load an artists predesigned GUI from file is important. How much control over widget design should be available to a programmer at design time? And what should be achieved behind the scenes?

I’m interested in hearing some peer opinions on GUI design (implementation not graphic). I have my opinions, but know that they won’t be shared by all. I’ll pose this as a list of questions that could easily be answered. I don’t think there are any strict answers to any of these questions but I value peer opinions. If popular this thread could become an interesting read for Leadwerks developers, before they begin their GUI implementations or before they choose a 3rd party library. • What do people feel are the “core” widgets necessary in a GUI system? • What widgets do people feel are unnecessary (for games development in particular)? • What should a GUI system implement? Image loading, audio playback, widget rendering, GUI load/save from/to file? Where do you draw the line? What functionality is outside the scope of a GUI and should be implemented separately? • How tied down to you engine of choice should a GUI system be? • What options do you think are needed when rendering widgets? Should they be simple coloured quads? Loaded from images? Have visible borders? • What widgets should have adjustable opacity? • Should a GUI system have native font loading functionality? These are just a small handful of questions I can think of, any answers? Opinions? Other important questions?

Leadwerks does use windows.h, But you are quite right, as I mentioned it has been a long week of in depth reading and research, and as you pointed out a program will use the correct header for the platform it is compiled on, in the case of windows it is windows.h.

SDL uses windows.h, Not to worry it's been a long week of research into all things platform independent, I've managed to grasp the concepts. Cheers though

Anybody have a good solution for obtaining mouse coordinates, without windows.h (C++) or Leadwerks?

After a look through glew.h I was able to define the function using: PFNGLCOMPRESSEDTEXIMAGE2DPROC glCompressedTexImage2D; Seem right? The program compiles and runs, but no texture shows, this could be caused by: Incorrectly reading the surface pixel data Incorrectly creating an OpenGL texture Incorrectly texture mapping a quad anyone done this before ( manually reading an image file and creating an OpenGL texture), willing to look over my code and get it sorted out. I'm very much new to OpenGL.

I wanted to avoid using 3rd party libraries, but that’s exactly what glew seems to be I may as well use OpenIL if that’s the case *EDIT* Let’s keep this ball rolling. My issue is not the loading of the DDS file as that was simple enough. However assistance is needed in using this collected data to create an OpenGL texture. Anyone created their own OpenGL image and texture loader...care to assist?

Does anyone have experience in manually loading images and using the surface data as an OpenGL texture? I'm writing a DDS loader: In particular I need to use to OpenGL command glCompressedTexImage2D, I receive a linker error when trying to use it. The problem is I have no idea where the function definition is and therefore no idea which lib, dll, header, etc to include. Any thoughts? Anyone written their own DDS image loader (or other formats) before, if so I'd very much like to pick your brains and receive some mentoring.

I believe the issue is with scenes that do not have a directional light. If this is not in the bug tracker then it should be, you can handle this yourself or point me in the right direction and I'll make sure it gets entered

understood thanks alot, nice and simple

Now we're getting somewhere, Should pause/resume be performed outside the main loop? the logic of one solution would be to * every in game objects movement, animation, etc by a value and change that value to 0 when you want the game paused, but surly there is a better way.

int main(int argc, char** argv) { Initialize(); // Create a graphics window Graphics(800,600); //Load the SDK directory RegisterAbstractPath("C:\Leadwerks Engine SDK"); // Create a world if (!CreateWorld()) { MessageBoxA(0,"Error","Failed to create world.",0); goto exitapp; } TBuffer buffer=CreateBuffer(800,600,BUFFER_COLOR0|BUFFER_DEPTH|BUFFER_NORMAL); // Create a camera TEntity cam = CreateCamera(); MoveEntity (cam, Vec3(0,0,-5) ); // Create a visual mesh TEntity mesh = CreateCube(); //Create another mesh to cast a shadow on TMesh ground=CreateCube(); ScaleMesh(ground,Vec3(10,0.1,10)); PositionEntity(ground,Vec3(0,-2,0)); //Create a spotlight TLight light=CreateSpotLight(); PositionEntity(light,Vec3(2,2,-2)); RotateEntity(light,Vec3(45,45,0)); // Main program loop while(!KeyHit(KEY_ESCAPE)) { UpdateAppTime(); PauseApp(); // Make the visual mesh spin TurnEntity (mesh, Vec3(0.0,0.5,0.0)); // Update timing and physics UpdateWorld(AppTime()); //Make our render buffer the current buffer SetBuffer(buffer); //Render the world to the render buffer RenderWorld(); //Make the back buffer the current buffer SetBuffer(BackBuffer()); //Call the RenderLights command, passing our buffer which //contains color, depth, and normal data RenderLights(buffer); //Swap the buffers so we can see what was drawn Flip (); } exitapp: Terminate(); return 0; } This does not pause the application for me. It takes a while to load up and the cube still rotates, slowly, but still rotates.

Now, what is the right way to pause a 3d application, this could be pausing an RTS or RPG or even pausing the application whilst the in game menu is opened. What is the logic behind achieving pause and resume functionality?

Thats it, bug remains

I did, and I didn't doubt you. If the issue is not across the entire customer base then a fresh install should have sorted out any issues, but it didn't

Based on this I did a fresh install last night, but the problem remains. Anyone else have suggestions before I contact the developer?

I believe the ambient light issue was fixed. Does anyone else's tunnels.sbx render physics, nodes and guides (basically all OpenGL lines) as black instead of the normal colours? or is it just me