• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

128 Neutral

About klaymore142

  • Rank
  1. I think your problem is in the parse_file() function. For some reason, the first call to parse_file(), which is calling getline(), is reading an empty string. This would cause the ': 0' line at the beginning of the write. This being the case, you would have an erroneous last entry in the map, because the incorrect first entry creates an offset. So the last item in the map won't get the proper data. I know it's not much help, but perhaps that will give you a start in debugging.
  2. check for integer

    Yeah, that's not right.....the spec for atoi() says it should be zero. Try posting your code, and I'll see if I can help.
  3. problem with SDL events

    The first thing I notice: else if(event.type == SDL_KEYUP) { crono.setVelocityX(0); currState = 1; } You don't set the Y-velocity to zero also...you should add 'crono.setVelocityY(0);' Also, you are checking keyboard state every time you have any kind of SDL event. You might want to only check the keyboard when there's a keyboard event. This shouldn't cause this problem, but might help in efficiency a little. I think your problem is caused by setting velocity based only on a single key's state - if you have more than one key pressed at a time, what SHOULD it do? Once you answer this question, you can keep track of the previous state of the keyboard (in between SDL events) and update player state based on multiple key positions. Hope this helps!
  4. check for integer

    you can use scanf() to read a string (array of chars) and then try to convert it to an integer with atoi().
  5. C++ String file i/o

    Quote:it looks to me like your code reads only the first character, instead of a conditional, wouldn't a for loop serve better? The code isn't intended to read the whole file, but instead a string within the file. The idea here is that the file might contain more than just the string - in fact, the string would be a single record / field in the file.
  6. Passing SDL event as parameter error

    Suggestion: change void ParseEvent(SDL_Event theevent); to void ParseEvent(SDL_Event &theevent); In other words, try using pass-by-reference instead Note that the SDL_Event class is actually a union, so the linker is having trouble binding the function call to the function itself.
  7. C++ String file i/o

    You really can't save a dynamic-length string to a file without writing the string length first. If you write the string length, then the string into the file, there's no reason to write a null terminator into the file. But if you don't, you'd have to append the null terminator to the char[] explicitly after reading the string from the file. This is why, personally, I don't use std::string objects unless necessary. Edit: You might try file >> ulong; file >> setw(ulong) >> str2; for file reads
  8. Quote:O(n*n/2) IS O(n^2). They are the same. For that matter, O((n*n+n)/2) = O(n^2) as well. Using proper big-O notation, you are right. However, the notation is misleading - O(n^2/2) will grow slower asymptotically than O(n^2). It would make more sense to say that the average performance is O(n*n/2). But it becomes irrelevant, since there's a better solution anyway.
  9. Well, there might be a better solution than this, but... You can optimize the O(n^2) by realizing that a visited pair doesn't need to be visited a second time. For example, the first vertex could be paired with any other vertex (not itself). The second one could then be paired with any vertex, but not the first or itself. Same with the third, and so on. This brings your efficiency to O(n*n/2). Still not that great, but better.
  10. Hey all, Perhaps someone with some experience with NURBS surface deformations and Terrain rendering can answer this question. I have a Terrain engine which seems to work well - it generates a ROAM-style mesh, which I render with Vertex Arrays. The main goal is to make the terrain look very realistic, with a mimimum of polygons. However, I am thinking (to make the terrain look smoother up-close) about using the active vertex list as deformation points for a NURBS surface, and rendering the surface as the terrain. I'm worried that it will just create a bunch of polygons - and won't be very efficient. Also, that it will give the terrain a very rounded and smooth look, which is good for plains but not for rocky crags. Any thoughts?
  11. Heightmap triangulation (jaggy valleys)

    I agree with emeyex - flipping triangles does not necessarily break triangle strips, it just makes them more difficult to build. Check out my terrain page at http://www.klaymore.net/klaymore/terrain.php
  12. Heightmap triangulation (jaggy valleys)

    The real problem to solve is which line to use to divide each quad into two triangles, at the smallest level, and it only occurs if the four points are not coplanar. Of course, artifacting occurs more as the four corners of the quad become less coplanar, but if the corners have very different altitudes, this implies more detail in the terrain at those points. The best solution to the problem would be to know which line causes the smallest amount of artifacting - which requires that you know the intended altitude at the center point of the quad. But that would require more vertices. If you're like me (and many other developers here) and you're using a heightmap to create the terrain - I would suggest using a very highly detailed heightmap (very high resolution). This will minimize artifacting, but require you to perform LOD optimizations, such as ROAM or Geomipmapping.
  13. Need advice: Frustum culling, BSP, etc

    As I understand it, Octrees are a type of BSP tree - and best in outdoor scenes with lots of objects. For indoor scenes, though, you might look into portal rendering or antiportal rendering - much better optimizations.
  14. If you're moving the camera through the scene, the camera has an orientation and a position in the scene. If you're moving the scene around the camera, the scene will have a rotation and an offset. These two modes are basically the same, but my examples below assume you're moving the world around the camera. So, to represent the orientation of the scene, you need a rotation (which is what quaternions do). To represent the offset, you need 3 coordinates (x,y,z) - which is what the vector stores. So all you need to figure out is how to pass this data to OpenGL. The translation / position is trivial : glTranslatef(vec.x, vec.y, vec.z); The rotation is a bit trickier, because you need to convert the quaternion into data which OpenGL understands. In particular, you need to convert the quaternion data into rotation about an arbitrary axis: float theta, ax, ay, az; Quaternion q; // Use the camera's quaternion here! q.normalize(); theta = 114.591559f * acos(q.w); float s = sqrt(1.0f - q.w*q.w); if(abs(s) < 0.0005f) s = 1; // prevents problems near and at s == 0 ax = q.x / s; ay = q.y / s; az = q.z / s; glRotatef(theta, ax, ay, az); I Recommend you Put the above code block into a member function of the Quaternion class, so you can convert a quaternion into a rotation about an arbitrary axis any time you may need it. Hope this helps!
  15. extern help

    You need to separate struct and class definitions into files separate from the implementation of the functions: super.h [source language="cpp"]#pragma once struct Super { int blah; void myFunc(); }; int arr[3]; // Not generally a good idea, but legal super.cpp [source language="cpp"]#include "super.h" Super::myFunc() { // code here } Then, in the other cpp file: [source language="cpp"]void main() { Super s; s.myFunc(); arr[2] = 4; } Hope this helps!
  • Advertisement