Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[alway]

I suspect it could have something to do with the way the values are copied combined with optimization, as strings are more complicated variables than ints. Try writing your own copy constructor and default constructor; I would bet Program 1 will call it, while Program 2 won't. Program 1 is probably creating an instance and copying it to the value, which itself was originally created with a default constructor.
effectively doing:
{
TestClass tc();
tc = TestClass("string"); //~tc(); called on original, new copy copied
} //~tc(); called on second copy
whereas the other does:
{
TestClass tc(42);
} //~tc();

Probably because the string itself needs to be initialized or something of that sort.

[Mego]

TestClass tc = TestClass("test"); actually constructs a TestClass in a unnamed temporary variable, then copies it to tc. My first guess is that your compiler is doing some optimisation that gets rid of this temporary variable, but for some reason can't do this for the version that has a string parameter.

Probably something to do with primitives versus objects. ints are primitives, while strings are objects. That's really the only difference I can see. Maybe try it with other data types, like doubles and vectors?

[GalenEvil]

is MS-DOS format Unicode-8/-16? or is it ASCII?

Eh, I have a question that I hope someone can answer:

In Unity, I am trying to come up with an easy way to figure out if a cube is surrounded by 6 other face-adjacent cubes. Normally this isn't that much of an issue, but I have upwards of 11k - 15k cubes in a List<Transform>. Is there a faster way to get adjacency information other than searching the entire list repeatedly? I might be able to make it into a single-pass search for all 6 values and just remove the search value from a bin if it is found but I'm not sure how much faster that would be, if at all. Would doing a Raycast work for this? And does a raycast return "if something is hit within R range" or does it return "raycast hit G gameObject"?

Need more info. 1. Is it grid-aligned? 2. Is it axis-aligned? 3. If grid aligned, do you track the empty cubes as well as solid ones?

It is currently I guess Grid aligned. The cubes don't have rotational values beyond what's needed to make them look right as different terrain types. I am going to hazard a guess that by empty cubes you mean "unrendered cube" and not "air cube." It has to keep track of all physical cubes adjacent to itself in order to determine if it should be rendered. If there is an air pocket next to it then it should be rendered. If there is a cube, rendered or unrendered, it has to check to make sure that it is completely surrounded in order to be set to not render. That still might not be as much information as you were looking for, but I am not sure. So ask for more detail please if I did not explain it enough.

You can do a limited-range raycast in Unity.

I thought that I was able to do that, but would the ray need to be originating from the face of the cube or from the center position of the cube? And if it needs to be from the center of the cube would it then need to set the cube to ignore the raycast? If the raycast originates on the face of the cube then it would need to have a 0 or close to 0 distance to check for, as each of the neighboring cubes would be flush with the origin cube.

Wouldn't you want to use something like a 3d array, and store each cube at its coordinates? then you have O(1). You probably dont want to use arrays though, but still some form of indexed data storage instead of just a list...

If I had a specific working dimension that the cubes could occupy then I guess I could use a 3D array to store location data, which would be good. I was thinking that i might be able to implement an octree to keep track of points. The octree might be more easily implemented since it would also be able to check quickly for neighboring occupied cubes as well as ensure that a cube is not placed if the location has already been filled. As an extra, an octree search is not that inefficient, since it is mostly a layer by layer boolean operation down the tree's branches until it gets to a leaf; only checks that a branch could contain the point specified and then does the same for each child in that branch if it can, and returns a false value if it cannot.

I will have to think about the best way to implement this... With my current implementation (normal cubes only, no special terrains / ramps) it is able to create 11k cubes in a block and will only render the ones about 4k of them in the tests that I am doing. This seems pretty good but the list searches slows down the process immensely and brings the frames per second down to less than 10 by the time it nears the end.

[alway]

Since you are rendering, you would want ALL cubes which are on the 'surface.' Which makes it O(n) using a simple arithmetic method Twiggie described. I suggest an octree whose data is pre-calculated as the simplest method. Assuming your cubes are mostly static and you don't have massive numbers switching between empty and full every frame, updating an octree when something changes should be adequate. The data in the octree should then be a pre-computed answer to the question "should this be rendered?" stored as a single true/false bit. For the update of cubes, you simply check the cube that changed and each of its 6 neighbors, changing their octree states accordingly. Then going up the levels of the octree, if any child node has something to render, that parent node has something to render. Then it's just a matter of starting at the top level and following down the paths where the bit is true.

