Dingoo A320 performance problems

[zear]

Hey there, I'm one of the Dingoo A320 people and I would like to raise a couple of problems I met when running OpenXcom on my platform.

I know there is one Dingoo thread already, but while hanging out on the irc channel I was told I should create a new topic so I can get your attention.

The main problem the Dingoo (and a lot of other handheld platforms) face is the lack of a Floating Point Unit. The geoscape mode uses a lot of floating point calculations, so it takes a good couple of seconds for the Dingoo to refresh the geoscape view.
I think there are two solutions for that: 1) rewrite the geoscape to use fixed point math (at least optionally for nonFPU platforms), 2) highly optimize it and try to limit floating point calculations to minimum.

What about the battlescape mode? Does it also use a lot of floating point math? I recently found out that it uses 3D models for calculating the collision detection.

The other problem is gui design. I think a decent mouse emulation for platforms lacking a real mouse/touchscreen needs to be written. Also trying to limit the key shortcuts to a couple of main keys would be beneficial, as it would help controlling the game more effectively on platforms lacking a full keyboard.

I hope the developers here are interesting in supporting handheld platforms like Dingoo, GP2X, Wiz, Caanoo or the OpenPandora and are interested in improving and optimizing the engine for them.

I am not a coder myself, so I can't help much with the code, but I am willing to test every new svn update on my Dingoo and report any bugs/problems.

I am sure that handheld ports would raise interest in this project, as while on PC the main target will be people who played UFO series on their DOS machines in the 90s, the handhelds usually attract the whole new generations of players who never played the games of this series before.

[michal]

Main problem is that AFAIK SupSuper and Daiky don't have such handheld devices. It's hard to write code for something you can't test it on. It would be great if such optimizations could be made by someone who has access to device and has knowledge of coding / optimizations. Maybe you could look for such ppl on some dingoo's forums?

[SupSuper]

Well it's not a simple as that.

For one thing, I don't have the original source code, so all I can do is come up with my own solutions (or get contributors to help) that reproduce the original the best they can, even if they're not the most efficient optimized things. Maybe it's the easiest way. Maybe we don't know any better. Either way, the project is still very early so the focus is on getting stuff done. If I spent too long worrying about optimization, I still wouldn't have made it past the globe. There's not enough manpower to handle it all.

For another, the Geoscape is a prickly issue, as anyone who's worked on it by now knows. All the floating-point math is probably an issue, and getting rid of it could help, but that's not all to it. Not only does the Geoscape have to handle all the globe calculations, it also has to render it all every tick with detail/lightning/etc, as well as keeping the game timer and every single thing on the globe running as well. The day/night and ocean rendering is particularly slow, and SDL blitting can be a bit sluggish. So there's probably a lot more performance hogs in there.

I don't know about the Battlescape, though since it's all very static and turn-based (unlike the Geoscape which has to keep recalculating stuff in real-time), there shouldn't be big issues there.


In conclusion, I realize that people love portability, and the code is written to be as cross-platform as possible, it's just stuff like optimization/control-replacements/platform-tweaks aren't a priority at this stage, when the game is barely playable and the code is constantly changing. Maybe, as michal says, there are people out there who are much more knowledgeable than us and would love to just waste their time optimizing some stranger's code. I wouldn't know any though.

[Daiky]

There are fixed point math c++ libraries out there and using such a library is mostly done by replacing all occurences of "double" with "fixed" and functions like sin,cos,sqrt with fsin,fcos,fsqrt. Or whathever their fixed point counterparts are.
So it is not really rocket science to implement a fixed point library, but it's mostly a matter of priorities, like Sup said. And how to test it without the hardware, like michal said.

PS. there will be a lot of math once started with the collision detection / raytracing etc on the battlescape. I will try to take into account this issue.

[SupSuper]

Well I know X-Com took it one step further by only using integer degrees with pre-calculated sine/cosine tables. But I used the C math out of convenience (even though it uses radians and floating points), and I wouldn't know how to write all the globe formulas just with that.

To be honest my big worry isn't even replacing the math, it's finding out in the end that there's still other stuff slowing it down.