Jump to content

  • Log In with Google      Sign In   
  • Create Account

Zaoshi Kaba

Member Since 04 Nov 2012
Offline Last Active Today, 12:45 PM

#5262978 Random errors in Release builds

Posted by Zaoshi Kaba on 21 November 2015 - 02:53 AM

Turn up warnings to level 4. It'll notify you about unused variable, uninitialized variables, etc. Fix all of that.

If you're using Visual Studio 2015 (and maybe 2013?) you can also run static code analysis. It might show extra issues (possible nullptr, etc.), but sometimes it also points out false positives.

#5258401 Problem with save mechanisms

Posted by Zaoshi Kaba on 21 October 2015 - 01:43 PM

As far as I can see your loading and saving are not identical:

             ifstream fin((file+".save").c_str(), ios::binary);
             fin>>charactername; Sleep (100); // name is loaded first, but class is saved first, etc.
			 fin>>gender; Sleep (100); // you don't need these Sleep() either
			 fin>>characterclass; Sleep (100);
			 fin>>characterage; Sleep (100);
			 fin>>xp; Sleep (100);
			 fin>>lvl; Sleep (100);
			 fin>>hpmax; Sleep (100);
			 fin>>hp; Sleep (100);
			 fin>>mpmax; Sleep (100);
			 fin>>mp; Sleep (100);
			 fin>>ad; Sleep (100);
			 fin>>cs; Sleep (100);
			 fin>>armor; Sleep (100);
             ofstream fout((save+".save").c_str(), ios::binary);

Also, >> reads until whitespace (and maybe some other characters), so if your class or name or something else contains spaces it will not load the way you expect it to.


Just noticed that you have ios::binary flag set. I'm not sure how it works when writing strings using << and >>, but try to remove it, since your file isn't really binary.


More things you can try:

Try to open savefile manually and confirm visually whether it saved what you expected.

I assume you are using Visual Studio; try to play with debugger to see what gets loaded after each statement.

#5254748 Why did COD: AW move every file into the same folder where .exe is?

Posted by Zaoshi Kaba on 30 September 2015 - 04:00 AM

This is Steam, do they even have an ability to control that?

Besides, why do you care? It works and that's enough.


Edit: It seems my post sounded way more rude than I intended it to.

#5251702 Bones weights

Posted by Zaoshi Kaba on 11 September 2015 - 06:30 AM

I just can't think of a place where you would need so many influences.

Joints are usually only 2 influences, except for maybe fingers, toes, hip, neck, shoulders, etc. even in these cases 3 should be enough I believe.

Although I'm not an expert.

#5251692 Bones weights

Posted by Zaoshi Kaba on 11 September 2015 - 05:06 AM

5-6 bones? What are you making? A starfish?


Putting that aside, can't you just do:

    int4    boneNdxs1  : BLENDINDICES1;
    int4    boneNdxs2  : BLENDINDICES2;
    float4  weights1   : BLENDWEIGHT1; //why was it float3?_?
    float4  weights2   : BLENDWEIGHT2;
D3DVERTEXELEMENT9 decl_skinning[] =
        { 2,  16, D3DDECLTYPE_FLOAT4     , D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_BLENDWEIGHT  , 0 }, // I'm not sure why you had 3 weights but 4 indices
        { 2,  32, D3DDECLTYPE_FLOAT4     , D3DDECLMETHOD_DEFAULT, D3DDECLUSAGE_BLENDWEIGHT  , 1 }, // so I changed it to FLOAT4


#5251302 System requirements

Posted by Zaoshi Kaba on 09 September 2015 - 03:46 AM

1.3 GHz is less than my phone. Quad-core will help with multiple file compilation but your linking time is going to be awfully long, since it needs single core power.

Not sure about graphics, but compare it to other games: can you run Skyrim? Do you plan to make something better than Skyrim?

#5250411 temporarily exclude a rigidBody from ray testing

