General DoomSharp() Discussion

Quote:

---

Originally Posted by NoteMe

Yes yes yes I did..:D...it was your calculation that was faulty..:D

- ØØ -

---

ok my turn to not believe you, I have to see it for my self ;) where is the code that screws up the rendering? ;)

Quote:

---

Originally Posted by kedaman

I've not done any culling yet. I'm planning to use occlusion culling in the final algo. The other algo used a lot of floating point calculations, but I'm not sure how fast it will be than that, because the innermost loop was quite optimised, as it uses the same technique as my new one, having a constant depth, i.e. doom style rendering.

---

Hmmm...ok...well, I am doing the frustum culling, and I think I have the right idea on how to optimize it the most. So it is only depth culling that can be applied to optimize it any furuther. Would be nice to see a working implementation of it. Sounds difficult no matter what way you are using.

BTW with your drawing are you using a lot of API calls?


An other thing, are you good with Sorting Algorithms?


- ØØ -

Quote:

---

Originally Posted by NoteMe

Good, I have a very very interesting idea for a Demo...I will start on it right after we have finished this one...:)

- ØØ -

---

I can't wait, so hurry up :D

Quote:

---

Originally Posted by kedaman

ok my turn to not believe you, I have to see it for my self ;) where is the code that screws up the rendering? ;)

---

PS: ObjectView is the point in view coordinates:


[Removed because of frustration]

- ØØ -

Quote:

---

Originally Posted by kedaman

I can't wait, so hurry up :D

---

I am trying. But I guess it all depends on how much Mr. D# want to do with this one. In theory it can go on for ever.


- ØØ -

Quote:

---

Originally Posted by NoteMe

Hmmm...ok...well, I am doing the frustum culling, and I think I have the right idea on how to optimize it the most. So it is only depth culling that can be applied to optimize it any furuther. Would be nice to see a working implementation of it. Sounds difficult no matter what way you are using.

BTW with your drawing are you using a lot of API calls?


An other thing, are you good with Sorting Algorithms?


- ØØ -

---

No Api calls whatsover.. except the Getdibits call to access the bits on the window. Yeah I love sorting algorithms, what do you need to sort?

Quote:

---

Originally Posted by kedaman

No Api calls whatsover.. except the Getdibits call to access the bits on the window. Yeah I love sorting algorithms, what do you need to sort?

---

This is theory, rather then actual implementation. Keyword is Big O...;)...

Actualy I posted the Q here yesterday. So maybe we should keep this Q outside this thread:
http://vbforums.com/showthread.php?t=358234

Just note that we are talking SMALL NEARLY SORTED arrays.

- ØØ -

Quote:

---

Originally Posted by NoteMe

PS: ObjectView is the point in view coordinates:

Code:

---

        //float x = ((objectView.X * m_nearPlane) / objectView.Z);
        //float y = ((objectView.Y * m_nearPlane) / objectView.Z);
        //return new Vector((m_screenWidth / 2) - (x * m_screenWidth), (m_screenHeight / 2) - (y * m_screenHeight), 0);

---

- ØØ -

---

Nah, that's not what I wrote to you, it should be -(m_screenWidth / 2) and +(x * m_screenWidth) and the same for y and where did you pull m_nearPlane from?

Quote:

---

Originally Posted by NoteMe

This is theory, rather then actual implementation. Keyword is Big O...;)...

Actualy I posted the Q here yesterday. So maybe we should keep this Q outside this thread:
http://vbforums.com/showthread.php?t=358234

Just note that we are talking SMALL NEARLY SORTED arrays.

- ØØ -

---

I'll have a look at that in a bit, have to eat first ;) Btw this is just like old times, we keep posting and posting, I can barely keep up with your speed :D

Quote:

---

Originally Posted by kedaman

Nah, that's not what I wrote to you, it should be -(m_screenWidth / 2) and +(x * m_screenWidth) and the same for y and where did you pull m_nearPlane from?

---

I took the nearPlane from the drawing. But the near plane is 1.0f anyway, so it shouldn't have anything to say.

It was Wossy that changed the signes. Because it was rendering up down or something. I wasn't there when he did it, so hmmm...:)


- øØ -

Quote:

---

Originally Posted by kedaman

I'll have a look at that in a bit, have to eat first ;) Btw this is just like old times, we keep posting and posting, I can barely keep up with your speed :D

---

Yeah I know..JUST like old times...this project is the best EVER..:D..But you where lucky though. Since the only pretty girl in my department this week just invited me on a cup of coffeé, so I have just been away for 20min..:D.


- ØØ -

