That cute little button with the house and the 'www' under my posts, or even my two toned name in the signature will get you there. Nothing much really - I use the links. :tongue:
Posted on 2001-11-22 14:27:44 by bitRAKE
Guys,

can we pull the plug on this debate, thats what we have the Holy Wars forum for.

Now as far as "pre-ordering" code, please keep in mind that our members are not a free code production service, there is no problems asking if someone has some code that they may wish to share but treating people like "objects" will get a very cool response here.

Just keep in mind that behind every nick name here is a human being who comes here to help other people. Respect that and you will do OK here.

Regards,

hutch@movsd.com
Posted on 2001-11-22 17:49:17 by hutch--
how can i start directx 8.1 programming in win32asm using masm 6.11 ? I have no experience with directx programming.
Posted on 2001-11-26 04:50:39 by amr
Afternoon, AMR.

hrrm.
how can i start directx 8.1 programming in win32asm using masm 6.11 ?

To program DX8.1, you'll require M$ VC/C++6. Have you got that proggy?

I have no experience with directx programming.

Understandable. We all start there ;) .
Have you got the DX8 SDK or P/SDK yet?

Cheers,
Scronty
Posted on 2001-11-26 06:40:31 by Scronty
I have got the directx 8.1 sdk for visualc++ full sdk,
but I haven't tried to program using it yet I don't know how to use
it, thanks for replay
good bye
Posted on 2001-11-27 05:56:40 by amr
Hi amr !

There are not much differences between DX8.0 and DX8.1 - just some improvements for the pixel-shader and some minor changes.
So just take a look at those dx8.0 examples here. They will tell you everything you need ...

Greetings, CALEB !
Posted on 2001-11-27 14:12:46 by Caleb
Ok so I'm still working on the terrain generation example, but I hit a snag.

Basically what I'm doing to generate pseduo random terrain is:

fill in all the position "y" in the vertex buffer with random values (it is between 0 and pi for now).


push eax
fldpi
call GetRandomFloat
fmulp st(1), st
pop eax
fstp [esi + eax].CUSTOMVERTEX.y


Then by hitting the "HOME" key it is *supposed* to run through an algorithm (SmoothTerrain PROC) that will change the y postion of a vertice based on the position of the y-positioned vertices around it... in other words in C++ it would be:



for(ix=1; ix<TERRAIN_SIZE-1; ix++)
for(WORD iy=1; iy<TERRAIN_SIZE-1; iy++)
{
float zzz = (Plane.p_ObjVert[0][ix-1+(iy-1)*(TERRAIN_SIZE+1)-1].position.y +
Plane.p_ObjVert[0][ix+(iy-1)*(TERRAIN_SIZE+1)-1].position.y +
Plane.p_ObjVert[0][ix+1+(iy-1)*(TERRAIN_SIZE+1)-1].position.y +
Plane.p_ObjVert[0][ix-1+iy*(TERRAIN_SIZE+1)].position.y +
Plane.p_ObjVert[0][ix+iy*(TERRAIN_SIZE+1)].position.y +
Plane.p_ObjVert[0][ix+1+iy*(TERRAIN_SIZE+1)].position.y +
Plane.p_ObjVert[0][ix-1+(iy+1)*(TERRAIN_SIZE+1)].position.y +
Plane.p_ObjVert[0][ix+(iy+1)*(TERRAIN_SIZE+1)].position.y +
Plane.p_ObjVert[0][ix+1+(iy+1)*(TERRAIN_SIZE+1)].position.y) / 9;

Plane.p_ObjVert[0][ix+iy*(TERRAIN_SIZE+1)].position.y = zzz;
};


Instead of writing out the whole procedure I'll just include the source to the program and a demo example (use the home key to check out the problem). The example will look all sharp cuts because the procedure didn't work

