General DoomSharp() Discussion

Wow, 600 posts already! Scary.

Anyway, just to aid my slightly enebriated memory, me and note are going to synchronise code on saturday "before noon" (yeah right :)).

He's still working on some fundamental changes and I'll be taking it easy with some graphics, sound work and optimizing the blitter.

It feels good to have a fairly solid foundation under us now. This blitter looks like it may abe able to replace our flawed isometric texturer.

That's all for now.

I'm off to sink some more beers.

Wow, this is progressing so fast. I would have thought it would take ages to get to where guys are. Congrats. Keep up the good work. I try to keep updated on this thread, but if I forget to read it for even a day, there are 2 more pages. I end up just scanning for screen shots sometimes. ;)

Great work though. :thumb:

Hehe...yeah, this thread has soon a higher post count then you..:D..It is wØØsys fault that the project grows so fast. He wants to work on it each day. But right now I have to do a big change in the underlaying code. So I have convinsed him to lay off the code for 24 hours, so I can do the changes. I bet I have to work non stop those 24 hours to get it done. Hope I can manage it. Looks good right now, but I am a bit affraid that the code will first run slower before it will run faster again. Because I only have the time to write the shel around the code, and not optimize the functions as we go (I.E write dummy functions in stead of the algorithms I am supposed to write...:()..::)..But as long as the shell is up and running, we should be fine. That way we have again managed to separate our code, so we can both work on the same time. And that would have been a good thing. Looking forward to sync up with you hon'.


Tick Tack, Tick Tack (-29:30h)



- ØØ -

STOP POSTING ON VBF AND GET CODING!!! *whip crack*

You lazy who... :D

Sorry, had to go to the physiotherapy. But I have one Q.

Remember that you tested the speed on ordering the walls from back to front? Did you use an array list then? Should I use an array list? Or is an array list really slow. I know at least that using "foreach" is 50% slower or something then using just "for", but I can still use "for" on an array list, can't I? So any thoughts about it?


Tick Tack, Tick Tack (-25:30)

- ØØ -

An other thing. Are you not storing the width and height of the map anywhere?


Tick Tack, Tick Tack (-25:17)

- ØØ -

Quote:

---

Originally Posted by NoteMe

An other thing. Are you not storing the width and height of the map anywhere?


Tick Tack, Tick Tack (-25:17)

- ØØ -

---

I havent been storing that no. At the moment maps are no larger than 50x2x50 metres. I can insert this into the map class tonight if you like based on the actual contents of the map. One thing I can tell you though is that no MapCubes (and therefore wallparts) have negative X, Y or Z coordinates, they are always 0 or greater.

We are using Lists instead of arraylists and yes you can iterate through them like a normal array. List in 2005 are type safe and are just as good as arrays in terms of speed, plus they can be resized as needed.

The Generic Namespace is soooo amazing :D

How can a list be just as fast as an array. If you are unlucky a list will be spread all over the place in memory...hmm...well hmm...ok...ehh..

And yes, I need the width and height for the Culling. Would be boring if I guessed that the map was 25, but then it was 10 and then we used 100 times more memory then we needed...if you know where I am heading..:)...but for the moment I will just hardcode 10*10. Then we can fix it later. BTW look how simple it is for you to draw the map right now:

[Removed because of frustration]
Tick Tack, Tick Tack (-25:09)

- ØØ -

Why make 50 calls to DoEvents in the For loop? It should only be called once in a game loop per frame. That way there, the loop will be faster ;)

Quote:

---

Originally Posted by Jacob Roman

Why make 50 calls to DoEvents in the For loop? It should only be called once in a game loop per frame. That way there, the loop will be faster ;)

---

Ehhhhhhhhhh...It is calling DoEvents ONCE per frame..;) And it slows down the system 0.01FPS..;)



Tick Tack, Tick Tack (-24:50)

- ØØ -

Do you have a class for representing a 3d cuboid volume? Something like a 3d version of Rectangle? Or shall I create one? Can you post a copy of your vector class so i can test some code I've just written;

