[Bug] DD overwrite [Med]

[NoteMe]

I am not going to start to fix this bug/feauture right now, but I just wanted to lift my thoughts out there.

The reason why we get this artifact is because we are not drawing wallparts if they are too far away, and we are not clearing the buffer every frame.

Now, as I can see it, it is two possible solutions to this. Just want to hear, if anyone has any more solutions, or thinks that one is better then the other one.

1.
We can always draw a black quad over the portion of the screen that no wallparts are drawn over. This will be really hard to optimize, since it is hard to find out what part of the screen that is.


2.
The map editor, or the loading of the map can find out how long/wide the longest corridor/room is, then sent that to the culling class, and the culling class will change the FarPLane accordingly. This can work pretty sweet, but if someone makes a map where a corridor is 200m long, then it will bring the whole game dawn to a halt, and die on us, since it will use WAY too much resources. A way to limit this would be to not allow saving of maps that has coridores that is longer then N meters or so. Well at least it is a thought.


Andyone any better idea, or any more thougts about these solutions?


- ØØ -

[SLH]

How hard coded is the culling distance in the culling class, can it be altered dynamically? If so, have each cube an associated culling distance, i.e. the max seeing distance from that cube. It could be a simple step in the map editor that preprocesses the map before saving or something.

[NoteMe]

The problem is that it is a lookup table at the moment. When you are standing inside a cube (between "four" walls), you look up in a 2D array what wallparts are inside the frustum (a sphere around the frustum). And then these wallparts are sorted from back to font, and then drawn. So drawing wallparts that is not in that index in the lookup table is a bit difficult.


But your method seems ok, except that it will still have the problem of halting the computer. Not all the time, but if a person walks down a long corridor, then you will get the same problem as just staticaly change the FarPlane to N meters....or did I missunderstand you?



- ØØ -

[wossname]

I think I may be able to write a method that runs faster than GDI+'s FillRect() method.

I already managed to outrun FillPolygon()

Anyway, we could work out which area of the screen to blank out just by doing a calculation based on the up/down angle that we are looking...if we are looking up then clear the lower part of the screen, and vice versa.

But we'd have to make sure that all cubes have ceilings and floors allocated to them.

[wossname]

PS, the new blitter doesn't support distance darkening yet Might have to kludge this with a transparent polygon draw over the top.

[Phill64]

PS, the new blitter doesn't support distance darkening yet Might have to kludge this with a transparent polygon draw over the top.

yeah, it might be costly to do an rgb calculation in your blitter, 3 divides and rounding per pixel...

[SLH]

Wouldn't drawing a (semi)transparent polygon on top be about the same number of calcs??? i.e. take into consideration the background pixel colour.

[NoteMe]

Anyway, we could work out which area of the screen to blank out just by doing a calculation based on the up/down angle that we are looking...if we are looking up then clear the lower part of the screen, and vice versa.

But we'd have to make sure that all cubes have ceilings and floors allocated to them.

If you take away the word JUST from that sentence there, I guess I can work something out. It is not as easy as it sounds...but I guess you understand that by now....

Don't worry about the distance darkening though. It will come with time. But I have to see how you are drawing to be able to tell what would be the fastest method. Would be great if we could do it by some shifting. Or adition. As long as we know the distanve, just add a HEX number to each pixel as you draw them. That shouldn't take too much time. At least much less time the drawing two times as you do now with GDI+.


- ØØ -

[Phill64]

well... you would think... drawing a poly overtop would be slower... but it doesnt make it so, for the reason that it's part of the framework, so it *should* be able to run faster than our code.. however it is more likely that doing it youself as apart of your texture drawing is faster.

There is a way to find out, test

[NoteMe]

I do not agree with you. OK, think about it this way. What is drawing. It is a 2D loop (or 1D with some tricks) that changes one and one pixel at a time.

Now, if you draw twice, then you will have 2 of these 2D loops.


Pseudo code

for all i in width
    for all j in height
        //draw the first time
    }
}

for all i in width
    for all j in height
        //draw the second time
    }
}

Now, if you do it your self, you don't need to loop through it two times. You can do the second pass in the first pass your self. And it will loop like something like this:

for i in with
    for j in height
         //find the pixel color for the first time
         //add the distance darkening
         //draw the one and only time
    }
}