Posted by Zaoshi Kaba on 03 September 2015 - 07:39 AM

Just use non-default ray intersection callback and filter out your body manually.

That is, make derived class from btCollisionWorld::ClosestRayResultCallback and override virtual bool needsCollision(btBroadphaseProxy* proxy0) const.


#5240893 How do you write this down?

Posted by Zaoshi Kaba on 16 July 2015 - 02:15 PM

Func predicate = (meow? doA : doB);

The fact that this isn't purdicate bothers me more.

#5236774 SIMD and Compilation

Posted by Zaoshi Kaba on 25 June 2015 - 12:03 PM

Not quite.

Compilers provide intrinsics which are equivalent to single instruction, not including moving / copying data.

Intel has full list here: https://software.intel.com/sites/landingpage/IntrinsicsGuide/ and I'm afraid there's over 5000 of them.

MSDN doesn't provide as clean list but it still exists.

#5233224 Sacrificing time: Elegance vs crude coding

Posted by Zaoshi Kaba on 06 June 2015 - 03:26 PM

Day 1: I've created the most elegant and beautiful algorithm for the problem at hand.  I am a genius.
Day 10: My elegance has been improved by fixing the corner cases while changing the least amount of code.
Day 24: I am off on new and exciting things, but I will always look upon this code with joy and a deep satisfaction.
Day 122: I am fighting a terrible bug, and some @%$#% @#$%^&& wrote this stupid...  Oh wait.  That's my code.  WTF?!?!


I never get Day 24. And Day 122 happens on Day 4.

#5229418 no Vsync? why should you

Posted by Zaoshi Kaba on 17 May 2015 - 02:36 AM

vlj, it's not small. Problem with VSync is that you get either 60 FPS or 30 FPS (roughly speaking). While 60 FPS usually is fine, 30 FPS has unbearable input lag. I had to turn off VSync on Assassin's Creed Unity because of that (my FPS was roughly 50). Wouldn't even dare to play Action game with that kind of performance.

#5204882 Rendering .obj Model in DirectX 11

Posted by Zaoshi Kaba on 17 January 2015 - 02:23 AM

Your UV coordinates weren't loaded correctly.


In .obj file you have:

v  -3.9184 -2.6713 3.3765
v  -3.9184 -2.6713 -3.3765
v  3.9184 -2.6713 -3.3765
v  3.9184 -2.6713 3.3765
v  -3.9184 2.6713 3.3765
v  3.9184 2.6713 3.3765
v  3.9184 2.6713 -3.3765
v  -3.9184 2.6713 -3.3765
# 8 vertices

vn 0.0000 -1.0000 -0.0000
vn 0.0000 1.0000 -0.0000
vn 0.0000 0.0000 1.0000
vn 1.0000 0.0000 -0.0000
vn 0.0000 0.0000 -1.0000
vn -1.0000 0.0000 -0.0000
# 6 vertex normals

vt 1.0000 0.0000 0.0000
vt 1.0000 1.0000 0.0000
vt 0.0000 1.0000 0.0000
vt 0.0000 0.0000 0.0000
# 4 texture coords

which roughly means:

positions = {p0, p1, p2, p3, p4, p5, p6, p7};
normals = {n0, n1, n2, n3, n4, n5};
texcoord = {t0, t1, t2, t3};

Faces in .obj:

f 1/1/1 2/2/1 3/3/1 
f 3/3/1 4/4/1 1/1/1 

tell you to generate these vertices:

