0.6.1 released

[JumperTwo]

(01-30-2013 07:25 AM)Henrik Wrote:  I've reevaluated the plan a little and I plan to speed up the ARM JIT more (it is nowhere near complete, for example, it still interprets all FPU instruction) more before I try to implement multithreading. Speeding up the JIT will benefit all devices, both single and multi core.

The reason is that multithreading (putting the graphics on a separate thread) will make many parts of the code more complicated and harder to change, which is not a good thing when it's this early. JIT though is mostly isolated and doesn't really affect the complexity of the rest of the emulator at all.

this seems to be the right direction,you are doing a great work! speaking of speeding things up, i was looking at Math3d.h and rendering in general and i see that you are using plain C for vector multiplication,division and all the other common operations. for example :

inline float Vec3Dot(const float v1[3], const float v2[3])
{
return v1[0]*v2[0] + v1[1]*v2[1] + v1[2]*v2[2];
}

this can be optimized using NEON functions or using "basic" instrinsics like vld (load) and vst (store) to perform normal (for example) float multiplications (vmulq) etc. do you think this can speed things up? especially for the instrinsics , i'm afraid that maybe looping this : "loading a value from memory -> do something -> storing to memory " can even slow things down.it is worth a try?