Jump to content
  • Advertisement

Crypter

Member
  • Content Count

    1299
  • Joined

  • Last visited

Community Reputation

748 Good

About Crypter

  • Rank
    Contributor
  1. Crypter

    Location of data in the class

    Technically you can enforce a specific alignment or none at all via compiler specific #pragma options. For example, in MSVC, #pragma pack directive or G++ attribute((packed)). TheComet is correct though, floats are very well standardized and guaranteed to be 32 bits so it is most probably safe to assume proper dword alignment without padding. The only guaranteed methods however would be compiler dependent; that is, resulting to nameless structures or #pragma.   You can also just overload operator[] and call it directly.   Alternatively just don't do it. You are not gaining anything from doing this after all. It can be done, of course, but at what benefit?
  2. Crypter

    Location of data in the class

    As mentioned above, it is not safe due to possible padding between members. You can however use a nameless struct here to achieve the same effect, class matrix { public:      union {         float m[9];       struct {          float _m11, _m12, _m13;          float _m21, _m22, _m23;          float _m31, _m32, _m33;       };    };   // now m[1] = _m11, m[2] = _m12 etc. }; It is important to note that nameless structures are not standard although a few modern compilers support it.
  3. Crypter

    Prevent Losing Entire Project To Malware

    Sorry for the loss.   It is strongly encouraged to always make backups; version control software is also worth checking into (we use BitBucket with Mercurial) and is the recommended suggestion for software projects.   This is a good reminder to everyone - if you have not made any backups yet, do it now.   I suggest MalwareBytes AntiMaware; its free (although there is a paid pro version) and can both remove it and can potentially aid in preventing it. Please reference this post regarding Crypto Locker and how to remove it if not already done so (note however that your documents cannot be uncovered unfortunately.) Alternatively the Norton anti-malware suite is also really good although a bit expensive.   This one might also be useful to try. Particularly the section about recovering files from shadow copies if system restore is enabled. However I cannot guarantee it will work.
  4. Thanks again for the suggestions.   I really liked the idea of moving the window management code to a higher level and have been considering the problem with polling and waiting for system events in the event loop. I myself am not all that familiar with SDL either; only know a little bit - though I did eventually learn online that the main event loop cannot be in a separate thread which poses a potential problem.   Although none of this is yet official in the design, this is what I came up with. Please note that in this design I have dropped SDL in favor of Win32:   Project : HgKernel Implements the real entry point such as main or WinMain depending on operating system and platform. All the entry point does is the following, extern int HgApplicationEntryPoint(int argc, char** argv);   namespace hg { static DWORD WINAPI HgApplicationThreadEntry (void* Param) {    if (!wglMakeCurrent (GetDC(_hwnd), _hglrc))    cout << "ERROR" << endl;    if (HgApplicationEntryPoint (__argc, __argv))       return 0;    return 1; } class HgKernelCore : public HgKernel { public: void run () { startup(); HANDLE h = CreateThread(0,0,HgApplicationThreadEntry,0,0,0); SetThreadPriority(GetCurrentThread(),THREAD_PRIORITY_ABOVE_NORMAL); eventLoop(); } }; } //namespace hg int main () { hg::HgKernelCore core; core.run (); return 0; } HgKernel::startup creates a default hidden window and enters the event loop. HgKernel::eventLoop is the event loop; it sets its own default thread priority before entering it. It also creates and runs HgApplicationEntryPoint as a separate thread -- this is defined in the actual game software.   Engine application Since engine start up is automated yet still configurable, all the game program linked with the engine needs to do is define HgApplicationEntryPoint which acts as an operating system independent entry point. Note the initial window is not displayed until the engine is initialized by the game program. The engine can provide static access methods for the game program for all major sub systems; for example, HgKernel::GetVideoDriver or HgKernel::GetInputManager, etc. int HgApplicationEntryPoint(int argc, char** argv) {      HgKernel::initialize("My Game",800,600,32,false);      /* simple test for OpenGL in this game/render thread. */      glViewport(0,0,800,600);    glDisable(GL_CULL_FACE);    glMatrixMode(GL_PROJECTION);    glLoadIdentity();    glMatrixMode(GL_MODELVIEW);    glLoadIdentity();    while (true) {       glColor3f(1,0,0);       glRectf(-0.25,-0.25,0.25,0.25);       HgKernel::endFrame();    }    return 0; } Thanks again for all the suggestions and feedback; it is greatly appreciated.    As far as I could see, this design resolves all current concerns - no singletons; no global access point. Although HgKernel provides access methods; it is only for use by the game software since no other system links to it, the game/render loop runs in a separate thread from the event loop; the event loop thread runs with a configurable priority level and can send the events to the input manager using the input managers event classes to be buffered and time stamped, and also hides the entry point for operating system independence from the game programs perspective.
  5. Crypter

    Questions for all programmers.

    1) What was the first programming language you studied? C++ however the first language I actually practiced in was C.   2) Did you have any Computer Science background before your first language (ie: boolean algebra, memory organisation, algorithms)? Not really.   3) The first language you studied was it self-taught, formal instruction, or both? Self taught.   4) Was the Computer-Science background self-taught, formal instruction, or both? Both; I studied my first language long ago when I was young. Formal courses later on in university.   5) When you started to study Computer Science did it help your understanding of the language you first learned? To be honest, not really. It did give me a new appreciation for the underlying concepts that go into language design and software engineering; introducing me to a few more languages (Java and Scheme.)   6) What kind of environment did you first program in (ie: the IDE or text editor, and the OS)? Turbo C 2.1 followed quickly by Borland Builder 5 on Windows 95 IIRC.
  6. Thanks for the response.   I would like to clarify some things if possible; it would help greatly.  That is correct; the problem lies with how operating systems send event messages to the event callbacks responsible for a particular window. While the window should be within the graphics system (initialized with OpenGL compatibility) the event processing and dispatching should be within the input system.   That is, who should be responsible for the window procedure to process events?   If it is the input manager, then it must be in the same thread as the same thread that created the window via a call to the Win32 RegisterClassEx and CreateWindowEx (as far as I know; please correct me if wrong.) This would also require the graphics system to initialize the window with the window procedure callback found in the input module.   If it is the graphics system, the graphics system would need to pass those events to the input manager to be processed.   Is there an alternative? Sorry, I am not entirely sure how that is related to the use of SDL. Under the standard Windows event loop, messages are polled via GetMessage or PeekMessage and the window procedure is only called when the main thread executes DispatchMessage in the event loop. That is, polling for system events always occurs. SDL_PollEvent is just a wrapper around the event dispatching for the underlying operating system in this manner.   That is, I think the problem you mentioned would occur regardless of the use of SDL or not.   Thanks for the suggestions so far and for clarifying some things.
  7. Thanks for the responses. Technically the only statically allocated pointer was HgKernel::singleton. All other pointers were run time allocated on the heap. To be fair however, despite the design it has almost never been used since there really was no need (except in a few places discussed below.) Really good advice there. The goal of the redesign was to aid in the following,   1. Improve build times. The original design had the entire engine in its one module; a change in one source file typically resulted in an entire build. This I blame MSVC; it would rebuild source files that are completely unrelated. This would resolve this and any future annoyances from the MSVC build system since the projects are smaller.   2. Improve structure. The only reason I originally designed the HgKernel::get() method and design was for safety reasons - one cannot foresee what might be needed by systems that have yet to be written. In writing a lot of the system though I realized that this is rarely used and most probably indicates a design flaw since it opens up any system to any other system; it is easy to couple systems together this way that should not be if not careful.   I do completely agree though; the goal of this is to simplify the current design rather then make it more complicated then needed. I think I will do this; all image related material can go into that same module (HgImage class, HgImageCodec class, all image codecs for loading and saving the different images, HgImageColorFormat etc.) This way anything related to images are in the same project and not scattered between projects; the image library would define what an HgImage is -- not the engine or kernel or even the graphics manager that would link to the image library. It also makes it easy to use in engine tools as well that can just link to the library as needed. Very true. I realized this in the original design. There was a few cases however that I wanted to address for possible feedback - possible there is something that I don't see here.   Window events - Graphics manager or Input manager?   Currently I am using SDL to abstract the operating system specific API; I can easily just use SDL_PollEvent in the HgInput module and set up SDL OpenGL support in the HGOpenGL module separately. This of course won't work on standard Win32/Win64 or other system API's which the original designed used.   That is, lets say the system is using Win32. The graphics system creates a new render target (a Win32 Window.) Windows of course will send events to this Window, such as mouse, key, and system events (like Window close.) Do you typically handle this in the Graphics or Input manager?   The way I originally handled this (since I used Win32 not SDL) was to have the graphics manager handle these Windows events and pass them off to the Input manager. This means though that the Graphics manager needed access to the Input manager.   How would you handle cases like this?   Again please note that since I currently am using SDL I don't currently have this problem - its more so an interest.   Thanks for the help and suggestions!
  8. Hello everyone,   I am currently in the process of restructuring our current engine into multiple projects/library modules to improve compilation time and to better allow different modules to be selectively reused as needed in engine utilities. This posed a few questions in general architecture design however :   1. Where does resource loading actually occur? In the file module? In a special module dedicated to resource factories (like a "modelLoader" or "audioStream" etc.? Currently the file module only provides a basic file manager that allows loading files from ZIP/PAK and disk directories as it were a single abstract file system. Under the Single Responsibility Principle I would expect the actual loaders to be elsewhere in their own dedicated modules (note that by "module" here I am referring to a project in a Visual Studio solution that compiles as a static or dynamic library.)   That is, what I was considering was having different projects for different loaders; such as imageLoaderTGA, imageLoaderDDS, modelLoaderHG etc. These would inherit from some base class defined in another more abstract module, such as hgImage or hgModel. For example,   Project : LoaderDDS #include <hgimage/loader.h>   class HgLoaderDDS : public HgImageLoader {    //... }; Project : HgImage class HgImageLoader {   // abstract class for load,save for creating HgImage objects. }; This of course works I am just not sure if its good nor where it fits in with resource management.   2. Is it common to have a single module that is itself a library that links all the major libraries together? That is, I currently have an Hg module that has the HgKernel class. This would provide system startup and shutdown as well as the main loop; it is the only singleton in the entire engine that allows a single access point to all systems. In order for this design to stay (I can rewrite it if needed) we need a single library that imports all major other engine libraries/projects and basically provides a very thin interface like so, class HgKernel { private: static HgKernel* singleton; gfx::HgVideoDriver* pkVideo; public: HgKernel (); /*** KERNEL ACCESSOR METHODS ***/ virtual ~HgKernel () { if (singleton) { shutdown (); } } static inline HgKernel* get () { if (! singleton) singleton = new HgKernel; return singleton; } /*** ACCESSOR METHODS ***/ inline gfx::HgVideoDriver* getVideoDriver () {return pkVideo;} inline double getFramesPerSecond (); /*** SYSTEM METHODS ***/ virtual bool initialize (); virtual bool initialize (std::string caption, int w, int h, int bpp=16, bool fullscreen=false); virtual void shutdown (); virtual bool run (); }; The concern is that HgVideoDriver is implemented in a completely different library. If we extend this example to include an inputManager, audioManager, scriptManager, networkManager, etc., etc., all implemented in other libraries. Although the editor and game only need to link to this one HgKernel class, the HgKernel class would need to be able to link to all other main systems. To make it worse, the whole point of this setup was to allow any major system to call any other major system as needed; this would thus make this design impossible anymore - for example, the kernel object cant depend on the videoManager when the videoManager also needs to depend on HgKernel::get() -- we would have a circular dependency.   So the question for (2) is, how do you allow the major components to communicate with each other as needed without using a central setup like the above? Or is there a better alternative or way to implement the above that does not result in circular dependencies?   Thanks for any help!
  9. Crypter

    Opengl Basic

    Hello, Be sure to clear WNDCLASSEX if you are not going to be setting all of the data members in it (you are messing hIconSm). Invalid values can cause RegisterClassEx to fail. Also, because you are using the *Ex routines, I would recommend using CreateWindowEx over CreateWindow.
  10. Hello again, Moving the call to disable GL_TEXTURE_2D before glColor3f fixes that issue.. Everything is working as expected now. Thank you for your help! As of current, lighting is already disabled. I suppose I will need to disable it though when rendering the text. Thank you for the suggestion.
  11. Hello szecs, Thank you for your response - that fixed it :) ...However the first character in the output string is never being changed. ie, calling glColor3f sets the color for all characters except the first... Any more suggestions are greatly appreciated [smile]
  12. Hello everyone, I have been having an issue with setting the color of our fonts. I am using wglUseFontBitmaps to create the characters in a display list and can render the characters without problems. However I cannot seem to be able to change the color of the displayed text... Here is my rendering routine. If texturing is enabled, font is whatever the last color that was used. If its disabled, all characters are white (always white) except the first character rendered - it, too, is the color of the last color used. In both cases the glColor3i call seems to not effect anything - which is the problem. void fontWGL::render ( std::string str, point2d<float> pos, color col ) { //! set position glRasterPos2f (pos.x, pos.y); glDisable (GL_TEXTURE_2D); glTexEnvi (GL_TEXTURE_ENV,GL_TEXTURE_ENV_MODE,GL_MODULATE); //! enable color material glEnable(GL_COLOR_MATERIAL); //! font always white? (except 1st character) glColor3i (0,0,0); //! set base character to 0 glPushAttrib(GL_LIST_BIT); glListBase (baseDisplayList - 32); //! renders display list glCallLists(str.length(), GL_UNSIGNED_BYTE, str.c_str() ); glPopAttrib (); //! disable color material // glDisable(GL_COLOR_MATERIAL); } Any and all suggestions are greatly appreciated [smile]
  13. Crypter

    SVN Access

    Hello, I am still trying to understand the terms. I can set up SVN and work with it; I am needing to understand more about it however. It just feels unnatural right now. The SVN in question is not viewable sense its hosting a closed source project. Was there anything in particular that you wanted to check? I appreciate everyone's help :)
  14. Crypter

    SVN Access

    Hello, I created another folder for the repository and done an SVN Checkout and everything is in the new folder including the files that others uploaded now. Assuming that I just update and commit as needed on the new folder I shouldnt run into problems will I?
  15. Crypter

    SVN Access

    Hello, Quote:Does it show the list of files it updates? (IIRC it uses pink color for filenames of new files) If it does show the details, your copy will have been updated. I can only imagine you're in the wrong folder.It does. I assume I am looking at the right folder sense its the same folder that I originally used to create the SVN (and has an icon overlay from TortoiseSVN) :) It does seem like it copies them to my computer when doing an SVN update. If it is then I dont know where sense its not going in the same folder I used to create the SVN.
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!