Jump to content

  • Log In with Google      Sign In   
  • Create Account

Auskennfuchs

Member Since 07 May 2010
Offline Last Active Yesterday, 05:39 PM

Posts I've Made

In Topic: This singleton keeps crashing.

24 July 2014 - 02:42 AM

This *(int*) doesnt work in my opinion, because you subtract the content of the adresses instead of subtract the addresses of the pointers. This little piece of code should just calculates the offset from the Singleton class to the covered class. So in memorylayout the ms_Singleton-member needs its 4 or 8 byte for its pointer-storage. Appended to ms_Singleton the covered-class members are aligned. So to get the right startposition when GetSingleton is used, the pointer is shifted by the calculated offset. Afaik this code was a workaround for older compilers and the newer ones automatically calculate those pointer-shiftings. I would give it a try to just cast the pointer ms_Singleton = (T*)this;

In VS2013 it should probably work, but I haven't tried it on Linux or Mac.

Btw. using int as datatype is critical, because it's size isn't constant through x86 and x64 and different OS. You should use char, short or long.


In Topic: Basic Rendering

21 January 2014 - 12:47 PM

Create the same amount of vertexbuffers, one for each object. The vertex-struct for each object can be different but you have to draw all objects with a single draw-call.

 

Alternative: One big vertexbuffer, copy all objects into this (one after another in memorylayout like an array). But the vertex-struct has to be the same for all objects. Advantage is, you can draw all objects with one single draw-call if you use the trianglelist-topology. If not do a drawcall for every object but with different starting indices obvioulsly.


In Topic: Octrees

21 January 2014 - 10:58 AM

Quadtrees are a 2D subdivision, octrees are 3D or "2 quadtrees on top of each other".

In quadtrees the division is only in 2 axis (x,y). So the z-position of an object doesn't matter.

In octrees the third axis is also used for subdivision, so the z-position is evaluated, if an object is in the upper or lower quadtree of an octree.


In Topic: Basic Rendering

20 January 2014 - 12:32 PM

ByteWidth is the whole size of your vertexbuffer. So you have 6 vertices defined in your OurVertices-array then you also have to allocate the vertexbuffer for same amount of space.

For explanation (simple):

Just imagine the OurVertices-array is a data-container on CPU-side. This can't directly be accessed by the GPU. To transfer the content you have to create a data-container on GPU-side and this is the vertexbuffer. The data is transfered through Map->memcpy->Unmap. Map opens a "pointer" to the allocated vertexbuffer and you can copy the data. Unmap closes the "pointer" and the gpu now knows it can access the containing data for rendering. The transfer is an expensive process and you should do it as few as possible. So for static geometry just once when creating the vertexbuffer and not on every frame. Dynamic buffers like particles should be updated when needed. You can also just update a part of the buffer. You can also delete the buffer on CPU-side, the vertexbuffer will still contain all data until it will be released.


In Topic: SwapChain resize questions

20 January 2014 - 12:03 PM

I had the same issue, when I implemented the resizing and also got some ugly synchronization problems up to bluescreens from graphiccard-driver, cause I rendered in another thread to the window-messagequeue and called the resize-function on every WM_MOVE event.

When you trigger your resizefunction? I guess the order Drawing->Present->Resize or Resize->Drawing->Present should reduce flickering. In my solution I ended up in just resize the textures when resize is finished. So the rendered image gets scaled while resizing and corrected just once afterwards.


PARTNERS