Jump to content

Ultra Engine testing


Josh
 Share

Recommended Posts

I know why this is happening. 🤡

The engine uses the depth buffer for 2D ordering, so it does not have to draw 2D objects in order. This is one of the reasons it is so fast. When the GUI generates sprites for all the interface elements, it starts by positioning them at the far depth range, and moves each one a little closer to the camera, to make it appear on top of the last one. It seems that at about 2000 the Z-position increments pass the near depth range, so the sprites after that are no longer visible to the camera.

Not a bug, just the way it is designed. Normal sprites that you position yourself will not do this.

  • Like 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

Yep, I confirmed this. I could make the increment smaller. I don't know what the lower limit is before Z-fighting will start happening. But I don't think this is really a problem, in any case.

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

13 hours ago, SpiderPig said:
  • No mouse events for tabber or button (disable the panel creating in the loop to see this)
  • Press Space a few times - Red panel clipping exceeds parents size by 1 pixel in both x & y
  • Sprite remains in renderlayer 0.  Solved!  Powers of 2 required.  Only downside to not use the enum ;)
  • Tab page and button left border clipped off
  • Drawing widgets stops at the 2,000 mark?  Excessive I know but is this some sort of limit or bug?

I'm not going to worry about small cosmetic issues right now. There are a few places where a line is off by one pixel, or something like that. This should be resolved, but I would like to focus on anything more important right now.

  • Upvote 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

2 hours ago, SpiderPig said:

Got it to work, Thankyou.  Should the sprites follow the same position system as the GUI?  I mean 0,0 at the top left?

No, because your sprites are in 3D space. Just calculate the Y position like this:

y = framebuffer->size.y - y

I suppose the fact there is no 2D drawing is an argument for camera project/unproject to pre-flip the Y coordinate.

  • Like 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

34 minutes ago, Josh said:

No, in the GUI system everything is right angles. I thought about adding lines and Bezier curves in a future update.

I manged to use a sprite for now.  Looks okay but maybe AnitAliasing will help with this when it's ready.  Can I simply change the depth position of a sprite so it can appear behind a widget?  In this case the line sprite needs to go behind the "head" panel.

CharacterLines.png.d529abdb4f63c720d77feea8838a72cb.png

Link to comment
Share on other sites

Update

  • Fixed serious bug in thread manager that could have affected all system, physics, rendering, culling, etc. The wrong mutex was being locked when commands were added to the thread command buffer. 😱
  • Number of maximum GUI widgets visible will probably be about 20,000 now
  • Like 2

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

45 minutes ago, SpiderPig said:

I manged to use a sprite for now.  Looks okay but maybe AnitAliasing will help with this when it's ready.  Can I simply change the depth position of a sprite so it can appear behind a widget?  In this case the line sprite needs to go behind the "head" panel.

You could also just create a model with a mesh that uses lines:
https://www.ultraengine.com/learn/CreateMesh

  • Thanks 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

@Josh

Made a pull request to the preprocessor to allow user flexibility. It'll still work the same way without any additional parameters set. Decided to contribute it as this will probably change as the engine matures.

  • Added arguments to define search paths and file names.
  • Added timestamps to be written to generated files.
  • Added timestamp to the start of the application.
  • The preprocessor will force a rebuild if the application is newer than the component system files.
  • Fixed GetComponent() not having a return value in all cases.
  • Added Help screen. when -help is set.
  • Set the project to be built as a console application.
  • Fixed size conversion warnings.
  • Fixed a typo.
  • Like 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

Yes. If the preprocessor is ever newer than an existing project, it'll force a rebuild.

	//Compare it with the time of this application.
	//If this application is newer, force a rebuild. 
	if (FileTime(WString(argv[0])) > headertime && !rebuild)
	{
		Print("Regenerating Component System files as the pre-processor has been updated since last generation.");
		rebuild = true;
	}

 

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

Should note that my EOF fix doesn't work when compiling with the engine. But it's super simple to fix with a comment.

// 230102 - reep: Make me compatible with the engine.
#if !defined (Eof)
#define Eof EOF
#endif

The engine defines _ULTRA_APPKIT so there isn't a safe way to find a difference between the two. However, it's more ideal to keep compile this with UAK as it's a shorter build time.

 

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

 

Okay, your changes to the preprocessor are live now.

I also removed UPX compression from the VS template. I don't recommend using this because it can sometimes trigger antivirus programs.

 

  • Like 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

7 hours ago, Josh said:

Update

  • Fixed serious bug in thread manager that could have affected all system, physics, rendering, culling, etc. The wrong mutex was being locked when commands were added to the thread command buffer. 😱
  • Number of maximum GUI widgets visible will probably be about 20,000 now

So this was the cause of the random crashes?

Link to comment
Share on other sites

  • Josh locked this topic
Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...