reepblue

I just want to resize brushes on two axes at once by the corners. 😭 I am sorry I'm so attached to the older controls, but everything just feels much slower to make in 2D. I usually layout using the top viewport and using the vertex tool is the thing close enough to the old way of resizing brushes (but arguably more useful). Maybe it also feels slow because copy/paste isn't in yet which I also use. One other thing I'd like to do is click on edges in face mode to select the face I can't see. For example, if I'm looking at the top view but want to move the Z+ forward, on the same viewport, I should be able to click the top edge to select that face. I think the little dot on the face does (or should) the same thing, but it's too small. I honestly would need to try it again.

I know there was a reason for this but one thing I was critical of all the modern engines was that I couldn't do this and I use this all the time. Hammer and the Leadwerks editor are the only two that support this. One idea is to allow two axis scaling is if two faces are selected that share the same edge and you try to scale it. I understand this is a change in workflow and I guess I'm just not used to everything yet. Clarification here. I meant instant creation, not selection. I have this off in Leadwerks and I am itching to be able to turn this off in Ultra.

Few thoughts while you continue on. 1) Please allow me to deselect an object by clicking on it again instead of asking me to select the void. I keep accidentally selecting things when I'm making things and I keep accidentally building things when selecting things and I only recently noticed that this happens because I'm trying to build something close of a selected object. 2) When resizing in 3D (In Face/Vertex mode), please change the cursor to the vertical resizer (I believe it's CURSOR_SIZENS in the API) when the alt key is used like in transform mode. It may be a good idea to ignore the alt key when resizing in the 2D viewports as it's useless and the brush will distort when you release the key while dragging. It's just odd. 3) I'm really, really, heartbroken that I can't uniformly scale brushes by scaling by the corner. I understand it because there's no logistical way to translate that to 3D but still, it's an end of an era for me. 💔 4) I'm not a fan of instant selection, and I don't care for instant selection for point entities. Hopefully an option will come online to disable it and it'll effect both tools. But the point entity tool works as intended.

The thing is, you need some sort of an array because you want to support multiple input values for the same action! This is how controller support works in my system. I check if ether the key or gamepad button is pressed. There are people who like to bind 2 different keys for the same thing. Maybe std::multimap would be a better option here? The entire system should also be action based. We shouldn't need a reference or instance to the input system. It should be emitting an EVENT_INPUTACTION event sending the action pressed to whatever needs it. Not only this will help to avoid the use of singletons but doing it this way will also allow very easy integration with different controllers down the road such as Steam Input. Those are my thoughts as I am still sitting here thinking about how I'm going to solve this problem,

This is a good start, but I can see this not scaling well when implementing controllers and other input devices. Also, I would make a PollEvents() function for the key events As much as I want to recycle my own library, I think I should make it like it's part of the engine itself. My current system is a DLL and uses raw pointers. Not sure how or if I'll add in controller support since Steam Input takes over XInput calls.

I think my input system fixes this because you're looking for actions instead of raw key presses. I still need to convert my system off of WinAPI and this seems like a good reason to start that soon.

Why would you make a class for the sky? Just use world->SetSkybox(). Also, don't use delete with Leadwerks entities. You would use Release() but the world class does this for you and you'll run into crashes if you try to manage entities on your own.

This seems to also happen on Windows 10 also with an RTX 3060 so I don't think it's a Window's 11 issue. Saying this now because Microsoft is forcing this machine to Win11 now.

We fixed this before the engine went Early Access. Right now the only issue I'm aware with AMD is with the tertian/maybe tessellation. I dunno, I'm team green most of the time because I can't be bothered. Maybe I'll re config a PC to have my RX 480 again.

Ok, it's possible just with elbow grease. I was expecting a virtual function to override but I'll give this a shot. Thanks.

I was wondering if it's possible or will be possible to have components listen to events. I've made custom events for changes to the settings, and I want my camera component to apply the settings whenever the event is emitted. For example, I emit the event with this function. void Settings::SetFov(const float value) { UpdateSettingsFile(); auto data = std::make_shared<SettingsData>(); data->float_value = value; settingstable["fov"] = value; EmitEvent(EVENT_SETTINGS_FOV, data); } And then in the Component, I want something like this. virtual void ProcessEvent(const Event& e) { auto camera = entity->As<Camera>(); if (camera) { if (e.id == EVENT_SETTINGS_FOV) camera->SetFov(e.data); } } From my understanding, there's no ProcessEvent virtual function in the current Component class, but I recall this being possible in earlier builds.

Nevermind, the shaders didn't copy over properly from the client. It lied and told me everything was up to date.

Something small I've found. The box in this example is green. #include "UltraEngine.h" #include "Components/Mover.hpp" using namespace UltraEngine; int main(int argc, const char* argv[]) { //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); //Create a camera auto camera = CreateCamera(world); camera->SetClearColor(0.125); camera->SetFov(70); camera->SetPosition(0, 0, -3); //Create a light auto light = CreateBoxLight(world); light->SetRotation(35, 45, 0); light->SetRange(-10, 10); //Create a box auto box = CreateBox(world); box->SetColor(1,1,1); // Material auto material = CreateMaterial(); material->SetColor(1, 1, 1); box->SetMaterial(material); //Entity component system auto component = box->AddComponent<Mover>(); component->rotationspeed.y = 45; //Main loop while (window->Closed() == false and window->KeyDown(KEY_ESCAPE) == false) { world->Update(); world->Render(framebuffer); } return 0; }

This is wonderful. I no longer need to rotate things by the widget tool. Now you need to re-implement switching between transform and rotate by clicking on the object when selected and I'll be a happy camper. I think you should re-add the widgets as it gives you visual feedback what mode you're in. Should they be operational? I don't know. But I like them being there to tell me if I'm about to move the object or rotate it. May as well throw in the scaler widget too. Also, you need better cursors. It might be aesthetics, but I think it'll make your editing tools more obvious. I also would like something that showed me the origin of the object. Creating brushes in 3D is better, but I'm still making brushes in places where I didn't intend to make them. I sometimes make the brushes behind my structures and the height of the brush seems to be the highest brush made in the session. I would like to turn instant creation off and adjust my wireframe to build by brush where I need it to be. In Leadwerks, I have instant creation for brushes turned off as I sometimes use the wireframe to measure.

I like textured/flat rendering (no lighting) for dark areas like caves and wireframe mode can be useful if it shows me how things are culled. I never ever used solid mode.

With the new engine coming along and me noticing limits with Cyclone's current architecture, it's time for me to start thinking about the mistakes I've made and how would avoid repeating them with the new engine. Luckly, Ultra Engine is far more flexible than Leadwerks thanks to smart pointers and the event system. I wish to share some of my plans going forward. Log, Log, Log Everything! I personally never look at my log files. I instead look at the CMD output and the debugger to see what's going on. However, end users don't have that luxury. The engine will automatically log its warnings and error messages, but it'll not tell you when that message was printed or the events that led up to it. Creating your own log stream like this will give you far more control over your log file. // Prepare the log file. auto logfile = WriteFile("Game.log"); // Main loop bool running = true; while (running) { while (PeekEvent()) { const auto e = WaitEvent(); if (e.id == EVENT_PRINT) logfile->WriteLine(e.text.ToString()); } } logfile->Close(); logfile = NULL; You can easily do add time stamp before the message, so you have an idea when the event actually happened. You can use real world clock time or the current application time. Do Nothing OS Specific (Unless It's Aesthetic) Cyclone is a Win32 application. Period. It works wonderfully on Proton and there isn't any reason for me to install an outdated version of Ubuntu and waste time making a native build for Linux that'll only sometimes work. I took the liberty of using the Windows API to create my own Input System, XInput integration, and the Splash Window. I also created a custom DLL for my Input System so the Action Mapper application would use the same system as the game. Going forward, I want my code to work wherever Ultra Engine can run on. This means sticking to the API for mostly everything unless I need to use a 3rd party library (Like Steamworks). Still, 98% of your users will be using Windows so you might as well add some nice touches like the application knowing what theme the user is using and dressing your application accordingly like this. Launch Arguments != Settings If you've programmed with Leadwerks, you should be familiar with System::SetProperty() and System::GetProperty(). This by default will register a launch argument as a setting and then save it to a settings file. Cyclone works like this too, but arguments don't get saved to the settings file to avoid confusion. I never used arguments to override settings. I only used -devmode, -console, -fullscreen, +screenwidth and +screenheight. So, instead of mixing launch arguments with user settings, I think just going to keep them separated and only use the arguments to tell the application how to launch. Everything Will Be One Cyclone ships with 2 applications. One being the main game, and the other being the Action Mapper for key binding. They both share a dynamic library. This is because Cyclone is made using Leadwerks and the Action Mapper is made using Ultra App Kit. I want to make a Console window to remove it from the UI and a dedicated window for graphic settings would be handy. My new approach will make these separate windows that can be called with a launch command. Compartmentalize Everything I ran into many conflicts when adding working on the Flag Run update. Cyclone was structured to be a Puzzle game, and here I was adding clocks and an auto reload system. I had to do a lot of edits to my code to make it work and not break the older maps. Because of how Leadwerks worked, I had to do a lot of mixing and cross referencing of classes. In the end, it's all very messy now and it discourages me from adding to it more. My game application code will only create the window, framebuffer and camera. It's also will be responsible handle scenes and emit events. The components should do everything else. I plan to make a component for the always existing camera entity and have it listen to events when to show UI elements or change its settings. I can make the UI and settings components separate too! Since there will be multiple "apps" in one application, I kind of have to do this. Thankfully, I don't have to do things like create my own reflection system this time... Get The Essentials Right, The First Time When you're making your first game, you generally want it up and running as soon as possible. Everything else critical you'll say "Meh, I'll worry about that later". Why would you spend time on things like an Input System or A Sound System if you don't even know the game is fun? A month or so later, you find yourself figuring out how the new systems you just built should be integrated with the existing game code. It's not funny, it's not fun. I already have a game, and I know what works so I don't need to repeat that again. And being that the engine isn't 100% yet, I have plenty of time to get the essentials right. Here is what I'll be spending the first few months on. Ensuring that windows display and activate correctly. A splash window should show up, and the next window should be brought forward 100% of the time. Cyclone has a bug right now which a game window doesn't get brought to the top although I'm using every API call to make it do so. Settings system should be in-place before drawing a 3D cube to a framebuffer. I have a very good input system in Cyclone already, but it relies heavily on WinAPI to work. I also include XInput code which gets overwritten by Steam Input anyway. The input system will now need to use the engine's API instead of Windows. This system will work exactly the same as I have it today, but I think I'm going to leave out controller integration for now. I really liked using FMOD, but to lower dependencies, I think I should try the new OpenAL-Soft sound engine. I plan for my new system to read json scripts for sound entries that contain data for the Speaker and close captioning to display on the screen. I plan to get cracking within a few weeks! I set up my PC with the RTX 3600 running Windows 10 to develop and stream to Discord! I noticed a lot of slow down with my GTX 1050 running the engine in fullscreen so it's time to use something with more power. I am keeping an eye out for a good price on a 4070 Ti though.

I agree. I recall changing values to public members of the character controller class for Cyclone. I shouldn't need to do that.

@Josh Everything works well in 3D, but my 2D experience feels like a total downgrade. I can't resize brushes correctly in the viewport at all. It's not that intuitive to change modes. I miss double clicking to change between resizing and rotating the brush. I now need to take my mouse to the toolbar. Vertex mode doesn't work at all in 2D. I miss rotating brushes by the corners. Although it takes more time, it seems I can do what I want in 3D perfectly. Only things that tripped me up were multiple times of me selecting and moving a brush instead of creating a new one and vice versa. It's obvious that the 2D system wasn't the focus. I would say just go back to how you did it in Leadwerks, but I know you want consistency between 2D and 3D editing. I actually loved that you removed most of the widgets, and the rotation widget is nice for models/3D but it's terrible in 2D. If I wanted to rotate something to line up with something else, it was easier to rotate it by the nearest corner. Now I have to rotate it by the center, and I see it being really awkward. Overall, I think I should feel right at home using the editor like it was Leadwerks, but was surprised that things weren't working as I expected. I guess after half of my life using both Hammer and Leadwerks, I expect it to act how it always acted.

I also get the black viewport issues as well as the issues I described before. I haven't had time to really play with the recent updates, but I just hope the older 2D viewport tools with CSG come back. I want to still be able to rotate and scale with the corners. Also, don't forget shear!

It should. One thing it'll do is remake the textures from the sources so some textures will not be using the correct compression. Otherwise, it should work fine.