High-speed holoemitter

[Lord Wagener]

I have to disagree on this one..
The term high-speed means that you can enter the data very quickly and directly.. as far as the high-speed holoemitter is concerned, you send the vector/color/size/etc data once and then it is used to draw the actual hologram - every point is then being rendered simultaneously
the low-speed variation adds a new point every couple of frames according to a vector input
so high-speed means you can enter the data faster

however, processing color information for each point does take slightly more time in each rendering pass - but this is not that much that you can actually experience it

The only thing I can imagine is that when you specify more information and update them often the server will have to send more information to the clients and that can cause lags.

[Azrael]

I think that would defeat the point of high-speed though. The simplified coding found here allows it to process it faster. Since you're sending information directly to the bytes it can process it much faster without having to process extra things like vectors and such.

if i'm wrong please correct me, but this is what I believe to be true.

if Memory[blah] == nil then color  = DefaultColor

It's not hard.

[Fizyk]

Yeah, that's a good idea. Also, I'm thinking of compressing color information into one or two bytes, 4 is too many I think. My propositions are:

1. One byte, (255-Alpha)*16777216 + Red*65536 + Green*256 + Blue
2. One byte, Red*65536 + Green*256 + Blue + (255-Alpha)/256
3. Two bytes, first: Red*256 + Green, Second: (255-Alpha)*256 + Blue

Using 255-Alpha instead of Alpha would let the points be non-transparent by default. The third way should work well, I'm not sure if the other ways don't exceed the floating point precision though (bear in mind that I have to send those values to clients, as rendering is clientside, and I heard the values are then converted to 32-bit floats).

[Lord Wagener]

if Memory[blah] == nil then color  = DefaultColor

by my understanding, the default value for any cell is 0 and you cannot assign nil by expression2 so i suggest that assigning 0 should cause the emitter to use a default color

Yeah, that's a good idea. Also, I'm thinking of compressing color information into one or two bytes, 4 is too many I think.

Agreed. However I wonder if storing an alpha value is even required - does it have a visible/desirable effect?
And if it comes down to it, you should stick to RGB(A) encoding I think, that is RED + GREEN * 256 + BLUE *256*256 + ..

however.. to speed up the code you should not multiply by 256 but rather shift the values bitwise to the left by 8 .. i dont know if these operators are implemented but if they are, you should use them

[Azrael]

Wagener: RGB encoding is always 0xRRGGBB, not 0xBBGGRR. By which I mean, it's the red and green that get shifted.

Anyways, I'm not sure this encoding scheme is sensible. I've proposed it before, but everybody else seems to be reluctant to use it -- and standards are important.

Actually, thinking about it, it'd be good to get some tools using this encoding for colours. Here's how you'd convert the components into the color quickly using zASM:
[highlight=asm]
mov esi, color
mov eax, #esi
fshl eax, 8
inc esi
add eax, #esi
fshl eax, 8
inc esi
add eax, #esi
finish: jmp finish
color: db 255,192,0
[/highlight]

(Internally, zASM uses multiplication for its fshl and fshr instructions... they're not implemented in Lua so you need a separate bitwise library to do stuff like that. That's also why I use adding instead of ORing in the example above.)

For the colours... -1 could be 'use default value', I'm thinking?

[Fizyk]

However I wonder if storing an alpha value is even required - does it have a visible/desirable effect?

Yes, it has, low alpha makes points transparent. But that made me think: do we need whole 24-bit color palette? Difference between, for example, (128,128,128) and (129,128,128) is [almost] impossible to be seen. It may be useful when you need to make a gradient, but we have very limited amount of points, so it is impossible anyway. So, maybe we could limit ourselves to 12 or 15 bit color (16 or 20 when counting alpha)? It would be possible then to put it all in one byte.

For the colours... -1 could be 'use default value', I'm thinking?

There is no need for a default value then. The point is, all colors are 0 by default, so let's make 0 mean default color and, for example, -1 would be black then. If you don't like it though, it's possible to initialize memory with -1's.

[ZeikJT]

if Memory[blah] == nil then color  = DefaultColor

It's not hard.

Actually, lua makes it even easier:

Memory[blah] or DefaultColor

If the first term is nil it will jump to the second, and so on and so forth. It can plopped pretty much anywhere. This is how it works in the lua conditionals as well, if the first term is nil or false it jumps to the next term, and you can string together huge chains of terms.

[Azrael]

Fizyk: It makes it far simpler if you use a 24-bit palette. Everything else uses alues from 0 to 255, so using anything else would be kinda silly.

[OmicroN]

So as far as implementing a way to change the point size of multiple points, is this possible to do with the current format or would it need some re-writing?

[Fizyk]

It would need rewriting.
I think I will make 3 additional bytes in the special mode, one for red and green, one for blue and alpha (or 255-alpha for convenience), and one for size. Also, everything set to 0 will mean 'default', and to set the color to black you will have to put -1 in the red-green byte. What do you think of it?