Jump to content

Ultra Engine testing


Josh
 Share

Recommended Posts

Yeah...there's also something else. It's more complicated than that.

When you record a frame, that command buffer might be reused several times. There is also a transfer command buffer, which gets run once per frame and is not reused. So we will need something like HOOKID_RENDERTRANSFER as well.

Should there be an optional boolean value in AddHook() for a hook to just get call once, or should the the hooks themselves call RemoveHook() inside the function? I don't know...

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

I personally like it more if I can handle all these things my self. So a removehook would be best. For everything else I first need to get everything working and let my mind fully transition from OpenGL to vulkan again ( which is hard after working with OpenGL for a long time ). If Someone understand this, it is you ;)

  • Windows 10 Pro 64-Bit-Version
  • NVIDIA Geforce 1080 TI
Link to comment
Share on other sites

I've spent the weekend with this. I gotta say, Ultra Engine is very verbose, and I really had to think about what I was doing. I've created App classes that do all the setting handling and Window creation alongside a Stage class much like I did with Cyclone.  I wrote a lot of function wrappers, so entities are created to the stage world and registered to a vector list, so they don't go out of scope. 

What will be really nice is that I'll not need to recreate the camera every time the map loads. 🤪

Not too sure how loading a scene is going to be since I see it as its own container of entities. I might have a scene member and push new entities to its "entities" vector. 

unknown.png?width=914&height=514

unknown.png?width=913&height=514

 Things I've in-countered:

  • Scroll bar is still broken.
  • Still can't make sense of how the component system works. I had better luck copying and pasting the preprocessor to my game folder but it still wasn't working correctly. I'm under the impression it's still a work in progress. Right now, I guess I'm sticking with my StageActor class.
  • Parent UI windows don't like to be parented to windows with an active frame buffer.
  • Showing a complex array of panels for the first time takes a bit, even on Release.
  • I can't seem to create anything besides panels, labels and sliders within the frame buffer. That's why I only have 2 panels and a label up above, the rest is commented out.
  • Not a big fan of having the compiler freak out and report 120 errors for minor syntax errors. It's more of a chore to find out what's wrong compared to working with Leadwerks. 
  • I would like a UpdateMatrix hook for the entities.
  • I would like access to the material's json class member so I don't have to reload anything.
  • I would still like access to Model::collapsedfrombrushes
  • Noticing this grey ugly dot on the reflection of the cube.

unknown.png

Hope this was helpful.

  • Thanks 1

Cyclone - Ultra Game System - Component PreprocessorTex2TGA - Darkness Awaits Template (Leadwerks)

If you like my work, consider supporting me on Patreon!

Link to comment
Share on other sites

I think the gray dot is caused by an unclamped BRDF texture. Don't worry about it right now, there's a long explanation I could give but it wouldn't really make your life better to know it. :D

1 hour ago, reepblue said:

Ultra Engine is very verbose, and I really had to think about what I was doing

I am curious about the specific situation you had? Some of that is by design, some is due to Vulkan, and some might need to be ironed out. I think there is a ternd for APIs to become more verbose as they become more capable, but hopefully we can make it as smooth as possible by always choosing the most common usage as the default.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

1 hour ago, reepblue said:

Not a big fan of having the compiler freak out and report 120 errors for minor syntax errors. It's more of a chore to find out what's wrong compared to working with Leadwerks. 

I am guessing this had something to do with shared pointers, like assigning an incompatible type to another?

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

1 hour ago, Josh said:

I am guessing this had something to do with shared pointers, like assigning an incompatible type to another?

My two cents - using the old version you gave access to on steam - errors surrounding shared pointers are a headache to track down as they take you to headers like memory.h. etc... with no indication on where the actual problem you typed is...

Link to comment
Share on other sites

What usually happens is you will get an error like this, with no clear indication of where in your code the mistake lies:

Untitled.thumb.jpg.01d20ba38998d4fd2729a5f0e2454d2f.jpg

But if you switch over to "output" you will see the line in your code where the mistake actually is, two lines down from the highlighted line:

Untitled2.thumb.jpg.2bd3c8083fea5e56cb3e98e07c23d694.jpg

You can double-click on a line of text in the output window, too, and it will take you to the place in your code where the error is.

I wish Microsoft's handling of these errors was better, but C++ is an octopus made by nailing legs to a dog.

  • Haha 1

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

Again some progress :)

auto targetTexture = CreateTexture(TextureType::TEXTURE_2D, 256, 256, TextureFormat::TEXTURE_RGBA32, {},1,TEXTURE_STORAGE);
	auto cshader = ComputeShader::Create("Shaders\\Environment\\checkerboard_gen.comp.spv");
	cshader->GetPipelineBuilder()
		->AddImageBinding(targetTexture);
	cshader->BeginDispatch(world, 16, 16, 1, true);

	auto mtl = CreateMaterial();
	mtl->SetRoughness(0.25);
	mtl->SetMetalness(0.5);
	mtl->SetTexture(targetTexture, 0);

this code actually works and results in this:

image.thumb.png.0e362d17a83d94d67a88f1fe6e4dd746.png

