Miniphy
code - September 20th, 2006 - aymeric - 8 Comments »Miniphy is a Packet Forth words library that provides various simple math shortcuts and handy functions that can be useful to handle simple 2D vectors.
While working on “go forth & *” it became obvious to avoid as much as possible buillt-in components and prefer generic libraries that can live outside of the project itself for later use and better code structure.
At the moment miniphy is the first of those metabiosis Forth libs to have made its way out of the main project and will be kept synced with it for later fixes and improvements. Future version will in priority implement double space geometry for 2D vectors and later 3D vectors (higher dimensions are also considered but will be probably live next to the n-dimension multigrid tool instead).
Miniphy comes with simple examples that show how to use it for autonomous agents.
You can grab miniphy here: http://devel.goto10.org/
Hmm nice, should definitely make things easier fr you guys for future stuff, can you overload operators in pf (you probbly can coz pf seems uber flexible)?
for instance in c you can redefine +
so that it will work differently for specific data types.
so you could do vector+vector and it would do all the elements of vector. You can do this with structures but overloading can let you do funky stuff thats not part of the basic operations. But then again you might not be interested in this kinda stuff. Hope you dont have to do too much re-inventing the wheel libraries, dont wanna get caught with enginitis :)
p.s. hows it working out speedwise so far? screen object limit etc?
yes working with vector/matrix packets type only speeds up everything, but unfortunately there are some bottlenecks where we have to unpack vectors to do some operations, though I’m sure we could find workarounds later.
Concerning the wheel, well … Reinventing it is the beauty of Forth somehow :) Except OpenGl and Math stuff there is no libraries for what we do, even most of PF itself is written .. in PF :)
For the performances, well it’s pretty fast, but i can’t really say about what would be a screen object limit .. It really depends on what they do. But I’m already working on a simple quad tree spatial partioning system and round robin scheduler fitted for the go forth & * project.
cool!
I wrote a few adaptive quad tree systems for terrain drawing, to do level of detail stuff, got me really confused for a while:( Optimising stuff can be a pain but its worth it in the end when you can do realtime swarms! Are you using the OpenGL utility libraries? Coz im sure theres alot of useful functions in there, im not sure how much pf works with wrapper functions or if you just do OpenGl calls direct.
Yeah optimisation is really important but I’m more struggling at the moment chasing down the bottlenecks and fine tuning the event scheduler (like when to update the physics and for who…). The biggest issue with that is that implementing a round robin scheduler was good enough for everything but NOT for the collision detection. I need to do a separate one or at least implement priorities over the current scheduler.
For the rest you can’t do direct OpenGl calls from PF, this has to be implemented in the C OpenGl plugin for PF.
hmm shame the scheduler wont work for collision, why is this?
In most of my stuff(c++) i have pretty much everything checked n updated every single frame and it works fine. If your objects are travelling in small enough increments you will always catch colision, if they are moving too fast, or across longer update increments then i guess you would have to do interpolation to catch the collisions? In most games they do a 2 stage method, using a coarse grid for potential colissions followed by a more detailed check.
I think I should post an article soonish on how the whole mess is processed.
The problem I have with the collision is because computations are scheduled, when the ecosystem starts to be crowded (20+ organisms) and with a small queue (say 1 overlay check for one organism every frame), the data start to be biased. As a consequence with a round robin system like this, 2 organisms can be closed to eachother but far in term of overlay computation, which has for consequences the creation of glitches, errors and jumps instead of proper collisions checks.
ah yeah, i seee. Is it just too slow to do checks every frame for every object? i think you should be able to do this and it would make the most sense in terms of consistencey too? i can see that youre gonna get gaps coz you will be missing steps etc and the increments from one check to the next will get bigger etc. Myabe there are some other botlenecks that you could knock out to allow more frequent checks?
oh and if you wanna stop clogging up this blog lmme know and i’ll post email instead :)
At the moment if everything is updated all the time without anykind of optimisations (quad-tree, 2D physics, steering behaviours, overlay-check) I can’t put more than 20 organisms without starting to see slowdowns and high CPU usgae peaks.
Hence the scheduler… and the immediate effect on the collision detection, that’s why I want to implement some kind of priority system for overlay tests and chase down the other bottlenecks.
Spaming the blog is fine, you seem more handy with it than with email :P
But anyway, would be good to see you one day to talk about that and show you the code.