Printable View
I wish we had some sort of source control too, its difficult working like this.
I don't want to change the size of the map for the following reasons:
1. The game doesn't work yet, lets get the bloody thing running before we start worrying about the map size. 25x25 is perfectly fine for testing.
2. The editor would need lots of extra GUI code.
You keep saying it yourself note, lets get it working before we start optimising and fiddling. Larger maps are a job for much later.
My point is that I need large map to test if my Space partitioning is working..:).25*25 is minimum. So it will work for now. So no need to make it bigger right now.
Yeah, I know about the source controll stuff. We could have had it if you where allowed to use Fx or an FTP client at work...we moved our projects togheter WAY to fast. I feel that I can't alter ANYTHING right now. And there is so much I want to redo to test stuff. But that seems like an awfull lot of job as long as you are working on the same files....
- ØØ -
At the moment I'm adding a default starting point to the map, shich means I have had to alter the camera class a bit (adding a few members and making the class serializable, I havent removed anything). The Mapcube and Map classes have changed a lot too. I'll make the necessary changes to enable the BSP sorting of Cubes instead of wallparts. I'll need to change "Primitive" to "Drawable" too since these classes are not so primitive anymore :D
If I can get it rendering tonight can you at least show me your camera class so I can know what to expect, I may be able to integrate it myself.
Yeah sure...I will sit here at work from 17:30-20:40 working on this today (one hour less for you: 16:30-19:40). So you can have a look at it. It is working in DX at the moment, so I hope the mileestone to get it integrated won't be too big. It isn't that many changes from the version I gave you before my vecation...:)...so I guess we may still have the up down problem...but I can fix it..;)
- ØØ -
You mean you can actually move the camera???
I'm going to write a short concept document today, like Devian has in his mechwarrior thread. Should have done it a while ago actually.
Long ago, in a galaxy far fa.... :D
Quote:
Originally Posted by wossname
In DX I can that...I have told you, the ONLY thing missing in the camera class you all ready have is to check if the arrow keys are down, AND how much the mouse has moved since last frame. The rest of the code is there..;)...I have asked you 999 times if I should take a look at it, or if you should do it...guess it can't be that many lines. But I can't 100% sure see how it would work with delegates though....events is NASTY in games...
- ØØ -
Quote:
Originally Posted by wossname
Hehe..at least we have an iteration plan..:)...
We could use the API to check the keyboard without events. I can code that today.
But wouldn't that be cheating...;)...remember to use SetCursour("middle of the screen") for every frame though. (After you have calculated how much it has moved.
BTW is your rendering in a game loop now? Maybe we should consentrate on that today. Since the rendering has to go through me anyway. If you have time that is.
Agenda:
- Game loop
- Get input
- Update Camera class
- ØØ -
Not got a game loop set up yet. We can handle the mouse without api, just compare its current position with the centre of the screen (then reset it).
Keys will need api though. Damn the API docs, they don't give you the values for all the constants :mad: Does anyone know a really decent API reference (and don't say API Guide because its crap :D)
No I don't, but I have all ready done this in C++, so I guess a port won't be to hard...
Good to hear you can at least fix the mouse without using API..:)...
- ØØ -
Something like this?
[Removed because of frustration]- ØØ -
Yeah that'd be fine if we can find out the constant values.
Will do that right away when I go off work..:)
- ØØ -
I think this is right
[Removed because of frustration]
- ØØ -
OK its a good start. I'd rather like to find a reference for all the keys on the keyboard, we'll need to handle Escape as well so we don't get stuck in the program :D
I get the feeling its 0x1B but I could be wrong.
Actually, didn't DGlienna mention something ages ago about there being text file on VBF somewhere containing all he Win32API constants?
Quote:
Originally Posted by wossname
VK_ESCAPE = 0x1B
Quote:
Originally Posted by wossname
No idea...Can't remember him saying anything about it...but then again..he has 99999999 posts, and IMed everyone 99999999999999999 times though...
ØØ -
From winuser.h:
[Removed because of frustration]
Excellent!
I love you, you know that?
also: http://www.codeproject.com/system/keyboard.asp but its not as good.
I know you love me...you HAVE too since I love you so much...:) I feel a special bond to you these days you know..:;)
- ØØ -
wossy, as in my PM, i made the quadrant thing.. it also turned out my 2nd idea was a waste of time, as i also tested my triangle code with a quad and got better results
running a test on 9 diff shapes i averaged the inaccuracy of all of them
new method=920
old 2 triangle method= 632
so i guess it depends how accurate it would need to be.. its only an estimate to decide whether to fully render or half render right?
EDIT NOTE: top 'Calculated' Field is the bad method 'quad', and below is the good method using 2 triangles
I've posted a nice keyboard testing class in the codebank.
http://www.vbforums.com/showthread.php?p=2144947
Phill, I've decided against using that idea after all. Thanks for trying though.
Oh, ok.Quote:
Originally Posted by wossname
no worries, was a nice 1st project for C#, it finally got me to write something in it :bigyello:
You got me thinking anyway, found this alg on google...Quote:
Originally Posted by Phill64
As long as the rect isn't twisted into a figure-8 this works very well...
Code:int GetQuadArea(Point[] pts)
{
uint i, j; //uints loop faster than ints
int area = 0;
for (i = 0 ; i < 4 ; i++)
{
j = (i + 1) % 4;
area += (pts[i].X * pts[j].Y) - (pts[i].Y * pts[j].X);
}
area >>= 1;
return(area < 0 ? -area : area);
}
Quote:
Originally Posted by wossname
Nicely...guess we are finaly getting this mother up and running tonight then...even with 6FPS..:D...
- ØØ -
Hope so. Might be late night before its rendering in a loop though. I have a big fat hairy bug (with tattoos and piercings) in the map editor.
(is one of those annoying bits where you are trying to snap a float to an integer but you still have to store both in the file and synch them before loading and after saving. I might end up removing the float from the file altogether and keeping it as a runtime only value.
I've been moving a whole load of constants around too. Shouldn't be much to worry about, probably won't affect anything you've done at all.
Hehe..I don't hope so. The only thing is the wallpart Vs. Cube thing...but I will have a closer look to that this evening...after all. No matter what I do you won't notice since I am the guy doing it before you even notice in the renderer..;)
heheheheeeehe
[Edit] That was post 9000, maybe it is time to retire?
- ØØ -
Hehe..didn't you give me the code with the back face culling..??? hehehehehehhehe
BTW I think I am on to something when it comes to the scewed width vs height problem of ours...
http://www.noteme.com/doomsharp/img/img039.jpg
PS: look at the FPS..:)
- ØØ -
OK, just have to get online some of the ideas I have right now...so I can have a look at them in Linux tomorrow too..
29*29*50*32=1.345.600
29*29*30*32=807.360
http://www.noteme.com/doomsharp/img/img040.jpg
- ØØ -
Yo've got me seriously worried now note. that map should be flipped left to right and the backface culling should be as it was, I think this might be the same problem, sort out the left-right flipping and it should look normal again.
If its not that then something must have changed in either the texeng class or the wallpart.Draw()
I will have a look at it tomorrow. Don't have much time tomorrow, but some time. Yes it is flipped left to right, or rather mirrored. I didn't have the time to check out what the right thing actualy is. If it is right now, or was right before. Because one thing that bugs me is that you don't remember what you did to my camera class. Because the world to view code of mine was left handed, but the camera was right handed. I was going to change this, so they both was the right, And that is partly what I have done now. But it isn't looking good, so I have to find out what you have done. Will try to do that tomorrow....
- ØØ -
I know exactly what I did to your camera class...
I changed it to this:
return new Vector((m_screenWidth / 2) - (x * m_screenWidth), (m_screenHeight / 2) - (y * m_screenHeight), 0);
from your original:
return new Vector((m_screenWidth / 2) + (x * m_screenWidth), (m_screenHeight / 2) + (x * m_screenHeight), 0);
That last x should have been a y and I changed those "+" to "-" because it was rendering upside down and backwards. Ever since then its been rendering beautifully until today when you messed it up again :D
Anyway.
I've added a camera member to the map class so we can now save a default player starting position into the map file. I need to add a way to edit the camera position in the edirot though, I'll probably use a custom dialog.
The newest version of the map loads and renders fine on my version. I'll spend a few days finishing the editor and thinking about the dreaded blitting speed problem.
Note, it feels like we are starting to write 2 copies of this game, we need to synchronise ourselves soon. Let me know when this is convenient for you :)
nice, i looked around and never found anything on quads, that would've saved time.. lol, but as i said, was an excuse to try C#, since if i did it in any other language it would be useless to you.
Noteme, you cannot retire until at least 10,000
hey wossy, along with what you're doing with that area thing, you could perhaps have 3 levels of it? (best quality, no perspective, no image), where you just paint a color instead of the texture, when creating your texture array you could calculate a corresponding color, being the average of all the colors, so for a texture that will only have a small display anyway, you could save time not drawing an image(normally these objects will be far away looking through rooms etc so it would be unnoticeable in gameplay
this thing is great!!!! :thumb:
but will it run on mono?
Quote:
Originally Posted by tr333
Not at the moment. .NET does not have a High Resolution timer. So for windows we have to use an API call to test how much time has passed. Then again. In Linux it seems to me that the buildt in timer is actualy fast enough. So if there is a way in .NET to find out what OS you are on, and there is demand for it. Then I can make an alternative Timer class.
But one more thing. wØØsy didn't have .NET 03, so we had to use 05. And 05 is using partial classes by default. Something that mono at least doesn't know what is yet. And won't know before january 06. So this has to be changed by hand outside .NET 05 or you have to wait untill january.
So the milestone isn't too far. But at the moment. No.
- ØØ -
OK, thanks. Last time I asked, you said you didn't know.:D So well, hmm..you changed the code the wrong place then....so then actualy before I messed it up yesterday both the world to screen change was right hand, and the camera class was right handed. Not weird that the rendering broke when I replaced the world to view with lefthanded rendering as it was in the beginning..:D...hehe..ok...I'll fix it again...just need to draw some more sircles and triangles..:DQuote:
Originally Posted by wossname
- ØØ -
Quote:
Originally Posted by wossname
OK, thanks. Last time I asked, you said you didn't know.:D So well, hmm..you changed the code the wrong place then....so then actualy before I messed it up yesterday both the world to screen change was right hand, and the camera class was right handed. Not weird that the rendering broke when I replaced the world to view with lefthanded rendering as it was in the beginning..:D...hehe..ok...I'll fix it again...just need to draw some more sircles and triangles..:DQuote:
Originally Posted by wossname
- ØØ -
Quote:
Originally Posted by wossname
For me that is actualy totaly fine, as long as we are not working on the same files. And yes we could have syncronized yesterday if you came online earlier..D:..but I am NOT handing over unfinished code to you again, so you can mess upp my coordinate systems..:D:D:D::D:D::D
- ØØ -
it's like you two are already married :)
Quote:
Originally Posted by Phill64
Yeah I know...special bond here..:D..This is kind of OT, but back in Norway I have a friend that I have known since I was 5. And the 3 last years when I studdied for my CS we where room mates. And one day when his GF was over in our appartment. She said:
"You two are just like an old married couple, just without the sex"...:D
She should have known..:D
I guess me and wØØsy can get the same kind of relationship in the near future..:D
- ØØ -
I implemented this feature about 4 weeks ago :D except we have approximately 120 levels of rendering detail. As things move away from the camera they get progressively darker (by applying a ColorMatrix to the quad). Until they get to a known distance (currently: 0.8 * frustrum depth), beyond which the quad is replaced by a grey polygon. The brightness of which also depends upon its distance frrom the camera. We can't see this Distance Darkening and Long Distance Polygon Substitution (DiDaLoDiPoS :D) in action until we are able to move around in the map under our own steam.Quote:
Originally Posted by Phill64
You bring to light an important point though, if I write a true quad blitter then it won't have colormatrix support, I'd have to draw a transparent poly over the top of the final coords before Present(). We might lose some performance unless we just forget Didalodipos altogether.
*Still in search of a FAST quad bitting alg*
One thing we could try is abandoning color matrices altogether and drawing a transparent polygon over the top of each cube. then we would only have to draw 1 polygon instead of one for each visible wallpart.
We'd need to somehow get the silhouette of the cube though, might be easy...might not.
This would still be slower than having no DD.
Hmmmmmmmm.
An example...
Oh, i was aware of your darkening.. but that wouldn't create less processing? infact wouldn't the darkening be more cpu costly? (except for when you make a grey polygon) i think you should still consider the diff colors thing though.. so a far away green roof piece is dark green not grey, otherwise everything would look the same down a long hallway.
I don't know what you mean about the transparent poly and why it is needed, but you will lose alot of performance doing it, as you say, with your 4 coords you calc the area and decide to draw the image with your skewed boxes syetm(if thats still what ur using) or if not, with a colored polygon, where does the transparent drawing come into play?
btw, i think that program you recently posted of the quad area will be the fastest you will get, only 4 iterations and a fairly small sum, i dont think you'll do any better than that, only other possible way of doing better would be to just use the perimeter as your decider.
oh, i see, for your distance darkening you have a semi-transparent shape that you draw ontop.. well the solution to that is the same as the color thing, it means say goodbye to your 120 levels though.. which is when you load your textures, generate a few darkened versions to be used inplace of the original texture when the object is far away
Hmmm...ok...I think I fixed it, and fixed the perspective....or? At least on this picture 800*600 it is the same width as height.
But I got a new problem..:(..but I am not sure if it needs a fix? What position do you have your camera on your picture that is equal? Tell me at least the Y value. I guess you are using 1.0f? Right? If so, then something is wrong with that. The screenie I just did had to have 0.73 to be more or less right. I don't think this is a big problem since the Y value will be the same throughout the lifetime of the app. But if you think it is a big problem, then I will try to find a solution for this problem too.
- ØØ -
Grr..and the picture..:D
http://www.noteme.com/doomsharp/img/img042.jpg
Phill, you can decide exactly how transparent a polygon is immediately before you draw it and also what color it wil be, we can have a smooth fade into black without any significant overheads.
Note: I have been using 1.0f as my y values so far. I'm not sure what you mean by yuor last post though, an average human standing in a 2 metre corridor would have a y value (eye level) of closer to 1.7. Can you show me what happens when you use a different y value??
Good work on fixing the stretching problem. Can you render a view of the whole map (like in your sig picture) ? i want to see if backface culling is working :)
Nice job. h4xx0r :D
I just came on VBF to tell you that while I was optimizing the camera class furuther I found the error..:D..small rounding error...big diff on the camera..:D...so now it looks perfect.Quote:
Originally Posted by wossname
Quote:
Originally Posted by wossname
Sure I can, but you can already see on this picture that backface culling is working...;)...The FOV is not the same as it used to be though. I have changed it a bit. But we can change it back later if we want. But I think this is more then enough.
One thing I want to talk to you about is the way we calculate is the way we calculate the view to screen coordinates. That function has to be changed a lot. And I have a few ideas. But first I need to know...can you freshen my memory. Back face culling, does that HAVE to be done in screen space, or can it be done in view space?
- ØØ -
hang on.. didn't you just say it will effect performance? and do you mean you draw the texture as half transparent? or the color overtop semi-transparent? because if you draw your texture half transparent it may work the first time.. but anything ontop of that will see through to the behind wall slightly :/ and with drawing the darkness overtop of the texture, this is another gdi+ operation, which we know is slow.. so it would slow you down a fair bit wouldnt it.. when i saw your first screenshot of distance darkening when you just had a hallway, i used the idea for a game i had using the semi-trans black idea, and it did slow it down, however i was able to makeup the speed by making the line of sight smaller.. which was made possible because of the distance darkening itself.. don't know if that's possible in your case or not.Quote:
Originally Posted by wossname
Anyway, i hope you're right about it not being very costly, i guess you won't find out until you're z-ording is all finished anyway. :thumb:
Yeeuch... Doesn't C# have include files?
Anyway, great work guys, it's looking very very nice so far. I've been following your progress since the start of the thread. Two :thumb::thumb:'s up
All textures are being drawn solid, that has always been the case, if polygons are[semi]transparent and could be drawn over the top of a fully rendered cube, then one poly makes the whole cube darker instead of a few poly's making a few wallparts darker.
Then we don't need the colormatrices which slow quad rendering down quite a bit. Drawing a transparent poly needs to be faster than the overhead of drawing at least 1 wallpart with colormatrices. Should be doable.
No need to go and try to get stuck in a circle of include files if the compiler is smart enough to avoid it..;)Quote:
Originally Posted by penagate
Quote:
Originally Posted by penagate
Thanks, still a few miles to go...but unless I piss off wØØsy totaly with my last post, then I think we will get there..:D
[Edit] I deleted it just in case. I need to think this over once more..:D
- ØØ -
Just done a quick experiment, we can easily create the outline of a cube without any special maths, just by adding the outlines of each wallpart (in screen coords) to a graphicspath (FillMode = Winding) and using the graphicspath instead of a polygon. We can put the GP as a return value from Cube.Draw().
Note, which classes are you working on at the moment? I'm editing the whole of the editor project, and classes: MapCube, Map and a minor addition to camera (made it [Serializable]). The game project has had a big alteration to its map loading code, to reflect the changes in the editor and the *.dsm map file format.
We can move the distance member out of the wallpart class and into the MapCube class, this will give the 3d engine less work to do.
I'm not sure what view space is. Well my clockwise detection only works in 2d space. Can you explain what Viewspace is?Quote:
Originally Posted by NoteMe
What the **** is GP, what are you talking about....Quote:
Originally Posted by wossname
I am working on the CameraClass of course...lay off my files..:D..the think is that we two need to sit down one day and rearange the whole mechanism here. We will need about 3 hours I guess. The thing is that it is ok to have a "game loop" in your form, but that game loop will need to call one of my functions in a class I am at the moment just calling the BlackBox. What this function does is:
- Updating the camera.
- Culling all wallparts outside the frustum.
- Calculate distance of wallparts from the screen.
- Sort the wallparts after distance.
- Convert from world to view (this method is really changed and optimized)
- Then I will call your DRAW function. (and of course that one have to change a tiny bit too. But not much)
So as you can see, most of the things YOU have been doing untill now, is no longer your work...
- ØØ -
Quote:
Originally Posted by wossname
Grr...not up to it right now...:D to much to think about...but I found out that I can all ready do it in World space, so that will also increase the speed, but then again that means taking the controll away from you, as I said in my last post.
BlackBox is here to rule the world.
- ØØ -
You've changed your mind again, I thought you wanted to use MapCubes in your BSP instead of wallparts???
GP == graphicspath.
OK I don't mind you dealing with backface culling, takes a bit of stress away from me :)
I thought you didn't want to let me use that method..:D..well anyway...I can deal with wall parts but that means that we can't have maps that are much bigger then 30*30. So if that is ok for you, then 30 wallpart it is. If you want much bigger then that, lets say, close to 100, then we need to use cubes.Quote:
Originally Posted by wossname
?? :confused: The trick I showed you...or ??? ehhh :confused:Quote:
Originally Posted by wossname
Well, it is going to be faster if I do it anyway..:)..going to take some time all this though...Quote:
Originally Posted by wossname
- ØØ -