Those timings are for 1024x768 by the way.
I'll experiment with texture image sizes there may be an undocumented optimum size.
Printable View
Those timings are for 1024x768 by the way.
I'll experiment with texture image sizes there may be an undocumented optimum size.
And don't forget this test machine is a bit crap. It'll fly on a 3ghz rig. 30+fps.
Timings for different texture sizes...
40 triangles @ 1024x768 game screen area:
texture: 512x512 = 1 frame per second :D
256x256 = 5 fps :sick:
128x128 = 12 fps :(
64x64 = 16 fps :)
32x32 = 16.5 fps but has some ugly artifacts and it crappy resolution.
My original guess of 64 by 64 is about optimal, my previous tests were with 128x128 textures.
There is still a bit of scope for optimisation. Hopefully I can get it up to 18-20fps by the weekend. Then the 3d math can have a bit of breathing space.
I still have to do about 2000 calculations in a matter of 10ms or so though..:D...and traverse a tree with as many nodes as the map has walls...going to take forever..:D
PS: Grrr...getting so confused about the world to screencoordinates..:D
- ØØ -
Are you using unsafe code for the calculations? That should help a bit, although you can't do pointers to managed classes which is incredibly annoying (although understandable). There's not many places in my code where unsafe will help though :(
I still have at least 2 optimisations to try out, probably think of more tomorrow.
I hate the both of you...I wish I knew 1/1000th of this stuff :p
And I have tried learning, but I always get sidetracked (I think I have AD...Hey look! a kitty!
Quote:
Originally Posted by wossname
I will probably use it for the three, but that is miles away right now, since I am going on a vecation on Monday. But for the world to screen it isn't much use for it. Might find a place or two where I can optimize with pointers later on, but first I just need it up and running. Getting closer now, but it is still some mile stones away. (is that even an expression in english...hmmm).
Quote:
Originally Posted by kfcSmitty
Thanks, I hate you too..:)
And sure you know 1/1000th of what we know. At least me...I am a beginner here...:)
Any chance of you sendin me your half of the project before you go?
Then I can alter my half as needed to accomodate your's.
yeah sure....but I will wait as long as I can to do so. because there is still a chance that I can get the camera to work before I leave...SMAAAL chance..:)
- ØØ -
Hehe...this is just hillarious..:D..what do you think about my coding style..:D
Code:Vector3 vAxis = (m_lookAt - m_position).crossProd(m_up).normalizeThis();
Its all good baby! Saves having to declare temporary variables :)
I've done similar stuff a couple of time in TexEng (the rendering engine).
I will add a weapon crosshair to the screen too, maybe several different types like there was in Quake II (laser dot, cross or angle). Shouldn't affect framerates noticably, could even be semi-transparent :D
I don't think we need to add enemies or any real gameplay. This should be an option for MUCH later. If we have the computer power to spare we should consider it but not now. I'm happy for this to remain a software graphics demo.
Any thoughts? :)
Yeah, forgett about the enemies...at least for now...if we add something they are probably just going to be billboards anyway...will take 100hours to actualy render a real mesh..:). And I don't even want to start to calculate the movements and so on...:)
- ØØ -
Well I was thinking more along the lines of the 2 dimensional enemies from Doom 1.
Meshes would be a nightmare :)
== Billboards...;)Quote:
Originally Posted by wossname
Thats what billboards are you muppet..:)...I think that would have been fun. But it would be for iteration 2 or 3. BTW when we are at it, maybe you should make a map creator too...;)
Not heard that use of billboard before.
Do we really need a map editor? I thought we were using a text file to define the maps. I could do a map editor after I finish my current book chapter. Might as well be a proper vector map instead of a 2D numeric array. I'll think about it. We could get some more optimisations if we use textures that span more than 2 metres in the game world, we could have a single long wallpart (say 8 metres) instead of 4 normal ones. The texture would have to be 4 time wider too but thats OK.
Then we could have hexagonal rooms, bendy corridors and so forth.
That would be really cool, but again I have to say that it sounds like a second or third iteration thingy. And yes, I guess it could work with longer textures too, but then we would have to have textures in all "colors" spanning 1, 2, 3 and 4 and maybe more wallparts. Going to be an awfull lot of textures though...but they are so small anyway, so I guess it won't eat all our memory...
Billbaords:
The effect of making a 2D image to rotate towards the camera at any time...:)
- ØØ -
Housten....I got it working...;)
I am going to stay a couple of more hours. But you really need to check this out as fast as you can, so I can tell you how it works, since I can't tell you tomorrow..:)
I havn't had the time to fix much at all...just made the lines of code all over the place that does the job. Functions have to be moved, and lines of code has to be made into functions and so on, so that is why I hope you get online so I can show you....but if you are not....then poor you at the moment..:)
[Removed because of frustration]
Hi folks ;)
Note showed me some of the pictures from your project, and I thought I had to warn you of one thing with rendering the textures. From my analysis I can see that the textures are rendered in isometrics, which is what causes those glitches with the diagonal. The more perpsective you have in viewing in say a wall you will see the texture out of perspective, since the pixels on the texture will be spaced out at the same distance on the screen near the camera and far from the camera. So when you render the triangles you need to increment the spacing after each scanline and that in proportion to the inverse distance to the camera.
Keda: Yeah textures will start to look weird when the perspective is harsh, but we can't really do anything about this without resorting to some non GDI+ resources (inline ASM compiled in a C++ library for instance). As it stands we don't have control over each scanline. If it turns out to be a real problem then we'll just have to use low-contrast textures so the illusion is less obvious.
Also greating small rooms, and short corridores will make them more difficult to see I guess...
OK...since I havn't had the time to fix the code, here is what you have to do to make it work right now...
- Make a Vector with World coordinates. Like (1, 2, 0).
- Then call teh UpdateProjMatrix() function, to update the conversion matrix.
- Then multiply that matrix (now called m_worldView) with the point.
- Then you get a new vector as the result.
- Throw this one in as a parameter in the function ViewScreen(Vector objectView).
- The result of this function is a vector where the X and Y component is the Screen coordinates.
- ØØ -
Woss: You can but its going to slow down the rendering even further, but what's the deal, you've already restorted to being without hardware support ;)
Note, its in the small rooms where perspective will show up, as you are close to the walls ;) one solution would be to make the textures uniform so you don't see much of a difference ;)
debuggery...
Quote:
Originally Posted by kedaman
What is a uniform texture? Do you mean single colour? Well as I all ready said, vertical stripes is not getting distorted either...:)..so I hope stripes are in today..:)
- ØØ -
no, because the stripes will appear with same width both near as far from the camera, just ask woss to put in a striped texture and see what I mean ;)Quote:
Originally Posted by NoteMe
Ehhhh....w00t? You sure?
If I draw have a texture here that is 200*200 pixels with vertical stripes, then I scale it to 100*100, then the stripes won't have the same width? I don't get that....you scale the triangles, hence you scale the stripes....
hehe, no I said they will have the same width ;) Or are you saying that they wont have the same width as the original textures? Anyway I was talking about the difference (or rather the lack of it) between the widths on the stripes that are rendered.Quote:
Originally Posted by NoteMe
Keda is right, if a stripy texture is used for a long wall then the stripes in the distance will be the same width (in pixels) as the ones in the foreground. It will look a bit weird. Also the spacing between then will be constant, which is also a bad thing.
I think low contrast textures are better such as plain concrete or metal. We can still have a texture but it shouldn't have many sharp features on it.
Maybe we will have to resort to ASM to make the textures draw properly. Not that I have a clue about ASM coding any more its been a good 12 years since I did any, and that was on a RISC machine anyway :eek:
well if you can do inline ASM in C# then there you go ;) alternatively you could make a dll in C++ or ASM ;) Or, if you want to do it pure C# now that you dropped D3D and openGL, you could always compute the spacing ;)
Can't do inline ASM in C# and we just doooon't haaaave the powerrrrrr captain to do the per pixel rendering in C#.
Really don't want to go outside GDI+ though.
WO0o0000ooOT!!!1!1
It lives!!!! Noteme is a geneus. I fixed a couple of minor math bugs in the transformation code and it ended up upside down and back to front so i changed a couple of "+" to "-" and it came out right!!!
The camera seems to bahave properly when it gets moved around. (cam_up vector seems to work ok too, if you tilt the camera a bit to the right (1, 5, 0) then the world seems to rotate to the left a bit).
Møøseman, I salute you. I may not be able to resist the temptation to mess around with your code. I'll try but at least its safe until friday, since my chapter is due in and I have done hardly any work on it yet :(.
Feast your eyes. This wireframe represents a wallparton the left side of a corridor that is a few metres ahead of us and 2 metres to the left. Corner sequence: red, yellow, green, blue.
:D
Can't wait to get this textured up and optimized.
I'm going to start coding a proper texture rendering function, that does a per-pixel copy onto a quad.
I just want to see how long it will take. It should be easy to optimise with unsafe code too. It'll probably be unbelievably slow but its worth a look anyway.
Hey, only just found this thread (well, was shown it)
Lots of posts...
Pixel by pixel will be so slow you dont even want to think about it, just checking the color of pixels of a fullscreen image takes long enough to require being a background function.
Overall GDI+ is limited by how many pixels are being handled. You may want to think about multi-threading your image (splitting it into quadrants) but this would be tricky as any wall overlapping all four would need rendering 4 times, so that in mind may not even be beneficial, but an idea anyway.
I have done some 3d stuff in GDI+ before (not as indepth as here) and thought i was really pushing it (because everyone says its pathetic).
One technique i did use for cubes (was not textured) was line by line (since in perspective the cube gets warped), you could try drawing the texture 1pixel wide at a time. As in px1 (and full height of the wall at this position), px2 of the image (and full height of the wall at this position).
btw, are you basically recreating doom ? because i'd love to see that to show people how powerful GDI+ truely is (when placed in the correct hands)
Well our scene wil be truly 3D, meaning the camera can rotate in all 3 axes.
We already have a texture rendering algorithm but its got some serious perspective issues. I was thinking that per pixel would increase the rendering quality if we could get it running fast enough but I have a feeling you are right.
Using Lockbits() on a bitmap and reading/writing the RGB data directly using unsafe code is about the fastest way to work with individual pixels. Allegedly its possible to get performance gains of 25times faster than using unlocked bitmaps and safe (managed) code.
I was also looking into ASM as a last resort but i really want to go as much of this with GDI+ as possible.
i understand you are rotating around on all 3 axis, where as my program is straight foward the whole way, however, it is the same theory of drawing a 3d theme, just your algorithms for calculating the corner positions changes, even in mine the lines are not straight (as illustrated), they angle the way they need to as they progress along the object.. although come to think of it, im not sure if textured lines will rotate the image for you.. will just use the next pixel along if the line moves across that way...
But i say don't give up on GDI+ go all the way.
You have implemented a fisheye lense effect. actual lines do not curve as they move away, they advance towards a vanishing point. Imagine looking up at the Empire State building, the walls always look straight, they don't curve unless you are using a fisheye lens.
I'm nearly done writing my per-pixel algorithm but i'm having trouble with a 2d vector. i'll post about it in the math and VB forums.
Actually i am going towards a vanishing points, (the co-ordinates are anyway, shrinking towards the center as distance increases)
the curved fault you see is the thickness of my lines being 2, to fill in some gaps, that causes this curved look, still a minor detail (and this was and still is a prototype as u can tell)
either way, this performs between 25-60 frames per second (although still just solid colours)
EDIT NOTE: actually after reading over the old code the lines are 1 pixels.. curve seems to be caused by rounding (as the two sheets meet each other) might review that now that youve got me interested
Guys, I'm not sure if its any help to you at all, but there is a basic 3D engine on Planet Source Code written in VB6. It uses GDI+ to render stuff, and rotate it with the mouse. Theres no textures, but the objects you can load are things like, spheres, cubes, donuts, etc.
Might be worth a look if theres math stuff (I couldn't understand it myself).
chem