I played it for a few minutes (...) then I used some key combination to quit the game (start+select mostly) and got thrown back to gmenu2x, now I tried using the video player and it was not working properly, (...)
This is the same old bug that already affected the demo 'code alone' : apps running after suffer slowdown or random behaviour.
It was already reported during the beta test, that's why I added the stop940 program, that's supposed to halt the 940.
Apaprently it's not working, or it's not enought to stop the 940.
I will have to seriously look after this bug. If someone has a hint, please help me because I've none for now.
Edit : just read your edit. Mplayer and neogeo emu might be two different bugs : mplayer is probably affected by the 940 settings (although I don't know what setting I changed, perhaps the interrupt vector ? Yes, perhaps), while neogeo, if it's not using the 940, might be affected by the video settings (gpu940 uses YUV with an OSD, and I let gp2xmenu to reset the video mode, but perhaps it's not reseting everything ?)
down the street, where there live some poors...
It would be nice to see it optimized enough that it required little over-clocking...
Yes. I will probably try to lower the impact of the opengl lib on the 920, so that the 920 (at least) could stay a 200MHz (or lower).
There is a huge amount of unnecessary work on the 920 : convertion between float and fixed values, glBegin/End surplus of work...
it seems like the viewable area of the game is larger than the actual screen is, but only by a little bit. I noticed that the adventurer seems to spawn just to the left of where you can see.
It's right, I had to scale down many things (texts, overlays, etc). Camera positionning was tricky so I left it mostly untouched.
Another instance of the same bug is that when you are close from the level border, the camera stops following your character.
Yet, it should no be hard to have the camera farther away from the characters at start. Will probably change it.
