Printable View
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.
Keda: your code lacks a function signature, I can't work out what i'm supposed to pass into it.
Here's a simplified summary of our drawing system:
1. backbuffer bitmap is declared of the same size as our screen area (once, at program bootup)
2. for each wall segment we know the 4 corners
3. each wallpart is split into 2 triangles, upper and lower
4. upper and lower are rendered separately as 2 triangles with isometric textures
5. once all wallparts are drawn the backbuffer is copied to the screen.
Basically thats it. The isometric texture drawing is very fast due to the GDI+ api.
That's what i'm doing using CreateDIBSection
Woss: Just drop that one in your code. You need to use CreateDIBSection to access the bits on the backbuffer though:
Code:_bitmapinfo.biSize = sizeof (BITMAPINFOHEADER);
_bitmapinfo.biWidth = _clientrect.right -_clientrect.left;
_bitmapinfo.biHeight = _clientrect.bottom -_clientrect.top;
_bitmapinfo.biPlanes = 1;
_bitmapinfo.biBitCount = 32;
_bitmapinfo.biCompression = BI_RGB;
_bitmapinfo.biSizeImage = 0;
_bitmapinfo.biXPelsPerMeter = 0;
_bitmapinfo.biYPelsPerMeter = 0;
_bitmapinfo.biClrUsed = 0;
_bitmapinfo.biClrImportant = 0;
_bitmap = CreateDIBSection (NULL,(BITMAPINFO*)&_bitmapinfo,DIB_RGB_COLORS,(VOID**)&_pBits,NULL,0);
Ok. I'll look around for a while.
I guess I am somewhat useless as a texture finder because I am on 56k and everything takes forever to load, but I will continue look anyway. Here is a good link for a bunch of metal textures.
http://www.mayang.com/textures/Manma...tal/index.html
When I was making crappy 2D games I had a look around these sites which had some pretty good ones.
Here (Zips)
And for my Half-Life programming stuff..
Valve Texture Resources
Texture Pack (Zip size 124mb)
chem
Ok, gun sight and a small head-up-display...
I think that once we have occlusion cullin in place this will be a decent algorithm.
Don't comment on the roughness of the HUD and the gun, they will probably not end up transparent anyway :D
Alsothanks to smitty for this avatar demonstrating isometric texture abberation...
http://www.vbforums.com/attachment.p...id=39601&stc=1
Quote:
Originally Posted by wossname
Grrrrr....so I should really have obscured the code a BIT more so you wouldn't find out how to use it before I got back from my vecation...grrrrrrrrrr....
- ØØ -
Quote:
Originally Posted by wossname
You are so giving me a hard on now, even if you have messed up my code...and your code.....but you are so triggering my light finger...what about some Blinn/Phong lighting in our engine..:D
- ØØ -
Yeah you should have written it in Befunge or something :D
I'll post your my code later on so you'll need to do what I said in my PM.
I have said that I have 600Mb of textures home you know...grrrrrrrrrrrrr...Quote:
Originally Posted by wossname
Quote:
Originally Posted by wossname
I can port it if you want....if it is not all ready done *keeps reading the thread*
Quote:
Originally Posted by wossname
I have to leave work early today. Need to get some food. But will try to bring it with me back home and have a look at it. Might also start on the BSP tree since that soon has to be implemented anyway..:)
- ØØ -
Its at home right now so i'll email it to you later on, pm me with your email address.
Sendt PM. Maybe you should elaborate on that new map format here, in staed of answering about it in the PM. So others can see it, and you can aslo posts some pictures about what you mean..:)
- ØØ -
Good idea, extract from my PM to NoteMe...
Well the way i have it now (not finished though) is that you create a MapCube object by passing in 3 parameters:
1. the SouthWestBottom corner of the current cube
2. The length of the cube's side
(these first two are used to define the 8 corners that make the cube)
3. An array of 6 texture integers (if -1 is found then this wall is not used, zero and above means one of the texture images)
Thats all you need to create one cube of the map, a corridor might be 5 cubes in a row for example. I have already tested this MapCube onscreen and it looks OK.
The setup test code for a 6 metre coridor would look like this
This is a good system because its easy to setup, all the vectors are handled internally and this means clockwise points are dealt with properly (clockwise from inside the cube).Code:Cubes[0] = New MapCube(New vector(0,0,0), 2, new int[] {0,1,-1,2,3,2}); //-1 means the north wall is missing because it connects to the next cube to the north
Cubes[1] = New MapCube(New vector(0,0,2), 2, new int[] {0,1,-1,2,-1,2}); //north and south a mising because this is the middle of the corridor.
Cubes[2] = New MapCube(New vector(0,0,4), 2, new int[] {0,1,3,2,-1,2}); //south wall is missing (opposite end from the first cube)
//texture 3 could be a door or something, one at each end of the corridor.
We can do large rooms, corridors, "crossroads", "T-junctions" anything floor layout that sticks to a square grid can be done easily. Its just a matter of leaving walls out when we specify the textures.
Here's an illustration of the above code.... Its a birds eye view so you can't see floors or ceilings, just the walls. Hope this makes sense. Its jsut a simple 6 meter long corridor where each cube is 2 metres in size. Where the cubes meet we disable that wall so you can see into the next cube. The walls are disabled by putting the value -1 into the texture index array in the constructor.
All the vectors are assigned to each of the potential 6 sides of each cube automatically by the constructor.
As you can see from that image
The walls that have been disabled:
A North
B North and South
c South
This means you can stand in the Southern-most cube (A) and look north and you will be able to see all the way to C at the north end of the corridor because all the walls in between are missing apart from the sides, floors and ceilings. Thus a tunnel corridor is created.
So by using this system we could just have an editor that looks like this:
all we'd need to do is click a square to toggle between room, corridor and nothing
Then the computer can decide which walls to remove based on adjacent squares.
It should take no time at all to design a map like this :D
Well basicaly it doesn't do or peform anything else then the map system I have all ready made. It just represent it in an other way. :confused:
- ØØ -
Then I must have misunderstood what your idea was. Care to run it past me again? I can't see how you'd represent 6 sides per grid square just by using a 2d array.
ok just had a look at your posts in page 2. Its a bit of a hard way to design a level. In the editor I'll be putting a preview box that lets you look at the current cube and change the textures by clicking the sides of the 3d box.
At the moment all the namespaces are a bit messed up. I want to put the 3d in its own DLL file and then we can access things like wallparts, vectors and primitives from both the editor and the game. I'll do that tonight before i send it to you.