I can't believe its not working as it should, you must be doing something wrong elsewhere. Ah wait a second, you say that if the screen was wider then it would also turn out wider, of course it will. You need to incorporate that sort of transformation into the camera matrix anyway, not the camera to perspective calculation where it would only slow down things ;)

Quote:

---

Originally Posted by NoteMe

Yeah I know..JUST like old times...this project is the best EVER..:D..But you where lucky though. Since the only pretty girl in my department this week just invited me on a cup of coffeé, so I have just been away for 20min..:D.


- ØØ -

---

You mean it could have been several girls or it could have been more than a cup of coffee? or both ;)

Quote:

---

Originally Posted by kedaman

That's odd with the black dots btw, you're definitely not doinf it the right way if you are leaving black dots, you're suppose to map the pixel coordinates to texture coordinates no the other way around.

---

So much criticism, did I inadvertently upset someone?

Its pretty obvious taht the texture does have perspective all you have to do is look at the corners of the image, but anyway I have rendered a chessboard just to prove it. See attachment.

The black dots are a problem because i am scanning lines that are parallel to the sides of the quad at the moment not horizontally and vertically. This is something I need to fix soon and it was a strategy in mind when I wrote this but I had to make sure my pixel mapping was right so I just used the trajectories to check. Its still bloody quick though :D

It'll be even faster when I work out the orthographics scan lines :D i'll probably keep 2 arrays, one for xstart another for xstop, both with a length equal to the height of the destination bitmap, then convert all the pixels from start to stop adn then move down 1 line. I'll jsut need to work out how to assign the start and stop values from the quads. I can do this with the trajectories I already have though so this means less floating point operations and more ptr++ :D

When I'm done with this I hope to be able to get 90fps on this machine for a quad of the same size as above. And we won't have to worry about pointers running off the screen either.

Quote:

---

Originally Posted by kedaman

I can't believe its not working as it should, you must be doing something wrong elsewhere. Ah wait a second, you say that if the screen was wider then it would also turn out wider, of course it will. You need to incorporate that sort of transformation into the camera matrix anyway, not the camera to perspective calculation where it would only slow down things ;)

---

No no no no..:d..I am doing it in the view to camera now..and it is wokring JUST fine..:D..don't screw up the working code now..:D...


- ØØ -

Quote:

---

Originally Posted by wossname

See attachment.

---

Care to post it?

Quote:

---

Originally Posted by kedaman

You mean it could have been several girls or it could have been more than a cup of coffee? or both ;)

---

It was one girl one cup of coffee and one man to rule them all...;)...now stop CC in our thread..:D

Quote:

---

Originally Posted by NoteMe

No no no no..:d..I am doing it in the view to camera now..and it is wokring JUST fine..:D..don't screw up the working code now..:D...


- ØØ -

---

hah :D It's going to slow you down :D Show me the code ;)

Quote:

---

Originally Posted by wossname

So much criticism, did I inadvertently upset someone?

Its pretty obvious taht the texture does have perspective all you have to do is look at the corners of the image, but anyway I have rendered a chessboard just to prove it. See attachment.

The black dots are a problem because i am scanning lines that are parallel to the sides of the quad at the moment not horizontally and vertically. This is something I need to fix soon and it was a strategy in mind when I wrote this but I had to make sure my pixel mapping was right so I just used the trajectories to check. Its still bloody quick though :D

It'll be even faster when I work out the orthographics scan lines :D i'll probably keep 2 arrays, one for xstart another for xstop, both with a length equal to the height of the destination bitmap, then convert all the pixels from start to stop adn then move down 1 line. I'll jsut need to work out how to assign the start and stop values from the quads. I can do this with the trajectories I already have though so this means less floating point operations and more ptr++ :D

When I'm done with this I hope to be able to get 90fps on this machine for a quad of the same size as above. And we won't have to worry about pointers running off the screen either.

---

Not upset me anyway, its just my nature to be critical about these sort of things ;) I checked out the checked texture, and it seems that although its not isometric, its not perspective rendering either, you seem to be stretching the image over a 2d polygon. The attached picture shows that the stripes are not getting thinner to the right.

I am optimizing it later on tonight..I just have to get the stuff around it working first..:(...I just made it work before I went on my vecation so Wossy could use it. And when I got back everything was caos....:D...But the way it is right now is more or less like this:


- First call the first function here to update the WorldToViewMatrix.
- Then multiply a point with that matrix.
- Then send the point into the second function here, so you can get the screen coordinates out.

[Removed because of frustration]


- ØØ -

Quote:

---

Originally Posted by kedaman

Not upset me anyway, its just my nature to be critical about these sort of things ;) I checked out the checked texture, and it seems that although its not isometric, its not perspective rendering either, you seem to be stretching the image over a 2d polygon. The attached picture shows that the stripes are not getting thinner to the right.