Now if the addition is just to add a number/constant depending on the distance of the object. Then that calculation should be way faster then doing a second double for loop. And not only that. You will get much better cashe use. A second for loop like that will hogg the cache to pieces once more.

But then again. I still need to see how wossy is drawing it, to see if it is possible. Or wossy can figgure it out himself.


- ØØ -

[Phill64]

I realise this, that's why i say it is more likely that doing it in your code will be faster.

however i was looking at it from the angle.... C++ is much faster than C#... C# is much faster than VB... etc.

the polygon method being written into the platform could make it faster.. that was my thought.

also, it wouldnt be a case of adding a number, it would be a case of 3 numbers, RGB being divided by the darkness level (eg: 3), R/3 G/3 B/3 and of course they will be rounded back to integers(or uints), and in wossnames code it would certainly be possible, as he uses a 1d array to represent the images, where the array is RGB RGB RGB, so the 3 numbers r copied from one to the other to make 1 pixel, unless wossy is now doing it another way... as obviously we havn't seen his latest revision

[wossname]

I don't think its as simple as adding or shifting bits. Wouldn't we have to multiply each RGB value by a float in order to darken it?

PS. Latest high score is 508 frames per second I changed a load of flops to an increment, the only problem is that I don't know how to properly calculate the source pointer's increment properly. It's currently fetching the wrong pixels.

If I can fix it and keep it at 450ish FPS then we are on track to have the same speed we have with the older isometric texturer, and it uses half the ram too.

[Phill64]

yes, that's what i was trying to say, 3 numbers need to be fiddled with to achieve it, i didnt explain very well

as RGB 100, 50, 120
at 50% darkness would be (either /2 or *0.5) and parsed back into uint
= RGB 50, 25, 60

that's all darkening is, your 0.5 or 2 would be set at the start (since you're not using perspective)

[timeshifter]

But the value of that number would change with distance, so maybe a number proportional to the distance in meters away from the camera the pixel is?

[wossname]

Well, we are happy with using a single darkness value for each wallpart. Since our wallparts are all square anyway this should not present any obvious visual problems. Indeed the in-game screenshots using single-darkness values are perfectly servicable. Calculating per-pixel darkness values would cripple the algorithm, we'd be lucky to get 50FPS for a single quad.

However, I'm quite close to finishing the blitter now, few days time it should be finished.

[SLH]

What you could do is calculate the darkness values per-vertex, then interoplate for each pixel in a quad.

[NoteMe]

Ok, I am not sure here, since I have never looked at Wossys drawing stuff at all, but just look here.

What do we need to add to make a colour darker?
- I thought it was grey we needed to add. The darker grey it is, the darker the texture will be in the end.


Ok, so next question. What is grey.
- Grey is a colour where R = G = B. So (2,2,2) is a grey shade. (90,90,90) is a grey shade, but (30,50,30) is NOT a grey shade but a dark green shade.


So what happens if you use Phill64 method (put to the extreme).
- Well if the colour is all ready a grey colour. well then you will add a new grey colour. But if it is all ready nearly blue or green or red, then we have a problem. Lets say that we have the colour (100, 40, 40). Then with Phill64 method, the new colour will be for example (50, 20, 20). So what has happend now? It has become darker, but hasn't it also changed colour? slightly? It was much more red, now it is much less? Wouldn't the real darkening result be something like (80, 20, 20), then you have darkened with (20,20,20) something that is a grey colour. And not (50,20,20) something that is a red shade?


So if this is true (not saying that it is, since it is late, and I am drunk AGAIN).
- Then it should be easy to find a hex value for the grey colours to add or subrtact or what ever. Like (20, 20, 20). In Binary that is:
[RRRRRRRR|GGGGGGGG|BBBBBBBB]
[00010100|00010100|00010100]

Something that is in Hex 141414. And that should be easy to be added or was it subtracted (darn Tuborg).


Any thoughts?
- ØØ -

[SLH]

That's not true (at least it wouldn't work anyway).

Consider (100,50,50), lets say we want to make it really dark, so we subtract (50,50,50), ending up with (50,0,0). Now we've got a pure red colour, not one with elements of green and blue!

[Phill64]

Noteme, you have your thought completely opposite here i think...

as SLH states, if you simply minus from the values you will get a new color, my method DOES NOT get a new color because it's ratio