Maps are 25 cubes by 25 cubes in size which equates to 50 metres by 2 metres (high) by 50 metres.

When I store the map size, the size will shrink down from 50 metres to fit the actual walls.

Do you want the map size in metres or in cubes?

Quote:

---

Originally Posted by wossname

Do you have a class for representing a 3d cuboid volume? Something like a 3d version of Rectangle? Or shall I create one? Can you post a copy of your vector class so i can test some code I've just written;

---

Ehhh..no, I don't have a class for cuboid...what do we need it for? yeah, I can give you the vector class. Shall I mail it to you?


- ØØ -

Quote:

---

Originally Posted by wossname

Maps are 25 cubes by 25 cubes in size which equates to 50 metres by 2 metres (high) by 50 metres.

When I store the map size, the size will shrink down from 50 metres to fit the actual walls.

Do you want the map size in metres or in cubes?

---

I think cubes would be for the best. So the first map is 10*10 in size.


- ØØ -

Quote:

---

Originally Posted by NoteMe

I think cubes would be for the best. So the first map is 10*10 in size.


- ØØ -

---

That makes life easier then, as long as you are not calculating metres from it (because cube sizes might change in future builds).

In that case I won't need that vector class after all :)

I'll give the map class 2 int members then, Width and Depth if thats ok for you.

OK, but then I have to ask..ehh...can a cube have different size on the same map? If so, then I need it in metres. But if it is a constant for each map, then I just need the constant and the widt, height (num cubes).



Lunch time:
Tick Tack, Tick Tack (-23:11)

- ØØ -

Yeah it'll stay constant throughout the map. But may change from build to build.

I think it is defined as

Code:

---

public Const float DEFAULT_CUBE_WIDTH = 2.0f;

---

In either Map or Mapcube class, can't remember which right now. Changing that single constant will change the size of the cubes (width=depth=height at the moment).


Intro:
I guess the intro screen will just be a form with a nice bitmap on it, I don't think we'll need a menu yet until we start adding features into the game (select level / difficulty and so on). Then when Visualad has got off his lazy bum and made us a theme tune we can have it playing at the same time. This will gives us lots of time to load complex levels, install textures and initialise the enigmatic BlackBox. I've had the idea to make a campaign editor too (very simple in theory, just a class that contains a selection of levels taht the player can battle through in sequence., when one level is won then another one loads up!!!). All we'd have to do is throw away our class instances (texeng, blackbox) an create them with the new level settings. Then we can have another screen come up while the loading happens. this is a job for muuuuuuch later through :D

Also the map files are TINY! even with 10 textures (64x64) the size isn't even near 100kb yet :D this decompresses a bit when it gets loaded but its still not much :) woo0t;

Quote:

---

Originally Posted by NoteMe

Ehhhhhhhhhh...It is calling DoEvents ONCE per frame..;) And it slows down the system 0.01FPS..;)



Tick Tack, Tick Tack (-24:50)

- ØØ -

---

Man.. get rid of that Doevents entirely. Doevents doesn't allow other processess cpu time, it only processess the messages for each window in your app.

Wow wow wow....slow down now honey..:D...campaign editor....hmm....it sounds like you are 100 steps in front now. And we never actualy but a hat on this project. How much do you actualy want to make out of this? I have other projects I want to to later on too, not just this. Remember I am a DX man..:)...So I am kind of hoping that this project doesn't drag me into the next century if you know what I mean..:D


BTW, the loading screen sounds fine to me. Just one comment. Maybe it would be cool if it changed from one image, to an other, or if there was a loading bar, or maybe both? Not just ONE static image?


Tick Tack, Tick Tack (-22:05)

- ØØ -

Quote:

---

Originally Posted by kedaman

Man.. get rid of that Doevents entirely. Doevents doesn't allow other processess cpu time, it only processess the messages for each window in your app.

---

It is the best option if we use pure .NET. And other method would be to controll the messages sendt "peekmessage" and so on. But that is a totaly different storry. Using Sleep is an API call. And BTW I don't care about your other processes Keda...you will not be able to run DC++ and DoomSharp at the same time anyway..:D:D:D

