I'm going to hold up now momentarily until I hear some grunts of satisfaction - in other words, I want to clear up the issues with the includes and get everyone to the point where they have an executable file to run.
Posted on 2003-10-10 08:14:39 by Homer

The macros in the FKT file are ALTERNATIVES to the associated DX functions of the same name. We can't call a macro and a procedure the same name, so we have to disable either a PROTO to a procedure, or comment out the macro of the same name. I have stated that the FKT macros are in fact preferable to the DX functions, but they will BOTH work, and furthermore, you can happily mix and match them provided the names are not duplicated. If you WANT to, you can rename the macros and have the full complement of both codebases at your disposal.
Does this make sense?

of course it does :) .. but will i get problems if i kinda mixed that now? i mean, once i commented out the proto, and then the complete macro.. i'm not sure if I'll have problems calling this stuff..
if i understood right, the ones are macros and the others are functions, you call them differently.

seems that I'm missing a whole lib package or something :( .. the next missing file is uuid.lib

sorry that you had to stop, because of me actually.. but i really want to get started with this.. i never thought that I would be confrontated with such problems..
perhaps we should think about the implementation or the possibility of programming dx in asm (without problems like this)? :tongue:

could be that i can't visit the board for the next 2 days :(

Posted on 2003-10-10 16:23:46 by NOP-erator
sorry.. i found the two libs (the second "missing" was libci.lib), they were in the masm32\lib folder.. but the linker said it could not open them. i copied both to the same folder as the source is, and it FINALLY compiled!!! YAY!!

but trying to start the exe, it sais that it can't start because there is no MSVCR70.dll :(
i heard of that dll in connections with C++ .. but i've no idea about that :(

thank you for your attention.
Posted on 2003-10-10 16:33:16 by NOP-erator
Unfortunately, the msvcvr70 dll is REQUIRED TO RUN THE EXE but not needed to build it.
This m$ file is free to distribute with your DX application.
Get it almost anywhere online where you'd normally go for missing DLL files.

Congratulations on building your first DX executable !! Exciting days ahead :)

I hope you understand now why I was not inclined to post fixes and files.
It's much better to fix these issues ONCE yourself as I said before.
You have gained valuable insight form the experience.

If you want to mix and match the functions (FKT/DX math), you should leave the PROTOS in Scronty's includes alone, and change the names of the FKT macros.
The procedure (PROTO) names are correct, whereas the FKT macros have been named as duplicates and should really not have been, because it causes such confusion later. I recommend simply putting an UNDERSCORE in front of the MACRO names, and I further recommend this naming convention for macros in general.
You can see I call my own macros things like _saferelease, and the leading underscore tells me its a macro. That way I can't get mixed up, and the name still makes sense to me :)

Apparently the LIB path issue can be fixed by adding an "environmental variable string" to your startup scripts which contains the path to the masm LIB folder.
I've never bothered myself, and think Hutch should add that to the MASM installer.
Posted on 2003-10-11 04:54:04 by Homer
Looking at that little Render function, we can see it has two input parameters - one is a window handle (which we aren't using yet), the other is a color code.
The color code is just a DWORD, in ARGB format.
For the uninitiated, thats Alpha Red Green Blue, as four byte values in a DWORD.
00 is fully off, and FF (or 255) is fully on.
Look for the call to Render in the Windows MessagePump and play with the FillColor :)

Anyone have insurmountable problems at this point?
Posted on 2003-10-11 08:21:12 by Homer
Now, we have a rather unsophisticated D3D skeleton in place, let's do something with it, but before we do, just some notes about what we have made so far.

This tutorial application is starting up in 32bit color, 800 x 600 display mode.
This is pretty much guaranteed to work on anything out there, but later we'll improve the initalization function by adding a "display modes enumerator" which is code that queries the hardware to see what it has available.

At this point in time I'm ready to talk about State Machines.
The gamecode will be driven by soft switches called "flags".
We'll invent any flags we want to have, and also invent the possible values for each flag, and what they mean, and have the flag values determine the behaviour of our program. It's not as hard as it sounds.

Try adding the following lines to ProjectData.inc...

