I try to add some particle effects at end of game. in device it worked fine. and in simulator it crashes. i attached the screenshot regarding crash.
it says getting image failed. My Particle str path is firework.plist
in debug its shows correct path.
but i got this error Get data from file(Images/FinishEffect/particleTexture.png) failed!
why its taking wrong path
check screnshot here :- http://postimg.org/image/k97ql9z59/
My code:-
CCParticleSystem *emitter;
char particleStr[64];
sprintf(particleStr,PARTICLE_EFFECT_FINISH_GAME_SCENE);
emitter = CCParticleSystemQuad::create(particleStr);
emitter->setScale(ScreenHelper::getTextureScale());
emitter->setPosition(ccp((m_StartPos.x*PTM_RATIO+RandomInt(-100,100))*ScreenHelper::getCameraZoom(),(m_StartPos.y*PTM_RATIO+RandomInt(-50,150))*ScreenHelper::getCameraZoom())); // setting emitter position
m_ccLayer->getParent()->addChild(emitter,10); // adding the emitter
In this line crash occurs only in simulator. emitter = CCParticleSystemQuad::create(particleStr);
If you check your Firework.plist file you will notice that it has textureFileName. It tells the particle engine which texture to use for your particles. Cocos requires this to work, because it doesn't "draw" the particles itself, it rather uses the provided texture and applies color to it - that's why it generally should be white, but color textures can be used to obtain different results.
Related
I am building a simple Solar system model and trying to set textures on some spheres.
The geometry is properly generated, and I tried a couple different ways to generate the texture coordinates. At present I am relying on glu:quadric-texture for generating the coordinates when glu:sphere is called.
However, the textures never appear - objects are rendered in flat colors.
I went through several OpenGL guides and I do not think I am missing a step, but who knows.
Here is what is roughly happening:
call gl:enable :texture-2d to turn on textures
load images using cl-jpeg
call gl:bind-texture
copy data from image using gl:tex-image-2d
generate texture ids with gl:gen-textures. Also tried generating ids one by one instead of all at once, which had no effect.
during drawing create new quadric, enable texture coordinates generation and bind the texture before generating the quadric points:
(let ((q (glu:new-quadric)))
(if (planet-state-texture-id ps)
(progn (gl:enable :texture-gen-s)
(gl:enable :texture-gen-t)
(glu:quadric-texture q :true)
(gl:bind-texture :texture-2d planet-texture-id)))
(glu:quadric-texture q :false))
(glu:sphere q
planet-diameter
*sphere-resolution*
*sphere-resolution*)
I also tried a more manual method of texture coordinates generation, which had no effect.
Out of ideas here…
make-texture function
texture id generation
quadric drawing
When the program runs, I can see the textures are loaded and texture ids are reserved, it prints
loading texture from textures/2k_neptune.jpg with id 1919249769
Loaded data. Image dimensions: 1024x2048
I don't know if you've discovered a solution to your problem, but after creating a test image, and modifying some of your code, I was able to get the texture to be applied to the sphere.
The problem comes into play with the fact that you are attempting to upload textures to the GPU before you've enabled them. (gl:enable :texture-2d) has to be called before you start handling texture/image data.
I'd recommend putting the let* block with the planets-init that is in the main function after 'setup-gl', and also moving the 'format' function with the planets data to work correctly without an error coming up.
My recommendation is something like:
(let ((camera ...
...
(setup-gl ...)
(let* ((planets...
...
(format ... planet-state)
In your draw-planet function, you'll want to add (gl:bind-texture :texture-2d 0) at the end of it so that the texture isn't used for another object, like the orbital path.
As is, the (gl:color 1.0 ...) before the (gl:quadratic-texture ...) will modify the color of the rendered object, so it may not look like what you're expecting it to look like.
Edit: I should've clarified this, but as your code stands it goes
initialize-planets > make-textures > enable-textures > render
When it should be
enable-textures > init-planets > make-textures > render
You're correct about not missing a step, the steps in your code are just misordered.
I am trying to transform bones within UE4 (4.25) using UPoseableMeshComponent. (image of initial state)
However, after I transform the bones using SetBoneTransformByName, the rendering gets into some weird state, below is not motion blur, is just a pose after applied SetBoneTransformByName (image after transform blurred rendering). Although Unlit rendering seems just fine.
After I call AActor::SetActorHiddenInGame(true) to set invisible, and then AActor::SetActorHiddenInGame(false) to show the actor again, the rendering will be fixed. (Image after hide/show)
The code is purely in c++ (no BP), I first create custom Character with SkeletalMesh and added UPoseableMeshComponent in code something like in below:
void AMyCharacter::CreatePoseableMesh() {
USkeletalMeshComponent* skeletalMesh = GetMesh();
UPoseableMeshComponent* poseMesh =
NewObject<UPoseableMeshComponent>(this, UPoseableMeshComponent::StaticClass());
if (poseMesh) {
poseMesh->RegisterComponent();
poseMesh->SetWorldLocation(location);
poseMesh->SetWorldRotation(rotation);
poseMesh->AttachToComponent(GetRootComponent(),FAttachmentTransformRules::KeepRelativeTransform);
poseMesh->SetSkeletalMesh(skeletalMesh->SkeletalMesh);
poseMesh->SetVisibility(true);
skeletalMesh->SetVisibility(false);
}
}
Are there something missing to set in UPoseableMeshComponent?
I might be wrong, but I think this is because setting bone transform manually doesn't write to the velocity buffer, and temporal AA doesn't know that something moved, causing ugly blur.
If you switch to FXAA and the problem disappears - here's your hint.
There is a material node called Previous Frame Switch - you can control the velocity buffer through it using a custom parameter.
Self solved(sort of..). I tried with BP first, where even BP needs to SetVisibility(false) then SetVisibility(true) on PoseableMeshComponent to render properly. Maybe a minor bug within UE4.
TMap<FString, FTransform> const& transforms; // given. map of bone name and its transform.
poseMesh->SetVisibility(false); // PoseableMeshComponent. Hide once
for (auto& x : transforms) {
poseMesh->SetBoneTransformByName(FName(*x.Key), x.Value, EBoneSpaces::WorldSpace);
}
poseableMesh->SetVisibility(true); // show it.
seems to be the workaround for now.
Using coco2d-iphone 1.0.1, I have a continuous fire particle emitter. I would like to modify its alpha pixel format:
// Change format
[CCTexture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGBA4444];
// Make emitter
emitter = [CCParticleSystemQuad particleWithFile:file];
// Change back
[CCTexture2D setDefaultAlphaPixelFormat:kCCTexture2DPixelFormat_RGBA8888];
This doesn't work. I am well aware that RGBA4444 should make my particles look weird, but they don't look weird - so I know that RGBA4444 is not taking effect.
I suspect that it is because RGBA8888 is being applied on all newly created particles. If I remove the RGBA8888 line, it does work.
How can I make my emitter emit RGBA4444, regardless of the formats used in the rest of my game?
I don't know why, but it works if you modify CCParticleSystem.m
That file loads the particle texture like this
CCTexture2D *tex = [[CCTextureCache sharedTextureCache] addImage:textureName];
So you change the format before and after that, and it works. Not sure why didn't it work in my example above though.
I have started to create a paint program that interacts with drawing tablets. Depending on the pressure of the pen on the tablet I change the alpha value of the line being drawn. That mechanism works.
Thin lines look decent and it looks a real sketch. But since I am drawing lines between two points (like in the Qt scribble tutorial) to paint there is an alpha overlap between the line joints and it is very noticeable for thick strokes.
This is the effect with line to line conjuction:
As you can see, there is an ugly alpha blend between the line segments.
In order to solve this I decided to use a QPainterPath to render lines.
Two problems with this:
A long, continuous, thick path quickly lags the program.
Since the path is connected it acts as one, so any change to the alpha value affects the the entire path(which I don't want since I want to preserve a blending effect).
The following images use a QPainterPath.
The blend effect I want to keep.
The following image shows the 2nd problem which changes the alpha and thickness of the entire path
The red text should read: "if more pressure is added without removing the pen from the tablet surface the line thickens" (and alpha becomes opaque)
Another thing is that with this approach I can only get a blending trail from a dark to light (or thick to thin path width) but not light to dark. I am not sure why this effect occurs but my best guess is that it has to do with the line segments of the path updating as whole.
I did make the program increase/decrease alpha and line thickness based on the pressure of the pen on the tablet.
The problem is that I want to render lines without the alpha overlap and QPainterPath updates the entire path's alpha and thickness which I don't want.
This is the code that creates the path:
switch(event->type()){
case QEvent::TabletPress:
if(!onTablet){
onTablet = true;
//empty for new segment
freePainterPath();
path = new QPainterPath(event->pos());
} break;
case QEvent::TabletRelease:
if(onTablet)
onTablet = false;
break;
case QEvent::TabletMove:
if(path != NULL)
path->lineTo(event->pos());
if(onTablet){
//checks for pressure of pen on tablet to change alpha/line thickness
brushEffect(event);
QPainter painter(&pixmap);
//renders the path
paintPixmap(painter, event);
} break;
default:;
}
update();
The desired effect that I want as a single path (image created with Krita paint program):
To emulate the Krita paint program:
Keep a backup of the original target surface.
Paint with your brush onto a scratch surface that starts out completely transparent.
On that surface, your composting rule is "take maximum opacity".
Keep track of the dirty regions of that surface, and do a traditional composite of (scratch surface) onto (original target surface) and display the result. Make sure this operation doesn't damage the original target surface.
Now, you don't have to keep the entire original target surface -- just the parts you have drawn on with this tool. (A good tile based lazy-write imaging system will make this easy).
Depending on the segment size you are drawing with, you may want to interpolate between segments to make the strength of the brush be a bit less sharp. The shape of your brush may also need work. But these are independent of the transparency problem.
As for the Qt strangeness, I don't know enough Qt to tell you how to deal with the quirks of Qt's brush code. But the above "key-mask" strategy should solve your alpha overlap problem.
I do not know how to do this in Qt. Glancing at the Qt compositing modes I don't see an obvious way to say "take maximum" as the resulting alpha. Maybe something involving both color and alpha channels in some clever way.
I know this question is very old, and has an accepted answer, but in case someone else needs the answer, here it is:
You need to set the composition mode of painter to source. It draws both source and destination right now.
painter.setCompositionMode(QPainter::CompositionMode_Source);
If you want your transparent areas to show through underlying drawings, you need to set the composition mode of your result back to CompositionMode_SourceOver and draw over destination.
I don't know if you still look for an answer, but I hope this helps someone.
I have a CCSprite which gradually needs to be exhausted linearly from one end, lets say from left to right.For this purpose ,I am trying to change the textureRect property of the sprite so that the part that got exhausted from one end is 'outside' the displaying frame of the sprite.
I did this sort of thing before with a sprite that gets loaded from a spritesheet.And it worked perfectly.But I created this CCSprite using CCRenderTexture and by changing the textureRect property,the entire sprite gets disappeared.
The first image is the original CCSprite which I get from CCRenderTexture.The second image shows what I want to achieve.The black dotted rectangular portion of the Sprite needs to be omitted out.Only the blue dotted portion of the sprite needs to be displayed.Essentially,this blue dotted rectangle is my textureRect.
Is there any way how I could make my sprite reduce from one end.
Also is there any difference between a sprite created normally,and one created using CCRenderTexture.
I have done similar thing like this before using some low-level hack.
There is a work around solution if you use CCProgressTimer, that's very easy and I think it should be enough for your examples.
But you said in comment that you have some special requirements like "exhaust it from both the ends at once" then some low-level hack is needed. My solution from my last object is:
1) Get the texture image's raw data. In cocos2d you can use CCRenderTexture and in cocos2d-x you can use CCImage.
2) CCRenderTexture has a method of - (BOOL) saveToFile: (NSString *) name
format: (tCCImageFormat) format
. You can read its source code then try to save it into an 2D array instead like byte raw[1024][768]. Each element in this array represents one pixel on your picture(the type may not be byte, I'm not sure, nearly forget the details). The format MUST BE PNG since transparency will be needed.
3) Modify raw data directly, set pixel's transparency to 0x0 which you want it to disappear.
4) Re-initialize a CCRenderTexture using picture data you modified.
I can't provide the code directly since is a trade secret and core part of one of my projects. But I can share you my solution. You also need some knowledge about how PNG file works. Read:
https://en.wikipedia.org/wiki/Portable_Network_Graphics#File_header
Turns out I was making a silly mistake.While supplying values to the textureRect(CGRect),I was actually setting the textureRect.origin.y to the height of the texture which made my textureRect go beyond(above) the texture area.This explains why they were disappearing.