Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 20 May 2007
Offline Last Active Apr 22 2013 02:30 PM

Posts I've Made

In Topic: Crash on reference obj method call OSX x64

29 March 2013 - 02:39 PM

The configuration you suggested does solve the issue, below is the new method to register.

ret = engine->RegisterObjectType("Vector", sizeof(GtVector), asOBJ_VALUE | asOBJ_APP_CLASS_CA | asOBJ_APP_CLASS_ALLFLOATS); assert( ret >= 0 );


Looking at my vector class, I did have a default constructor and assignment operator, but no explicit copy constructor or deconstructor.


I believe part of my problem was a confusion about what I was passing in.  I had assumed the the types being passed in for constructor/deconstructor/ect... dealt with what I was going to register on the class with the engine, not the actual class itself.  I now understand the separation of these two concepts.


I apprecaite the help, thank you very much!

In Topic: Serverside movement processing

12 August 2011 - 10:10 AM

I agree with the method Sirisian describes, and have done this method several times in my own games. If you are looking at tile based movement 10 updates a second will be more then enough for your needs, this number of updates also will work fine for more action based games if you add a interpolation method on the client to smooth the movements.

In Topic: Fast blit using GDI and PBO

18 August 2009 - 06:00 AM

Original post by AndyEsser
Why not use OpenGL to render direct into the Window?

Good question. I wish that were possible for my situation, as it would make things much simpler. I will be happy to explain.

- The offscreen OpenGL context is being used for rendering different scenes to multiple windows. This is a requirement of the application.

- Some Non-OpenGL windows in the application are created with WS_EX_LAYERED. Which I was disturbed to find does not interact well with standard OpenGL windows. You get horrible flickering and incorrect layering of windows when the two touch each other.

Setup a child window and use opengl on that like you would making any other opengl application. Check out frame buffer objects, I beleive they do rpetty much the same thing just faster.

The child window idea wouldn't work for what I need. The issue is not embedding OpenGL in another window, but instead of transferring the data more efficiently.

Frame buffer objects allow you to render OpenGL to a offscreen buffer of memory on the GPU. I actually already use them in the application, but not for the purpose above. At the end of the day I still need to abstractly get the data from the GPU and into the CPU.

Note that you can have OpenGL render to anything with an HWND. This includes Pictureboxes and many other Windows Controls.

Maybe I'm confused on your response, though I'm unsure how that would help. Rendering to a window is not an issue. There are several reasons I'm unable to use the standard WGL implementation.

In Topic: How does the STL vector clean up memory?

16 September 2008 - 11:10 AM

Original post by Washu
Original post by Hodgman
Original post by Driv3MeFar
Original post by KiroNeem
I would assume then that the STL vector is doing runtime checking of the template type to see if it should call the constructor/deconstructors.

What do you mean? It will always call an object's constructor when constructing it, and always call the destructor when destroying it. Why would you want an object that could be destroyed without a call to its destructor?
Primitive types don't have destructors, so the following is invalid, isn't it?*** Source Snippet Removed ***
As for KiroNeem's question - if the STL is checking if the type has a destructor or not, the check will definitely be done at compile-time, not runtime.

*** Source Snippet Removed ***
Is valid. :) Check your local standard for more interesting revelations about C++.

Your right! That is magical and quite awesome. Thanks for bringing this up, it really glues together all of the pieces I had questions about.

- Kiro

In Topic: How does the STL vector clean up memory?

15 September 2008 - 11:51 AM

Okay, that would makes sense. I've had to use placement new before so I'm familiar with the functionality, very cool stuff. Though I was unsure if there really was any alternative method the STL vector could have been doing.

Thanks for the replies. ^^

I would assume then that the STL vector is doing runtime checking of the template type to see if it should call the constructor/deconstructors.

- Kiro