GS_IDLE equ 1

GameState dd GS_SPLASH

We just defined our first (and most important) flag, the GameState flag is a DWORD whose value will control the game state (ie paused, running, etc.)
We have defined (so far) two possible values as Equates, and we have initialized the GameState flag with the value GS_SPLASH.
We invented the flag and its possible values, now for their meanings.
We'll decide that GS_SPLASH means "Display the SPLASHSCREEN"
(A splashscreen is a picture that appears before most anything else, and usually displays a corporate logo or relative legal disclaimer.)
In other words, we're telling our app to start up ready to display a picture.

Of course, we'll need to load a texture if we want a picture.
Since we are keeping things simple at the moment we won't be using Alpha Blending just yet, so we'll just use the following code to load the texture...
(add this code to your D3D Initialisation code so that the texture is loaded during d3d initialization)

pSplashTexture dd NULL
invoke D3DXCreateTextureFromFile, lpd3dDevice, CTXT("c:\full\path\of\texture.bmp"), addr pSplashTexture

and now add the following line to your d3dcleanup procedure, right at the start of it...

_saferelease pSplashTexture

Now we are loading the texture, and we are dumping it at shutdown.
We are going to draw the splashscreen using D3D , on a Textured Quad.
It might not make much sense to be using the 3D hardware to draw 2D stuff, but when you realise what's involved, it will make perfect sense.

A Textured Quad is just two textured triangles, and the 3D hardware excels at one thing above all others, and that's spitting out textured triangles.

Next I'll talk a bit more about geometry and Flexible Vertex Formats, and give you code to create and destroy (and Render) a Textured Quad...
Posted on 2003-10-12 08:53:26 by Homer

i'm back. i started to occupie myself with this project again, and recompiled the application. first thing i noticed was:

Assembling: c:\masm32\nop\dxproject1\dxproject\project.asm
Microsoft (R) Incremental Linker Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

LINK : warning LNK4089: all references to "GDI32.dll" discarded by /OPT:REF

i know, that it's just a warning, but where does it come from? i don't like warnings :tongue:

then i tried to start the created exe file again.. guess what, this msvcr70.dll was no longer needed, and i'm sure that i didn't download it last time. don't ask me why.. i just don't understand that.

i will now go on with the tutorial..


edit: there's something else: i replaced the fkt file i already edited with the one you uploaded again, to change the macro names as you proposed, just prefixing it with an underscore.
ok, as i said, i replaced it and removed the ";" in the include file with the PROTOS... guess what.. no error :confused:
did you replace the fkt file with an edited one?
Posted on 2003-10-14 13:22:52 by NOP-erator
ok, everything seems to work fine, i'm really excited! :alright:
i plan to port my game from dx7 to dx8, but first i gotta check if it makes sense. i'm talking about advantages, like special effects (from menu to game screen for example). i'll think about that when i'm perfectly able to use dx8.

ok, some questions: does it make sense to use CTXT even if a text appears more than once? i mean, is the string "cleared" or "deleted" after the call?
is, or how is it possible to load gifs or jpegs as a texture?

thank you,
Posted on 2003-10-14 13:48:33 by NOP-erator
CTXT generates named string variables in the data segment.
As such, subsequent iterations of the same string are treated by the compiler as References to the Same. IE, only one instance of a unique string is generated in the DATA segment, and all common stringpointers point to the same string.
It's lazy coding on my part, and you are right to point it out, but in this case it does not matter.

As for loading other formats, you'll find that the DX functions can load a suprising number of them, including PNG, TIF and GIF, TGA and more.
Anything it can't load can be loaded with your own code, and then you can create a blank DX texture and copy the image data into it.

Accessing the image data in a new or existing DX texture is easy -
We'll do this a little later when we throw together some Terrain HeightMapping code - we'll be using a BMP to store our heightmap, which means we can paint the 3d terrain geometry in any 2d art program :)
Posted on 2003-10-15 02:50:53 by Homer

CTXT generates named string variables in the data segment.
As such, subsequent iterations of the same string are treated by the compiler as References to the Same. IE, only one instance of a unique string is generated in the DATA segment, and all common stringpointers point to the same string.