There are a number of other possible optimizations, but they are case-dependent; this is just a general solution. If this method is inadequate for your purposes, further describe precisely how your blocks are changing over time, how and for what purpose they are being used.

[dreadmullet]

I added a "Copy Constructor called" output for when the copy constructor is called for TestClass. The results aren't surprising:

Code: (2 destructors called) [Select]

...
TestClass tc = TestClass("test");
...

output:

Constructor called
Copy Constructor called
Destructor called
Destructor called

Code: (1 destructor called) [Select]

...
TestClass tc("test");
...

output:

Constructor called
Destructor called

As for the string/int argument difference, I can only assume it was inconsistent optimization by the compiler, as alway suggested. That kind of explains one really weird thing I had happen to me. All this code isn't what I'm working on, obviously, but I seperated it from my original program, which at first had a crashing issue. Apparently a destructor was being called twice, and it crashed because it tried to delete a pointer twice. Anyways, at one point, it was working fine. Then in one file, I added a space and deleted it then compiled, which meant it recompiled into what should have been the exact same program, except it then crashed. Really odd. I could replicate it, too.

Thanks again for everyone's insight.

[alway]

As for the string/int argument difference, I can only assume it was inconsistent optimization by the compiler, as alway suggested. That kind of explains one really weird thing I had happen to me. All this code isn't what I'm working on, obviously, but I seperated it from my original program, which at first had a crashing issue. Apparently a destructor was being called twice, and it crashed because it tried to delete a pointer twice. Anyways, at one point, it was working fine. Then in one file, I added a space and deleted it then compiled, which meant it recompiled into what should have been the exact same program, except it then crashed. Really odd. I could replicate it, too.

Thanks again for everyone's insight.

A really good thing to do when deleting pointers is this:
#define sdelete(x) if(x != NULL) { delete x; x = NULL; }
So long as you use that, you won't get null pointer crashes. After that definition is created, just use "sdelete(ptr);" instead of "delete ptr;" and you never again need to worry about accidentally deleting null pointers. Though trying to do so with a pointer to invalid memory at a valid memory address will still cause issues. (for example, calling: "delete ptr; sdelete(ptr);" will crash, as ptr still has a non-null value but points to deallocated memory; but will generally prevent most of the ptr deletion crashes people have)

[GalenEvil]

Since you are rendering, you would want ALL cubes which are on the 'surface.' Which makes it O(n) using a simple arithmetic method Twiggie described. I suggest an octree whose data is pre-calculated as the simplest method. Assuming your cubes are mostly static and you don't have massive numbers switching between empty and full every frame, updating an octree when something changes should be adequate. The data in the octree should then be a pre-computed answer to the question "should this be rendered?" stored as a single true/false bit. For the update of cubes, you simply check the cube that changed and each of its 6 neighbors, changing their octree states accordingly. Then going up the levels of the octree, if any child node has something to render, that parent node has something to render. Then it's just a matter of starting at the top level and following down the paths where the bit is true.

There are a number of other possible optimizations, but they are case-dependent; this is just a general solution. If this method is inadequate for your purposes, further describe precisely how your blocks are changing over time, how and for what purpose they are being used.

I think that method should be adequate for my purposes. I will likely need to include 2 render bits instead of just a single one. One for the inside/outside render value, and the other for an occlusion culling method that I am developing which would value true if it is viewable from the current camera position and orientation. I might be overcomplicating that part, or oversimplifying it if dynamic occlusion culling turns out to be more difficult than I think it is. Thanks for the information and explanation Alway!

[alway]