vertices = {
	// face 1
	{p0, t0, n0},
	{p1, t1, n0},
	{p2, t2, n0},
	// face 2
	{p2, t2, n0},
	{p3, t3, n0},
	{p0, t0, n0}

After this you find identical vertices and replace them with index in index buffer.

#5204800 Rendering .obj Model in DirectX 11

Posted by Zaoshi Kaba on 16 January 2015 - 03:51 PM

That's not how index buffer works.

Not sure if I'll be able to explain this correctly though.


Currently your buffer contains indexes for position, normal, texture coordinate separately, but all these are properties of vertex and they're impossible to index separately.


If you wish to include color your vertex structure might look like this:

struct Vertex {
    float x, y, z; // position
    float nx, ny, nz; // normal
    float tx, ty; // texture coordinates
    float r, g, b, a; // color

Now Vertex* vertices = new Vertex[countVertex]; should contain all unique combinations of position/normal/texcoord/color.


In cube case there will be 24 unique combinations.

It appears you have 8 different vertices, but no, you have 8 different positions.

Lets take front top right vertex - it'll have same position for all 3 walls (top, right, front), but these walls have different normal vector, which results in these combinations:

(position1, normal1)
(position1, normal2)
(position1, normal3)

And that is 3 vertices in your vertex buffer. If you do same for 7 other vertices you'll have 24 unique vertex combinations. Adding color and texture coordinate won't increase number of vertices in this case.


So when you load file:

s 2
f 1/1/1 2/2/1 3/3/1 
f 3/3/1 4/4/1 1/1/1 
s 4
f 5/4/2 6/1/2 7/2/2 
f 7/2/2 8/3/2 5/4/2 

you need to track all unique combinations of faces, generate vertices from position, normal, texcoord indexes, and generate index buffer from these combinations.

Ex.: combination (1/1/1) will have index 0 ( vertices[0] ), which mean you add to your index buffer value 0. If later on you encounter (1/1/1) again, you'll be adding value 0 again.


Hopefully I managed to explain it.

#5204497 Rendering .obj Model in DirectX 11

Posted by Zaoshi Kaba on 15 January 2015 - 09:46 AM

After trying to solve the problem for awhile, I can now see the mesh, however I see 2 triangles instead of a box (incomplete box)


I guess the problem is with the indices, I have 8 vertices, how do I calculate the indices for the box?


Inside ModelLoader.cpp you have:

// Read in the faces.
if(input == 'f') 
	if(input == ' ')
		// Read the face data in backwards to convert it to a left hand system from right hand system.
		fin >> faces[faceIndex].vIndex3 >> input2 >> faces[faceIndex].tIndex3 >> input2 >> faces[faceIndex].nIndex3
			>> faces[faceIndex].vIndex2 >> input2 >> faces[faceIndex].tIndex2 >> input2 >> faces[faceIndex].nIndex2
			>> faces[faceIndex].vIndex1 >> input2 >> faces[faceIndex].tIndex1 >> input2 >> faces[faceIndex].nIndex1;

Which assumes 3 vertices per face, aka. triangle, however in your .obj file:

g Box001
usemtl Material__26
s 2
f 1/1/1 2/2/1 3/3/1 4/4/1 
s 4
f 5/4/2 6/1/2 7/2/2 8/3/2 
s 8
f 1/4/3 4/1/3 6/2/3 5/3/3 
s 16
f 4/4/4 3/1/4 7/2/4 6/3/4 
s 32
f 3/4/5 2/1/5 8/2/5 7/3/5 
s 64
f 2/4/6 1/1/6 5/2/6 8/3/6 
# 6 polygons

each face (polygon) contains 4 vertices.


You have 2 choices here:

  1. load correct number of vertices for each face / polygon and triangulate them;
  2. when you export .obj file there should be an option to triangulate meshes / faces / polygons, use it to generate triangles instead of arbitrary polygons.

#5204296 Rendering .obj Model in DirectX 11

Posted by Zaoshi Kaba on 14 January 2015 - 02:43 PM

You removed most of temp files from your project, I'll give you that. Usually people are unable to do even that.


I am unable to compile your project because I don't have D3DX, but there is something I have noticed:

  1. you aren't doing any transformations in your vertex shader, meaning it's not being transformed into the screen;
  2. your box is relatively far from (0, 0, 0) point, it won't be visible with 'default' camera transform.