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
Just saw it, looks a bit primitive. Probably doesn't count as a 3D engine though. Anyway we already have a more advanced engine set up. :D
Hope Note doesn't mind that I've broken my promise not to mess with his code :D It was just too much temptation.
Making progress now. Walls in green, floor and ceiling in grey... four wall parts in total, 8 triangles. 800x600 mode.
34fps approx (not happy with this but we have a fair bit of stuff we can optimise).
The camera is deliberately offset slightly to the right and slightly up but its looking on (0,0,1). The tunnel should be square but the scene appears to be stretched along the x axis (I think its something to do with the aspect ratio. Otherwise the drawing is correct :D
update...distance darkening. framerate 30fps :D
AntiClockwise Culling:
Camera moved out to the right (and turned to face objects) so its no longer inside the tunnel. Thus the right side of the tunnel is deliberately not rendered because its points are no longer clockwise onscreen.
Damn guys. You r0xx0rz my b0xx0rz. Keep up the good work. I think I'll go skim the rest of this thread to see how things are going. I read part of the first page a while back.
Woot. That was quite a read. I had no idea what 80% of it was talking about. But I will try to keep up on whats going on in this thread. You guys need any help with finding textures still? I know smitty was looking for some for you before. Any other minor things that I could help with?
Some hastily made experimental perspectival texture rendering in C++ if you guys are interested :D Sorry about the texture itself, couldn't bother making one so i pulled that one off the stack.. looks funny as the textures changes with the variables ;)
Yeah dude, we need textures desperately. we need things that would look like the ones in Doom (preferably not identical though) and we need them in 256x256 pixels size (or larger, so we can resize them as required).Quote:
Originally Posted by eyeRmonkey
We currently have no decent textures, so anything you could give us would be a big help, and you'd get onto the credits page too :)
Keda: Thats exactly the sort of thing we need, I'm trying to write something like this from scratch to see if i can manage it but if you have the code for that we'd appreciate it.
You've come along way
congrats! that's looking really good and at 30fps, hopefully you can keep this hanging around at least 20 when the screen is filled with walls, i think your animating characters will play a big role in this, but as long as you just make more powerful single enemies as opposed to swarms of useless slaughter, it should be ok.
I packaged up some "doomish" textures from my old backgrounds folder, i dunno how useful theyll be to you.
Nice one phill. pinkmarb.bmp looks nice...Quote:
Originally Posted by Phill64
Well, since i'm a fan of experimenting with algorithms, i tried to come up with a perspectival texture painter but it takes a WHOLE second to draw this:
Its not optimised though, which is a poor excuse but i don't think any amount of optimisation will help this alg.
We'll be sticking with isometric textures for a while unless Kedaman can deliver on the C++ alg he talked about.
Here's my feeble effort anyway...
BTW, here's my alg for the perspective if anyone feels like commenting on it. I'm not going to try to optimize it.
VB Code:
If you want true perspective correct texture mapping, I got code in both C++ and VB that you can convert to C#. If you need any more code if confused by something in these, I'll get back to ya. ;)
I guess Jacob Roman got a much better code listed as mine can only handle the usual rectangular walls you see in Doom. But still its pretty fast rendering.Code:int texture[9];
int xt=0,yt=0,//texture iterators
w=30,h=30//
,WIDTH=(_clientrect.right-_clientrect.left),//screen width
CENTERX=290,CENTERY=180,//screen position at Camera center
CENTER=CENTERX+CENTERY*WIDTH;//array disposition of center
double x1=-500,y1=-500,z1=3,//top left vertex
x2=500 ,y2=500,z2=10,//bottom right vertex
xi=x1 ,zi=z1,//texture iterators 3d
xa=(x2-x1)/w,za=(z2-z1)/w,//texture 3d increment
Px1=x1/z1, Py1=y1/z1,//2d corners
Px2=x2/z2, Py2=y1/z2,
Px3=x1/z1, Py3=y2/z1,
Px4=x2/z2, Py4=y2/z2,
W=Px2-Px1,//2d width
H1=Py3-Py1, H2=Py4-Py2,//2d heights
HPW=(H2-H1)/W/w,//screenpixels/texturepixel increment
BH=Py2-Py1, //bottom edge diff in height
BHPW=BH/W, //bottom offset increment
YI,XI,YS,
YT=H1/w;
int X,Y,X0=xi/zi,Y0;
while(zi<=z2){
YI=y1/zi;
X=(xi+=xa)/(zi+=za);
while(X0<X){
Y0=YI,yt=0,YS=YI,Y0*=WIDTH;
for(int i=0;i<h;i++){
Y=(YS+=YT)*WIDTH;
while(Y0<Y)
_pBits[CENTER+X0+Y0]=texture[yt+xt*w],Y0+=WIDTH;
yt++;
}
X0++,YT+=HPW,YI+=BHPW;
}
xt++;
}
With my code, it would be better to use look up tables in some areas for speed
So you guys don't want me to use the texture extractors you talked about earlier? So should I just be googling for random textures? I havn't played the original Doom forever so I am not even sure what I am looking for.Quote:
Originally Posted by wossname
Whether wasting cpu time on perspective textures is viable or not really depends on how the maps are going to work and how much extra time is taken to do it. It appears to me that you are going to block together the walls piece by piece.. each piece will have its texture drawn seperately(scaled to the current position of that segment) Thus you will never have the case where you will have a long wall looking incorrect because of this limitation.
However the size of the tiles will effect this also, if the tiles will be fairly large, then it will be problem as the joining of each piece will be rough, but if the tiles remain small it won't be an issue as the wall scaling itself will be enough to control it.
All right, we'll shelve this idea for a while. Its just not practical.
Monkey, use whatever tools you want, its not important really. Just think "I'm inside a battered old space station, what would I expect the walls to look like?".
Greasy metal bolted walls, gratings, strip lighting computer panels.....just let your imagination go mad.
Anything, ANYTHING will do :D we need something at least.
Not practical? I get a decent 50 fps drawing 20 of those walls in a loop, and think I can optimise it further. Almost done with a version that supports any triangles.
How bout direct memory addressing to draw pixels at lighting speeds onto the backbuffer, and swap buffers to the main window. It's a thought.