Laurens

I don't think you quite grasp the concept of Editor (Sandbox) and the SDK. Think of Editor like a car. The car provides high-level functionality such as accelerating. The engine of the car (the SDK) is what makes it possible on a low level such as injecting the proper amount of gas when you hit the gas. A car (Editor) without an engine (SDK) is useless. I hope that cleared it up a bit

Signed up aswell, hopefully I'm not to late Cheers!

Hi, Correct, but as of LE 2.3, Sandbox has been renamed to Editor. Yes, as Shard already said, it is a fully fledged level editor. You can download an evaluation kit from the download section that includes Editor. If you want to make a game you will need to learn some programming language or have a coder on your team. With the addition of LUA scripting it is fairly easy to pick it up though. If you have any additional questions, don't hesitate to ask

You can try compiling your project with VS2008 from VS2010. Open up your project settings and go to "General". Then set the "Platform Toolset" to "vs90". You will need to have VS2008 (express will be fine) installed. Cheers!

Hi Rick, I just managed to get it working! The following code glPixelStoref(0x806E, 0); // GL_UNPACK_IMAGE_HEIGHT glPixelStoref(GL_PACK_ROW_LENGTH, 0); glPixelStoref(GL_UNPACK_ROW_LENGTH, 0); is only part of the solution. For the previous lines to take effect you have to enable extra state settings on the OpenGL renderer before calling them like so: ceguiRenderer.enableExtraStateSettings(true); I will write a blog later today or tomorrow getting Leadwerks working with Framework and CEGUI. Many thanks for the help everyone Cheers!

Thanks Rick, looking forward to it

I am willing to supply a working template if I can get it up and running properly. I have been following the documentation over on cegui.org.uk and my code compiles fine, it just isn't showing anything on the screen. My setup routine is as follows: ScreenManager::ScreenManager() : ceguiRenderer(CEGUI::OpenGLRenderer::create()) { framework.Create(); CEGUI::System::create(ceguiRenderer); CEGUI::DefaultResourceProvider* rp = static_cast<CEGUI::DefaultResourceProvider*>(CEGUI::System::getSingleton().getResourceProvider()); rp->setResourceGroupDirectory("schemes", "GUI/schemes/"); rp->setResourceGroupDirectory("layouts", "GUI/layouts/"); rp->setResourceGroupDirectory("looknfeels", "GUI/looknfeel/"); rp->setResourceGroupDirectory("imagesets", "GUI/imagesets/"); rp->setResourceGroupDirectory("fonts", "GUI/fonts/"); rp->setResourceGroupDirectory("schemas", "GUI/xml_schemas/"); CEGUI::Scheme::setDefaultResourceGroup("schemes"); CEGUI::WindowManager::setDefaultResourceGroup("layouts"); CEGUI::WidgetLookManager::setDefaultResourceGroup("looknfeels"); CEGUI::Imageset::setDefaultResourceGroup("imagesets"); CEGUI::Font::setDefaultResourceGroup("fonts"); CEGUI::XMLParser* parser = CEGUI::System::getSingleton().getXMLParser(); if(parser->isPropertyPresent("SchemaDefaultResourceGroup")) { parser->setProperty("SchemaDefaultResourceGroup", "schemas"); } } Then, the constructor of the MenuScreen is supposed to add a new frame window: MenuScreen::MenuScreen() : Screen() { CEGUI::SchemeManager::getSingleton().create("TaharezLook.scheme"); CEGUI::FontManager::getSingleton().create( "DejaVuSans-10.font" ); CEGUI::System::getSingleton().setDefaultFont("DejaVuSans-10"); CEGUI::WindowManager &wm = CEGUI::WindowManager::getSingleton(); CEGUI::Window *root = wm.createWindow("DefaultWindow", "root"); CEGUI::System::getSingleton().setGUISheet(root); CEGUI::FrameWindow *fWnd = static_cast<CEGUI::FrameWindow*>(wm.createWindow("TaharezLook/FrameWindow", "testWindow")); root->addChildWindow(fWnd); // position a quarter of the way in from the top-left of parent. fWnd->setPosition(CEGUI::UVector2(CEGUI::UDim(0.25f, 0), CEGUI::UDim(0.25f, 0))); // set size to be half the size of the parent fWnd->setSize(CEGUI::UVector2(CEGUI::UDim(0.5f, 0), CEGUI::UDim(0.5f, 0))); fWnd->setText("Hello World (from CEGUI)!"); } It is then rendered as follows: void ScreenManager::Render() { framework.Render(); CEGUI::System::getSingleton().renderGUI(); } Immediatly after which Flip(1) is called. I ran the example Drew wrote in http://leadwerks.com/werkspace/index.php?/topic/1484-cegui-leadwerks/page__view__findpost__p__13811 just fine but that example was not using Framework. Could this be causing it? Cheers! EDIT: There are not errors in Cegui.log whatsoever.

I agree that most are pretty bloated but I prefer not to spend time on writing a system myself. Perhaps I'll replace it later on in the process but right now I would like to focus on gameplay.

