Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
40 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to For Beginners

Am I just retarded or what?

Started by
26 comments, last by OneThreeThreeSeven 13 years, 4 months ago
Quote:Original post by Fl4sh
But it took me all day just to setup a 800x600 window w/ a triangle in it.


There's something called the Black Triangle effect or something. Can't google it because I'm overwhelmed by UFO stuff, but it's basically about a bunch of programmers going nuts and leaping around the room because they have a black triangle on the screen.

Non-technical producer type walks in and is confused by why a black triangle would cause such excitement.

Point is, it's a significant milestone - going from having nothing on the screen to having a triangle on the screen is a fundamental step forward.

Quote:Original post by Fl4sh
woot I made a square. :D


See? Now put a texture on it. Then make a moving camera.

Only way to stay sane with this stuff is to take it all one tiny step at a time.
journal | website | twitter | youtube
Advertisement
I had an API class and learned a good deal from:

http://www.amazon.com/Beginning-Game-Programming-Jonathan-Harbour/dp/1435454278/ref=sr_1_5?s=books&ie=UTF8&qid=1292109528&sr=1-5

It covers the basic Sprite, Surface, DXFont objects, and gives some insight into getting them into a running program. It's not the best book in the world, there is some erroneous code, but the written portion describes most processes well.
Quote:Original post by Aardvajk
Quote:Original post by Fl4sh
But it took me all day just to setup a 800x600 window w/ a triangle in it.

There's something called the Black Triangle effect or something. Can't google it because I'm overwhelmed by UFO stuff, but it's basically about a bunch of programmers going nuts and leaping around the room because they have a black triangle on the screen.

Here it is: The Black Triangle

(And excellent example in this case)
Quote:Original post by Servant of the Lord
Quote:Original post by Aardvajk
Quote:Original post by Fl4sh
But it took me all day just to setup a 800x600 window w/ a triangle in it.

There's something called the Black Triangle effect or something. Can't google it because I'm overwhelmed by UFO stuff, but it's basically about a bunch of programmers going nuts and leaping around the room because they have a black triangle on the screen.

Here it is: The Black Triangle

(And excellent example in this case)


Yay. Well done. All I could find was people claiming to have been abducted by aliens.

(Not disputing it BTW)
journal | website | twitter | youtube
Quote:Original post by Fl4sh

But it took me all day just to setup a 800x600 window w/ a triangle in it.


Thats normal. It doesn't matter because its something you do once. Once you have it you can port that bit over to other projects. Then you start to think "Hmmm I could create a function or two called Start (or something) that does all that."

It may seem hard work, but its just the progression of programming. But once that first stone is layed.....you can take it with you for next time.
Exactly.
Quote:How did you guys learn directX?
The very same way you do now: Fiddling around with example code, digging docs, scratching head at monochromatic output, crashes ... frustration. One day for the dreaded triangle under DX 10 sounds quite good to me ;). Approx. a year ago I switched from XNA to managed DirectX and hassled with the fixed function pipeline without knowing about the DX Debug runtimes. That was painful, believe me.

You can lower frustration considerably doing the following:
  • Baby steps. This was already stated. Don't change several things at once. So you know where to look if something fails.

  • Get all the feedback from the system/API you can get (or need): Error messages (e.g. DirextX debug runtimes), device capabilities, performance characteristics etc. Error codes are a must to reduce frustration ;) But they're only a start. A catched "invalid call" error is only good enough to tell you where you did something wrong. The DX debug runtimes tell you what. Hopefully.

  • Get the most out of your development environment: easy code navigation, debugging(!), context help. Use additional tools where appropriate (PIX, shader authoring tools)

  • Write diagnostic functionality like log-files or reports. Setup automated tests, debug-views, make output-diffs.

  • If you don't see output and you think you should disable more and more features: alpha blend, depth/stencil/alpha-test, culling, clipping, fog. Go wireframe or even points. For shaders: Output a constant (known) color from your pixel shader.

  • Refactor. The vast possibilities DX offers are also the greatest pitfall. A tiny little flag wrong and your output vanishes. Turn things you have learned into code that does it automatically, e.g. a proper device setup or correct DrawPrimitive call.

  • Don't forget you got a fast computer to your aid: I once did a flag combination brute force attack of a function because I gave up trying to understand the docs. The non-failing combinations were more conclusive.

  • Bad docs/bad books/bad code. No clues from the internet. Can happen. Learn to deal with it. And trust no-one. If something's off write code to find out yourself.

  • If the frustration gets unbearable consider using a simpler API, e.g. an engine which eases (at least) the administration. Consider using an easier language.Consider using OpenGL, maybe you are more comfortable with it (IMO just a matter of taste, the possibilities are likely the same)


    • Since you already got your triangle(s): Forget the last point and keep going.

    Quote:If so, what's that language called so I can get some more info on it?

    The language you are using now is HLSL and you are targeting shader model 4. Most tips from above apply.
    I find error checking for COM code to be pretty unsightly and I can see why it's hard for a beginner to make heads or tales of what they're looking at when they see the code in some of these books/tutorials. For a *real* application error checking is obviously a necessity, but I think it does obscure the important parts of sample code. When I'm just getting familiar with a set of new COM APIs I like to just stick a "HRESULT hr =" in front of every call and step through it in the debugger and manually verify the return codes. Then once I have a grasp on everything and I'm ready to do something real I add all the "if (FAILED(...))" blocks.
    Get Frank Luna's book.

    This topic is closed to new replies.

    Advertisement

    Popular Topics

    Aybe One
    How do you manage yourself and your time as years pass on? GDNet Lounge
    Jikoob
    Too many managers? General and Gameplay Programming
    aigan
    The promise of freedom in story games Game Design and Theory
    robertrobert
    Facebook Ads for sales on steam, does it work? Games Business and Law
    gjl
    New Generated Constructor & JIT Issue AngelCode
    Advertisement

    Recommended Tutorials

    GameDev.net
    Interview with Eric Christensen, Senior Programmer Interviews
    Myopic Rhino
    Interview with Jamie Woodhouse Interviews
    GameDev.net
    Game operation costs: the unpredictable beast? Networking and Multiplayer
    Myopic Rhino
    The Physics of Racing, Part 7: The Traction Budget Math and Physics
    Myopic Rhino
    Avoiding Redraw in Graphics Graphics and GPU Programming

    Reticulating splines

    About GameDev.net
    Community Guidelines
    Terms of Service
    Privacy Policy
    Contact Us
    Copyright (c) 1999-2024 GameDev.net, LLC
    Back to Top