---

Can you show me a screeny of your function rendering a checkers board? So I can see what it is supposed to look like?


- ØØ -

Quote:

---

Originally Posted by NoteMe

I am optimizing it later on tonight..I just have to get the stuff around it working first..:(...I just made it work before I went on my vecation so Wossy could use it. And when I got back everything was caos....:D...But the way it is right now is more or less like this:


- First call the first function here to update the WorldToViewMatrix.
- Then multiply a point with that matrix.
- Then send the point into the second function here, so you can get the screen coordinates out.

Code:

---

        private void UpdateProjMatrix(){
                Vector cam_forward = m_lookAt.Normalise();
                Vector cam_right = cam_forward.CrossProd(m_up).Normalise();
                m_up = cam_right.CrossProd(cam_forward);

                m_worldView[0,0] = cam_right.X;
                m_worldView[1,0] = cam_right.Y;
                m_worldView[2,0] = cam_right.Z;

                m_worldView[0,1] = m_up.X;
                m_worldView[1,1] = m_up.Y;
                m_worldView[2,1] = m_up.Z;

                m_worldView[0,2] = cam_forward.X;
                m_worldView[1,2] = cam_forward.Y;
                m_worldView[2,2] = cam_forward.Z;

                m_worldView[0,3] = 0;
                m_worldView[1,3] = 0;
                m_worldView[2,3] = 0;
                m_worldView[3,3] = 1;

                Vector revPosition = -m_position;
                m_worldView[3,0] = cam_right.DotProd(revPosition);
                m_worldView[3,1] = m_up.DotProd(revPosition);
                m_worldView[3,2] = cam_forward.DotProd(revPosition);
        }


    public bool ViewScreen(Vector[] objectView, ref PointF[] thisPoint) {
        thisPoint[0].X = m_centerWidth - objectView[0].X / objectView[0].Z / m_effectiveFOV * m_centerWidth;
        thisPoint[0].Y = m_centerHeight - objectView[0].Y / objectView[0].Z / m_effectiveFOV * m_centerWidth;

        thisPoint[1].X = m_centerWidth - objectView[1].X / objectView[0].Z / m_effectiveFOV * m_centerWidth;
        thisPoint[1].Y = m_centerHeight - objectView[1].Y / objectView[0].Z / m_effectiveFOV * m_centerWidth;

        thisPoint[2].X = m_centerWidth - objectView[2].X / objectView[2].Z / m_effectiveFOV * m_centerWidth;
        thisPoint[2].Y = m_centerHeight - objectView[2].Y / objectView[2].Z / m_effectiveFOV * m_centerWidth;

        thisPoint[3].X = m_centerWidth - objectView[3].X / objectView[3].Z / m_effectiveFOV * m_centerWidth;
        thisPoint[3].Y = m_centerHeight - objectView[3].Y / objectView[3].Z / m_effectiveFOV * m_centerWidth;

        return true;
    }

---

- ØØ -

---

SLOOOOOOOOW ;)

http://www.vbforums.com/attachment.p...id=39549&stc=1
This isn't really a checkers board but its good enough to see that the texels are shrinking to the right.

Quote:

---

Originally Posted by kedaman

SLOOOOOOOOW ;)

---

No way it is..:D...so how would you have used it...and don't pull that I'll stretch your textures 10 time as wide as they should be on me again...;)

- ØØ -

Quote:

---

Originally Posted by kedaman

This isn't really a checkers board but its good enough to see that the texels are shrinking to the right.

---

OK, I can see your point....look like some nasty math behind that **** though...

- ØØ -

Quote:

---

Originally Posted by NoteMe

No way it is..:D...so how would you have used it...and don't pull that I'll stretch your textures 10 time as wide as they should be on me again...;)

- ØØ -

---

Basically depending on what size you have the screen height compared to the width, you can adjust the x and y scale transformations on the camera, it should be proportional, and it should save you all that stuff except the division by z ;)

Quote:

---

Originally Posted by NoteMe

OK, I can see your point....look like some nasty math behind that **** though...

- ØØ -

---

Nah, that was quite a cheap trick I pulled there, which might become a problem unless you do some mip mapping at distance. I'm having it fixed in the new algo anyway, which uses the 9 so called magic numbers, which I've still not completely understood. The nasty part was getting the clipping right though, I didn't imagine you could clip a triangle in so many ways.

So what is the proper way to draw a texture without any gaps? I can fix the problem with more iterations but it takes much longer.

Quote:

---

Originally Posted by kedaman

Basically depending on what size you have the screen height compared to the width, you can adjust the x and y scale transformations on the camera, it should be proportional, and it should save you all that stuff except the division by z ;)