100,50,50 is the same color but different shade to 50,25,25 (which is the original color divided by 2)

since from an RGB relationship point of view, (for every 2 parts RED, there shall be 1 part of GREEN and BLUE) which is true for both those numbers

where as, if i was to subtract say 25, making 75,25,25
you have just changed the RGB relationship to (for every 3 parts RED, there shall be 1 part of GREEN and BLUE) which is false for the original color of (100,50,50)

so the list of colors below are all valid shades of RGB 100,50,50
because they abide by the law (for every 2 parts RED there shall be 1 part GREEN and BLUE)
50,25,25
200,100,100
10,5,5
150,75,75
2,1,1
254,127,127

so it's as simple as (100,50,50 * 0.5 = 50,25,25)

[wossname]

You all seem to forget that floating point operations are not free. It takes a hell of a lot of runtime to perform floating point math, which is how the framerate jumped from 144 to 508 when changed 3 lines of code.

Also, interpolating between the 4 vertices would force us to pass an additional 4 floats for each quad we need to render, and do extra math in the 3d engine in order to populate that data.

[NoteMe]

I hear what you guys say, and it sounds a bit logic too, to stribe for the grey by adding a colour, in stead of what I said about adding the grey to get a darker colour.


But I have never taken any art classes nor danced ballet like you guys, so I am not sure. But what would pioneering D# work be witout a bit of testing. After all, all shaders in games these days are only aproximations of the truth anyway. And this shading could have been pretty easily done in a shader, and darn fast too. But since we can't do it that way, lets investigate our theories a bit furuther to see if we can get somewhere..


