Particle position with Monkey
- This topic has 11 replies, 2 voices, and was last updated 10 years, 6 months ago by
.
-
Posts
-
Hi,
I’ve been using TimelineFX with Monkey and have run into some issues. At the moment I only use the pre made example particles which I think look very nice. But for some reason particle positioning doesn’t always work.
Some particles, like the Shield Hit one work fine most of the time. They show up on the place where I want them to, but every time I do have that effect on screen it’s also displayed in the top left corner.
Particle position is calculated based on a virtual camera by the way.
The toon explosions don’t show up either when the virtual camera is not inside the original viewport (I mean the range of 0 to SCREEN_WIDTH and 0 to SCREEN_HEIGHT). The explosion ‘Small Dark’ does work the way it should.
Aside from some performance issues (especially in debug mode) I’m very happy with it, but I really would like to get these issues solved so particles always show up at their set location.
Any clues why some particles work whilst others don’t? Is it some setting in the particle?
Hi, I do recall this when I was testing the Monkey version but can’t remember what it was, maybe something to do with emitters that are relative, or something to do with how you’re setting the particle manager origin. I have used it with a virtual resolution and had it working fine, I just need to look at the code again.
I’m at work at the moment but will check when I get back home. Have you got a simple bit of code to replicate the issue in the meantime?
Hi,
The origin of the particle manager is the same for all emitters in my code. I’ll try to see if I can code up an example.
Sorry, I can’t seem to get a working example that demonstrates this. I could send you my current project. It’s based on Diddy by the way and I could point you to the lines of codes where you could change the effect used.
Sorry for all the double post :-(.
I’ve changed the General Settings of each particle inside the Toon Explosion effect to have Relativity checked. When it’s set to that the explosion is displayed at the right position.
I’m still having some troubles with ShieldHit. What I do now is call SetPosition on the effect just before rendering the particle. Yet ShieldHit is also shown at 0, 0. If I update its position every before every call of ParticleManager.Process() this problem is solved.
Is it possible to only have to call SetPosition on the effect just before calling DrawParticles without having these side effects? It seems like wasted CPU cycles, but I might be mistaken on how this stuff works :).
Really sorry for the spam, but I found out some more stuff. The Toon Explosion Arms wouldn’t display either. If I set the checkboxes Single and One Shot only then will the effect display. But doing so also alters the way the effect looks.
I’ve uploaded the little shootem up example that’s here on this site so you can have a look at the code and see if you’re doing anything different, link here: http://www.rigzsoft.co.uk/files/MonkeyExample.zip
It’s quite small so hopefully it’s easy to follow.
How are you adding the effects to the particle manager? Are you making sure that you copy them first? Maybe you could post a little snippet for the shield hit.
Hi, sorry for the late response.
I do copy the effects before I add the effect to a particle manager. I actually make use of a caching mechanism that stores the effect and when requested it looks up the cache and then returns it, but I always use CopyEffect (with copyDirectory set to False) when returning it.
(I’m not sure if this caching mechanism is useful. I decided to do it since I also did it with BlitzMax. Does TimelineFX does its own caching of effects?)
Checking your example you use TieToVector(), but since I’m using Diddy’s built in Vector Type I can’t do that. Aside from that I don’t see any difference in how we both use the TimelineFX library.
I also tried using TieToVector but it has the same effect as manually setting the particle position.
I’ve went through the code of WebInvaders again and I can’t find any difference in how we both use the TimelineFX library. I replaced the explosion in WebInvaders with the ones that failed for me in my project and there was no issue in displaying them.
Some peculiar thing I noticed is that with the Toon Explosion for example the particles are only shown when my camera is inside the original viewport (x:0..SCREEN_WIDTH and y:0..SCREEN_HEIGHT). When one is displayed and I move the camera it stays on the same screen position. This does not happen with Small Dark for example. The code for an explosion or shield hit are the same class, they only differ in a Select Case to load the proper effect.
I’ve got no clue as to why some effects behave as expected and some don’t. Like I mentioned earlier after altering some settings on an effect they would show up at the right position, but then the effect would also look and behave differently than the original effect.
(I wish this forum had an edit function, but oh well)
I believe I’ve more or less fixed my issue. I have to set the Relativity checkbox for every particle inside an effect now. For Stylised 1 to 4 that works fine. Toon Explosion as well, but Toon Explosion 2 won’t show up. I think I’ll stick to the Stylised ones for my project.
Glad you got it working, sorry I haven’t responded until now but I’ve been moving house and currently have no internet! It would be interesting to see if this behaviour is replicated on the blitzmax version… I’m not convinced it should work like that so will investigate, at least you have it working for now.
No worries! It’s not exactly like I’ve been quick to investigate and reply :). I can no longer test the BlitzMax version. I do have bmx installed, but haven’t used it in ages so I doubt my modules etc. will still work. Also can’t really port my game right now :P.
For the time being I can continue my project. I don’t think it should work like this either. Never had issues with the BlitzMax module before and used the same camera system for coordinate translation. Good luck investigating though, I’m curious as to why the behavior seems to differ.
You must be logged in to reply to this topic.