Since you are rendering, you would want ALL cubes which are on the 'surface.' Which makes it O(n) using a simple arithmetic method Twiggie described. I suggest an octree whose data is pre-calculated as the simplest method. Assuming your cubes are mostly static and you don't have massive numbers switching between empty and full every frame, updating an octree when something changes should be adequate. The data in the octree should then be a pre-computed answer to the question "should this be rendered?" stored as a single true/false bit. For the update of cubes, you simply check the cube that changed and each of its 6 neighbors, changing their octree states accordingly. Then going up the levels of the octree, if any child node has something to render, that parent node has something to render. Then it's just a matter of starting at the top level and following down the paths where the bit is true.

There are a number of other possible optimizations, but they are case-dependent; this is just a general solution. If this method is inadequate for your purposes, further describe precisely how your blocks are changing over time, how and for what purpose they are being used.

I think that method should be adequate for my purposes. I will likely need to include 2 render bits instead of just a single one. One for the inside/outside render value, and the other for an occlusion culling method that I am developing which would value true if it is viewable from the current camera position and orientation. I might be overcomplicating that part, or oversimplifying it if dynamic occlusion culling turns out to be more difficult than I think it is. Thanks for the information and explanation Alway!

I suspect you wouldn't want to store the occlusion culling in the octree's data, as the camera position & angle will (probably) be changing every frame. It would probably be more simple to use the structure of the octree itself to calculate the occlusion culling as the tree is traversed; as the octree's structure is tied to the spatial coordinates of cubes and sub-cubes. Since you can trivially determine the bounds of a node in the octree based on the size of parent nodes, you can do a fast comparison (if node has surface-blocks) initially, followed by an intersection test between the camera's viewing frustum and the node's bounds. An intersection between said frustum and such a simple, axis-aligned cube node should be fairly easy to sort out.

[Skyrunner]

The OTP system of a game that I play is really interesting, viz, I can't figure out how in the world it works o.O

See, it's a time-and-user-ID-based system, with an OTP generator on my phone which generates a short string of numbers to input into the website so I can get in. It seems pretty straight-forward, except there's the ability to regenerate an OTP so it is a different number. Also, each number has a 1 minute 30 second expiration time.

o,O? How does it do that? If the number can be regenerated, and each number has its own expiration time ... D:

[Siquo]

number of seconds since X + your id.
Then "hash" that, should get you a unique one every second.


Edit: hash in quotemarks because you need to be able to extract the actual time from the string in order to match it, so it isn't hashed per se. So the string is probably:
encoded time + hash(time + id + salt, key)
Where the encoded time could be anywhere in the string (every other char or something). The only thing that makes it secure is the secret key and/or the salt used for the hash (which is secure enough for any enterprise level encryption, given that they use a good hashmethod).

[Valid_Dark]

Ok, I'm having some trouble with SDL again, and need some help,

Spoiler (click to show/hide)

void Load_GUI_Colors()
{
   //(other GUI colors removed)
    GUIcolor[2]= SDL_MapRGB( screen->format, 123, 113, 115 );
}

SDL_Surface* button1 (int x, int y, std::string name, bool state = false)
{
    SDL_Surface* button = NULL;
   SDL_Rect color;
   color.x = 2;
   color.y = 0;
   color.w = x - 2;
   color.h = 2;
   SDL_FillRect (button, &color, GUIcolor[2]);
   return button;
}

void Load_GUI()
{
    Load_GUI_Colors();
    SDL_BlitSurface( (button1(40,20,"MAPS")), NULL, screen, NULL );

}

So I'm working on a GUI for a program i'm making,
When I call Load_GUI(); the program crashes, and I'm not sure why.
tell me if you need more information.

[RulerOfNothing]

In the button1 function, button is NULL when you try to call SDL_FillRect on it. It needs to point to a valid surface first.

[Valid_Dark]

K thanks, fixed it

Changed SDL_Surface* button = NULL;

to

SDL_Surface* button = SDL_CreateRGBSurface (SDL_SWSURFACE, x , y , 32, 0,0,0,0);

[kaijyuu]

Blarg, after talking to someone about it for a while... C++11 is a pain in the ass to type. I move we start calling it C+=2

[Mego]

Blarg, after talking to someone about it for a while... C++11 is a pain in the ass to type. I move we start calling it C+=2

++