Sequential draw commands with glVertexAttribBinding not working as expected - c++

I have a struct Vertex{glm::vec4 t,n,v;}. I have written a obj loader that takes two parameters, obj file path as string and reference to a vector of 'Vertex'es. This function populates my vector and returns the number of indices(In my case indices are just sequential numbers, anyway).
As I have 6 objects to render, after using that function 6 times I have the following
vector<Vertex> objects[6];
GLint SIZES[6],OFFSETS[6],SIZES_I[6],OFFSETS_I[6];
filled. SIZES are number of 'Vertex'es(object[i].size()) and SIZES_I are number of indices. The offsets are calculated as below
for(int i=0;i<6;i++)
{
if(i==0)
{
OFFSETS[0]=0;OFFSETS_I[0]=0;
}
else
{
OFFSETS[i]=OFFSETS[i-1]+SIZES[i-1];
OFFSETS_I[i]=OFFSETS_I[i-1]+SIZES_S[i-1];
}
}
I transferred vectors of Vertex into a single VBO all back to back. Similarly for indices, transferred into buffer bound to element array buffer. That part is shown below.
glBufferData(GL_ARRAY_BUFFER,(OFFSETS[5]+SIZES[5])*sizeof(Vertex),data,GL_STATIC_DRAW);
for(int i=0;i<6;i++)
{
glBindVertexBuffer(i,buffer[0],OFFSETS[i]*sizeof(Vertex),sizeof(Vertex));
}
glBufferData(GL_ELEMENT_ARRAY_BUFFER,(OFFSETS_I[5]+SIZES_I[5])*sizeof(GLuint),indices,GL_STATIC_DRAW);
glVertexAttribFormat(0,4,GL_FLOAT,GL_FALSE,offsetof(Vertex,v));
Now comes my problem. Of the two rendering codes shown below the first one doesn't work but the second works perfectly.
for(int i=0;i<6;i++)
{
glVertexAttribBinding(0,i);
glDrawElements(GL_TRIANGLES,SIZES_I[i],GL_UNSIGNED_INT,reinterpret_cast<void*>(OFFSETS_I[i]*sizeof(GLuint));
}
//second
glVertexAttribBinding(0,0);
for(int i=0;i<6;i++)
glDrawElementsBaseVertex(GL_TRIANGLES,SIZES_I[i],GL_UNSIGNED_INT,reinterpret_cast<void*>(OFFSETS_I[i]*sizeof(GLuint)),OFFSETS[i]);
To summarily say what I have done so u guys can understand whats going on here, in the first case i created 6 buffer bindings on the same buffer with 6 offsets. In the second case there is only one binding, but I used base vertex to offset 6 times. Btw both are compiling, so ignore any typos as I typed all this in my tab.
My first attempt at debugging: Since base vertex approach is working, obj loader is fine. Anyway to make sure of it, I just loaded a single model. Its working fine.
My second attempt at debugging: My suspicion naturally fell on binding calls and offsets. To resolve this, I removed the for loop in the first method and initialized i with 0(Since second method i.e. base vertex method works, we dont bother with it). My first model appeared on screen. Next I initialized 'i' variable with 1. My second model was displayed on screen. This I repeated till i=5. Each of my 6 models were displayed correctly. So my models were displayed individually. But when I combine my calls sequentially, I get some full models, some partial models and some not at all.
My third attempt at debugging: It seems that only last 2 models and so are displayed. Remaining are not drawn or partially drawn. So I reversed my for loop starting with i=5 and decrementing. Now first 2 models and so are displayed(Here 'first two' and 'last two' refers to the order in which models are loaded in obj reader. I did not change that). It is as if the subsequent drawing commands are somehow making the work of earlier drawing commands vanish. Sort of.
Thats it. Here I hit a dead end. Any ideas what might be wrong or how I might proceed with further debugging?

Turned out that it is due to a bug in my driver. The same code worked in my colleague's computer.

Related

Reusing FFMPEG AVFilterGraph

In my code I apply same filtering on multiple input files. In first version of code I created AVFilterGraph for every input, but I think these actions might be excessive.
However, when I try to reuse the same graph, I face with the error during sending frame to abuffer filter. At the previous iteration over input files, I passed EOF to it for flushing, and the av_buffersrc_add_frame function has a check for this:
BufferSourceContext *s = ctx->priv;
...
if (s->eof)
return AVERROR(EINVAL);
which crashes the execution on the second iteration.
Unfortunately, I couldn't find any functions that can restore buffer filter or something like that.
I would like to know if avfilter implies the possibility to reuse once created filter graph, or there are some fundamental misconceptions in my understanding of ffmpeg logic by passing input after EOF.
Thank you!

Jumping to a single frame in Node created in Cocos Studio

I have a Node named "Fruit" which contains 4 single frames for each fruit. It also contains a shadow, which should be the same for all fruits. I'm creating this node like this:
auto newFruit = CSLoader::createNode("Fruit.csb");
auto fruitAction = CSLoader::createTimeline("Fruit.csb");
newFruit->runAction(fruitAction);
Now when I'm creating this fruit I want to set a random frame:
fruitAction->gotoFrameAndPause(r + 1);
r is from 0 to 3.
However it doesn't work. It doesn't change frame at all. When I run debugging I can see correct frame number.
So I've tried different solution. I've made 4 1-frame animations named "a1", "a2", "a3" and "a4".
Then:
fruitAction->play("a" + to_str(r + 1), false);
Now I'm getting sometimes good sometimes not. Giving constant r continuously is giving me different results.
Only solution I've found is to make all animation 2-frames long (with 1 offset) so "a1": 0->1, "a2": 2->3, "a3":4->5, "a4":6->7, but this is too complicated to be worth using. Also it sometimes blinks first frame for a frame or few (so it looks very bad then).
Is it a bug or I'm doing something wrong?
After digging in cocos2d-x code it seems more troublesome than it looks.
There are 3 problems in current implementation:
1) when you won't play your animation it'll have playing property set to false so ActionTimeline::step won't even pass first if (checking if playing) and it'll never render another frame.
2) when you use gotoFrameAndPause _endFrame is never set (it's 0 by default) and because of that setCurrentFrame will always fail, because of this if:
if (frameIndex >= _startFrame && frameIndex <= _endFrame)
3) when you use "play" _startFrame and _endFrame are set between just this one particular animation and you won't be able to "jump" to frame outside it.
I've made a little workaround and put that in 3 macros:
#define CC_INIT_ACTION(__ACTION__) __ACTION__->gotoFrameAndPlay(0, __ACTION__->getDuration() + 1, 0, false); __ACTION__->pause()
#define CC_JUMP_ACTION_TO_FRAME(__ACTION__, __FRAME__) __ACTION__->setCurrentFrame(__FRAME__); __ACTION__->resume(); __ACTION__->step(0.0001f); __ACTION__->pause()
#define CC_JUMP_ACTION_TO_FRAME_BY_NAME(__ACTION__, __NAME__) int __FRAME__ = __ACTION__->getAnimationInfo(__NAME__).startIndex; CC_JUMP_ACTION_TO_FRAME(__ACTION__, __FRAME__)
CC_INIT_ACTION makes possible to jump to every frame.
CC_JUMP_ACTION_TO_FRAME jumps to particular frame number.
CC_JUMP_ACTION_TO_FRAME_BY_NAME jumps to first frame in particular animation.
Also step(0.0001f) in CC_JUMP_ACTION_TO_FRAME is necessary, because step sometimes calculates current frame wrong (maybe rounding problem, not sure).

