reepblue

That's because no components are included in the template. I was writing a few myself, but I got cold feet as I felt like I was telling people how to make their game. You can try this component in your project to ensure everything is working correctly. Also that was an odd bug with the Resolution Combo box but I do plan to overhaul the settings UI to have scrollbars and such.

That's normal for a first boot. You can fix the warnings by launching the app with -Settings and save down the default settings/controls. The error message is from the engine itself. If you're not using Lua, don't worry about it. If it bugs you, just make a blank file in it's place. Running the Preprocessor as admin should tell Windows to trust it going forward. If you're having issues getting the application to auto generate your component list, let me know. It works for me because I compile the application which you can also do since I have the code for that linked in my signature.

I ran into this trying to undo a deleted brush.

This was something I was working on but I'm reconsidering going back to a mono-component workflow. The code shows how to handle mouse look for an FPS camera both for Relative and Raw mouse look. This was made using the API systems found in my Game System and will simply work if you're using that. Otherwise, it needs modifications and stubbing of features. Sharing this as I know how awful it was for me to get this feeling right and it's nice seeing the system mostly isolated. Quick 180 turning, and zooming is also demonstrated, but there's a rendering bug with zooming atm. FPSViewControls.zip

Sorry for the bump, but I was wondering the status of this fix. I can't really get started what I want to work on until this is fixed.

This happens to me from time to time and I don't know why. One time, clearing out my ProgramData files for the engine worked, but when I had this happen again, it didn't work.

I'm curious if the Valve stuff still works as it's been a long time since I've tried the plugins.

Got it, here's a main.cpp example. I may want to consider revamping my settings panel since I now understand this. #include "UltraEngine.h" #include "CustomWidgets/ScrollPanel.h" using namespace UltraEngine; int main(int argc, const char* argv[]) { //Load plugins auto plugin_svg = LoadPlugin("Plugins/SVG.*"); //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 800, 600, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR | WINDOW_CLIENTCOORDS | WINDOW_RESIZABLE); //Create User Interface auto ui = CreateInterface(window); auto sz = ui->root->ClientSize(); auto scrollpanel = CreateScrollPanel(0, 0, sz.x, sz.y, ui->root); scrollpanel->SetLayout(1, 1, 1, 1); //Parent your widgets to scrollpanel->subpanel. auto panel = CreatePanel(0, 0, sz.x - 100, sz.y - 100, scrollpanel->subpanel); panel->SetColor(0, 0, 0, 1); //Call SetArea to set the size of the entire subpanel. scrollpanel->SetArea(1000, 1000); while (true) { const Event ev = WaitEvent(); switch (ev.id) { case EVENT_WINDOWCLOSE: return 0; break; } } return 0; }

Push an update today fixing VR support. I also changed how you define if your app is a dedicated VR app. See the config.json file for details. Removed the ConsoleWindow and SettingsWindow and put all the code into a PanelUI class which can be used both in a window and within the Vulkan Renderer. Lastly, I refreshed the solution files to reflect the changes made to the ones shipped in the stock C++ template.

Should be the same.

I'm having a hard time understanding the Scroll Panel widget found here. I tried parenting my custom panels to the subpanel pointer, but it doesn't draw the sliderbar. A main example would be appreciated as I need this for my settings panel.

I've been making my components into separated parts now and I gotta say, it's nice to only focus on one part of the system at a time, but I miss the "Place an entity in the world, and attach a script to it approach". A good example would be with a portal system. You can have one component be for the rendering, one for the collision and another for teleportation. I've been meaning to write about my experience, but I keep getting caught up in other things. I'm also waiting for bugs to get fixed and allowing other entities to be referenced in the component properties panel.

Pushed a new build today with VR Intergration! You can easily enable VR in your project in one or two ways; Use the -vr argument. If your game is a dedicated VR application, you can force VR by making a new table in the config.json file. "engine" { "vr": true } You can also use the engine table to define the rest of the engine settings, but tread carefully! If you wish to temporarily disable VR, then use the -novr argument. The Preprocessor was updated with the change today and I removed the GameObject class. I'm still playing with components so a future update will come eventually. The solution doesn't include the System Environment edit or any recent changes. I'm going to be syncing the solution files at a later date.

Fixed it, but still not getting this issue.

I was able to compile my project just fine with the delayload option, but it seems to be ignoring it. I'm probably going to refresh my projects being all the changes that happened recently.

