Jump to content
  • Advertisement

Fireborn

Member
  • Content Count

    16
  • Joined

  • Last visited

Community Reputation

123 Neutral

About Fireborn

  • Rank
    Member

Personal Information

  • Interests
    Art
    Design
    Programming
  1. It's been awhile since i put together a project from scratch and realized I don't actually understand enough about static and dynamic libraries. I'm having a bit of trouble sussing out the confusion through google so I was hoping someone here could sort me out. My game logic is broken up into 3 libraries: GameCommon GameClient (references GameCommon and implements client versions of classes) GameServer (references GameCommon and implements server versions of classes) Since the server doesn't need to do any rendering, I'm breaking up my engine into two libraries: Engine EngineRender (references Engine) So theoretically my game client executable will leverage the GameClient, GameCommon, Engine, and EngineRender libraries. Here are some of the questions I'm struggling with in regards to building that game client executable: When compiling the above libraries as static, I thought the linking step would happen once at the very end when building the actual executable. As a result I set up my executable project to link in the 4 static libs it needed. I was surprised to see unresolved external errors reported from the GameClient library project when using functionality from the Engine library. I hadn't set up the GameClient library to explicitly reference (or link?) against the Engine library based on my initial assumption - I figured the library would just carry on with it's build and any holes in functionality would surface down the road when linking the executable. Since that initial assumption seems wrong, does that instead mean that I ought to have the GameClient library link in the Engine library somehow? Should I then assume all of the Engine library content will be inside the GameClient .lib file, or does the game executable still need to link against both GameClient.lib and Engine.lib? As a followup to question 1, if my executable only has to link against GameClient.lib and EngineRender.lib, does that mean I'm effectively pulling in two copies of Engine.lib since both GameClient and EngineRender will have to link against Engine.lib? For some reason I thought static and dynamic libraries had some high level differences but were basically interchangeable if you weren't doing anything fancy. Swapping my libraries above from static .lib files to dynamic .dll files started causing some unresolved external issues though. From reading around I think this is because my GameClient library is trying to use functions from Engine library which I haven't explicitly marked up as dllexport? I feel like I have worked on .dll libraries in various projects over the years and don't have any recollection of having to meticulously manage exporting the functionality I added, but maybe I'm mistaken and this is just a huge hole in my understanding of how .dll's work? Does swapping from static to dynamic libraries impact the answers to questions 1 and 2 above? I loosely thought the way .dll's worked was that as the executable started it would try to find the functionality it needed across the various .dll files in the directory with it and would fail to start if it didn't find what it needed. Based on what I was seeing in question 3, it's looking like there is still some kind of linking that happens when generating the libraries and/or executables that detects when a function used from a .dll doesn't have an implementation, but maybe I'm still misunderstanding something? Thanks in advance for any help anyone can provide in clarifying this stuff in my head!!
  2. Hey all, I'm integrating a 3rd party library into an existing application. The executable itself is written in C#, and there is a C++/CLI wrapper used to call various native C++ libraries. I have a 3rd party library which, after integration, has caused several access violation issues. I initially couldn't even get the assembly to load after integration (the C# app would crash when attempting to load the C++/CLI dll). I worked around this by wrapping the 3rd party library in it's own .dll, and programmatically loading it once I was past the C++/CLI layer in an entirely native C++ library. Now that I'm able to execute code within the library, it is causing access violations inside various API function calls. I guess I'm trying to understand the nature of the problem, and if it is something I can even really fix on my own given that I don't have access to the source for this library. In general, I understand what it means when you hit an access violation, however I'm concerned that the real error, down in the C++ libraries, is getting masked by a generic .net exception type due to the CLI layer (although, I thought I would see SEHException if that was the case). Does anyone have any advice on how to tackle this sort of issue, or if it's a lost cause without working with the 3rd party library developer?
  3. Fireborn

    Line/plane collision math aggrivation?

    Even using the algebraic form, I'm getting the same -433 value for t. My facing vector is pretty close to being (0,0,1) So, lets look at how plane's Y values trend as we move forward along the z axis: plugging in x = 0, z = 0: (0, -3.67, 0) plugging in x = 0, z = 100: (0, -3.066, 100) and how about the X values? plugging in y = 0, z = 0: (-79.63, 0, 0) plugging in y = 0, z = 100: (-66.58, 0, 100) In both cases, as we move Z outward, our X and Y values are coming closer to zero, which to me indicates that they are on a collision path with the line defined by our facing vector as we go in the positive z direction (which is the same as a positive t value). I can't seem to grasp why my intuition isn't working out with the math.
  4. I'm pulling my hair out trying to figure out what I'm doing wrong here. My line is defined by two points: (0,0,0) (0.078, 0.011, 1.0). My plane is defined by the following equation: -0.046x - 0.999y + 0.006z - 3.663 = 0. If I'm "facing" the direction going from my first line point (0,0,0) to my 2nd line point, I want to know if my line intersects my plane "in front" of me, or "behind" me. Here is my current solution: 1. Solve for two points on the plane by plugging in to the equation. To handle things like axis aligned planes, I simply find the first non-zero coefficient (in this case -0.046) and solve for that coefficient twice, once by plugging in all 0's for the other terms, and once by plugging in 1's. In this case, that gets me the following two points: (-79.61, 0, 0) (-101.19, 1, 1) 2. I can use these two points to find a planar vector, and then I use the cross product between that planar vector and the normal to get a third point. Solving myself, I get: (1.005, 0.086, 21.603) Although the library that my C# code is using returns the negated version (-1.005, -0.086, -21.603). These should both be coplanar vectors though, so I figure there is no error here. 3. Adding this new coplanar vector to the first of the two planar points I generated by plugging in gives me the final 3 points that define my plane: (-79.61, 0, 0) (-101.19, 1, 1) (-80.61, -0.086, -21.60) 4. Now, I can parameterize the line using my two points (lets call them A and B with A being the point at the origin): A + (B-A)t I can then parameterize my plane using the three points (lets call them p0, p1, and p2): p0 + (p1-p0)u + (p2-p0)v I can set these two equations equal to eachother, and then solve for t (basically using the technique described here: http://en.wikipedia.org/wiki/Line-plane_intersection). If the intersection is "in front" of me, then t should solve to be positive. The problem is, whenever I solve for t, both by hand and with code, I get approx. -433, which would indicate that the point is behind me. Looking at the plane that the equation creates though, and given the direction of my facing vector, I don't think the intersection is actually behind me. My facing vector is generally going along the positive z axis. Plugging in larger and large values of z, it looks like the plane is moving closer to colliding with my line, rather than further... I'm running this code on a large number of lines and planes, and I can see that some simple examples are working out fine. I can't for the life of me figure out why these values (along with many others) aren't working out properly :(.
  5. The find() was failing because I was calling it on an empty map. I'm not sure why the map is empty in my destructor though. I have no code anywhere in my program that removes values from my map. I can use the debugger to step through my program, see that the map gets 2 values added to it (one for each window) and then I can jump ahead to the destructor of my window class as the application is closing and the map is empty. Still, the actual line of code crashing right now is: if (windowHandle && !DestroyWindow(windowHandle)) I've stepped through my program and watched the two window handles generated by my window creation code. The windowHandle in this constructor is valid (it is one of the two handles from window creation). When I step over this line of code, I get the same kind of error: "Unhandled exception at 0x0041c03b in VirtualWindowV0.1.exe: 0xC0000005: Access violation reading location 0x00000004." and it takes me to a break point in the file "xtree", which seems to be code related to my std::map. I'm pretty confused about what the heck is going on. DestroyWindow() is a windows call, so it shouldn't have anything to do with my std::map, right? The only connection is that the std::map is using the window handle as a key value (although again, if you check the std::map in the debugger, it claims that it is empty at this point anyway).
  6. Hmm, I hadn't really thought about the copy constructor and assignment operator. A shallow copy should be ok (the only pointers I have are function pointers, so I want those to be copied shallowly), but this raises the interesting question of how copying a window should work. Copying a window is just tricky conceptually because each window must be unique for the operating system to manage it, so any copy I make won't actually be a true copy. I guess I would just have to go for mirrored functionality? If that is the case, then I'd need to run the Show procedure in my copy constructor/assignment operator when copying/assigning a window that has already been created with Show. Still, it seems like the auto generated copy constructor and assignment operator should function fine. I don't know how that could end up with me having an empty map when I hit the destructor. Its really odd too because the access violation is happening now when I call the windows function DestroyWindow, yet it still seems to be taking place in the std:: namespace.
  7. Awesome man! You were right, it was empty. Its so odd though, it seems like my member variables are getting invalidated by the time I reach my destructor. I can watch the code put two values in my static std::map, and then when I jump ahead to the destructor it has zero values in it. Same thing goes with my window handle. It seems to be invalid by the time I reach my destructor (I'm getting that same access violation but this time when I call DestroyWindow with my window handle). Anyone know what is going on?
  8. Hey all, I'm having a bit of trouble with my window class's destructor. My window class has a static std::map. Its keyed with window handles (HWND) and contains pointers to my window class (so static std::map<HWND, WindowClass*>). In my destructor, I'm trying to remove the window that is about to be destroyed from the map (windowPointerLookup is the static std::map: if( windowPointerLookup.find(windowHandle) != windowPointerLookup.end() ) windowPointerLookup.erase(windowHandle); The program crashes when I try to execute the .find() call. When running in the debugger and trying to step over a call to windowPointerLookup.find(windowHandle) it pops up with the message: Unhandled exception at 0x0041ae1b in myApplication.exe: 0xC0000005: Access violation reading location 0x00000004. which appears to be happening in stl code somewhere (xtree?). I am declaring my windows on the stack, I'm not using new, so the destructor is basically called automatically from my application class's destructor after the program finishes running through its main. I'm not sure if that affects anything or not. Anyone know what might be causing this? I've been digging around for awhile and am a bit stuck at this point :(
  9. Fireborn

    Callback question

    You can only pass static member functions as function pointers. You can still get a callback to a member function but you need to have a wrapper of some kind. This website (http://www.newty.de/fpt/callback.html#member) shows two methods of achieving a callback to a non-static member function.
  10. Quote: Such a class would serve no purpose. It doesn't add any functionality, and it doesn't make anything simpler...all it does is complicate things with another level of inheritance, which makes your code messier, and possibly less efficient. The purpose of the class would be to make code less messy. I'd like the user to be able to write a class: class 3DTetrisApplication : public ApplicationBase { /// Override virtual functions void Initialize(void) { /// Insert application initialization code here, such as /// window definition. } void Update(void) { /// This is called by the main loop } }; and thusly the user has an application, then in their main they could simply write: int main(void) { 3DTetrisApplication tetrisApplication; tetrisApplication.RunApplication(); return 0; } Also, I haven't been able to find any information about how inheritance could make my program less efficient. I'd love to read any references you could direct me to on the subject. Quote: Don't abuse function pointers...in this case a window probably SHOULD know how to draw itself based on the elements that the window contains. Then all you hav to do is add elements to the window and each one of those should have a virtualized draw function. Much better than trying to hardcode some sloppy customized draw function for each possible window! I thought doing callbacks in this manner was pretty standard. I think both methods are acceptable (using inheritance and overwriting virtual draw/resize/etc. functions for the window class itself AND allowing the user to register callback functions to be used for specific events). Part of the reason I chose the callback function registration method was I figured that the things a window needs to draw seem like they're going to be more application specific. I figured I'd leave that code inside the application. I'd love to hear more about how other people have implemented this. I'd like to have something really well designed when I'm finished :). For now I'm still looking for an intuitive way for the user to not have to deal with the static issues.
  11. Well I don't want to get into a debate about boost, but at this point I'd prefer to not use it if I don't have to. I've got a handle on a few ways that I can pass the static function in, but all of them seem to require extra code that I can't figure out how to abstract out of my application class so that I wouldn't have to see it/deal with it every time I make an application with it. Thanks for the info though guys. I'll keep the boost solutions in mind as a possiblity <3.
  12. OK guys, I'm trying to finish up some object oriented application/window code for use in my various projects. This is what I'd like to accomplish: 1. ApplicationBase - A class that I can inherit from, has a StartApplication function that starts an application loop. Basically I create my application class by inheriting this class and overwriting virtual initialize and update type functions. 2. Window Class - A really simple window class. In its current implementation it has functions like SubscribeToDrawEvent() which take a function pointer as an argument. Every time the window needs to be drawn it will call whatever function was passed in. I'd like things to be as simple as possible. I'd like to be able to declare a window inside my applications initialize function and pass some other function in my application class to that window's SubscribeToDrawEvent() and have it work. I don't want to have to make that member function static though. If it was it seems like I'd suddenly have to make most of my member variables static and such. I've read several ways to get around this, but most of them involve a lot of extra code that I can't figure out how to hide away. If there was some extra code I could write and hide it away in my base application class or my window class so that I wouldn't have to write it every time I made a new application, I'd be pretty happy. Anyone have any ideas on an approach for me to check out? So far the only idea I have to preserve the simplicity would be to make a base window class with virtual draw/resize/etc. functions. Then the user would create their own window class inheriting from the base class. I'm not too fond of this method though. It seems somewhat reasonable that a window would recieve data as input and know how to render itself given that data, but it just seems like a bit of an odd way to do things.
  13. I have another question about this method: Quote: If you do find a result, you also have the Window* that maps to that HWND. You then delegate the processing of the message to a regular method of the appropriate Window pointer. So the draw/resize/whatever virtual functions would have to be public so that I could call them with a this pointer for my window, correct?
  14. Sweet, thanks for the clarifications :). Also good to know my design isn't completely out of whack :)
  15. Hey all. I'm starting up a new project and was planning to just use the nehe window creation code to get started. I felt the urge to make something a little more object oriented. I came up with the following design: *I made a class WindowsOpenGlApplication. *This class will have all the basic code to open up a single opengl window. *The class will have virtual draw, initialize, resize, etc. functions. *When I want to create an actual project, all I should have to do is define a class that inherits from WindowsOpenGlApplication and create my own versions of the draw/resize/init functions. The problem is, to generate my window, I need to pass a WndProc callback function to the RegisterClass() function. This means that the WndProc function needs to be static in my WindowsOpenGlApplication. The WndProc handles resize messages from the system, so it needs to call my virtual resize function, but it can't because it is static. Some of the guys in the chat mentioned that I could somehow pass a this pointer into my window in the CreateWindowEx() function. Then my WndProc could extract that extra data from the window and call the virtual resize function using the this pointer. I was wondering if anyone had any other ideas or critiques of my design. The idea is to be intuitive and keep things as simple as possible. Thanks guys ;D
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net 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!