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
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 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
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
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?
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).
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.
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.
AntRush - Real-Time Strategy game, based around ants!
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.
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.
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.
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++;
}
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.
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
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).
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
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.
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.
AntRush - Real-Time Strategy game, based around ants!
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 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.
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
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.
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
Use
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
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.
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.
Can't wait to get this textured up and optimized.
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....
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..
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).
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
I have said that I have 600Mb of textures home you know...grrrrrrrrrrrrr...
Originally Posted by wossname
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.
I can port it if you want....if it is not all ready done *keeps reading the thread*
Yeah you should have written it in Befunge or something
I'll post your my code later on so you'll need to do what I said in my PM.
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..
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..
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
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.
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).
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.
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.
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.
It was just too much temptation.
Originally Posted by eyeRmonkey
Multi-Clipboard
Mark Thread Resolved
.
