ZGameEditor forum

Hi BeRo , wow , you've made some real interesting stuff about using your BeRoAudioOGGVorbisTremor in android , do you think (fpc trunk ) can optimize your library better, especially they add alot of improvment for ARM target ? "They" are mostly two workmates of me at my reallife job at Vi...

Kjell, that is a good suggestion. Only I'm not sure that ZGE scripting is fast enough to generate samples in the speed that the audio thread requires. So SampleExpressions might not be possible that way, at least not on mobile. Meanwhile, I made some small changes in ZGE to make sample loading fast...

Ville: Can you implement on-the-fly-decoding-while-playing for bigger .OGG's also? You can find example source for it in my mail from the last month. Because bigger .OGG's (for background music and so on) are no longer a load-time-performance issue then. And for mobile devices with slower CPUs, you ...

Code to convert a 4x4 transform matrix to position+euler rotation in PAPPE: Position:=Vector3TermMatrixMul(Vector3Origin,PhysicsObject.Transform); // or simply: Position:=PhysicsObject.Position; EulerRotation:=Matrix4x4Euler(PhysicsObject.Transform); Code to convert position+euler rotation to a 4x4 ...

One of my questions concerning physicalized models would be what PAPPE does when you overwrite the transformation matrix. Does it use separate values for velocity, or is it position / cache based? Which would probably mean that as soon as you input a new position, the collision check would use a tr...

humm,. not sure about the Transformation-Matrix vs separate vectors stuff,. is a transformation-matrix more efficient,. perhaps ZGE should adopt this? major rewrite issues aside,. just an intelectual question on speed and engine architecture out of curiosity. Also I'm thinking this. But only the pr...

I'll write new physics demos (for to demonstrate joints, constraints etc.) on this weekend probably.

Edit: http://bero.freqvibez.net/PhysicsDemo4.exe A small parameterunfinetuned rigid body constraint demo (is also on the SVN with source code). I'll write a rigid body joint demo later.

Luckily Mesh VS Mesh collisions are only needed under very few circumstances. Ray VS Mesh or Bounding Volume VS Mesh are more then sufficient in most situations, and a much smaller performance hit. Yes, right. By the way, ZGE features a Collision Group system enabling developers to limit the object...

My physics engine is called PAPPE and not POPPE :) The collision detection is advanced, therefore it has also trimesh vs. trimesh coillision routines, but which should be as possible avoided (if big meshes or very many meshes), and use as possible only Bounding Sphere / Bounding Box collisions. And ...

Hi BeRo! your physics is quite advanced and would make a great addition to ZGE, I can see some great physics based gameplay coming out of that! Yes, the base functions of the physics engine works already pretty very well, only the ragdoll object joint routines are a bit buggy yet, but this should b...

kattle87 wrote:Welcome I hope you will find ZGE interesting, because with your help/suggestions I think we can do quite a lot of things

Yes, I think also so.

kattle87 wrote:BTW: what do you mean exactly with "My primary demogroup: farbrausch"? Are you part of the crew???

Yes, I'm farbrausch member

So, here I am :D I've updated https://sourceforge.net/projects/pappe/ with my current local PAPPE sources and examples. I would spend my exe packer, but my exe packer has a problem: It is detected by the most antivirus software as false-positive. I'm working currerntly on a MIDI-driven 64kb softsynt...