Jump to content

  • Log In with Google      Sign In   
  • Create Account


Should data operated by class be inside or outside it?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Waterlimon   Crossbones+   -  Reputation: 2443

Like
0Likes
Like

Posted 26 December 2012 - 10:46 AM

Hey, i have a scroller class which has a 3*3 grid, and allows me to scroll (think minecraft, loading and unloading chunks) the 3*3 grid isnt a representation of the current seen cells, i need to apply an offset on both axes to get the right cell. (otherwise there would be needless moving data to adjacent cells, when i can instead just change the offset)

It also uses a lambda to load and unload cells that enter/exit the "seen area" (cells both enter and exit at the same time because they just jump to the other side of the seen area...)

Now, what im asking is, where should this 3*3 grid be stored?

If i were to do minecraft like scrolling, and each cell would hold a chunk, it would be all inside the scroller and i would need to use the scrollers interface if i were to access those chunks elsewhere. (not sure if thats ok)

If i wanted to only have a 3*3 grid for outside access, i would either need to ask the sroller for the grid, or store the grid outside and have the scrollers grid contain only pointers.

But i think the ask-for-grid approach is ugly, and having 3*3 pointers is wasting memory if i could just as well have a single pointer to the outside 3*3 grid.

By pointer i mean something like an iterator or a reference.

wat do? Store chunks in scroller, store pointers to chunks, pass grid iterator...?

The scroller only translates relative coords to absolute, it only needs access to the grid so i can ask for a cell at a relative x,y coordinate in a single method call.

o3o


Sponsor:

#2 Goran Milovanovic   Members   -  Reputation: 1104

Like
0Likes
Like

Posted 26 December 2012 - 01:04 PM

It's really hard to understand your situation/needs/problems from the given description. I mean, why do you need an axis offset? Why is a lambda necessary? Why the need for relative coordinates?

 

If you want to load in chunks of the level, you can split world space into a grid, and then figure out your location within it. Typically, you can simply divide your world position coordinates by grid cell dimensions:

 

void getCellPos(Grid* grid, float* wpos, int* cpos){

    float* cd = grid->cell_dim;
    
    int i;
    for (i = 0; i < 3; ++i){
        cpos[i] = wpos[i] / cd[i];
    }

}

 

 

So, now that you know your location in the grid (the cell where you reside), you can figure out the stuff that should be in that cell, and the 8 surrounding cells.

 

As for how the data should be stored: A "scroller class" is fine, but I would probably call it "ChunkLoader", or something along those lines. There's really not a whole lot of data to store, because it's basically a machine to manage the loading process, for objects that have a set world position.


+---------------------------------------------------------------------+

| Game Dev video tutorials  ->   http://www.youtube.com/goranmilovano |
+---------------------------------------------------------------------+

#3 Waterlimon   Crossbones+   -  Reputation: 2443

Like
0Likes
Like

Posted 26 December 2012 - 01:49 PM

I have a 3*3 grid to contain the currently loaded chunks. To prevent moving chunk data that doesnt change in the grid, i instead maintain an x and y offset so instead of moving the data, i increment or decrement the offsets (which has the same effect as moving all the rows or columns by 1 space)

The lambda is passed to the scroller to load the chunks that now are outside the seen area (if i didnt load them i would have a 3*3 wrapping grid scroller)

The absolute position is a chunks pos in the grid, the relative is the chunks position in the seen area (actual chunk could be in middle of grid even if its a corner of the seen area)

The scroller cant be called chunkloader because the loading is done by the lambda, which is supplied from outside the scroller. The purpose of the scroller is to use a 3*3 grid for the loaded cells, but not having to move rows and columns when i scroll to a direction.

The question is, whether this 3*3 grid that contains the loaded cells should be owned by the scroller, given that the scroller itself doesnt modify the data.

Maybe i shouldnt have asked this as i have no actual problem and probably wont have in the future either... :P


Let me simplify.

Lets say we have a class, called interpreter.

It reads 1000 bytes and you can call a method, blah(x) which modifies x based on those bytes and returns the result.

Now, these 1000 bytes will be randomly cleared by the class, and a lambda has been passed to it to fill the cleared bytes with new data.

Should this 1000 bytes of storage be a part of this class, or should it be passed to it as a reference/iterator?

o3o


#4 Goran Milovanovic   Members   -  Reputation: 1104

Like
0Likes
Like

Posted 27 December 2012 - 03:17 PM

You still didn't explain why you're using a lambda.

 

In either case, the point I was trying to make: You don't need relative coordinates, or an axis offset, you just need a mask that will reveal portions of the existing world, based on your position within it.

 

Did you understand the chunk loading mechanism I described in my last post? I think it's a much better approach.

 

Should this 1000 bytes of storage be a part of this class, or should it be passed to it as a reference/iterator?

 

It depends on the context. If you want to load portions of the world in chunks, you don't really need to store anything: When the player enters a new chunk, you have to recalculate, and add/remove objects in newly visible/invisible chunks.


+---------------------------------------------------------------------+

| Game Dev video tutorials  ->   http://www.youtube.com/goranmilovano |
+---------------------------------------------------------------------+

#5 Waterlimon   Crossbones+   -  Reputation: 2443

Like
0Likes
Like

Posted 27 December 2012 - 04:03 PM

Think of the 3*3 chunks as meshes that i need to show the visible chunks.

The scroller is a class that i can tell to lets say "scroll up" and it will automatically call the lambda on the row of cells that went unvisible (and visible, since they teleport to the other side of the visible area kinda)

The lambda is there so i can add the logic to uodate the data for those cells.

The question is, should i store the actual chunks inside the scroller, or store them outside it and simply reference them.

I dont think it really matters though.

What about this:

If i DO need the chunk data outside the scroller, should i add a GetGrid() function to the scroller, or should i move the grid outside the scroller and have the scroller just reference it (so i dont need to ask for the data as i own it, not the scroller)

o3o


#6 yckx   Prime Members   -  Reputation: 1163

Like
0Likes
Like

Posted 27 December 2012 - 05:33 PM

I still don't see the necessity of a lambda, but I'd recommend taking inspiration from STL containers and iterators. You should have some kind of container for the terrain data, and request an iterator from it. The returned iterator would then hold some index into the container, but not own any of the data itself.



#7 Waterlimon   Crossbones+   -  Reputation: 2443

Like
0Likes
Like

Posted 27 December 2012 - 05:51 PM

The scroller doesnt hold map data but renderable mesh chunks.

As its a scroller, it new mesh chunks need to be created from the map data as it scrolls.

The lambda is called by the scroller on one of the chunks to load it with terrain data.

As such i can provide the loading code from outside the scroller as the scroller only knows which grid cells need loading/upating with new data (on the 3*3 grid representing the amount of mesh chunks on screen at once), not how to update them.

o3o





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS