Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

122 Neutral

About Bonehed316

  • Rank
  1. Bonehed316

    Packing info into bits of a byte

    You can use xor to toggle a bit, for example: motionFlag ^= MOTION_MOVEFORWARD will set it, and to unset it (if it is set) you can do motionFlag ^= MOTION_MOVEFORWARD again. Exclusive or is only true when one is true, but not both, so since both are true, it evaluates to false. Be sure to note that it toggles, and doesnt set or clear only.
  2. Bonehed316

    keeping window seperate from renderer

    I dont know if its the "best" way or not, but I enjoy it. We both know that the window should be decoupled so that the renderer is platform independent. So I wrap the window, as you call it, into what I call a viewport. The viewport is platform specific, but thats okay! The viewport has variables to store the width, height, color depth, etc. for the window, as well as some methods for getting the ID for the paltform specific window. The platform specific window is defined in a derived Viewport class, for windows this is called WindowsViewport. The platform specific window class is WindowsWindow, for example, and basically encapsulates the creation and handling of a win32 window. The specific code is handled by a call to Init, which is called from the WindowsViewport. For D3D, the renderer calls the viewport->GetWindow() method which returns the HWND to the actual window, this is used in the presentparams structure, and should be platform independant, except d3d obviously is a win32 thing. OGL I've not used, but I'm sure its got a similar interface.
  3. Bonehed316

    DLLs in C++

    Its possible to use dynamicly linked libraries with classes, but you have to be clever ;) If you have in your main program (or better a "core" dll, which is staticly linked) an abstract base class (who is exported), and in your dynamicly linked dll a c function (delcared in a extern "C" block) which returns an object derived from the abstract class. Simply use LoadLibrary and GetProcAddress, and voila!
  4. Bonehed316

    Projectile Leading Problem

    B is only true if the targets velocity is lower than the projectile speed, otherwise they will never intersect. But in more cases than not, if the targets velocity is larger than the projectile speed, the projectile will never intercept the target.
  5. Bonehed316

    Projectile Leading Problem

    So far no one is correct. Angle = asin(sin(90)*Magnitude(TargetVelocity)/ProjectileSpeed); Wrong because sin(90) = 1, so you are doing useless calculations here. What you are getting is not the angle, but an arbitrary value based on the ratio of the target's velocity and the projectile speed. Dist = Tpos - Spos Dir = Tvel - Sspeed t = Dist / Tvel Dist is true, but how does that help you? The target is moving. If you aim where it is now, when you get there it wont be there anymore. Dir is incorrect because sSpeed is a scalar value, and you can not subtract vectors and scalars. t is wrong because you cant divide vectors either. t is defined as a quadratic function, at^2 + bt + c. I will not give you the specifics, as this is the answer ;) This problem is very complex, and a good physics/calc/math background is required to get to the solution. The iterative method is the easiest way to solve it, and it causes the least amount of dizzyness, but it is also extremely slow in most cases (unless you just get lucky and guess really close on the first divide). Let me give you this bit of help: The location of the target at any given time t is going to be tPos + Normal(tVel)*t, which is to say the starting position (tPos) + the velocity of the target (tVel) * the amount of time it moved at that velocity (which is constant, so no worries). The same is true for your projectile, except you dont know the velocity because you dont know its direction (you only know its magnitude). The trick is solving for time first, which proves very difficult without the velocity of the projectile, but it is possible! You know how to find the location of the target and projectile at a given time t...and you know that when those two equations are equal (or very very near it), they are intersecting! You just need to find a way to get t into a quadratic form, so you can solve it for the correct time. Only one of the answers will be correct. You need a good physics (or calc) background to do this. There is also the case where they will never intersect, which you will need to find as well. As my physics teacher always said, "It's easy if you were paying attention, but if you weren't, you're going to fail!"
  6. Bonehed316

    Win32 resource problem

    At home now, heres my wrapper class, there isnt anything fancy about it at all. class WindowsDialog { private: WindowsDialog(); DLGPROC DialogFunc; HINSTANCE Instance; HWND Parent; public: WindowsDialog(WindowsDialog& other) { DialogFunc = other.DialogFunc; Instance = other.Instance; Parent = other.Parent; } WindowsDialog(HINSTANCE hInst, INT Template, HWND hWndParent, DLGPROC DlgFunc) { DialogBox(hInst, (LPCTSTR)MAKEINTRESOURCE(Template), hWndParent, DlgFunc); } virtual ~WindowsDialog() { } }; There is pretty much no error checking, but I only use this once, lol. I call it like so: WindowsDialog dlg(GetModuleHandle("My.dll"),IDD_DLG_ERROR,NULL,DlgProc); Where GetModuleHandle returns the HINSTANCE, IDD_DLG_ERROR is the resource of the dialog box, NULL for parent, and DlgProc is the callback used to handle the dialog events: BOOL CALLBACK DlgProc(HWND hDlg, UINT iMsg, WPARAM wParam, LPARAM lParam) In this case, "My.dll" is staticly linked.
  7. Bonehed316

    Win32 resource problem

    Maybe it cant be done wit a lib, then. Or maybe its not detecting the dependancy, and thus not importing. Not sure what to do about that. Check compiler options, maybe.
  8. Bonehed316

    Win32 resource problem

    I wrote a wrapper for this, its fun. Unfortunately I dont have the source with me (at work). However, I do have MSDN, and I would be willing to bet money that your problem is in the first parameter of your DialogBox( call. That NULL should be the "Handle to the module whose executable file contains the dialog box template. " In otherwords, your dll, or wherever the .res file is compiled in to. You can get it via GetModuleHandle("MyCool.dll"), I believe. NULL is only acceptable if the resource is in the same module as the call, I believe.
  9. Bonehed316

    Orbiting a camera?

    For angular velocity, you could just divide by the radius, I beleive. The angular velocity (omega) is equal to the linear velocity (v) divided by the radius of the circle in question. If I recall my physics correctly, at least :)
  10. Bonehed316

    Programming School Options

    I just want to say something, so its on record. I go to UCF (here in Orlando). I drive by fullsail on my way to work everyday (which is were I am now, lol). Let me tell you from experience that your education is in large proportions irrelevant when seeking a job. Full sail is probably a great school, but it costs 4x as much as a university. Yes, you get out quicker, and yes you learn more relevant information, but what does it get you? You still have absolutely no experience, and with the schedule they give you, you're out before you know you're in, lol. And once you're out, youre in a very large debt, and still have no job or experience, and no gurantee to get either of those. I recently (this summer) decided against full sail because I couldnt justify spending $60,000 (yes, thats the going rate, not including housing and gas, bills, books (not tuition), etc that you will want/need/have) on something that I could pay $400 for (in books) and teach myself while going to a university. I already have my AA degree from a community college, so the time factor makes no difference to me. Another thing to understand is that your education does not make you a good programmer (or software engineer). I'm currently sitting through C and CS1 classes where people around me have NO clue what theyre doing. They should know this stuff by now, theyre my age. Our C class had a test and the average grade was 40% because no one knew pointers, lol. I did fine, of course, but I dont count. Just my $50^-1.
  11. Bonehed316

    Engine Error Handling

    Agreed! Actually, my stack unwind trick is a global char* initialized to a length of 4096. Pretty much what happens is you pass the guard macros a chunk of text, and it basically implements a try blcok and that text as a string variable inside of the try block. IF an error occours and an exception is thrown, the other macro (cleverly named unguard) will catch the error, and pass the newly created string into a function which uses some not-so-fancy pointer arithmetic to copy the strings in reverse order and rethrow the exception. The application is then responsible for catching the final error and calls another engine level function, which is what creates and displays the dialog box, and then the app does its cleanup and exit. I might not be the most elegant, due to the global string, but it works perfectly, and doesnt involve a lot of global pointers, or creating classes to handle the errors or a bunch of nonsense, just simple strings are good enough for me.
  12. I dunno about you guys, but my game engine is going to have an editor of some sort which is a totally seperate EXE. And while I have no idea about the specifics of doing such a chore, I would bet that a dll would make it way easier to have 2 seperate applications using the same code. ;) Unless you use your game exe as your editor exe, but that seems like a design error to me. Needles, I prefer to make dlls. Though I dont get any link errors. Now, for the original post. Why do they have to be abstract to export from a dll? Maybe I'm missing something, lol. I have a pair of dll's in my engine (so far) and almost all of my classes are exportable. I think all you should need is a CGuiEntry base class, which is abstract as you said, for the most part. Being abstract means having at least one pure virtual function (correct here if I'm wrong), but it doesnt mean ALL of them have to be pure virtual. I think you might be assuming that an abstract class can have no implementation (or maybe I'm assuming it can, lol). Reguardless, you would want everything that all GUI elements share to be in CGuiEntry, such as Draw() and OnClick, OnHover, OnDrag (wouldnt it be cool to have drag/drop and movable gui elements) type events. And depending on how you store your gui objects, calling Draw() on them is trivial simple if the functions. Every subclass of CGuiEntry will then draw themselves, and recieve all common events, which they will all handle differently depending on their implementation. Another great thing would be to have your GUI support callbacks, but I've no idea how to implement that (tried once long ago, and failed). Maybe I'm missing the problem..
  13. Bonehed316

    Engine Error Handling

    I have currently in my engine several forms of "errors." First we have errors that are accidental, such as attempting to call a function through a null pointer (sure, you could check for null pointers, but lets assume the programmer is human and forgot), or pretty much anything that throws an exception. These I handle by building a string of values passed into my guard macros which identify where in the stack the error has occoured, which really helps find the error. This string is presented in win32 dialog, along with some system specs and such for bug reports. Next, we have assertions. A program assumes certain things about its variables sometimes, perhaps that they should always be within a certain range, and getting outside of that range is "impossible." Other assumptions could be null references, or whatever you think should NEVER happen. These can be handled differently, but I chose a method that works for me. In debug builds, these are handled similarly to the errors above, with the stack unwind, but also the line and file of the assertion, as well as the actual code that causes the error are presented in a win32 dialog. In release builds, some assertions are removed, and the check is never executed. Secondly, we have things I call "uh ohs." Something got a bit out of whack, but it's not the end of the world. Generally we just like to make note of these, so they can be addressed in due time. These are handled by logging a warning message into the log, but the app continues its execution. I can provide a bit more info on any of these, if anyone is interested. It really isnt that fancy. ;)
  14. Bonehed316

    calculater (solved)

    This thread is painful to read...
  15. Bonehed316

    C++ "missing feature"

    I believe it stands for Run Time Type Information. dynamic_cast compiles always, and does its type checking runtime, instead of static_cast which may not compile if the types are not in heirarchy.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!