SDL_RenderCopy() has strange behavior on Raspberry PI

This is driving me up the wall..
I've got a very simple SDL2 program.
It has a array of 3 SDL_Texture pointers.
These textures are filled as follows:
SDL_Texture *myarray[15];
SDL_Surface *surface;
for(int i=0;i<3;i++)
{
char filename[] = "X.bmp";
filename[0] = i + '0';
surface = SDL_LoadBMP(filename);
myarray[i] = SDL_CreateTextureFromSurface(myrenderer,surface);
SDL_FreeSurface(surface);
}
This works, no errors.
In the main loop (which is just a standard event loop waiting for SDL_QUIT, keystrokes and a user-event which a SDL_Timer puts in the event queue every second) I just do (for the timer triggered event):
idx = (idx+1) % 3; // idx is global var initially 0.
SDL_RenderClear(myrenderer);
SDL_RenderCopy(myrenderer, myarray[idx], NULL, NULL);
SDL_RendererPresent(myrenderer);
This works fine for 0.bmp and 1.bmp, but the 3rd image (2.bmp) simply shows as a black field.
This is structural.
If I alternate the first 2 images they are both fine.
If I alternate the 2nd and 3rd image the 3rd image doesn't show.
If I use more than 3 images then 3 and upwards show as black.
Loading order doesn't matter. It starts going wrong with the 3rd image loaded from disk.
All images are properly formatted BMP's.
I even saved 2.bmp back to disk under a different name by using SDL_SaveBMP() after it was loaded to make sure it got loaded in memory OK. The new file is bit for bit identical to the original.
This program, without modifications and the same bmp files, works fine on OSX (XCode5) and Windows (VC++ 2012 Express).
The problem only shows on the Raspberry PI.
I have placed explicit error checks on every call that can leave a result/error-code (not shown in the samples above for brevity) but all of them show "no error".
I have used the latest stable source set of www.libsdl.org and compiled as instructed (configure, make, make install, etc.).
Anybody got any idea what could be going on ?
P.S.
Keyboard input doesn't seem to work either on my PI, but I haven't delved into that yet.
Answering myself as I finally figured it out myself...
I finally went back to the README-raspberrypi.txt that came with the SDL2 sources.
I didn't read it carefully enough the first time around...
Problem 1: I'am running on a FULL-HD display. The PI's default GPU memory is 64MB which is not enough for large displays and double-buffering. As suggested in the README I increased this to 128MB and this solved the black image problem.
Problem 2: Text input wasn't working because my user-account was not in the input group. I had added the default "pi" account to the input group initially, but when I later started using another account I forgot to add that user to the group.
In short: Caught by my own (too) quick skimming of the documentation.