- ØØ -

Btw, I haven't bothered reading trough all of this thread. I've been off for a week due to some nasty things happening here with my ISP. Is there's still need for some doom style perspective correct texture rendering that is reasonably fast? I've worked out the clipping and occlusion filtering now, and only need to sit down and put it into code.

Quote:

---

Originally Posted by NoteMe

It is the best option if we use pure .NET. And other method would be to controll the messages sendt "peekmessage" and so on. But that is a totaly different storry. Using Sleep is an API call. And BTW I don't care about your other processes Keda...you will not be able to run DC++ and DoomSharp at the same time anyway..:D:D:D

- ØØ -

---

screw .NET ;) If I can't use DC++ while running Doomsharp then you have to wait til I download my po.. I mean finished my downloads til I can beta test it and that's going to be a while ;)

Quote:

---

Originally Posted by kedaman

Btw, I haven't bothered reading trough all of this thread. I've been off for a week due to some nasty things happening here with my ISP. Is there's still need for some doom style perspective correct texture rendering that is reasonably fast? I've worked out the clipping and occlusion filtering now, and only need to sit down and put it into code.

---

Ohh..sounds nice...I think you two have something to talk about. Wossy have been working on this too:
http://vbforums.com/showthread.php?t=358061

I'll leave it up to you two to decide how to draw. I'm doing the space partitioning at the moment. And writes my shell so wossy can't **** up my code anymore..:)

- ØØ -

Quote:

---

Originally Posted by kedaman

screw .NET ;) If I can't use DC++ while running Doomsharp then you have to wait til I download my po.. I mean finished my downloads til I can beta test it and that's going to be a while ;)

---

You are never going to finish your P. So just don't bother..:D...well, we have to wait and see if wossy can improve framerate before we can see if you can run DC++. There is still light in the end of the tunnel...:)

- ØØ -

Quote:

---

Originally Posted by NoteMe

Ohh..sounds nice...I think you two have something to talk about. Wossy have been working on this too:
http://vbforums.com/showthread.php?t=358061

I'll leave it up to you two to decide how to draw. I'm doing the space partitioning at the moment. And writes my shell so wossy can't **** up my code anymore..:)

- ØØ -

---

Hmm.. I'm looking at the code and I'm looking at the pic, and I'm not sure what he is doing, I'm not certain if he is doing it right. First thing is why are those black dots over there, and the other thing is I can't really figure out if there is perspective in that pic.
Wossy: If you read this post, can you render a striped or even better a checked texture?

He can change the points as he want in that picture. That is what I know..but no idea if the texture is smaller on the right side then on the left side.

The Dots I guess is because of rounding errors or something...no idea...:)..but that is not a big problem anyway...


BTW have you speed tested your algo keda? Can you check how many FPS you can manage to get? Or even send the app if you don't mind?


- ØØ -

Quote:

---

Originally Posted by NoteMe

You are never going to finish your P. So just don't bother..:D...well, we have to wait and see if wossy can improve framerate before we can see if you can run DC++. There is still light in the end of the tunnel...:)

- ØØ -

---

I hope so, this is certainly a fun project, even if you are doing it in .NET ;) You could still benefit a lot from having the main loop coded in ASM ;)

Quote:

---

Originally Posted by NoteMe

He can change the points as he want in that picture. That is what I know..but no idea if the texture is smaller on the right side then on the left side.

The Dots I guess is because of rounding errors or something...no idea...:)..but that is not a big problem anyway...


BTW have you speed tested your algo keda? Can you check how many FPS you can manage to get? Or even send the app if you don't mind?


- ØØ -

---

The previous algo got up to 50fps by rendering 20 of those walls. My new algo will run faster, and in addition it will filter out wall parts that are not visible due to other walls being in front of it, so even if the screen is filled with a lot of walls, it could hardly go any lower than that. Mind you i'm running it on a 1,2Ghz Athlon. I have to check out why my cpu speed has dropped, but I haven't had the time yet.

Quote:

---

Originally Posted by kedaman

