Re: Can't create Device
From: Fredo (fredo68_at_hotmail.com)
Date: 11/01/04
- Next message: Fredo: "Re: Can't create Device"
- Previous message: Phil Taylor: "Re: Can't create Device"
- In reply to: Phil Taylor: "Re: Can't create Device"
- Next in thread: Fredo: "Re: Can't create Device"
- Reply: Fredo: "Re: Can't create Device"
- Reply: Phil Taylor: "Re: Can't create Device"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 1 Nov 2004 17:26:13 -0600
Phil,
I apologize. As I said, I didn't mean to be rude, but as I said, I know
to read the manual. I know to read the samples. I have already done that.
As you probably know, most (probably all) of the C# samples use the
D3DApp.cs for the initialization. D3DApp is roughly 60K of code, and I could
spend hours tracing through it to maybe figure out why it's working while
the code from the SAMS book isn't, but I may never find it because of all
the code that gets called prior to Manager.Adapters being queried, how will
I know what single line of code makes the difference between it working and
not working? I mean, the documentation doesn't spell it out, and so far,
looking in the code, nothing sticks out.
To carry on your metaphor of teaching a man to fish, I would argue that
using usenet is fishing. Getting a fish would be having someone write the
code for me.
You giving me the answer vs. me wasting hours tracing through sample
code does not make me particularly wiser, particularly if I never happen
upon the solution. Then I'm back where I started with a lot of time lost.
Sure, I might pick up a few additional nuggets from having traced through
it,but I may come upon those other nuggets without spending hours tracing
through the sample code.
Again, I don't mean to be rude, and I apologize if that's the way I come
off. It's not my intention. I have spent years answering questions for
people on Usenet. If someone asks a very general question, like "How do I
write a while loop", then I tell them to go read a book on programming. If
they ask a very specific question such as, "Why does this function not work
as I expect?", if I know the answer, I usually just give it to them. Again,
I would argue that their specific question is "fishing", using your
metaphor, not giving them a fish.
Pete
"Phil Taylor" <philipt@private-citizen-sorta.com> wrote in message
news:eVE4caGwEHA.1392@tk2msftngp13.phx.gbl...
> Fredo, there is an old saying
>
> "Give a man a fish; you have fed him for today. Teach a man to fish; and
> you have fed him for a lifetime"-Author unknown
>
> I am trying to teach you how to fish here.
>
> Read the sample framework and sample code, I cant be clearer than that in
> giving you a pointer. One that will help you with your next M-DX issue,
and
> the next, and the next...
>
> Of course I can go thru that code, and point out to you the right bits.
But
> what have you learned then? Nothing.
>
> As far as Usenet, these groups exist because I spent time and energy while
> at MS to update the DX Usenet presence back in 2000-2001 and then hung out
> here until critical mass occured. So any criticism of the help I give here
> is completely unfounded.
>
> "Fredo" <fredo68@hotmail.com> wrote in message
> news:MqadnVouPvA6IxvcRVn-3Q@giganews.com...
> > I'm not disagreeing with your assessment regarding the debug vs. the
> > retail
> > build. I take it from your response however, that you don't know the
> > answer
> > to my last question which was: is there anything I need to do prior to
> > calling Manager.Adapters?
> >
> > Since you didn't answer it, I assume you don't know the answer.
> >
> > I'm not working entirely in the dark here. I've got a couple of books on
> > managed Direct3D and several samples (though I hadn't really looked at
> > that
> > particular part before today), but being a new technology (even if it is
> > just a wrapper of an older technology), the quality of the books and
> > documentation tend to be on the weak side.
> >
> > For example, Chapter 2 of Sams Publishing "Managed DirectX Kick Start:
> > Graphics and Game Programming", provides the following example (and
years
> > and years of using SAMS books should remind me of why it's a bad place
to
> > look, but it's what I've got):
> >
> > /// <summary>
> > /// We will fill our tree view here
> > /// </summary>
> > public void LoadGraphics()
> > {
> > foreach(AdapterInformation ai in Manager.Adapters)
> > {...
> > }
> > }
> > static void main(){ using (Form1 frm = new Form1())
> > {
> > frm.LoadGraphics();
> > Application.Run(frm);
> > }}
> > Beyond creating a forms project, adding a reference to the Direct3D
> > assembly, and adding some controls to the form, it gives absolutely no
> > hint
> > that ANYTHING has to be done prior to calling Manager.Adapters.
> >
> > And as you might suspect, and now that I've tested it, I know, this code
> > does no even work on my machine with the debug build. Works fine with
the
> > release build, of course, but not in debug build.
> >
> > I don't mean to be rude, but if the best advice you can offer me is that
I
> > should look at the samples, then you aren't really helping me out a
whole
> > lot.
> >
> > Over the past 17 years that I've been using usenet, it's usually to get
> > answers (and a lot of times to provide them, though not on this subject)
> > from people that know how to do stuff, not to be told to RTFM. I've been
> > doing this long enough that I know to RTFM first. That's why I'm here.
> >
> > Pete
> >
> >
>
>
- Next message: Fredo: "Re: Can't create Device"
- Previous message: Phil Taylor: "Re: Can't create Device"
- In reply to: Phil Taylor: "Re: Can't create Device"
- Next in thread: Fredo: "Re: Can't create Device"
- Reply: Fredo: "Re: Can't create Device"
- Reply: Phil Taylor: "Re: Can't create Device"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