---

It sounds interesting, but I don't get it....but I suddenly got a problem with Merge sort here. I was looking at an example..and suddenly I didn't remember how it is done...hmmm..If you look at this example.


http://www.publicjoe.f9.co.uk/csharp/sort04.html

is the array split before you start into A and B? Or should it all be in A before you start or? Should it all be in a third array before you start? I am a bit confused now...


- ØØ -

Quote:

---

Originally Posted by wossname

So what is the proper way to draw a texture without any gaps? I can fix the problem with more iterations but it takes much longer.

---

Just draw one pixel after the other in horizontal spans, or alternatively vertical spans for walls ;)

And what about when none of the quad's sides are either horizontal or vertical (like the checkerboard above)?

Quote:

---

Originally Posted by NoteMe

It sounds interesting, but I don't get it....but I suddenly got a problem with Merge sort here. I was looking at an example..and suddenly I didn't remember how it is done...hmmm..If you look at this example.


http://www.publicjoe.f9.co.uk/csharp/sort04.html

is the array split before you start into A and B? Or should it all be in A before you start or? Should it all be in a third array before you start? I am a bit confused now...


- ØØ -

---

I only read the two first lines and saw it was bloated. It should be in one array from the start, its possible to do it inline but its probably cheaper (depends on the cost of memory) to do it with two arrays, the other should be half the size of the original. Merge sort is a divide and conquer (I was almost going to type command and conquer :D) which splits recursively the array to sort into two, until a certain point where you do insertion sort (better than splitting to smallest bits) this would be about when their size are about 10-20 each. Then (after the recursion call, unlike in quicksort) you merge the two sorted bits by picking the smallest of the two and put it back in the original array.

Quote:

---

Originally Posted by wossname

And what about when none of the quad's sides are either horizontal or vertical (like the checkerboard above)?

---

Then you will need increments for each row (or column), for the starting and ending points. Also you need to split the quad so that the top and bottom (or left and right) parts are level.

Quote:

---

Originally Posted by kedaman

I only read the two first lines and saw it was bloated. It should be in one array from the start, its possible to do it inline but its probably cheaper (depends on the cost of memory) to do it with two arrays, the other should be half the size of the original. Merge sort is a divide and conquer (I was almost going to type command and conquer :D) which splits recursively the array to sort into two, until a certain point where you do insertion sort (better than splitting to smallest bits) this would be about when their size are about 10-20 each. Then (after the recursion call, unlike in quicksort) you merge the two sorted bits by picking the smallest of the two and put it back in the original array.

---

But doing it with one list is not going to improve speed. And it is not much memory we are talking about anyway. Not even a Kb...so doing it in two lists should not be a problem. But in their example both a and b is of length 100.... :confused:

Quote:

---

Originally Posted by NoteMe

But doing it with one list is not going to improve speed. And it is not much memory we are talking about anyway. Not even a Kb...so doing it in two lists should not be a problem. But in their example both a and b is of length 100.... :confused:

---

yeah, that's why I concluded it bloated ;)

Quote:

---

Originally Posted by kedaman

Then you will need increments for each row (or column), for the starting and ending points. Also you need to split the quad so that the top and bottom (or left and right) parts are level.

---

Can you draw a quick picture of that? Not sure what you mean.

Sure, I love drawing pics ;) This time i just copied yours though to get it quickly over with. This is basically what I'm doing in my new algo: I'm splitting a triangle (it should work with other polygons as well, but it might best to split them into triangles to simplify the code) into trapetzoids that are parallell to the screen (vertical or horizontal depends on whether you render walls or floor/ceilings). Then use an increment for each starting and enpoint of each vertical or horizontal span. If you use floats, then converting to integers may be a bottleneck, so I'm using integers, but to be able to increment more precisely than 1 pixel per span I'm shifting the next starting and ending points by 16 bits. The spans should be fast to render, if you assume a constant depth accross it, which you can do for walls and ceilings.

Quote:

---

Originally Posted by kedaman

yeah, that's why I concluded it bloated ;)

---

Ok, hmm...I'll think I'll let it lie down for a while, and do an other that I actualy remember how works..:)

- ØØ -

Quote:

---

Originally Posted by NoteMe

Ok, hmm...I'll think I'll let it lie down for a while, and do an other that I actualy remember how works..:)

- ØØ -

---

I recommend you use insertion sort, since it will just run trough once, and do whatever small differences may occurr when you move around in a jiffy ;)

OK ok ok ..:D...but I kind of want to test Quick sort too.:)..but shell sort was REALLY REALLY fast, so it is not much time we can save no matter how we do this I guess...


- ØØ -