I hope so, this is certainly a fun project, even if you are doing it in .NET ;) You could still benefit a lot from having the main loop coded in ASM ;)

---

Yeah, everything can be done faster in C++ and ASM, but it is somewhat the point of this project NOT to use anything else then C# and .NET. I think it nearly does the project even more fun.

You should join a project once..:)


- ØØ -

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.

Quote:

---

Originally Posted by kedaman

The previous algo got up to 50fps by rendering 20 of those walls. My new algo will run faster, and in addition it will filter out wall parts that are not visible due to other walls being in front of it, so even if the screen is filled with a lot of walls, it could hardly go any lower than that. Mind you i'm running it on a 1,2Ghz Athlon. I have to check out why my cpu speed has dropped, but I haven't had the time yet.

---

Wow wow wow...that is incredible fast..well it is in C++ though. So we can't expect the same speed here anyway...but still. It is really fast.

What method are you using for the culling? Z-Buffer? W-Buffer? Querrerying? I am interested..:) Give me the details..:)

- ØØ -

Quote:

---

Originally Posted by NoteMe

Yeah, everything can be done faster in C++ and ASM, but it is somewhat the point of this project NOT to use anything else then C# and .NET. I think it nearly does the project even more fun.

You should join a project once..:)


- ØØ -

---

Maybe ;) But I'll probably do only bits and pieces here and there when I get time ;) And the ASM will run a lot faster even than C++ so, it might be possible to fit in the ASM part in C# using fake pointers to a block of ASM code you put in an array in C#, and api calls to callwindowproc and copymemory

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.

---

As usual I belive you..:) Wossy is not going to be able to work on it before after hours today though...:(...but hope he can drop a comment on it or two before that.

BTW I shouldn't belive you anymore...for some reason your view to screen coordinate calculation didn't quite work. It stretched the textures. So if the window was wider then it was tall, then the thextures where wider then tall too. but I have fixed it now though...But I should stop trusting your blind folded..::D


- ØØ -

Quote:

---

Originally Posted by kedaman

Maybe ;) But I'll probably do only bits and pieces here and there when I get time ;) And the ASM will run a lot faster even than C++ so, it might be possible to fit in the ASM part in C# using fake pointers to a block of ASM code you put in an array in C#, and api calls to callwindowproc and copymemory

---

But we are not cheating...this is PURE C# and PURE .NET...the ASM stuff can be saved to a later project...do you hear me..:D:D:D


- ØØ -

Quote:

---

Originally Posted by NoteMe

Wow wow wow...that is incredible fast..well it is in C++ though. So we can't expect the same speed here anyway...but still. It is really fast.

What method are you using for the culling? Z-Buffer? W-Buffer? Querrerying? I am interested..:) Give me the details..:)

- ØØ -

---

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.

Quote:

---

Originally Posted by NoteMe

As usual I belive you..:) Wossy is not going to be able to work on it before after hours today though...:(...but hope he can drop a comment on it or two before that.

BTW I shouldn't belive you anymore...for some reason your view to screen coordinate calculation didn't quite work. It stretched the textures. So if the window was wider then it was tall, then the thextures where wider then tall too. but I have fixed it now though...But I should stop trusting your blind folded..::D


- ØØ -

---

damn.. you probably didn't apply it right then? :D

Quote:

---

Originally Posted by wossname

We are using Lists instead of arraylists

---

??? Where are you making that list? In Form.cs I can only find this:

Primitive[] walls = null;


hence..maybe you forgot to make it a list? Or?

- ØØ -

Quote:

---

Originally Posted by NoteMe

But we are not cheating...this is PURE C# and PURE .NET...the ASM stuff can be saved to a later project...do you hear me..:D:D:D


- ØØ -

---

ok ok, but in the next project you can have some help from me ;)

Quote:

---

Originally Posted by kedaman

damn.. you probably didn't apply it right then? :D

---

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

- ØØ -

Quote:

---

Originally Posted by kedaman

ok ok, but in the next project you can have some help from me ;)

---

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

- ØØ -

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]


- ØØ -