DGUI? Why is there none of them?

[HammerFist132]

Well I think they could be really useful and nice looking, but why is there none of them. Can someone create one simple dgui, that moves nice when camera scroll? Please.

 

[Maker]

Can someone create one simple dgui, that moves nice when camera scroll? Please.

No, it is difficult.

 

[HammerFist132]

Sorry to hear that. What about in camera locked like in wow?

 

[Zwiebelchen]

There is DGUI and I have already seen it in maps. But it's only recommended for Singleplayer maps, as getting the camera position is slower in multiplayer.

 

[HammerFist132]

There is DGUI and I have already seen it in maps. But it's only recommended for Singleplayer maps, as getting the camera position is slower in multiplayer.

can you please give me link of some map, I think it is in one map by ilidan - mass destruction, but I havent seen it nowhere else. So may you share.
Most of dgui maps of wc3c are or useless or dont work for 1.24+ patchs.

 

[Zwiebelchen]

can you please give me link of some map, I think it is in one map by ilidan - mass destruction, but I havent seen it nowhere else. So may you share.
Most of dgui maps of wc3c are or useless or dont work for 1.24+ patchs.

I don't have an example right now. Played some maps several years ago that had this. Google "DGUI+Wc3" and you will probably find the system.

However, forget about it if you want to create a multiplayer map. It just doesn't work.

 

[WaterKnight]

However, forget about it if you want to create a multiplayer map. It just doesn't work.

Problem is?

 

[Zwiebelchen]

Problem is?

In Multiplayer, GetCameraEyePositionX() is only updated every 0.1 seconds. This is far too few FPS for DGUI to look good. As soon as you turn the camera, the GUI will shake like crazy.

 

[WaterKnight]

Why would they...? Well, even in singleplayer, would it not be better to hide the display while the camera is moving? Or you could calculate the average speed and assume the player does not fluctuate that much.

 

[Zwiebelchen]

Why would they...? Well, even in singleplayer, would it not be better to hide the display while the camera is moving?

If you want a really crappy and unusable DGUI, then yes, you can hide the GUI while moving the camera.

 

[HammerFist132]

Yes it is really bad looking if it hides, while camera is moving

 

[Zwiebelchen]

Well, technically you could interpolate the camera target between two value updates to make it smoother.

Basicly this means that you take the last camera eye and target XYZ and the current camera XYZ and then calculate the movement speed by having a time stamp matched to the camera updates. Then you can interpolate the inbetween positions on 32 FPS even in multiplayer.
It will still "flicker" as soon as you change movement directions though.


If someone could write a camera interpolation snippet, DGUI should be possible in multiplayer.


Actually, I'm pretty interested in that. I'd love to write a system like this, but I'm just way too busy to do it.

 

[WaterKnight]

Which functions would you realize in a dgui anyway? I think the hiding is more helpful when scrolling because you want to browse the map then. Of course in fast-paced maps it won't work out to put vital gameplay inputs there.

The flickering could be beautified by transitions.

 

[Zwiebelchen]

Which functions would you realize in a dgui anyway? I think the hiding is more helpful when scrolling because you want to browse the map then. Of course in fast-paced maps it won't work out to put vital gameplay inputs there.

It would just look ugly. The idea of DGUI was that you can create permanent on-screen buttons or displays.
You could use it for monitoring basicly everything in your map without the need to use multiboards. Also, the idea of DGUI is that those icons and buttons are clickable, as they are either units or trackables. When using trackables, you can even add tooltips to those onscreen buttons.

When thinking one step further, even full screen inventorys would be possible without the need to move the camera away from the hero.
Or health bars attached to the corners of the screen.

The flickering could be beautified by transitions.

Interpolation only works between two or more points. As soon as you switch move directions of the camera, the interpolation will fail.

 

[WaterKnight]

It's a difference if you need to give your hero a life-saving health potion or it's an additional game progress display or you can open the options menu with a button.

Interpolation only works between two or more points. As soon as you switch move directions of the camera, the interpolation will fail.

I did not mean the input fluctuation but the flickering of the dgui component if you decided to instantly move it to the new coordinates of the player's screen. That would be really ugly and annoying. Better make it graduate towards the target location at high speed/slow down before arrival.

 

[Zwiebelchen]

It's a difference if you need to give your hero a life-saving health potion or it's an additional game progress display or you can open the options menu with a button.



I did not mean the input fluctuation but the flickering of the dgui component if you decided to instantly move it to the new coordinates of the player's screen. That would be really ugly and annoying. Better make it graduate towards the target location at high speed/slow down before arrival.