a small generated checkerboard texture generated by a compute shader :)

  • Like 3
  • Windows 10 Pro 64-Bit-Version
  • NVIDIA Geforce 1080 TI
Link to comment
Share on other sites

I use the LoadShaderModule from UltraEngine and the provided info from the Texture (GetViewHandle). Everything else is plain Vulkan, no middle layer involved. It is also currently very limited as i have only implemnted the Image binding, next is buffer binding and a lot of refactoring as vulkan is a pain to keep track of all possibilities.

  • Windows 10 Pro 64-Bit-Version
  • NVIDIA Geforce 1080 TI
Link to comment
Share on other sites

Compute shaders are much easier to manage than the full render pipeline. If you do get into render-to-texture definitely use the dynamic rendering approach, which does not require framebuffer or renderpass objects. The extension is already enabled in the engine.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

9 hours ago, Josh said:

@SpiderPig @reepblue 

When I updated Visual Studio to the latest, those errors now stop on your own code instead of inside weird header templates.

https://gamedev.net/forums/topic/712870-fixing-confusing-c-shared-pointer-errors/

I already had the latest, the example you gave in the link you provided worked okay but there's still other examples like this;

shared_ptr<Model> test = CreateModel(Core->world);
shared_ptr<void> user_data = test;
shared_ptr<Model> v;

v = dynamic_pointer_cast<Model>(user_data);

This might be a very bad way to do what I want to do, I'm not sure.  But this gives 4 errors that take you to memory.h.  But now looking at the output there is one line that leads to the problem in your own code.  (static_pointer_cast works here instead though) There are other cases that still go to memory.h and other weird headers but I can't remember what they are...

Link to comment
Share on other sites

21 hours ago, Josh said:

I am curious about the specific situation you had? Some of that is by design, some is due to Vulkan, and some might need to be ironed out. I think there is a ternd for APIs to become more verbose as they become more capable, but hopefully we can make it as smooth as possible by always choosing the most common usage as the default.

Part of it was due to the engine API with the biggest thing to get use to is defining what world to place the entities in. I'm trying to recreate the system I've engineered for Cyclone. 

Pretty much I want a window to be created and show a black screen. Upon hitting ~ on the keyboard, a console window should popup allowing control via input. I want to be able to type map <mapname> and the application will load the map file with all actors spawned and ready to go.

I do this within a Stage class which pretty much had everything I needed to render a scene on the screen such as the frame buffer, and world. It also managed Stage Actors which were derived from Leadwerks' Actor class.

With Ultra, things get a tricky as the engine can now handle multiple worlds at once. I see this being really handy for VR as there should always be an active world and you should never see the SteamVR Home loading screen when in-game. I also want to support changing window modes while the game is running as I got feedback on that not being possible with the old engine without causing a lot of issues.

There's now Scene classes instead of the contents of the maple being automatically dumped into the current world pointer. Right now I have multiple creation functions within my new Stage class that loads entities in the Stage's world and adds it to it's own vector container. Now thinking about it, I probably should just have a Scene class as a member of stage and just use that for my entity manager. My creation wrapper functions will just call the AddEntity call instead. This way, no matter if the entity is loaded from file or created from the actor, it'll all be within the scene class which is part of my Stage Class. 

Regarding actors, I currently created Stage Actors in the Ultra Engine implementation. The stage just updates and passes the polled event to all of it's registered actors. This actually was really helpful drawing the panels to the screen, but I'm asking myself if I should continue to use it for gameplay objects. The new component system seems to be more modular and the editor would be able to read its values in real time thanks to everything being hpps. But because of that, and the need to use a preprocessor app, I may add support for how Actors were handled in Leadwerks. I prefer to use the hierarchy nature of C++ over a component system, hit I come from using Quakeworld tech, so I'm not the majority. 

I recall Ultra Engine being able to read Lua scripts in older builds. If that's included, I'll try that out. But right now I'm just interested in creating the basics of a game; which is just a glorified map loader with command support.

Sadly, weekends don't last that long.

15 hours ago, Josh said:

When I updated Visual Studio to the latest, those errors now stop on your own code instead of inside weird header templates.

https://gamedev.net/forums/topic/712870-fixing-confusing-c-shared-pointer-errors/

I had my Visual Studio updated as well, and I still got sent to memory.h and xutility.h a lot telling me there were over 100 errors and warnings. I was also forcing myself to start using templates for things while not fully understanding how they work, so that probably didn't help ether. 

Cyclone - Ultra Game System - Component PreprocessorTex2TGA - Darkness Awaits Template (Leadwerks)

If you like my work, consider supporting me on Patreon!

Link to comment
Share on other sites

I just installed the SDK and had these errors pop up as it downloaded-  I just clicked okay and the process continued.

Error.thumb.png.6a5f28a6d15e40b2e580842780c01a20.png

 

Creating a new project worked nice and fast!  I created it on a separate drive though because C drive I like to keep free for my OS.  Loading up the project in VS and it can't find UltraEngine.h.  Is that due to the errors above or using another drive you think?

Link to comment
Share on other sites

  • Josh changed the title to Ultra Engine testing
  • Josh locked this topic
Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...