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).
Related
I think it is impossible, but I should try.
I have a program, that is doing a physical simulation and recording frames to files. It is recording until the breakup value is not achieved, like:
int counter=0; //global variable
void SomeFunction()
{
...
if(counter == 400) //written exactly by this way, i.e. 400 is not a variable, just a number
PostQuitMessage(0);
else
MakeScreenshot();
counter++;
...
}
The problem is that I forgot to change if(counter == 400) to if(counter == 1000) and now program will be finished with 400 frames, although I need exactly 1000.
I can’t just recompile the program because calculations are very heavy and the program is already running for 2 days, I can’t wait.
It is very important for me, is there any way to change the if statement, or exactly the variable value during the program running?
The only hope I have, is, as far as I remember there was programs that could like change money/health/another stuff in games, and there user exactly could search a variable by value, and change it
Currently it is on about 200-300 frame, I have so little time to fix it.
You can use the Windows functions ReadProcessMemory and WriteProcessMemory.
But you need to determine the position of the value 400. Looking for the value in the running program can be done with the above functions. Depending on the size of the constant, it should be either a USHORT or an UINT.
So you can use the following steps:
Look for the value in a second instance
Isolate the surrounding OpCode sequence.
For example, a cmp xxx, 400
Look for this OpCode sequence in the running executable to find the unique location and replace the crucial value by 1000.
This can be called "hot-patch". It's how simple in-memory cheats do work and requires root privileges.
I downloaded Cheat engine and found address of the counter variable by its value. Through all addresses, the address I need was colored in green.
I changed the value stored at that address to 401, and now all is ok.
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.
I have an application in SDL 2.0.3 that enters relative mouse mode before entering the main game loop. In addition, function mouse_input is called in each step:
int mdltx = 0, mdlty = 0;
void mouse_input () {
auto r = SDL_GetRelativeMouseState(&mdltx, &mdlty);
if (mdltx != 0 || mdlty != 0)
cout << "(" << mdltx << "," << mdlty << ")" << endl;
// Update mouse key presses
mpul = !!(r&SDL_BUTTON(1)) | ((!!(r&SDL_BUTTON(3)))<<1);
}
According to the documentation of SDL_GetRelativeMouseState:
(...) x and y are set to the mouse deltas since the last call to SDL_GetRelativeMouseState() or since event initialization.
I've added the output lines for debugging purposes, because the resulting effect in the application was very awkward. It turns out that each time I move the mouse (and only when I move it), the console prints values in an unreasonable range. Below is a sample from doing simple mouse movements. The affected axis seems correct (moving horizontally will set mdlty to 0 and moving vertically will set mdltx to 0), but the numbers can get much higher than the screen resolution, and all of them are positive, regardless of the direction I move the mouse.
(342,216)
(47290,0)
(23696,0)
(23730,0)
(23764,0)
(23799,0)
(71190,0)
(117970,83397)
(23491,41802)
(23457,0)
(23423,83811)
(0,41871)
(23389,208322)
(23355,82847)
(0,41320)
(46812,0)
I have been looking around the web for people having the same problem, without any success.
Also note that this application was previously made for SDL 1, relying on SDL_GetMouseState and SDL_WarpMouse, but the latter function does not seem to do anything in some platforms. I'm working on the application under an Arch Linux + LXDE installation, which seems to simply ignore the mouse warp. This is the same machine where this other strange behaviour is happening.
The question is: why is this happening and how can I fix it with compatibility in mind, while keeping the advantages of having relative mouse mode? I even wonder if it could be an issue within SDL itself.
For anyone else struggling with this problem, it might help to set:
SDL_SetHintWithPriority(SDL_HINT_MOUSE_RELATIVE_MODE_WARP, "1", SDL_HINT_OVERRIDE);
SDL_SetRelativeMouseMode(SDL_TRUE);
This seems to give you relative mouse-output, where the center of the screen is (0,0).
However for me it doesn't currently reset the Cursor-coordinates properly, so while every frame resets this to (0,0), it jumps straight to the previous coord += movement.
This is a lot better than the alternative though, it seems.
The same code is working in a different machine, so this seems to be a bug. And it seems that some people found it too, with a broader range of misbehaviours than the one mentioned.
https://bugzilla.libsdl.org/show_bug.cgi?id=2150
Can this be done with SDL ?
What I mean is when you press F1 - "turn on the lights". When you press F1 for a second time - "turn off the lights", and so on.
A solution to this can be to keep a counter for the button and if it is pressed odd number of times - "turn on lights", if it is pressed even number of times - "turn off lights".
But if I have 12 buttons for different functions I don't think that's the optimal way to do it, because I will have to keep different counters for each of these 12 buttons.
Counter are not a bad idea, and I don't think that the optimal way too. If you use an int to do this, it only 4 byte per counter, so it's not that much.
But in my opinion, you can do this with a bool value, when the value is true, the button is active else, it's not. If will simplify your code too, because you will just need to implement a getter for your bool value, and you will be able to use it in your condition. On and off are binary option, because it's 0 or 1, so the bool represent that exactly.
And just for the conception of your software, you can make a class Button that contains that information and you just create an instance for each of your switches.
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.