Advanced HUD Tools

[Beer]

Good deal.. thanks for the info.

[emspike]

And if I remember right, HUD2 is supposed to be hispeed-capable (maybe I'm wrong, but I remember moggie saying that somewhere).

[moggie100]

I'm back!

Sorry, I've been back and forth from home, my girlfriend's home, and our place through all of December and the first part of January, hence the lack of updates.

I'm still working on the compile stage (mainly converting existing functions), but dont worry, this isn't going to change HUD2 into a CPU-style chip - to the user it'll be identical to how it is now, but in the background it'll be doing:

Code -> Parse -[send to server]-> Hook -[send to clients]-> JIT Compile -> Render

Which should (hopefully) be quicker, as by the time it hits your display its just rendering, with no processing during a frame

I'm sorry if this has been asked/answered countless times already, but I'm not about to go searching through 47 pages of HUD1 and HUD2 discussion. (perhaps a FAQ is in order)

Can HUD2 interface with E2? For example, if I wanted to make a settings/options dialog with derma to control settings for an expression, can clicking on a checkbox modify the value of a variable within my expression on the fly?

I sure hope so... but after reading your wiki page about the built-in math/string functions, I'm a little worried HML is being kept entirely separate from E2 (or wire in general for that matter). Preventing this capability would severely limit its potential.

The math functions are mainly for in-situe calculations to simplify things. For example, say we have a progress bar of width 320px on screen, but you have a wire output doing 0->100, it makes sense for HUD2 to be able to do the 3.2*Input calculation without having to slap an E2 in between, or such.

This quickly leads to the need for trig functions for radial displays, (pointers, gauges, etc) hence the large-ish math lib.

It was -never- intended to be a replacement for anything in wire, merely an injection of UI to it

And if I remember right, HUD2 is supposed to be hispeed-capable (maybe I'm wrong, but I remember moggie saying that somewhere).

Currently its not, but this is mainly because of the difficulty in representing dynamic I/O in a sane way, but it is listed as a 'wanted feature' on my current list.

-=Edit=-

As for an FAQ - I don't really have time to start collating one, but if someone sets up a page/section on the wiki with the older questions on it, I'll add anything NEW to it and/or correct anything.

Also, I don't remember saying it before, so in case I haven't - Thanks to Divran and Mangos Mechanicus for helping maintain HUD2's wiki page!

[TomyLobo]

<portmapping>
<port name="A" hispeed="5" />
...
...
</portmapping>
numbers as a single cell
strings as pointers to zero-terminated strings
vectors/angles/matrices/complex numbers/quaternions as as many cells as they have elements
arrays as a pointer to their contents. see XWL:writeArray(R) on how to do it

data for arrays and strings could be written in a separate area, like >= 1024 or something

[moggie100]

<portmapping>
<port name="A" hispeed="5" />
...
...
</portmapping>
numbers as a single cell
strings as pointers to zero-terminated strings
vectors/angles/matrices/complex numbers/quaternions as as many cells as they have elements
arrays as a pointer to their contents. see XWL:writeArray(R) on how to do it

data for arrays and strings could be written in a separate area, like >= 1024 or something

I guess, but with the new declarative inputs, it'd make more sense to do:

<input name="Wibble" type="vector3" offset=10 />

... to map 'Wibble' to 3 cells from offset 10 on hispeed, but we'll see

PS. I'm still alive, just had a block-mode course for the past week (9-5'ing it) so I've been rather dead afterwards.

Got *technicly* two weeks with no modules in them (only coursework) so I could get stuff done starting tomorrow

[TomyLobo]

yeah that's even better. I thought you rejected declaring inputs at some point.
also, make sure you allow using pointers.
<input name="Wibble" type="vector3" offset=*10 />
would mean look for a pointer at address 10 and then read the vector from Vector(mem[pointer],mem[pointer+1],mem[pointer+2])

[moggie100]

yeah that's even better. I thought you rejected declaring inputs at some point.
also, make sure you allow using pointers.
<input name="Wibble" type="vector3" offset=*10 />
would mean look for a pointer at address 10 and then read the vector from Vector(mem[pointer],mem[pointer+1],mem[pointer+2])

I guess, but I was going to just make it read from offset+0, offset+1, & offset+2 for a vector 3, so it removes the need for a pointer...

Why would indirection help ? (Am I missing something?)

Curiously, you could put a string at offset 0, and providing nothing is value '0' in memory, it would print out your entire memory block in ASCII... Potentially handy for debug (if a tad round-about)

[TomyLobo]

XWL:writeArray(R) uses indirection. one could use that to write everything in one go.
XWL:writeArray(array("hello", entity():pos(),5))

[Beer]

Any updates on this project?

[emspike]

Moggie slipped and fell on his HUD2 notes while holding a lit lighter. His last words were, "If only I had finished this sooner my house wouldn't have become a torch." He died of smoke inhalation while the paramedics tried to get the super-secret-hud2-dev repository URL out of him. Curse you moggie for making me stretch my humor :C .