Sliver
Posted on 2001-11-27 15:03:50 by Sliver
Found a few obvious errors :(

First: f9pt0 which is a floatshould have been "9 pt 0" or 9.0
-- instead it was 2.0 -- go figure


Second:
mov edx ,

it shoudl have been 4
because I pushed ecx (which contained "iy" onto the stack second and that would be what is at

This was a huge error and goes through the whole procedure --
So this is how I'm solvingthis problem (haven't actually worked on this in the last 2 days because I've been "away" but I hve a printout in front of me...




@OuterLoop4:
push ecx
mov ecx, 1

@InnerLoop4:
push ecx
__iy equ <DWORD PTR [esp]> ;used for clarity
__ix equ <DWORD PTR 4[esp]> ;used for clarity

;Plane.p_ObjVert[0][ix-1+(iy-1)*(FLAG_S + 1) - 1].postion.y
mov eax, FLAG_S+1 ;FLAG_S+1
mov ecx, __iy
dec ecx
mul ecx ;(__iy-1)*(FLAG_S+1)
mov edx, __ix
dec edx
add eax, edx ;ix - 1 + (__iy-1)*(FLAG_S+1)
dec eax ;(ix - 1 + (__iy-1)*(FLAG_S+1)) - 1
mov edx, sizeof CUSTOMVERTEX
mul edx
fld [esi+eax].CUSTOMVERTEX.y

;Plane.p_ObjVert[0][ix+(iy-1)*(FLAG_S + 1) - 1].postion.y
mov eax, FLAG_S+1
mov ecx, __iy
dec ecx
mul ecx
mov edx, __ix
add eax, edx
dec eax
mov edx, sizeof CUSTOMVERTEX
mul edx
fld [esi+eax].CUSTOMVERTEX.y

;Plane.p_ObjVert[0][ix+1+(iy-1)*(FLAG_S + 1) - 1].postion.y
mov eax, FLAG_S+1
mov ecx, __iy
dec ecx
mul ecx
mov edx, __ix
inc edx ;now add 1 to __ix
add eax, edx
dec eax
mov edx, sizeof CUSTOMVERTEX
mul edx
fld [esi+eax].CUSTOMVERTEX.y



Ok haven't checked it out, but it should work -- I hope... If someone wants to check it out and change all relevant code -- tell me if it works (otherwize I'll do the changes sooner or later)

Sliver
Posted on 2001-11-28 20:06:09 by Sliver
im going to post this stupid incomplete program of NeHes' i like to call mine on this forum & who ever wants to help me see why the hell i cant get it to work for a whole year then that would be nice .

it works but i am trying to make a loop inside the opengl scene so that i dont have to rewrite "_gltranslate" Etc. over & over again when ever i want a structure made of polygons .

one time i got a program from NeHe & someone told me it had a virus so if this does then i had nothing to do with it .

if i ever get rich i am going to build an abstract college foundation that doesnt suck or in other words the students will controll it & it will be more like a commune / lab .

heres the "include.def" please excuse mr. NeHes' dirty language .


DM_BITSPERPEL = 00040000h
DM_PELSWIDTH = 00080000h
DM_PELSHEIGHT = 00100000h

_glClearDepth MACRO t ;this is not defined in hardcode's include files
gl_dpush t ;so here it is.
mov eax, eax
mov ecx, ecx
call glClearDepth
ENDM

_glColor4f MACRO R,G,B,A
gl_fpush A
gl_fpush B
gl_fpush G
gl_fpush R
mov eax, eax ;without this crap, it fucks up
mov ecx, ecx ;don't ask me why...
call glColor4f
ENDM

_glClearColor MACRO a,b,c,d
gl_fpush d
gl_fpush c
gl_fpush b
gl_fpush a
mov eax, eax
mov ecx, ecx
call glClearColor
ENDM

_gluPerspective MACRO a,b,c,d
gl_dpush d
gl_dpush c
gl_dpush b
gl_dpush a
mov eax, eax
mov ecx, ecx
call gluPerspective
ENDM
Posted on 2001-11-29 09:37:10 by comofmic
Ok, got home an hour ago and fixed the code (so now the PROC Smoothterrain is working :)

I'm assuming all is now right -- The movement code is still pretty crappy... I don't know what to do about this, because I've never really considered how I actually move in 3 dimentional space :( at least code wise -- Anyway here is the program added functionality to the insert and delete keys to spin you (Might make it easier to figure out walking around and seeing what happens when Smooth Terrain is done... Oh the only problem is that in my function the outside vertices aren't affected (more easily seen in the program)

Inotherwords







where UV is Uninfected Vertice (by algorithm)
and CV is Changed vertice (by algoithm)

this was done because the vertic had to look at all 8 points around it to determine what size it would change to... I wasn't sure how to take into account for being the top, bottom, left or right vertices...

if anyone has an ideas how to change this so I have nicer looking map edges I'd appreciate it...

-=Sliver=-

---EDIT---
I should have mentioned that SmoothTerrain is call, I believe, just once when the application is initialized (in InitGeometry) -- if you want to see what it looks like with smooth terrain not on just comment the call (BTW, Home key is still used to call smooth terrain, however, it calls it like 60times a second so you may want to add the call in directly to see exactly what's happening)

Thanks again
Posted on 2001-11-29 18:40:33 by Sliver
I've gotten sick and tired of not being able to move correctly in a 3d environment... Because of this fact I've decided that I must create some movement code...

So this is what I think woulkd be the best plan:

Take the my location in the 3d world (x,y,z)

and then find where this point intersects the closests vertex below it.

take the height (y-position) and then make my height some value plus the vertex height. now it seems very easy, but I forgot how this can be accomplished.

This would mean that as long as I'm on the terrain I would seem like I'm walking right above its surface :)

Sounds easy enough, but I'm not sure how to begin...

It might be the best to start off telling me how do I find my current looking position in DirectX :) Once I get that I can try to intersect the point below that...

Sliver
Posted on 2001-11-30 09:49:49 by Sliver
I seriously need help... anyone...

Until I can figure out a few more things I'm completely stuck and nowhere can I find an example of how this is done. It would seem those that program using d3d aren't very giving with their source code as people on this site (if I had at least that I may be able to extract the c++ and convert it)

Things I'm still trying to do:

-- Create walkable terrain

-- Using various textures create a level effect
(ie. green -> brown -> white (to make it look like a mountain of sorts)

--Create a sky-box behind the terrain

The walkable terrain I thought was going to be easier than I've actually found it to be...

Given a point (the player (x,y,z)) a direction(vector) and a plane I can give the point of intersection on that plane... however, I don't really have a plane and I don't know the point anyway :(

So if anyone wants to seriously help me please e-mail me or send me a private message or just give suggestions on this forum

Sliver
Posted on 2001-12-06 00:00:01 by Sliver
Afternoon, Sliver.

Attached is your proggy with "cursorkey" movement support.

Cheers,
Scronty
Posted on 2001-12-28 01:39:44 by Scronty
Thanks Scronty, I had just about given up on this... I just didn't know how to port some of this stuff from C++ :( Anyway, I appreciate the work and I'll upload a copy of new program with all the fixes and some added stuff soon.

Sliver
Posted on 2001-12-28 02:29:47 by Sliver
Afternoon, Sliver.

I've mucked around with the proggy. Thanks go to Scali for putting me right:alright: .

now, the terrain stays where it is (i.e. it doesn't move), and the camera(View) gets moved about.

The only changes I made are in the "SetupMatrices" proc.

Cheers,
Scronty
Posted on 2002-01-06 07:39:32 by Scronty