Re: Why do we use different files for C ?

På Fri, 24 Aug 2007 02:49:55 +0100, skrev JGCASEY <jgkjcasey@xxxxxxxxxxxx>:

On Aug 24, 12:09 pm, //\\\\o//\\\\annabee <w...@xxxxx> wrote:
På Fri, 24 Aug 2007 01:40:15 +0100, skrev JGCASEY <jgkjca...@xxxxxxxxxxxx>:
..
There are allready working examples and apps that use the
webcam in the SDK as I recall. I mean, if you dont want to
write it, why not grab some of the gazillion apps allready
making good use of a webcam?

But it isn't someone elses app I am looking for. It is the
means to use a webcam in my own apps.

Read the DirectMedia SDK for a place to start.

From what I can make
out most of you guys don't actually write apps.
There are
people out there that do write apps and that included the
use of assembly code but they don't frequent this newsgroup
and aren't interested in sharing their knowledge.

cant blame them for not visiting this newsgroups.

> As for format I don't know much about dlls etc as I used
> to use BASIC and assembler. Thus the format I am used to
> is simply a statement in a language.

> Can assembler ever be as much fun as it was in the old dos
> days?

Just load dos, and have the fun of a whole lifetime... :)

The apps I am writing use the high color resolution of a
modern graphics card which only have M$ support.

Then you are correct. That isnt much fun.
But, still, possible.
Due to the __extremly__ low quality of the SDK documentation, anything more then
a me too demo app is a lot of work, because you have to guess at all the parts
that make the thing interessting. You need to test and experiment, guess, and test again and etc....

basically you need to first understand COM in the relation to assembly.
I learned this by reading the tutorials for RosAsm at Eric homepage:
< http://www.quanta-it.com/easbell/ >

accessing COM objects are "easy" once you have access to an Icall macro:

[iCall | mov edx #2 | mov edx D$edx | push #L>3 | push #2|call D$edx+#1]

all of DirectXMedia is accessing COM objects.
From our point of view, com objects are pointers to calltables.

You instansiate such a COM object, either by calling a spesific API created for the purpose, like for instance "Direct3DCreate9" (exported by d3d9.dll) or by calling
CoCreateInstance. For calling that discusting abomination, you need the unique GUID
of the COM object you are createing (instantiating)

example:
CoCreateInstance CLSID_FilterGraph &NULL &CLSCTX_INPROC_SERVER IID_IGraphBuilder COM_Ptr

here, CLSID_FiltherGraph is the GUID and "COM_ptr" receives the pointer to the COM object

I have no idea what the other *** means, and dont care. And have not seen it to be important yet.

The CLSID for it looks like this:

[CLSID_FilterGraph:
@cData1: D$ 0_E436_EBB3h ;a dword
@cData2: W$ 0_524Fh ;a word
@cData3: W$ 0_11CEh] ;a word
[@cData4: B$ 09Fh 053h 0h 020h 0AFh 0Bh 0A7h 070h] ;8 bytes

All of this is a real pain in the but. But, once you got the COM object created, here returned in a generic pointer i called COM_Ptr - you are ready to invoke the functions of the comobject, via the icall macro.

The functions are listed in the SDK docs. You are intessted in the FUNCTION INDEX of your COM object

1. each function index (called interface in COM terms) have an offset of 4, from the previous one.
2. ALL com objects, allready contain at least one another comobject. call iUnknown.

iunknown looks like this

[IUNKNOWN_QUERYINTERFACE 0
IUNKNOWN_ADDREF 04
IUNKNOWN_RELEASE 08]

if the COM object you are trying to access, derives (OOP term) from iunknown (some do, some do not) then all of its added interfaces (functions) starts from offset 0C (12)

you need to find their names and create a list like this:

[DirectMedia8.Graph_AddFilter 0_C
DirectMedia8.Graph_RemoveFilter 0_10
DirectMedia8.Graph_EnumFilters 0_14
DirectMedia8.Graph_FindFilterByName 0_18
DirectMedia8.Graph_ConnectDirect 0_1c
DirectMedia8.Graph_Reconnect 0_20
DirectMedia8.Graph_Disconnect 0_24
DirectMedia8.Graph_SetDefaultSyncSource 0_28
DirectMedia8.Graph_Connect 0_2c
DirectMedia8.Graph_Render 0_30
DirectMedia8.Graph_RenderFile 0_34
DirectMedia8.Graph_AddSourceFilter 0_38
DirectMedia8.Graph_SetLogFile 0_3c
DirectMedia8.Graph_Abort 0_40
DirectMedia8.Graph_ShouldOperationContinue 0_44]


Now you have enough info, for knowing what to pass to the icall macro.
You read the SDK info for the chosen function (interface) to call.
Lets take an example:

iCall DirectMedia8.Graph_RenderFile D$DirectMedia8.FilterGraph FileName 0

DirectMedia8.FilterGraph is here just another name for the previously aquired (once) COM_ptr above.

( D$COM_ptr = D$DirectMedia8.FilterGraph )

thus, you pass the index of the function to call as the first parameter,
then you pass the COM object of the function to call,
then you pass as many parameters as required, according info found in the SDK documentation.

Now, since none of this was any help for you to directly access your webcam, you need to read the DirectShow (DirectMedia) SDK, in order to guess at what COM objects you need to know, and then you have to find their GUIDS, and translate each of their interfaces lists, or just the once you need, and then you need to read about how to use them. You need to learn what the parameters of their interfaces means, and you need to go through hell and back in order to have it do what it says on the cover.

This thing is an abomination. It is to a large extent microsofts way of shitting on your nose, and to make a mockery out of people ten times more intelligent than the complete morons that came up with this useless stupid _criminal_ thing. Because of crime and co, and CS people like Randall Hyde and his cronies, you need to swollow all your pride and more to get this thing rolling. It will eat at your brain, you will be fantasizing of circumsizing M$ emplyers. You will feel like you swallow dicks on dicks.

You will finally hope for some theorist to blow them out of their missary.

But by then, you will know, that this is just the start. Hell is straight ahead.

You will understand why ASM is the only resonable way. And you will understand that HLLs will rot your brain.

> I suspect not. And I guess anyone who is curious as
> to how to write assembler routines can always use the
> inline assembler of a HLL.

Sure. But this will be doing the right thing the wrong way, and at a lot more pain.
A tool crafted for using asm the right way. Like Rosasm, this will be a 1000 times easier way. However, in this insane world we still have to fight the APIs, and SDKs and they are theese days going to take 90% of the time, because they are basically insane and stupid at every point of view.

Just a warning. Before you could ever wade through the info on DirectX7, they will drop DirectX10 in your face, and all those versions will differ completly, destroying all of your work, in an insane effort to force you into paying for upgrading you HLL tool, that they have created "for you" in order to ....in the _exact_ same way as this complete LIE above, "make it easier" for you, without telling you that you STILL have to learn all this COM ***, in the same slow time, while they get ready to BOMB you with the next version before you could be half done, and you need to upgrade, and the info you __really__ need is not there anyway, and ect ect ect ect until you die.

Ok. Fact is, that once you get some of this *** rolling, it works pretty well. DirectShow really has amazing low latencies. I mean, once you have eaten the setuptime. I mean, if you do not have access to directly program the hardware, and do not have the documentation, this is the only way I know of, and after all that work I guess it will feel like its worth it.




> --
> jc-


.