Help please,I feel sick with Directx
Author
After learning DirectX with a book("Role playing game programming" by Jim Adam) for a week.I found it hard to understand because it has many components and functions .
Could u tell me ? How did u do when u learning DX for your first time? What skill & experience needs? Ah,one thing that get me in the trouble that i can't remember any functions,member of function,etc.Do u remember some of them?
At this time,I have stuck with Direct3D graphic.i feel sick to see a hundred lines of codes but it draw only a 'Box' .
This books povide some engine code for comfortable use.Is it a bad idea if i use it but don't understand about code in that engine,only understand what parameters it needs and what that engine do?
Then I will go to hospital now.
Have you experimented with any other API before?
Thing is, 100 lines of code will draw a box, 101 lines will draw two boxes, 120 and maybe you've got player movement code in there - A lot of DX is getting it up and running - once you've done that, it's pretty plain sailing! On the oher hand, a handful of lines will get SDL up and running. Maybe invest some time in creating some wrapper functions for DX that will let you call simplified functions that do the hard work for you, breaking down the API into more manageable chunks?
Thing is, 100 lines of code will draw a box, 101 lines will draw two boxes, 120 and maybe you've got player movement code in there - A lot of DX is getting it up and running - once you've done that, it's pretty plain sailing! On the oher hand, a handful of lines will get SDL up and running. Maybe invest some time in creating some wrapper functions for DX that will let you call simplified functions that do the hard work for you, breaking down the API into more manageable chunks?
I hated it. It took hundreds, maybe thousands of lines of code to properly do all of the enumeration/config settings. All that for a blank window. 2D support is spotty at best,and frankly, I think there is next to no reason to prefer Direct3D over opengl now. It's just easier to learn/use. MUCH easier.
Author
during a week,i'm learning in DX3D about how to initializing,creating,drawing.i can do texture mapping,draw polygon with vertices, a box with lighting,and some tutorial by myself(but still take a look some codes in the book).
Now next chapter it offer DX3D engine codes,provide some function to use texture mapping,lighting,drawing,etc. with many class .it looks complex so i decide to use its by won't understand the code inside but only understand what that function do for me.
How do u think about this idea?
Now next chapter it offer DX3D engine codes,provide some function to use texture mapping,lighting,drawing,etc. with many class .it looks complex so i decide to use its by won't understand the code inside but only understand what that function do for me.
How do u think about this idea?
Quote:I found it hard to understand because it has many components and functions
Like most API's, D3D has a LOT to it. Just remember that as a beginner you can probably ignore a lot of it, and in the long run (projects depending) you may never even need to use a lot of it. Don't worry about it!
Quote:How did u do when u learning DX for your first time?
I learnt almost exclusively from example code, but thats just my preference. The SDK combined with websites like this one offer you a lot of "ready to go" source code. Download it and make a copy of it... read through it, change things, break things, fix them. You can learn a lot about things just by changing parameters and seeing what happens... and if you go and break it you might learn *why* you broke it, but you also have the original source code to compare it with to get an idea of what you need to change to fix it again. Interactive learning if you like.
Quote:Ah,one thing that get me in the trouble that i can't remember any functions,member of function,etc.Do u remember some of them?
Some people do remember all of them - I remember a lot of D3D calls/constants/parameters simply because I've been working with it for years. I never sat down with a list of the API and memorised it, and I highly doubt you'll get much from trying that.
The SDK helpfiles are there for a reason - keep the help file around, don't get something? type it into the index and pop-up the specification for that function. Most of the time you'll find what you need to know.
Myself, I can't program Win32 programs properly without a copy of the MSDN help files and Petzold's "Progamming Windows" book [smile].
Quote:i feel sick to see a hundred lines of codes but it draw only a 'Box' .
As benryves brilliantly pointed out - a lot of that code is the same from project-to-project, a lot of it you need only write once. Try benryves suggestion and block the code together in re-usable chunks (even if you just copy-n-paste those chunks). Most experienced developers round here probably do this - at least have a framework that they start with each time they want to start something new...
Quote:Is it a bad idea if i use it but don't understand about code in that engine,only understand what parameters it needs and what that engine do?
In some respects it is a bad idea to use something if you don't understand it, but definitely for a beginner to an API you shouldn't worry about it. If you use it enough - or once you've taken your first few steps and started to get your head around some concepts you can go back and look over the things that you didn't understand the first time!
Quote:Then I will go to hospital now.
Hope you feel better soon [smile]. If you give some thought to what I've said and the other replies say, and maybe take a step back and try it from another angle you'll get somewhere. Unless you're a really really really good programmer I doubt anyone can learn D3D from scratch in a couple of days! - don't sweat if it takes you some time, the results will be worth the effort.
Quote:I think there is next to no reason to prefer Direct3D over opengl now. It's just easier to learn/use. MUCH easier.
I'm not stupid enough to get involved in a flamebait over API's, but I do think you're a bit out on knocking Direct3D like you do.
Have you looked at the code for the last few releases? (October/December 2004)
For learning and for knocking up simple demo's/PoC's the structure/initialisation can be done by changing all of 4 or 5 lines of code. FACT. I'd say it rivals SDL's simplicity in that case.
How? by using the built in framework project (sample browser->empty project->install). I'm at work now so don't have the SDK to hand, but it has the basic functions set up for you - including single function initialisation of a basic D3D window. All other stuff - catching lost/reset devices and frame updating can be registered with a simple callback (similar to OpenGL I understand??).
Sure, you might not want to do that if you're writing a full blown engine, but for learning purposes it allows you got get to the meat quick and easy. You can go back and learn all of the more complex/tedious "background" work later on when you write your engine. In my view, you shouldn't start D3D by writing a full-blown engine anyway [smile]
Don't take it personally, I know I'm a bit of a D3D fanboy at times - but a lot of beginners will read what you've said...[smile]
hth
Jack
Well, there is your problem. A week is not long enough to learn DirectX.
Although, if you are having a tough time, I recommend OpenGL.
Although, if you are having a tough time, I recommend OpenGL.
Quote:Original post by Si0n
Well, there is your problem. A week is not long enough to learn DirectX.
Although, if you are having a tough time, I recommend OpenGL.
Yeah, I'd probably go along with this, OpenGL is MUCH easier to learn. It just seems harder to get the more complex stuff going, such as multitexturing, but the basics are as simple as you could possibly get; no vertex buffers, no FVFs, just plot 3 points and you have yourself a polygon.
However, later down the track after you start to get the hang of OpenGL, give D3D another look. By that time you'll probably have a firm idea of why the initialisation is so verbose, and you'll come to respect D3D for what it offers, such as image-file loading support and native multitexturing.
I used to be an 'OpenGL is teh bestest!!1 DX is chumpz' kid, but after playing around with D3D with a little more knowledge under my belt I came to prefer it.
Note: I'm NOT saying people who use OpenGL are bratty kids. I'm more pointing out that I was a bratty kid and I thought D3D was crap for the pure reason that I didn't understand it.
Quote:Original post by PlayfulPuppy
Yeah, I'd probably go along with this, OpenGL is MUCH easier to learn. It just seems harder to get the more complex stuff going, such as multitexturing, but the basics are as simple as you could possibly get; no vertex buffers, no FVFs, just plot 3 points and you have yourself a polygon.
You can use vertex buffers and multitexturing in OpenGL, using extensions (i dont think there are extensions in d3d).
If you have a problem in image loading, you can use windows's IPicture (nehe has a tutorial on it) or download an image library or create your own (with tutorials of course).
I'm just saying that you can program games with OpenGL as a beginner, you don't need to worry about it.
Just started with DirectX too, at least, with C++. Used to do some basic shit before with VB but never really went into it since I didn't really care back then. But well yeh, I don't really think it's all that much code actually to start up the first box. Although in my honest opinion boxes are just plain shit and worthless, lol, o jolly, look at me, I can create a box. Therefor I also don't retype any of that code from books or tuts, just copy/pase it or get it from the cd-rom, read it to see how it works and if there's anything surprisingly and just do a test run to see if it creates exactly as I thought by reading the code.
I find it much more interesting to read a new thing which is actually somewhat usefull, like how to make use of image files and render them to the screen and then just make some shit on myself.
Also out of the first tuts I think most lines of actual code are just the crappy lines of code used to create the application window. That reaches about 60 lines or so in most tuts and a shit load of comments goes ontop of it still to make it look even bigger.
But in the end, don't forget, 100 lines of code is nothing :P. If you just take a glance at sources of open-source engines, games or stuff like the leaked HL2 version, you will sometimes see singular files which reach upto about 10k lines of code or even more. Then you'll realise how few a 100 lines of code actually is :P.
I find it much more interesting to read a new thing which is actually somewhat usefull, like how to make use of image files and render them to the screen and then just make some shit on myself.
Also out of the first tuts I think most lines of actual code are just the crappy lines of code used to create the application window. That reaches about 60 lines or so in most tuts and a shit load of comments goes ontop of it still to make it look even bigger.
But in the end, don't forget, 100 lines of code is nothing :P. If you just take a glance at sources of open-source engines, games or stuff like the leaked HL2 version, you will sometimes see singular files which reach upto about 10k lines of code or even more. Then you'll realise how few a 100 lines of code actually is :P.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