This has been updated so the header generated will now be named ComponentSystem.h instead of RegisterComponents.h.

Can the installer create a System Environment Variable for where Ultra Engine is installed? I think this will help make installing tools and sharing C++ projects easier if we can just reference something like %ULTRAENGINEPATH% in batch scripts or the PropertiesSheet.props file. This is now more important as there's the Steam install and the standalone version.

Noticed this too but I couldn't tell if this was intentional or a feature. I agree with you regardless. I don't like this.

This looks like a huge time saver! With this enabled as a converter, no model will accidentally be left using png images.

The code will remain C++ but in the future I plan to expose the more useful classes to Lua. The idea is that you can still have your game component code as Lua while the backend stuff is C++. I'm not sure how to manage/distribute something like this as I would be required to build the executables for all platforms on every release.

Notice that components attached to entities with a parent don't save properly. I've ran into an issue where my camera (Which is a child of a pivot) rotation doesn't save automatically. I tried to patch this within the component, but then I noticed that the Load function is skipped when the scene is reloaded. Saving works fine. This example shows how the component load function is skipped on a scene reload call. #include "UltraEngine.h" using namespace UltraEngine; class TestComponent : public Component { public: TestComponent() { name = "TestComponent"; } void Start() { Print("Start"); } shared_ptr<Component> TestComponent::Copy() { return std::make_shared<TestComponent>(*this); } virtual bool Load(table& properties, shared_ptr<Stream> binstream, shared_ptr<Map> scene, const LoadFlags flags) { Print("Loading TestComponent"); return true; } virtual bool Save(table& properties, shared_ptr<Stream> binstream, shared_ptr<Map> scene, const SaveFlags flags) { Print("Saving TestComponent"); return true; } }; int main(int argc, const char* argv[]) { RegisterComponent<TestComponent>(); if (AllocConsole()) { freopen("conin$", "r", stdin); freopen("conout$", "w", stdout); freopen("conout$", "w", stderr); } //Get the displays auto displays = GetDisplays(); //Create a window auto window = CreateWindow("Ultra Engine", 0, 0, 1280, 720, displays[0], WINDOW_CENTER | WINDOW_TITLEBAR); //Create a world auto world = CreateWorld(); //Create a framebuffer auto framebuffer = CreateFramebuffer(window); //Load scene auto scene = CreateMap(); auto camera = CreateCamera(world); auto ent1 = CreatePivot(world); scene->entities.push_back(ent1); auto ent2 = CreatePivot(world); ent2->SetParent(ent1); ent2->AddComponent<TestComponent>(); scene->entities.push_back(ent2); //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { if (window->KeyHit(KEY_F5)) { //Save the starting scene to a file Print("Saving..."); scene->Save("game.sav"); } //Reload the starting scene when space key is pressed if (window->KeyHit(KEY_F6)) { Print("Loading...."); scene->Reload("game.sav"); } world->Update(); world->Render(framebuffer); } return 0; }

As first mentioned here. Normals don't return the right value with GetWorld()->Pick() on brushes. It's fine with models. auto end = LoadModel(GetEntity()->GetWorld(),"Models/Developer/Widgets/normal.gltf"); auto p0 = GetEntity()->GetPosition(true); auto p1 = TransformPoint(0, 0, viewdistance, GetEntity(), NULL); pickinfo = GetEntity()->GetWorld()->Pick(p0, p1, radius, true); bool lookingatvoid = !pickinfo.success; if (!lookingatvoid) { // Set the end point to the position. end->SetPosition(pickinfo.position); end->SetRotation(0, GetEntity()->GetRotation(true).y, 0); end->AlignToVector(pickinfo.normal); } Wanted to make this it's own thread so it doesn't get forgotten.

I've also seen files being identified as folders when a new file is added to the project when the editor is opened.

On the subject of a widget, I think it's more important for the 3D viewport than the 2D viewports. I love moving things around in the 2D viewport, but in 3D, it can get a little sloppy. I mostly liked the widgets because they automatically showed the origin point and the entity's rotation (In local mode) without anything else being needed.

I got to play with it and my first reaction was: The example models snap right into place where I want it to go. It feels so much better. For uniformed models, this is perfect, but I understand not every model is like this. Making brushes seems much better, but it might be a placebo effect. I'll have to play with it more. But I was the only one complaining about this, I guess let's see if anyone else finds this a step forward or backward.