Notices

THANK YOU, this is definetly faster even with same config files than the dosbox in repo or fastdosbox, i tried without mouse patch version.
When i start it from terminal, it does complain/shows some things... See attachment.

tried shareware version of doom -timedemo last night. takes a while to load splash screen, even longer to actually start demo and runs quite poorly. however interupting and starting a game it actually runs really well.

there is one option set via arm-target patch to enable unaligned memory. i enabled it based on m-ht advice for pandora (http://boards.openpandora.org/topic/...dynrec-update/). might be worth a build without to compare it.

I got the same errors when using Maemo's repo DosBox - it is related to (somehow) unability to use installed timidity as MIDI seq device (cause, obviously, there is *no* such device created by Maemo's timidity).

I tried to ask timidity maintainer, Peli, but he was as baffled as myself about the issue. BTW, I'm certain that it *wasn't* the case in the past, and I don't know what I did to spawn this error (and why dosbox started trying to use non-existing device, at all).

/Estel

Some NEON optimizations could perhaps help?

DOSBox uses libSDL, and Notaz has written an SDL library that has some NEON optimizations for the blitting functions that is supposed to provide some speedup on the armv7 processor... however, it isn't working on n900.

thread:
http://talk.maemo.org/showthread.php?t=93201

I have updated the dosbox link so contain a few versions based on the latest version in the repos. One has the same mouse patches disabled as my svn build, the other has a further patch related to vertical mouse scaling removed.

Additionally, I have found an old extras-devel version with all mouse patches but vertical_scaling enabled. Hopefully this lot will help track down the culprits.
http://maemo.org/packages/package_in.../0.74-0maemo5/

Can you compile this for Harmattan too?

If I get time. I currently don't have a harmattan environment set up.

Android, I tried to PMyou, but the forum is set-up in such incredibly stupid way, that I would need to spam 10 posts outside of off-topic section, to actually be able to send PMs, which I'm not willing/have time to do. Someone must have spend interesting 5 seconds inventing that "feature"...

Anyway, I have tested your latest +svn version of dosbox with all mouse patches, and it works much faster by a HUGE amount than our standard dosbox repo, at the same settings, using the same config files etc. The improvement is obvious, non-negilible, and to be honest, quite stunning. No adverse effects observed, so I recommend sending it to extras-devel as new version of official Maemo's dosbox ASAP.

BTW, for everyone wanting to test dosbox on Maemo - never, *ever* use and "auto" for cpu cycles setting, no matter if in the repo one, or Android's compilation. It is completely broken for Maemo due to reasons unknown, and all games/programs I have tested so far (ones that work fine with auto settings on desktops, and doesn't require fixed cycles or whatsnot) are working much worse with "auto". Cycles are set to some absurdly high value, that N900 isn't able to handle. It is recommended to set cycles manually (but not "fixed" if not necessary!) in config file, thus.

BTW, settings that seems to work best (for +svn build) in 900 mhz overclocked device, are exactly 5500 cycles (both 5600 and 5400 cycles gives a slight reduction in performance). Using Android's build and such cycle settings + 1 frame skip (negligible re quality, but huge boost for performance), you're able to play things like Superfrog with advmame2x scaler without slightest slowdowns, and unplayable things (like M.A.X or Conquer of the New World) become playable. Haven't tested System Shock yet, doesn't expect playability, but for sure it's going to work better than Maemo's repos build.

your favorite dosbox build requester, from the other side, with love.

did you experience any issue with mouse though? such as offset

Sorry, forget to write about it.

I have tested all versions, with all comboinations of mouse patches. No regressions in your +svn compilation, it works exactly like Maemo repo version for dos games (haven't tested windows in dosbox or other controversial fancy things. No offset, but mouse goes off-seted crazy if clicking at the border, either left/right or upper/lower.

As for other versions, it works exactly the same with or without vertical patch, or without any patches, at all. No idea what causes this border issue, I could swear that it wasn't the case for Maemo's dosbox, once.

Just to be sure:
We have some relatively recent patches that allowed right clicking or mouse hovering. Also, we have much older patches by javispedro, that added some windoze tablet mouse patches.

The thing that you disabled *included* the javispedro's patches *and* the mouse clicking ones, yep? If yes, none of them is the patch to blame for border-craziness, as it happens without them.

I'm starting to wonder if maybe, some Maemo's general (CSSU?) thing started affecting dosbox mouse behavior? I have yet to see a game that *doesn't exhibit the problem, and in old times, I was playing things like darklands without such issues.

Side note: keep in mind that contents of those posts (and whole account) may dissapear without any traces and warning, thanks to wannabe maemo gods. In theory, one touch ban&clean shouldn't be, ever, applied to non-spambots, but I have seen it used in practice against real peoples, all too often.