Thanks for the links, I should use the search function more often Anyway, CEGUI seems like the right way to go and will give a crack at implementing it with my project. Cheers!

Glancing over the CEGUI documentation it seems really easy to integrate. http://www.cegui.org.uk/api_reference/rendering_tutorial.html The setup for OpenGL is apparently limited to: // Create an OpenGLRenderer object that uses the current GL viewport as // the default output surface. CEGUI::OpenGLRenderer& myRenderer = CEGUI::OpenGLRenderer::create(); And the drawing is limited to; // user function to draw 3D scene draw3DScene(); // draw GUI (should not be between glBegin/glEnd pair) CEGUI::System::getSingleton().renderGUI(); Is it indeed possible for OpenGL to grab a window that is already open, such as the window created by LE without passing a handle to it? It almost seems to easy. Cheers!

Hi guys, I am about to start working on a GUI and I was wondering if any of you have tried implementing a third-party library such as CEGUI or Navi, or are instead rolling your own. Cheers!

This has been fixed in the latest update. http://leadwerks.com/werkspace/index.php?/tracker/issue-59-crash-on-updateframework-when-using-callbacks/

Have you used the update tool (Tools/Update.exe)? I experienced the bug in r5 aswell until I ran the updater.

Hi Shard, Your last post makes me believe you are experiencing the bug I reported earlier. http://leadwerks.com/werkspace/index.php?/tracker/issue-59-crash-on-updateframework-when-using-callbacks/ EDIT: Josh had already solved it yesterday and I confirmed it is now working as it should. Most likely if you upgrade yours will be to.

I have been away for a few months and kinda lost track with all the updates. I installed 2.32r4 last week. Will the included updater correctly bring me up to r5 or do I need to keep downloading these packages? Thanks!

If I recall correctly there are some restrictions on the Dexsoft artwork (the Viper and perhaps other models). Can't say about the other artwork.

Agreed. Although I feel this is more of a design issue than a coding style. What are other people doing in this situation? Cheers!

I thought of that before but the problem is that you can get a gigantic source file when the game grows larger, which is why I opted for the solution above. In practice it works fine really, I just dislike the fact it has a cyclic dependency. If this is a standard practice for this kind of problem however then "Cyclic dependency is bad design" is not as black and white as I think it is.

When LUA was introduced I felt the same way as you MasteR. I intensely disliked working with LUA but over time it really just is an extra folder in your game map and some scripts that came with the engine anyway. Now I don't have to fuss over a ProcessScene() type of method. You can easily create a game without ever touching it yourself.

Personally I would love LUA, hadn't it been for the fact the god-awful way they hacked "classes" in.

Hi guys, It's been a while for me. Recently finished my internship and can finally dedicate some time to Leadwerks again It's great to see how much this place has evolved in just a few months and the GDC demo was absolutely stunning! Anyway, I will get to point I am currently working on a class diagram for my Breakout clone, the game state management part to be precise. I read several articles regarding game state management (http://creators.xna.com/en-US/samples/gamestatemanagement, http://gamedevgeek.com/tutorials/managing-game-states-in-c/ and http://www.codeproject.com/KB/architecture/statepattern3.aspx) and found they all have cyclic dependencies. For those of you not familiar with these articles, a quick explanation is in order. There is a StateManager and an abstract State, from which all other states (such as an IntroState or a GameState) derive. The StateManager obviously has references to a State but the State also has a reference to the StateManager so that they can push new states onto the stack themselves. A this point my college professor starts to reverb in my head. Cyclic dependencies are bad design! Cyclic dependencies are bad design! Cyclic dependencies are bad design! I was wondering what you guys think of cyclic dependency in a state manager. I though of a few ways around the issue as well: 1) Make the StateManager accessible through the GameEngine class or some sort, then push new states on the stack from a state using GameEngine::stateManager->push(new GameState()). I don't feel this is very OO. It feels more like a dirty hack. 2) Create a derived StateImplementation class that derives from State. Let the State have the reference to StateManager and let the StateManager have a stack of StateImplementation. Then derive other screens (IntroScreen, GameScreen) from StateImplementation. This would break the cyclic dependency but it would be the only purpose of the class and does not feel very clean either. Thanks!

I understand, but if you do so you need to be aware of the fact that MAC addresses can easily be forged.

For Linux there is GNU MAC Changer (http://www.alobbs.com/macchanger/). If my memory is serving me incorrectly about Windows there is still SMAC to change the MAC address (http://www.klcconsulting.net/smac/) or simply go into the registry and make the appropriate modifications. There is no need to modify the firmware at all and this works for all devices.

Do keep in mind that it is fairly easy to change one's MAC address and these tools are either built into your OS (Windows XP for sure) or are easy to get your hands on. Additionally, because there are only 3 bytes interface specific, and there only being a handful of large scale vendors (Intel, Realtek (the other 3 bytes in a MAC address)) makes the GUID susceptible to brute forcing if not coupled with some other piece of information.

The blame for the skybox issue can't be put on Josh. The fact that LE is one of the best engines available to indie developers is not negated by the fact that ATI has bugged drivers. This coming from an ATI user.