For GM6'ers: There are things to do after getting the editable LGM'd to gm6. There is in one part constant c_orange used. In many parts there is a constant ps_distr_invgaussian (what is its value?). You can fix this by throwing random values for the constants if you don't happen to know c_orange and that. There are luckily nothing more that'd need to be changed.
I ran into the same problems as I had run before with your camera system. It took me some time, but I managed to frame the problem into the few variables that limit the movement variables. I ignored them by doing argument0 instead of median(min,max,argument0) in those parts. And it worked. 
define c_orange 4235519
define ps_distr_invgaussian 2
in your constants
weird the invert gaussian is not in gm6
As for the camera median problem... I have no clue why GM6 would act differently... So going through all the camera scripts and removing those seems to do the job. Chances are, everyone would have his own cam anyway.
-------------------
This is freaking awesome, dude! The particles run amazingly fast (as described), they look like the ones in 2D (just that in 3D), and the engine is incredibly easy to use! 
I checked out some functions and I was surprised how well and easy you made the function controlling in 3D space. For example that the gravity works using a vector, and that the direction works with the yaw - pitch -system so to say. And if there indeed are equivalents for every single particle function, all I can say is wow. You've also commented the scripts very well, so that this could be used for anyone. I like it.
I'll surely know what to point to when someone comes asking again for how to make a 3D particle system. I'll say: you don't need to, it's been done for you, and it has been done very well. I'll most probably use this engine in my future games. And I'd rather not use anyone else's engines, that tells how good this is (and you'll be credited).
Perfection! Is there something it's missing?
It's missing the destructors, deflectors, atractors and changers... But I may add them.
Some functions like the speed and direction, I am not 100% sure if it works 100% like the original. I would not mind someone taking a second look at that. For the direction, i'm not sure the step deviation is right and the wobble though as is, it does look like it's working and should do the job fine...
Some functions have extented features like the sprite function.
I plan to add model support and add a flag to NOT TILT the sprite towards the players but keep it oriented in the orientation and movement direction specified.
Oh and I managed to find a pretty fast metod to detect if the particle is in view BTW...
Distance to cam plane = adj, point_distance_3d = hyp... arcsin and you have an angle cutoff.
p->dist = camplanedistance(p->x,p->y,p->z);
if(p->dist>0)
{
if(asin(p->dist/point_distance_3d(p->x,p->y,p->z,camx,camy,camz))>anglecutoff)
{
AddToDList(p);
DrawCount++;
}
}
p = p->PartNext;Works well enough... You can change the angle cut off if you plan to have huge stretched particles. Since the sprite is always oriented to the camera plane, worst case you set angle cut off to 0, you will never see anything appear out of nowhere while turning arround. Anything behind the cam will still be cut off. It works because, again, of the spite orientation. So I dont need to take the size of the particle into account.
With models, it's will be different though.
Reboot your system too. This is a common GM7 problem with all the dlls I have used and made. When GM starts to complain about a working dll, you basically have to reboot.
Weird, never had that. In what environment do you compile? XP or Vista?
I know GM7 does funny things to DLLs but are you sure it's not a function/memory related problem?
I have that happen quite a lot since I do a lot of dlls... Less now that I know the causes
1) If I convert a gm6 example with a dll, and forget to save as gmk before runing, I have a 30% chance of getting this error.. And I am screwed for any other gmk that use a dll.
2) If I run a gmk that uses a dll and it had an error (The game has GML error, variable does not sxist for example) and I abort (Quits without unloading the dll), the next run has increased chances of getting the error... When it does happen, I have to reboot. So, TIP, if you use a dll and you have an error, try to ignore it before quitting
3) I also have the error reported eroneously, clicking ignore and many times the dll was actually loaded and the game works fine when passed the errors.
I use dev c++ and it makes dll that have no dependencies but the last cause
4) MS compiled dlls that require undocumanted dll not everyone has one their system... That, my dlls do NOT suffer from.
I have gm7 and Vista
Edited by icuurd12b42, 07 March 2009 - 01:14 AM.
