OK, basically with a texture that has half of it transparent, it effectively becomes a triangular texture. If you want to skew a bitmap in GDI+ you need to specify the first 3 points of a parallelogram (the 4th is implied).
So using 2 overlapping para's and ignoring half of each one we can stitch together a whole trapezium.
Granted the texture will be a bit warped, but if we use subtle textures this will be less noticable, but the outline of the shape will be perfect.
All I need to make this happen is the 4 corners of the para. OR 2 triangles. Triangles would be better because it lets us shade and shadow each part naturally.
both of those drawn will look like the picture that noteme posted.
We ned to use simple textures to make this look right though.
If we wanted to use just a single color within the quad, it would be a simple matter of filling a polygon, and we might do this for objects far away in the distance. that would increase drawing speed massively.
Hehe...ok..yeah...well, I guess it is triangles all the way here...or at least quads twisted to paralelograms represented as triangles...this is going to take a LOT of processor power. I better make my part of the code REALLY REALLY good.....and we better not make big rooms where you have easily 40-60 wall/floor/roof items...
Hmm...so how do you want the points now. Do you only need 4 points for the actual wall, and you devide it up to become two paralellograms or?
PS: I am going to lunch in a a ccouple of minutes...be back in an hour...
An other thing...is it ok if we represent as room as a 2D array? Something like:
[Removed because of frustration]
and make it look funny....an other problem then will probably be to go from one texture to the other one...guess we have to do some manipulation in phptpshop. So we have a texture that goes from one texture to an other. So if 1 is one wall texture and 3 is an other texture, then we have to have a texture 2 that goes from texture 1 to texture 3 and a texture 4 that goes from texture 3 to texture 1, so we it looks nice if we do this:
12341 comared to just do this:
131
Any thoughts on this?
- ØØ -
Last edited by NoteMe; Sep 15th, 2005 at 06:29 AM.
Wallpart: One sqare (at the moment 64*64pixels).
Wall: Many wallparts after each other so it can be for example a whole wall in a room.
If that wall have to types of textures. Lets say like this house:
Then it will look pretty stupid if it was a totaly straight line on the middle where it suddenly became red on the right side and brown on the left side. Of course we don't have to support more then one texture on a wall, but it is just an idea. Want to hear your oppinion..
And BTW what do you think about the 2D array map idea? Doable? Or do you have an other idea. If you like it, I also guess we need a class to read in a map file too.
Well, it works but its not exactly what you'd call fast...
The number on the titlebar is the drwaing time in seconds as per your timer class. Doesn't include loading any textures or instantiating the rendering engine. The diagonal line is an atrefact of the stretching and the border of the 2 transparent regions.
First of all updating the text field of a form is expensive in it self..but it can't have that much to say. This was not really fast. Hmmm....
But since this will be a full screen app, I can't see any reason why you want to clear the back bufffer. Do you? You will after all write all over the buffer the next iteration anyway.
I am not sure how you are dawing in GDI+ anyway. But as long as you are not casting any big objects back and forth from functions, it should go any faster with pointers. As long as you use refernce that is.
BitBlt should be faster, but as you said. We probably don't wan't to go there.
The artifact (or atrifact as you like to call it) was nasty though. Didn't think about that. Both the line and th scewed end of the arrow is not what we won't I guess..
About the map format...hmm..yeah, you are right. But should we implement curved walls in the first iteration anyway? Is it nessesary? SHould we make a road map now, so we know where we are going, and set iterations, so we get some parts done before we start on other parts?
BTW if you use 0.03 sec on one picture, and we can expect to have 10-20 in the frame at every time, I guess we will end up with 3FPS or something just for the rendering..:
Nope , the drawing routine is dead fast, I just called it 20 times in a row and it hardly dented the time, although smaller parallelograms do go a bit faster.
Here's my timing code anyway: (yes it does look like MDX code doesn't it )
Hehe..yeah it does....what was the time after 20 wallparts or what ever you did. And BTW...why are you still clearing the backbuffer? Do you really need to do that...to me it looks like waste of time.
BTW, I just saw that CornedBee has all ready made a balanced BinaryTree and posted it in the CodeBank. I might be able to use that as the foundation to BSP. If I do, I will ask him later on if it is ok. Will save us a lot of time, and it is better then an unblanced tree too.
You've got to clear the buffer because if you don't the old drawings will still be visible..
I just realised I forgot to bring my work home so I can't continue with this part of it until monday I can do something else in the meantime though. Probably sleep with a bit of luck.
But helloooooooooo...this is a fullscreen 3D app. Indoor. EVERY frame you will draw over the WHOLE buffer. Not one single pixel will be left un rendered each frame. So how can you say that the old picture will still be there...it will get rendered over...????
I bet you didn't bring it with you home on purpose...boooo...I actualy sat half an hour extra at work today to bring my stuff with me home...I did a dist-upgrade on linux the last 20 minutes, and when I was going to go home I wasn't longer able to connect my MP3 player to my machine so I couldn't get my stuff out of that dumb machine.. Had to upload it to my server in the end...
No no no...what are you talking about.....Look at this picture:
If that was what we just drew. And then next frame the user camera has moved 3 cm toward the right side. Then you have to draw the roof again, because it has moved, you have to draw the floor again because it has moved, you have to draw the walls and door again because it has moved, so there is really NOTHING that won't be overwritte because after the 3cm move, everything has changed position...do you see what I mean..
We need to discuss lighting. I presume (hope) that we are just using ambient light and no localised light sources. Also how should a surface's angle to the camera affect its brightness?
EG. if a surface is facing us then the texture will be as normal, but as it turns away from the camera, does it get lighter or darker? (or does it approach an arbitrary shade of gray?).
I'll have to use ColorMatrices to draw these re-shaded triangles, but if the angle is large then we can just use a filled gray polygon instead, much faster.
It would be useful to make this quite a dark and atmospheric demo. All kinds of optimisations are availabe to us then.
Correctamundo! we are pushing the boundaries of the GDI+ to see how much it can do. It's going to be interesting whatever happens
I hope you can amaze me with some speed soon...
Well, hard to me to discuss your lightning since I have no idea how you use ColorMatrices and so on. But one thing is for sure. If you are planning on only using Ambient lightning, then it is easy. Ambient lightning is the ONLY lightning made in DX and OGL that doesn't actualy exist in the real world.....it is a light that lit every surface equaly much, the only difference in result is the materical color for the lit surface. So that means that the degree between camera and surface doesn't have anything to say.
Of course if you really want we can add other lightning effects as we go. But I wouldn't prioritize that if I where you.. So what is happening with our road map? Something like this:
Iteration 1:
- Read in the walls from a file (what file format?)
- Sort them according to a starting position.
- Straight forward draw 20 walls. (no culling, no Space Partitioning, no ....)
Iteration 2:
- Make camera, so we can start to move.
- Get input, so camera can move.
- Draw more realistic walls (wØØsys Colormatrices and lightning questions and hoohooo).
Have I forgotten something importent? Please add it while I drink the rest of this beer..
My god guys. I wouldn't mind having a look at it when you's are done (or whenever you feel like showing it to people). I've had a little bit of experience with C#, and getting back into .NET would no doubt prove alot easier looking at this
I've always wanted to do something like this in VB6/ASM. I just can't get my head around the 3D math
I would say BSP would be the way to go NoteMe. I posted a link to a very good article about BSP Trees (I think to Electroman, or maybe it was you ) a short while back. Worth the read, if you haven't already
It was probably me or Keda posting it.....maybe in our big Space Partitioning thread.....if it wasn't I would be glad if you showed it to me. Since I can't remember any other then that one.
This is going to take some time though. I am leaving on a vecation for 10 days in a week. And then an other vecation for 9 days or so the week after that. At least if I am lucky. But the work has started, so we just have to see where it ends up...
The article doesn't go really deep into the field. At least not as deep as the links I all ready have. But thanks anyway. Not able to rate you today anyway..must have done it lately I guess...
Well, hard to me to discuss your lightning since I have no idea how you use ColorMatrices and so on. But one thing is for sure. If you are planning on only using Ambient lightning, then it is easy. Ambient lightning is the ONLY lightning made in DX and OGL that doesn't actualy exist in the real world.....it is a light that lit every surface equaly much, the only difference in result is the materical color for the lit surface. So that means that the degree between camera and surface doesn't have anything to say.
Yes, but it would look slightly more realistic to be able to fade a high-angle surface to a single color, we might only actually be using ambient lighting (not lightning you fool ) but at least we can fake some environmental effects.
Iteration 1:
- Read in the walls from a file (what file format?) any image format for the textures size limited to exactly 64x64 pixels at the moment
- Sort them according to a starting position.
- Straight forward draw 20 walls. (no culling, no Space Partitioning, no ....)
Iteration 2:
- Make camera, so we can start to move. Just an XYZ position and a couple of vectors?
- Get input, so camera can move. There is a joystick class in Sandpaper.dll knew it would come in useful ONE day
- Draw more realistic walls (wØØsys Colormatrices and lightning questions and hoohooo). This is going to be hard to do. We'll see. We should keep textures simple.
Have I forgotten something importent? Please add it while I drink the rest of this beer..
- ØØ -
I'll work on the automatic triangular texture code (takes a normal picture and cuts it in half diagonally, filling the other halves with transparent pixels).
I'll work on the automatic triangular texture code (takes a normal picture and cuts it in half diagonally, filling the other halves with transparent pixels).
Iteration 1:
- Read in the walls from a file (what file format?) any image format for the textures size limited to exactly 64x64 pixels at the moment. Since you started to talk about picture format, I guess I have to add what I really ment. Map file format....
- Sort them according to a starting position.
- Straight forward draw 20 walls. (no culling, no Space Partitioning, no Occlusion..finaly..I remembered the word..)
Iteration 2:
- Make camera, so we can start to move. Just an XYZ position and a couple of vectors? Havn't you learned anything from your MDX days....We need, position vector, lookat vector, and up vecotor, and of course functions to work on these vectors.
- Get input, so camera can move. There is a joystick class in Sandpaper.dll knew it would come in useful ONE day. Not that I have a joystick though, so guess keyboard, (mouse?) has to be used too.
- Draw more realistic walls (wØØsys Colormatrices and lightning questions and hoohooo). This is going to be hard to do. We'll see. We should keep textures simple.Ai ai sir...you deside that one..
Since the map files will be read into the 3d engine directly I think that is entirely up to you, use whatever format suits your code , I am concerned only with graphics at the moment. I have started work on distance darkening (DD), and it works great, depending upon how fast I can generate color matrices we can get some good effects here. If its too slow to generate them on the fly then I'll have to have a buffer of colormatrices and select an appropriate one.
I think I can save some time by optimising the surfaces I'm are drawing to. Use a few SetStyles() to drop some default options. May increase rendering speed a bit.
I have tried fiddling with Bitmap.LockBits(WriteOnly) but it seems to prevent drawing rather than accelerate it. MSDN is no help on this subject.
I'll be back to coding it the main graphics engine again tomorow, I'll take my DD code to work and incorporate it into the engine.
"so just keep in mind that fantasy is not the same as realtiy and make sure u remember that wii sports may be fun but u cant count on it as exercise ok cool bye" - HungarianHuman
Hmm...if that is wraps around the GetPixel and SetPixel API, then they are bound to be REALLY slow. IF they are wraps around some of the DIB interfaces or something, then it might be interesting. wØØsy?
Since the map files will be read into the 3d engine directly I think that is entirely up to you, use whatever format suits your code ,
But if I do it the way I stated in one of my first posts here, then you won't get your round corners...and BTW I just remembered that I have no idea how to read or write to a file in C#.....I think I need to start there now..
...and we better not make big rooms where you have easily 40-60 wall/floor/roof items...
Originally Posted by chemicalNova
) a short while back. Worth the read, if you haven't already 