Printable View
Ok srry just re read the bits of da thread! U doin it in c# i am no help! And about trignometry coming in the end, i posted it because i thought u guys were trying to increase fps! And srry about the attitude i just got a little excited! Neways if i get some more tips or something usful stuff 4 u guys will post it here!
Quote:
Originally Posted by wossname
I thought you asked me about ColorMatrices on MSN like 2 months ago, because you couldn't find any info about it on the net. But back then I had never touched GDI+ so I couldn't give you any info on it. I think you wanted to know because of the book or someting. Might be wrong though.
but if this really do vertex transformation and not just color transformations, then I am so going to yeah you know...."swwing"....:)...
Quote:
Originally Posted by RapchikProgrammer
Thanks...:) We are happy for all help we can get. And we will be sure to use lookuptables for what ever we can in the end...:)
- ØØ -
I'm already using ColorMatrices, but ColorMatrix is separate to ColorMatrixEffect.
CME is only available in 2.0. Looks like you simply supply it as a parameter to Graphics.DrawImage(). It would be extremely cool to be able to combine distance darkening AND perspective in one object!! That would save us a bit of time too.
We are already using lookup tables for the Distance darkening. Saves us having to instantiate ColorMatrices 1000 times a second :D
Quote:
Originally Posted by wossname
But I am not using it for any of my code yet..:) But I don't have many places to use it either though.
Just as I remember it. This is REALLY importent. And we need to discuss this now.
Is wallpart going to be a object that I can do what ever I want with. And will it have the Render function. Or have you screwed me over? The thing is that the "wallpart" class need to use unsafe code. Every wallpart needs to have two pointers. Those pointers have to be of the type "wallpart". If this isn't possible at the moement, then I strongly recomend you start fixing it the way it was..:D..NOOOO kidding..:)
- ØØ -
Quote:
Originally Posted by wossname
Ohhh....my bad..:D....well, I am looking forward to see the results. I am unable to test this in Linux anyway. But I will try to stay in Windows a couple of hours after work today. Are you going straight back home after hours? Going to work on this today?
- ØØ -
I'll be checking this out tonight yes, I'll send you a screeny if it works :D.
There's no problem having a couple of pointers in the wallpart class. You'll need to mark the whole class unsafe though. You will be able to do what you want with a WallPart object.
Wallpart has a Draw() method but you don't need to worry about the rendering though, thats my job :D
Wallpart.Draw() basically makes the wallpart send itself to the renderer. his may turn out to be redundant because the actual code for the painting is in TexEng. We'll see.
The rendering is your job, but it is much safer to let me actualy call the Render function. And a public render function should really not have any parameters, because all points and textures are supposed to be contained in memeber variables and member objects. That is why we are using classes..:) Just to make you understand the scenario from my point of view.
- We load the map
- My code checks the points in world coordinates for ALL wallparts, and construct a Binary Tree out of the wall parts.
- Our game loop starts, and after updating inupt states, and updating camera, then you call RenderScene().
- RendeScene, will get the camera coordinates, and traverse the Binary Tree discarding nodes and "tree arms" that is not supposed to get drawn. The way this is done is by going from one pointer to the other. So I am not holding any object, just touching them with my pointer. But when I find one that should be drawn I have to call it's render function, so I will use that pointer and just say. "mypointer->Render()", nothing more then that (at least I hope), the rest should be encapsulated far far away from me. but that is what I need to be able to do.
- ØØ -
Grrrr... you edited your post..:D...well as long as the wallpart is public to me, and that it has two pointers to other wallparts, and a public draw function with no parameters, then we agree..:) Good..:DQuote:
Originally Posted by wossname
- ØØ -
OK we'll give the wallpart class a public STATIC variable that holds a reference to the renderer object then we won't need to pass that in as a parameter.
here's a mockup...
Code:public unsafe class WallPart : Primitive
{
WallPart* left;
WallPart* right;
public static TexEng Renderer = null;
public int Render()
{
Renderer.DrawPrimitive(this);
}
//all the rest of the code.......
}
Hmmm..is WallPart a primitive? Is there some possibility that there will be other stuff that we might draw that is a child of primitive, but is NOT a wallpart?
If so, then Render() and the two pointers HAVE to be moved to Primitive, well I guess, they should probably be tehre anyway. Render() as a pure abstract method.
- ØØ -
Good point, I'll need to think about this tonight.
If this ColorMatrixEffect thingy does what we want we'll have to make some big changes anyway don't do anything to the wallpart and primitive classes until tonight, jsut do something about the stretching bug in the camera class.
Quote:
Originally Posted by wossname
I won't do anything with that....I think I have to use more or less all evening just to get back on track...and try to find out how to use VS 2005..:D..
BTW can later on tonight give me a screeny of the stretch thingy you are talking about. Not 100% sure if I know what you mean. I guess it is the world to screen code there is something wrong with. You have seen that the resolution you are using DOES matter? So if you change resolution then you have to change the hard coded values in my calcs?
- ØØ -
I already removed those hard coded resolution values out of your class. I made it a parameter of the constructor (i think... can't remember right now). I think you are right about the world-->screen code because it all other respects the scene does look right.
The scenes we have drawn so far have all been of perfectly square tunnels. if you look at the screenshots the floor and ceiling is a diferent length to the height of the walls, they should be the same (2 metres high and 2 metres wide).
It seems to ignore the aspect ratio and stretch he image sideways to make the square tunnel fit into the rectangular window.
Screeny of what i mean about the stretching.
i have nothing to contribute :(
i just wanted to say that you guys are seriously my freakin heros
Yeah we rule. :lol:
Quote:
Originally Posted by wossname
OK, thanks...will take a look at it later on tonight. Hope I can figgure it out. Because at the moment I have no idea what that can be (if the scren res really isn't the problem that is).
You can trust "Bob the builder"
PS: What did you call that big blue blob in "Sesammy Street" in English. The guy that fixes everything. He was called "Max Mekker" in Norwegian. "Max Mekker mekker max..:)"..:)
- ØØ -
Quote:
Originally Posted by vbdotnetboy
Heheh...thanks..:) It is so fun to get posts and rep points with comments like that on this project..:) Never happend to me before. Really need to get better to advertise my self..:) Thanks for teaching me that wØØsy..:)
It 'feels' to me like a ")" in the wrong place or something like that. It looks really weird when you turn the camera around the z axis because it gets stretched into a diamond shape slightly.Quote:
Originally Posted by NoteMe
Which proves its in the world-->screen code because the stretching is still perfectly horizontal regardless of the angle of the camera. We know where the bug is but not what the bug is :D:D
So does it happen if you pitch the camera too? Does it then happen verticaly, or is it just if you jaw the camera?
'
- ØØ -
Seems to happen regardless of camera orientation.
Oki doki....will have a look at it in a couple of hours...quitting 17:30++ (that is 16:30 for you I guess)
- ØØ -
OMG....I usualy don't say anything bad about any language. I usualy say "find the right tool for the job", but after seeing this I am NEVER going to say anything bad about ANY language at all....I was looking for some info on BSP and I found this java applett. Just use your arrow keys and your mouse and have a look at this...
http://www.theparticle.com/applets/wobble/
AMAZING....
- ØØ -
Blimey. Does that use hardware?
I still can't visualise how BSP's work :( Do you have to create the tree every frame or what?
Thanks for that link Noteme.That Java applet is too sexy.Its wayyyy cool :)
It is ONLY using the CPU. So we should get the same speed as that thing does...:D..hehehe..are we going to make it..ehhh..no..:D..well, he doesn't use textures though. Tht is a BIG drawback. But he does have a fake lightning formula there. That is cool.Quote:
Originally Posted by wossname
Quote:
Originally Posted by wossname
Do you know anything about Binary trees at all? Ever made one? I can try to explain everything to you if you want. Just need to know where you stand.
And no, I only need to make the tree once. THen we will traverse through the tree every frame. Pointer to pointer and check for a condition. If we find out that one wallpart is not going to be drawn, then we can discard the rest of it's right arm, or was it left..ehh..well guess I can define that later on. So then we will go down the other arm and keep testing.
BTW I have been reading more about this now, and I seriously think about using CornedBees tree. Do you think that stinks? Should I make it from scratch? Or is it ok for you?
- ØØ -
have you checked the source out yet? it's pretty wild.
the designer comments this isnt built to be fast, but it runs extremely quick for me.
I know how binary trees work but I can't understand how you chain up a 3d world into a tree. How do you know which wallparts get connected to which other wallparts??
Quote:
Originally Posted by uniquegodwin
Yeah, it is really cool...really really 1337..:)
- ØØ -
Quote:
Originally Posted by wossname
It is really not easy to say with two words..:D. But I can try.
You start with a "random" wall. And make the wall go from left to right on the map. Then you will have a lot of walls in front of the wall, and a lot of them behind them. Then you have two lists + the first wall. The first wall simply becomes the root of the tree.
- Thereafter, the "next" wall is placed in the bsp tree to the right of its parent wall if in the scene the wall is in front of the parent wall.
- The wall is placed in the bsp tree to the left of the parent wall if in the scene the wall is in back of the parent wall.
To find what the "next" wall is, you recursively walk through the two lists that ou made after the first splitting.
THen when you have made the tree like this. Then all the walls will be stored relatively to each other in the tree. Meaning that if you are on a node, you know that all the nodes to the right is in front of that node, and all the nodes to the left is behind that wallpart.
Tell me if you want me to elaborate even more. The simplest page to follow that I have found is this one:
http://maven.smith.edu/~mcharley/bsp/
Click "how to make a BSP tree" on the left menu there.
- ØØ -
Quote:
Originally Posted by Phill64
I didn't bother to check it since I am at work, and I know it is not going to help me to look at it anyway. But I can imagine that it is wild. But his comment is kind of BS though. He is using BSP trees and everything. You do that to optimize. So yeah, I guess he could manage to get it to run a bit faster, but I don't belive that it is far far away from as fast as it gets.
Noteme, about the BSP thing.. this could also be what has wossname wondering too.
you say you create the tree once, but then you only store reference to wallparts behind and infront.. how would this work for rendering when the camera has turned and looking on the side, this would then indicate walls left and right, not front and behind, wouldn't you require to record 4 to make this successful for all angles?
I think I get it now. So how do you decide which wallpart gets to be the root? of each branch? I suppose its best to have the same number of wallparts on the left as there are on the right. This sounds hard.
I was originally wondering that but you have to deal with each wallpart as if you are facing it directly (imagine its part of a very long invisible fence running through the map) eveything on the other side of the fence is behind this wallpart, everything on the same side as we are standing is in front of it.Quote:
Originally Posted by Phill64
So when you have 2 lists: BEHIND and INFRONT, you pretend that BEHIND is a new map and do it all again, then do the same with INFRONT.
God who invented this system? its brilliant.
front and back and right and left is just terms in our 3D world. When you are constructing the tree, we are in World coordinates. So we can say left and right and back and front. And when we load the game we deside what is back and front and so on. But once loaded in the tree there is no longer something called back and front and right and left. A node ONLY knows about it's parent and his left and right child (if he has some). So that means taht they are all stored relatively to each other. Not with coordinates back and front and so on. That is how we know.Quote:
Originally Posted by Phill64
- ØØ -
Quote:
Originally Posted by wossname
That is why I said "random". Because in theory we can just pick one. But in practice we will get better performance if we pick the right one. I have a feeling that there is a way (really have math) to find out what the root should be. But I havn't had the time to check it out yet. But if we are using a AVL tree then I am not sure if it matters anyway, since the tree will always be balanced no matter what.
- ØØ -
what you're saying is, you continually disect the map until you've narrowed to a single piece at the end, is that it?Quote:
Originally Posted by wossname