# Auron

Member

442

328 Neutral

• Rank
Member

2. ## what type of games?

If it's implemented as layers, then the larger stars are the ones in the layer intended to be closest to the viewer. If it's implemented such that each star has an x, y, and z point, then the size of the star would be a function of its distance (or its z value). -Auron
3. ## No Debugging Information

Maybe you really don't have debug information in your executable? VC++8 doesn't turn debug symbols on by default. Go to your Project Settings, and under C++ (I forget which subheading), there's an option called "Debug Information Format," change that to anything but disabled. Then under Linker, go to the Debugging subheader and make sure "Generate Debug Info" is set to enabled. That should take care of the popups and make your breakpoints work. -Auron
4. ## Scaling about an arbitrary axis

Well, you could use soconne's method, but in the event that one of the axial directions is zero, you just internally use 1/scalar. That said, could you explain what you mean by scaling about an arbitrary axis? What output are you expecting in certain cases? (eg: scale(Vector3(0,1,0), 5) or scale(Vector3(1,3,0.28), 0.1)) -Auron
5. ## Want a vector of known length newbie Q

If it needs to be a specific length in a given direction, just normalize the direction vector and multiply the direction vector by the desired length. No need to go through all that trig. Edit1: Though, if yor direction is in the form of just an angle, then what you do there would equate to finding a normalized direction vector and multiplying it by the desired length Edit2: Quote: Therefore the ratio (0/A) squared is L Inverse Tan(sqrt(L)) = Theta. That doesn't work. L^2 = O^2 + A^2, and O/A = tan(theta), so theta = arctan(O/A). Nowhere can you make a direct ratio relationship between O and A. To see what I mean, draw a circle of any size. According to what you're saying, you can draw a line from the origin to the edge of the circle, then use that line as the hypotenuse of a right triangle. What you're saying there is that the ratio of lengths of the other two sides is constant with respect to the length of the hypotenuse. You'll see that that's clearly not the case if you draw a few different triangles that way. I should really read through to the end before I post... then I don't have to make so many edits... -Auron
6. ## Opengl Book Question

Quote:Original post by nsto119 Quote:Original post by Auron As for what you're looking for (explanations of how Windows stuff works with it), the Super Bible, Red Book and Blue Book make no mention of any of that. -Auron Err, the SuperBible has 3 whole sections devoted to specifically dealing with Windows, Mac, and Linux. Oops. I hadn't read the SuperBible in a while. I guess I forgot about those sections... my mistake. Sorry. -Auron
7. ## Opengl Book Question

First up, you can get read the Red Book online here. The Blue Book (which is the OpenGL reference manual), is available from here. I don't think there are any other complete e-books like this about OpenGL available for free online... As for what you're looking for (explanations of how Windows stuff works with it), the Super Bible, Red Book and Blue Book make no mention of any of that. The Hawkins/Astle books you mention do have some explanations of the Windows based code, but (if memory serves) their explanations tend more toward "you need this code, but don't worry too much about what it's doing." My recommendation for you would be to use the Red Book, one of the Hawkins/Astle books, or the NeHe Tutorials to learn how to write stuff in OpenGL and consult the MSDN documentation to look up the Windows-specific code and datatypes to figure out what they're doing. You could also go get a book specifically about the Win32 API (like Petzold's book), but I don't think any of those books will really go into the OpenGL side of things... -Auron
8. ## many noob questions!?

Yeah, my guess is that xBallVeloity and yBallVelocity are just the x and y components of a direction vector for the ball. And for your other question, the way time is measured is up to you and how much resolution you need on it. Usually you use milliseconds to measure elapsed time because most functions that tell you about elapsed time will give you the reuslt in milliseconds. If you measure in seconds, you'll either have to use a function that gives it to you as a floating point value (like 0.01 seconds), or deal with 1 second resolution time (as in, your objects only perceive change once per second). Using milliseconds (assuming a decent resolution on the timer), will usually let you measure elapsed time to a resolution of 1/100 second or better. To move an object using a time basis, you need at least three values: current position p, velocity v, and elapsed timet. Current position and velocity are both vectors (in as many dimensions as your object can traverse) and elapsed time is a scalar. Then you would find the new position like so: p_new = p + t*v Typically, position is in units, time is in milliseconds and velocity is in units per millisecond. Alternatively, time is in seconds and velocity is in units per second. As already mentioned, units is an arbitrary measurement that you define relative to your camera usage and the other objects in your scene. You typically endeavour to make the unit sizes as convenient as possible. This might be disorienting, but do realize that the real world measurement systems are no less arbitrary (feet and inches are derived from the sizes of the feet and some part of the hand of rulers in Europe), so you just have to pick some way to gauge a unit in your scenes. Hope that's all helpful... -Auron
9. ## Hello MFC!