There's no need for that if you interpolate, as you will have 32 FPS then. The human eye will not notice any flickering there.

 

[Xonok]

Make it always take a certain amount of seconds to reach new position and update the move speed every 0.03 seconds. I did that with camera and used a 3-second timer - Way better results that just changing camera rotation.
I'm assuming with a DGUI the proper period would be something like 0.5-1 seconds.

 

[WaterKnight]

As you changed direction/strayed away from the interpolation, the dgui would shoot away from it's screen-relative position and reappear after the delay. If it just popped back instantly, that would be unaesthetic and less likely controlable for the player. Make it like a fun feature for the player to catch that little rascal like a missile.

 

[Xonok]

As you changed direction/strayed away from the interpolation, the dgui would shoot away from it's screen-relative position and reappear after the delay. If it just popped back instantly, that would be unaesthetic and less likely controlable for the player. Make it like a fun feature for the player to catch that little rascal like a missile.

That is true, however, with a sufficiently small timer it will always come back fast and thus, the shakiness wouldn't be as bad.

 

[WaterKnight]

Mapmaking is also deceiving and disguising disadvantages!

 

[Zwiebelchen]

That is true, however, with a sufficiently small timer it will always come back fast and thus, the shakiness wouldn't be as bad.

You should definitely update and instantly move the DGUI positions as soon as GetCameraEyePositionX() retrieves a new value. This is like every 0.1 seconds. Interpolation is only for smoothing the movement until the next update of the GetCameraEyePosition comes.

 

[Xonok]

You should definitely update and instantly move the DGUI positions as soon as GetCameraEyePositionX() retrieves a new value. This is like every 0.1 seconds. Interpolation is only for smoothing the movement until the next update of the GetCameraEyePosition comes.

Yeah, this would be even better.

 

[gorillabull]

i dont think the flickering is a big problem as this system is already at its limit also its not possible to make it not flicker because there is too much math used to calc the positions so as the update interval decreases the cpu load will increase thus causing lag

 

[Adiktuz]

I think the hiding is more helpful when scrolling because you want to browse the map then.

--> But what if the camera is locked to a unit, then whenever the unit moves, you lose the DGUI...

interpolation is cool, assuming you can make an accurate one... though that maybe really easy...

 

[WaterKnight]

If the camera was locked to the unit, you would not have to detect scrolling.

 

[Adiktuz]

Oh... yeah, you can just detect the unit's x/y...

 

[Almia]

Im so sad Mag didn't continue this system. He wants to make the camera movement friendly in the system.
You can contact gorillabull for a beta DGUI he made,it works and has scroll features.

Also, the camera's movement when using mouse is very fast for a timer 32 to attach it into the camera.

 

[Zwiebelchen]

i dont think the flickering is a big problem as this system is already at its limit also its not possible to make it not flicker because there is too much math used to calc the positions so as the update interval decreases the cpu load will increase thus causing lag

From my perspective, the amount of maths is pretty small, actually.
You need a little bit of vector algebra, of course, but nothing that can't be handled.
You just need to make sure that the trackables are extremely close to the camera eye. The closer the objects are, the less of a problem are variations in terrain height.

 

[Zwiebelchen]

Btw, have you guys already tried:
http://www.wc3c.net/showthread.php?t=102351

Seems that the maker is still active (last post was on march 2013). You might be able to contact him.

 

[HammerFist132]

I have tested all dgui from wc3, some of them are working, most dont work for 1.24+ patch, and this you have linked looks really ugly when you are moving camera.
Also there is bag system with dgui (first in "samples" on wc3c), but it is not working for 1.24+ (i heard that that bag system looks nice even when camera is moving).
Btw I feel like there is too much talking and not much working.

 

[Zwiebelchen]

I have tested all dgui from wc3, some of them are working, most dont work for 1.24+ patch, and this you have linked looks really ugly when you are moving camera.
Also there is bag system with dgui (first in "samples" on wc3c), but it is not working for 1.24+ (i heard that that bag system looks nice even when camera is moving).
Btw I feel like there is too much talking and not much working.

All you need to do to make them 1.26 compatible is replacing all H2I functions by GetHandleId().

Why should we work on this? We never said we need it, just saying how it could be done.

 

[HammerFist132]

please can you do itif have some free time), because I dont know jass/vjass

 

[Zwiebelchen]

You just replace this:

function H2I takes handle h returns integer
   return h
   return 0
endfunction

by this:

function H2I takes handle h returns integer
   return GetHandleId(h)
endfunction

and all the systems should work in 1.26.

 

[Almia]

There is a working version found in EpicWar.

 

[HammerFist132]

link?