It's lazy coding on my part, and you are right to point it out, but in this case it does not matter.

lazy coding? i like lazy coding :tongue: ... this macro seems to have only advantages, so why don't use it ? :)

what about the warning? do you have any idea where that comes from?

Posted on 2003-10-15 03:51:30 by NOP-erator
The warning concerning GDI is an easy one to explain.
We are including the GDI inc and lib, but we don't actually call any of its functions !! It's totally unnecessary to have it there, and the Linker is telling us that it found no dependant calls in our source and won't be including GDI in our executable's Import Table.
Posted on 2003-10-16 01:47:18 by Homer
We are including the GDI inc and lib, but we don't actually call any of its functions !! It's totally unnecessary to have it there, and the Linker is telling us that it found no dependant calls in our source and won't be including GDI in our executable's Import Table.

Except, if you don't include GDI32.INC and GDI32.LIB, the Linker will refuse to link the file, on the grounds that it can't find the DeleteObject function. So it actually is required.
Posted on 2003-10-17 06:57:31 by Tatterdemalian
That's right, because internally, DirectX makes calls to those functions, but it doesn't load those libs itself, it ASSUMES that the libs are imported by the executable who instanced it.
Yes we need to include GDI, even though we call no GDI funcs implicitly.
It's strange I know, but thats the way it is.
Thanks for pointing that out.
Posted on 2003-10-17 09:12:40 by Homer
Hi EvilHomer2k,

Can we start the tut with the basic description about game programming. Assuming that we start it from A (only know about litttle ASM command but don't know how to proceed with the basic).

At least, beginner like me can learn ASM step by step. I know basic ASM, but I don't know how to build small project to improve my knowledge.

Thanks for your consideration.
Posted on 2003-11-06 03:06:05 by ledang
Like most programs, games contain something called a "Main Loop".
This is the guts of the program and from here all the other code will be called.
Here is some "pseudo code" that describes what I mean:

-Check Keyboard
-Check Mouse
-Update Player
-Update Enemies
-Draw Screen
-jmp MainLoop

Also, most games are "stateful", that means they use "flags and counters" which determine the logical flow of the program.
Another example in pseudocode:

IF Player.Lives == 0
Play the PlayerDeath Animation
Play the PlayerAction Animation
Posted on 2003-11-06 06:33:00 by Homer
It seems I'm already skipping ahead too far for some readers.
Let's keep this nice and simple for now.

Basically we are going to talk about writing 3D games using Direct3D. The first thing we need to know is that we can't even start Direct3D without making a boring application window first.
If you can't make a win32 skeleton application yet, either use the prostart utility provided in the masm package, learn how to do it, or stop reading - this is not for you.

Once we have our Window created, we will have stored a handle to it in a variable - that's important, because we NEED a valid window handle to initialize D3D !! We already need a window created which will act as a Host for D3D, even if we want to use FullScreen mode !! You simply cannot start D3D without a valid window handle.

Ok now, can we all get to the stage of creating a Window, then adding the code I've already provided to make D3D render a color to the window? :)
Posted on 2003-11-12 23:18:13 by Homer
Ive been at scrontys site but find no download link to directx 8 include file

I am currently generating meshes for an object, using integers
are there any easy way to take out the sign bit, shift the rest to fit perfectly into the 23 bits and "or" together with the right exponent to get the floats needed for directx?
Posted on 2003-11-15 08:27:26 by daydreamer
Yeps, Scronty's examples for Scronty's older tutorials and examples, and as far as floats for dx are concerned, you might consider just defining some floats in your data segment, if they are static values, or using macros and/or helper procs which use fpu code if they are dynamic... as far a "quickie" integer - to - float conversion, see the RandomGen code I posted with my SKinMesh stuff ;)
Posted on 2003-11-16 00:12:07 by Homer
I am still stuck with it wont link uuid.lib, even if the file is there
tried to download v7 and copy it from there, but still the same problem
Posted on 2003-11-16 16:49:13 by daydreamer
it compiles now
Posted on 2003-11-16 18:43:58 by daydreamer