WinForms is the new windowing toolkit from Microsoft for use with the .NET framework. You cannot separate it from .NET itself but it is useable from C#, C++, VB.NET and pretty much any language that can access the .NET framework. If you have a decent reason to claim that nobody can convince you to use .NET, then there are alternate decent toolkits out there that you could use for basic windowing: Qt and wxWindows come to mind. They're nice because they're cross-platform, but in my opinion not really as nice to work with as .NET WinForms... -Auron
10. ## Multiple references to a single class

I'm not so sure I like the inheritance approach. I mean, if SpriteEngine and TilingEngine both maintain proper is a relationships with RenderManager and would have reason to inherit all of the methods of the RenderManager class, then go for it. On a matter of semantics, if you had called the class to inherit from "Engine", it wouldn't have struck me as wrong. That said, if you intend for the base class to contain only an instance of the Renderer, then that sounds to me like a ridiculous way to achieve data aggregation. If all you need is to give both classes a reference to the Renderer object, then you should instantiate the Renderer in the Kernel, then pass it on to the TilingEngine and SpriteEngine when they are created. You've been given a few code snippets to accomplish that, but you weren't told where to put them. Just put that wherever the Kernel creates the Renderer (its constructor? in some init function?). -Auron

12. ## How long have you been programming?

Wrote my first programs on my Commodore 64 at the age of 6 (which was 16 years ago, making me 22). I found a book in my school library that was just a bunch of code listings for games. You just copy the code in then play it (it was like Open Source before the internet [grin]). I thought this was so cool, since it meant I could play new games for free. As I was playing around typing this code in, I slowly started to understand what I was typing and figured out how to tailor the game to my liking, and within a year I started making my own stuff. A few years later, I moved to AmigaBASIC/AMOS when I got an Amiga, then Hypercard on an Apple II. I got an Intel box at age 14, downloaded DJGPP and proceeded to learn C++ from a Java book (I am so not kidding here), and just sort of rolled with it from there. As you can tell, I have a way of doing things all bass ackwards... -Auron
13. ## OCamel, Oh what?

Quote:Original post by Sneftel Quote:Original post by Auron Umm... methinks you're a wee bit confused. Functional programming isn't the same thing as procedural programming. Procedural programming is like C, where the point is that things get executed one line after the next and your program operates much like a finite state machine. Functional programming is a little more abstract than that and while my understanding of it is weak (to say the least), you can read about it at Wikipedia. OCaml does this stuff way better than C++, and so that's why you might want to learn it. -Auron I think David understands the concept of functional programming. OK, my bad. It came off as though he didn't, but then again, that's from the perspective of someone who doesn't know much about functional programming, so I probably should've kept my mouth shut in the first place... Sorry David if I insulted you at all... -Auron
14. ## OCamel, Oh what?

Quote:Original post by dawidjoubert I Saw the raytrace comparison and I see OCaml is quite impressive however my concern is that the code they made using C++ does not need to be OO, c++ supports functional coding as well. Well then I guess OCaml learning I will be Umm... methinks you're a wee bit confused. Functional programming isn't the same thing as procedural programming. Procedural programming is like C, where the point is that things get executed one line after the next and your program operates much like a finite state machine. Functional programming is a little more abstract than that and while my understanding of it is weak (to say the least), you can read about it at Wikipedia. OCaml does this stuff way better than C++, and so that's why you might want to learn it. -Auron
15. ## C# as a FPS programming laguage

Well, even Python is viable for game development, but it definitely does have speed issues. Of course they can even be dealt with by hooking in C/C++ code. My recommendation is to use the language with which you think you can write the game most easily. If you think it would be easier to write it with C#, then use C#. If you think it would be easier to write it with C++, then use it! The speed arguments in the C++ vs. C# battle have been proven moot. They say that DirectX programs in C# suffer only a 2%-5% speed hit compared to the same written in C++ (if someone has a reference to somebody important saying this, it'd be helpful; I think Microsoft themselves may have made such a claim). In the end, my guess is that if you were to want to break into the industry, you'd be WAY better off having a very well written game done in C# than a not-so-well written game in C++. And if you're just a hobbyist, use whatever language you want. If your program ends up slow, it's more likely because of poor algorithm design than your choice in implementation language. If you find out later on that your game is truly choking on its use of C# features (use a profiler before even trying to make any such assertions), then you can port it to C++ or recode the slow bits in C++ and use them that way. -Auron