Look at this picture (sorry for the image size, didn't want to ruin the colours for sure..):


This is the colour I talked about. Here is their values in the same order as they are displayed in the pic:
Original: (100, 40, 40) | PhillDD: (50, 20, 20)
SmalNM: (80, 20, 20) | EqualP: (70, 10, 10) | OverP(60, 0, 0) | NMSatur(40, 0, 0)


Ok, the first upper left one, is the original one. The one to the right of it is Phills 0.5 distance darkening. To me it looks like it is brown shifted. It is a lot less red colour in it. That might be what we want, and it might not be.

The one in the lower left corner is my test. Where you take away the same amount of colour for each colour component. It is not becomming as dark as Phills method. So if we where going to do it this way, then we have to darken them more for the same amount of distance.

So the one to the right of it, is a test where I have taken away the SAME amount of colour as Phill has. 90 in total. 30 for each colour component. It is still not as dark as Phills, but it still has quit a lot of red in it. And it is still not over saturated.

Then the next one, is where the my method will have to take a new approach. Because two colour components can no longer become any darker. But as you can see, there is still a lot of red in it. But it is really dark.

Now on the last picture, we have only one red component to change. And you see that we get the same kind of brown shift as Phill got on his test. Mainly because it is only the red component that was altered in his test, and that is what we do here too.



So any thoughts? Am I a lunitic? Or can it maybe be used as a fast aproximation? Any feedback is good feedback. Just be gentel with me..


- ØØ -

[NoteMe]

You all seem to forget that floating point operations are not free. It takes a hell of a lot of runtime to perform floating point math, which is how the framerate jumped from 144 to 508 when changed 3 lines of code.

Also, interpolating between the 4 vertices would force us to pass an additional 4 floats for each quad we need to render, and do extra math in the 3d engine in order to populate that data.

Me too?

[wossname]

Me too?

No. NoteMe and Wossname are as one, a single entity. We are Borg.

How about a lookup table? If we use each byte of the RGB as the lookup and have lets say 50 levels of shading then we'd have an array of 50 * 256 elements.

All we'd have to do is use a pointer offset to fetch the right value.

Hmm is it possible to pin a 2d array?
What shape is a 2D array in Ram?
Is it possible to keep an array pinned for the entire life of a class, or is it limited to the lifetime of a single method?

[Phill64]

You all seem to forget that floating point operations are not free. It takes a hell of a lot of runtime to perform floating point math.

hey i was on your side #6

[NoteMe]

No. NoteMe and Wossname are as one, a single entity. We are Borg.

How about a lookup table? If we use each byte of the RGB as the lookup and have lets say 50 levels of shading then we'd have an array of 50 * 256 elements.

All we'd have to do is use a pointer offset to fetch the right value.

Can you outline this a bit more? How will this effect distance and colour of the pixel from before and so on?

Hmm is it possible to pin a 2d array?

Pin....In norwegian please?

What shape is a 2D array in Ram?

It is of course 1D. The second demension is just a multiply. So if you have something starting at pos 100, and you have a 10*10 array there. and you want to fetch [2][3], then what the code in theory does is.

100*sizeof(datatype) + (2*10*sizeof(datatype)) + (3*sizeof(datatype))

to find the mem location. If I am not wrong that is. I hope it was that way, or maybe that 2 and 3 should change place.. You know me..

Is it possible to keep an array pinned for the entire life of a class, or is it limited to the lifetime of a single method?

I thought you knew about lifetime of object and variables wossy.. Located memory is located at the same place in memory, untill it goes out of scope.. If not, you would get a lot of Null pointer exceptions after your app have been running for a while.


- ØØ -

[wossname]

I know all about scope, but I have little experience with using pointers across scope boundaries.

I know that the stackalloc command and the fixed() construct are only valid within a method but what about pointers to objects on the stack?

[NoteMe]

Can you get an object on the stack at all? As far as I know, and object is on the head, and the reference to the object is on the stack.

[NoteMe]

OK, I have looked up stackalloc now. Never knew about that function. Obviously something they try to hide.

Well the GC is not fetching it, so you don't have to pinn it with "fixed". But when the function is over, the stack unwindes anyway. So you are going to lose it anyway though.

- ØØ -

[wossname]

Might not need a lookup afterall. I'm going to try something.

[NoteMe]

I am going to sit here and cross my fingers..


- ØØ -

[wossname]

Well, it's not perfect but it kind of works...

set up a trackbar and a picturebox...

(this is just a test of logic, not speed)

private void trackBar1_Scroll(object sender, System.EventArgs e)
{
	//trackbar needs min and max set to 0 ant 255 respectively...
	byte dist = (byte)(255 - trackBar1.Value);
	Color c = Color.LemonChiffon; //can be any color

	pictureBox1.BackColor = Color.FromArgb(255, (byte)(c.R & dist), (byte)(c.G & dist), (byte)(c.B & dist));
}

Certain colors go a bit weird (Orange for example) it needs work but its faster than floating point ops.

[wossname]

Or even better...

private void trackBar1_Scroll(object sender, System.EventArgs e)
{
	byte dist = (byte)(255 - trackBar1.Value);
	Color c = Color.Red; //can be any color

	int temp = (255 << 24) | (dist << 16) | (dist << 8) | dist;
	
	pictureBox1.BackColor = Color.FromArgb(c.ToArgb() & temp);
}

[wossname]

Yeah this second one will work really nicely

We can use a simple lookup instead of having to do all that shifting and it'll only need to be done once per quad anyway, then its just a matter of bitwise anding all the integers in the image with the temp temp value.

Should be fast.

[NoteMe]

So you are finaly comming all over to my side now.....

[SLH]

You all seem to forget that floating point operations are not free.

At what point did i say flops wern't free??


I'm pretty sure i read about doing integer division using bit shifts (not just dividing by multiples of 2!), i did a little searching and found this:

https://www-927.ibm.com/ibm/cas/toro....201/index.pdf

Not too sure, but i think it'd help.
EDIT: Looks like you've sorted the darkening thing, still might come in handy elsewhere?

[wossname]

How can all that code be faster than a floating point divide?

[SLH]

It has to be faster than an integer divide, but no idea how it's faster, i guess it is though otherwise it'd be kind of pointless.

I've not tested it or anything though.

[NoteMe]

I didn't bother to read much right now. But what is this UNSIGNED datatype? Size? What would it be equal to in C#?


- ØØ -

[wossname]

I didn't bother to read much right now. But what is this UNSIGNED datatype? Size? What would it be equal to in C#?


- ØØ -

I think its meant to be the equivalent for the platform you're programming on.

[NoteMe]

Hmmm...so Uint32 then? Well it is still going to be tricky though, since things like this:

if (!(d & 1)) {


doesn't work the same way in C and C#. Not even sure when that is true or false in C to be honest. Is it still looking at the leading bit or?


- ØØ -