04-01-2005 new version out!

[kornalius]

New version of PPL is now available for download at: http://ppl.arwen.com

Fixes:

- SpriteAt(), SpritesAt() sprite lookup order fixed.
- List parameter passing fixed.
- Faster SO_WORLD sprite drawing/
- Benchmark.ppl rotate angle has been fixed.
- Fix setorigin functions to recalculate sprites visibility.
- Fix MoveSprite to check sprite visibility.
- Fixed CollideDir% variable.
- Changed CollisionDir% variable to be S_CollisionDir% and T_CollisionDir% variables.
- Changed CollisionX% and CollisionY% to T_CollisionX%, T_CollisionY% and S_CollisionX%, S_CollisionY%.
- And more...

New:

- Execution speed improvement of 45% in some cases. (Size of PPL.exe has grown a little, I'd rather have a bigger exe that runs faster, no?)
- AVGPPS() function to return the average Processing Per Seconds.
- SetCollisionSize() function.
- PIDE, when adding files to a project, the directory of the file is kept.
- T_CollisionAngle% and S_CollisionAngle% variables.
- And more...

[mmtbb]

[mmtbb]

[kornalius]

[mmtbb]

Arggg! I still can't get the code I sent you to work.
The spriteproc doesn't recognize WM_COLLIDE with sprites that are on the collide list. Example:

i$ = loadsprite(AppPath$ + "Good.bmp", G_RGB(0, 0, 255), 3, 0, &GoodProc);
setspriteid(i$,"good");
setspritecollide(i$,"bad,badarrow");
AddSpriteOption(i$, SO_FIXED | SO_COLLIDE);

bad$[0]=loadsprite(AppPath$ + "bad.bmp", G_RGB(0, 0, 255), 3, 0, &BadProc);
setspritedata(bad$[0], "alive");
setspritecollide(bad$[0],"good,goodarrow");
setspriteid(bad$[0],"bad");
AddSpriteOption(bad$[0], SO_COLLIDE);

Then when good and bad collide, it never triggers the WM_COLLIDE event in either GoodProc OR BadProc

[kornalius]

Did you try adding the SO_CHECKCOLLIDE? It is needed on sprites.

[mmtbb]

I guess i am confused.

I thought the checkcollide was only used in the GameProc and not the SpriteProc.

If not, it seems that checkcollide and collide are very similar. How could you have one without the other? If you are checking for a collide, the only way you will know is if you got one is if so_collide is turned on, thus firing an event? Likewise, how can so_collide fire an event unless you are checking for collisions with so_checkcollide. What is the advangtage of using one without the other?

PS. I added SO_CHECKCOLLIDE and now all collisions are being registered, even though they are not on the list. But at least this is progress.

[mmtbb]

Ok, I have made some progress. However, When I press the fire button down and hold, all is well. But if I release the fire button the WM_COLLIDE event is still fired as my heros bullet touches the hero before if moves toward the enemy. Kind of strange. The collide event shouldn't be firing because neither are on each others collide list.

[kornalius]

SO_COLLIDE will tell PPL to trigger the WM_COLLIDE event in the SpriteProc. The SO_CHECKCOLLIDE will tell PPL to do collision detection on the sprite. You can have SO_CHECKCOLLIDE without SO_COLLIDE. You don't need to fire up WM_COLLIDE for all sprites.

Send me your code and I will check it out on Monday. I might have a new version out Monday or Tuesday.

[mmtbb]

OK, I sent them to your email. Post back or reply to my email if you get my email. THanks