c++ having strange problem

I have a function that creates and insert some numbers in a vector.
if(Enemy2.dEnemy==true)
{
pt.y=4;
pt.x=90;
pt2.y=4;
pt2.x=125;
for(int i=0; i<6; i++)
{
Enemy2.vS1Enemy.push_back(pt);
Enemy2.vS2Enemy.push_back(pt2);
y-=70;
pt.y=y;
pt2.y=y;
}
Enemy2.dEnemy=false;
Enemy3.cEnemy=0;
}
It should insert 6 numbers in two vectors, the only problem is that it doesn't - it actually inserts more.
I don't think the snippet will run unless Enemy2.dEnemy == true, and it won't stay true for ever.
The first time the snippet runs, then Enemy2.dEnemy is set to false and it shouldn't run again.
I don't set Enemy2.dEnemy to true anywhere except when the window is created.
If I insert a break point any where in the snippet, the program will work fine - it will insert ONLY 6 numbers in the two vectors.
Any ideas what's wrong here?
ok so i did some debugging.
i found that Enemy2.dEnemy=false; is being skipped for some reason.
i tried to do this to see if it was.
if(Enemy2.dEnemy)
{
pt.y=4;
pt.x=90;
pt2.y=4;
pt2.x=125;
for(int i=0; i<6; i++)
{
Enemy2.vS1Enemy.push_back(pt);
Enemy2.vS2Enemy.push_back(pt2);
y-=70;
pt.y=y;
pt2.y=y;
}
TCHAR s[244];
Enemy2.dEnemy=false;
if(Enemy2.dEnemy)
{
MessageBox(hWnd, _T("0"), _T(""), MB_OK);
}
else
{
MessageBox(hWnd, _T("1"), _T(""), MB_OK);
}
Enemy3.cEnemy=0;
}
well the message box popped saying 1 and my code worked fine. it seems that Enemy2.dEnemy=false; doesn't have time to run ;/
blahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah!
ok i found where is the real problem which was causing to insert more than 6 numbers..
it was where i was asigning Enemy2.dEnemy=true;
if(Enemy2.e1)
{
Enemy2.now=time(NULL);
Enemy2.tEnemy=Enemy2.now+4;
Enemy2.e1=false;
}
if(Enemy2.tEnemy==time(NULL))
{
check=1;
Enemy2.aEnemy=0;
Enemy2.dEnemy=true;
}
the problem seems that the second if runs more than one time, which is weird!
First things first: get rid of that abominable if (Enemy2.dEnemy == true) - it should be:
if (Enemy2.dEnemy)
(I also prefer to name my booleans as a readable sentence segments like Enemy2.isABerserker or Enemy3.hasHadLeftLegCutOffThreeInchesBelowTheKnee but that's just personal preference).
Other than that, the only thing I can suggest is a threading problem. There's nothing wrong with that code per se, but there is a window in which two threads could enter the if statement and both start pushing values into your vector.
In other words, if thread 1 is doing the pushing when thread 2 encounters the if statement, thread 2 will also start pushing values, since thread 1 has yet to set dEnemy to true. And don't think you can just move the assignment to the top of the if block - that will reduce but not remove the window.
My advice is to print out the contents of the vectors in the situation where they have more than six entries and that may give a clue as to what's happened (post the output here if you wish).
Re your update that the second if below is running twice:
if(Enemy2.e1)
{
Enemy2.now=time(NULL);
Enemy2.tEnemy=Enemy2.now+4;
Enemy2.e1=false;
}
if(Enemy2.tEnemy==time(NULL))
{
check=1;
Enemy2.aEnemy=0;
Enemy2.dEnemy=true;
}
If this code is executed twice in the same second (and that's not beyond the bounds of possibility), the second if statement will run twice.
That's because time(NULL) give you the number of seconds since the epoch so, until that second is over, you may well be executing the contents of that if thousands of times (or more).
If this problem disappears when you put in a breakpoint or a diagnostic output message, that's a strong clue that the problem is undefined behavior, which is usually caused by something like dereferencing an uninitialized pointer or careless use of const_cast.
The cause of the problem probably has nothing to do with the code you're looking at. It's caused somewhere else and just happens to show up here. It's like someone being hit by a falling brick: the obvious symptom is a man lying unconscious on the sidewalk, but the real problem has nothing to do with the man or the sidewalk, it's several stories up.
If you want to find the cause of the error, remove your diagnostics until the problem reappears, then start removing everything else. Prune away all of the other code. Whenever the error stops, back up until it starts again; if you don't see the cause of the error, start pruning somewhere else. Eventually the bug will have nowhere to hide.

Recursively created linked lists with a class, C++

I'm using C++ to recursively make a hexagonal grid (using a multiply linked list style). I've got it set up to create neighboring tiles easily, but because I'm doing it recursively, I can only really create all 6 neighbors for a given tile. Obviously, this is causing duplicate tiles to be created and I'm trying to get rid of them in some way. Because I'm using a class, checking for null pointers doesn't seem to work. It's either failing to convert from my Tile class to and int, or somehow converting it but not doing it properly. I'm explicitly setting all pointers to NULL upon creation, and when I check to see if it still is, it says it's not even though I never touched it since initialization. Is there a specific way I'm supposed to do this? I can't even traverse the grid without NULLs of some kind
Here's some of my relevant code. Yes, I know it's embarassing.
Tile class header:
class Tile
{
public:
Tile(void);
Tile(char *Filename);
~Tile(void);
void show(void);
bool LoadGLTextures();
void makeDisplayList();
void BindTexture();
void setFilename(char *newName);
char Filename[100];
GLuint texture[2];
GLuint displayList;
Tile *neighbor[6];
float xPos, yPos,zPos;
};`
Tile Initialization:
Tile::Tile(void)
{
xPos=0.0f;
yPos=0.0f;
zPos=0.0f;
glEnable(GL_DEPTH_TEST);
strcpy(Filename, strcpy(Filename, "Data/BlueTile.bmp"));
if(!BuildTexture(Filename, texture[0]))
MessageBox(NULL,"Texture failed to load!","Crap!",MB_OK|MB_ICONASTERISK);
for(int x=0;x<6;x++)
{
neighbor[x]=NULL;
}
}
Creation of neighboring tiles:
void MakeNeighbors(Tile *InputTile, int stacks)
{
for(int x=0;x<6;x++)
{
InputTile->neighbor[x]=new Tile();
InputTile->neighbor[x]->xPos=0.0f;
InputTile->neighbor[x]->yPos=0.0f;
InputTile->zPos=float(stacks);
}
if(stacks)
{
for(int x=0;x<6;x++)
MakeNeighbors(InputTile->neighbor[x],stacks-1);
}
}
And finally, traversing the grid:
void TraverseGrid(Tile *inputTile)
{
Tile *temp;
for(int x=0;x<6;x++)
if(inputTile->neighbor[x])
{
temp=inputTile->neighbor[x];
temp->xPos=0.0f;
TraverseGrid(temp);
//MessageBox(NULL,"Not Null!","SHUTDOWN ERROR",MB_OK | MB_ICONINFORMATION);
}
}
The key line is "if(inputTile->neighbor[x])" and whether I make it "if(inputTile->neighbor[x]==NULL)" or whatever I do, it just isn't handling it properly. Oh and I'm also aware that I haven't set up the list fully. It's only one direction now.
If you want to create a hexagonal grid you should remember that it easily can be simulated using a normal grid!
__ __ __
\__/2 \__/4 \__/6 \
/1 \__/3 \__/5 \__/
\__/8 \__/10\__/12\
/7 \__/9 \__/11\__/
\__/ \__/ \__/ \
This will make life MUCH simpler :)
Hence the easiest way would be
set up a temporary square grid m*n
fill it with tiles
traverse the grid and connect properly
Now the connections, based on the diagram above:
A) Connect to previous and next [x-1,y], [x+1,y]
B) Connect to row above and row below [x,y-1], [x,y+1]
C) Connect to row above previous and next [x-1,y-1], [x+1,y-1]
... and you have all desired connections (just remember to check bounds to decide if the tile isn't on the edge) -- if you hold the tiles in another way, you can even remove the grid :).
I'm only guessing at what MakeNeighbors() does, but instead of blindly doing InputTile->neighbor[x]=new Tile();, you could check to see if neighbor[x] is non-NULL before creating a new one and initializing it. E.g. if its parent creates it and sets all of its neighbor information, then it shouldn't go and create its parent.
When the parent creates the children, it should also define the children's other neighbors appropriately, as far as it knows them. So, it should make sure that child[i] also is neighbors with child[i-1] and child[i+1].
Creation. Recursion is a neat and elegant way to solve some problems, but it isn't perfect for every problem. I suspect that a purely recursive solution to creating the nodes would be much more complicated (i.e. less elegant) than Kornel Kisielewicz's straightforward iterative solution. That's because the Tile constructor needs to know the layout of all tiles in its immediate vicinity, in order to avoid recreating nodes that are already there.
Traversal. The main problem in your node-traversal code is similar in that you will wind up with an infinite loop and blow the stack because every node will eventually "traverse" back to its parent, beginning the cycle again. I presume you're trying to visit every tile exactly once, right? In that case TraverseGrid() needs to have a parameter telling it which direction we are entering the node from, so that we avoid traversing back that way.
But that's not enough -- you also need more discipline in deciding which directions to go. Simply spreading out in all directions except the direction we entered from will still wind up in an infinite loop and stack overflow, since any three adjacent tiles will cycle endlessly. In order to do this recursively you need to really think about which strategies will wind up visiting each node once and only once.
One possibility would be changing the signature of TraverseGrid() to TraverseGrid(Tile *inputTile, int fromDir, bool leftmost) and then using the following rules:
If we entered from above-left, traverse only to above-right, passing leftmost = false.
If we entered from below-left or above-right, traverse only to below-right, passing leftmost = false.
If leftmost, and there is a node to our lower left, then also traverse to that node, passing leftmost = true.
Of course fromDir and leftmost could be combined into a single parameter, but this gives the general idea.
Another alternative would be keeping a visited flag in each tile which is checked before traversing to that tile. Then your traversal will be a flood fill. But again, a simple iterative traversal is likely to be much simpler and easier to understand, and has the additional benefit of using constant stack space.
In the class declaration there is a second constructor Tile(char *Filename);. Maybe this constructor is used to create the main node, but doesn't initialize neighbor properly? (Its implementation isn't shown.)
And on an unrelated node, you have a duplicate strcpy() in the constructor that doesn't serves any purpose and might only lead to problems:
strcpy(Filename, strcpy(Filename, "Data/BlueTile.bmp"));
I actually did the same thing but my pattern was more like this:
00 01 02 03 04
10 11 12 13 14
20 21 22 23 24
30 31 32 33 34
This makes it pretty easy to figure out what can be reached, but forces a strange offset pattern. I just got rid of (in the above example) 00,01,10 and 20 to make it more of a hex pattern like this:
02 03 04 05 06
11 12 13 14 15
21 22 23 24 25
30 31 32 33 34
So if you look at the pattern above, reachable is always the same:
from 23 (call 2 "a" and 3 "b") you can get to:
NW(a-1, b), NE(a-1, b+1), W(a, b-1), E(a, b+1), SW(a+1, b-1), SE(a+1,b)
This pattern should hold correct for the entire grid.
EDIT:
I was going to do this in a comment but it got too long. I can see two approaches.
1) Allocate the array of nodes (null, don't allocate them). Whenever you need to allocate a node, just do so, but use the array address whenever you need to reference a node, if it's null populate it, if it has a value use that value. Huge empty arrays shouldn't take up that much memory, but if they do...
2) Create a HashSet to hold your nodes where the Hash value of the node class is calculated like this: (a << 32 || b). In this way you can instantly look up to see if a previous node existed or not. Remember to overload "equals" as well (it should return true only if the compared object is the same type and a and b are equal).
In a mostly populated system where bounds are known, 1 will save memory, but if your system is sparse (as you claim) then #2 could save a LOT of memory with no cost to efficiency.