Re: [Pre-Announce] FastDOSBox 1.6
 

Looks promising (although, some frameskip from config file is visible on first video, I have no idea if setting were comparable). Android_808, wanna give it a shot? Someone who bought it could provide you sources only (legally, as per GPL).

/Estel

Re: [Pre-Announce] FastDOSBox 1.6
 

Re: [Pre-Announce] FastDOSBox 1.6
 

Yes, check the openrepos.

https://openrepos.net/content/alexxxlrus/dosbox
But you musht have a bluetooth keyboard on the N9!

oh and please don't use colors next time.. thanks!

Re: [Pre-Announce] FastDOSBox 1.6
 

Try using their config files before any "miracle" patches, it's pprobably the source of any major performance improvements if any.

Re: [Pre-Announce] FastDOSBox 1.6
 

The only thing that is *greatly* superior, is their handling of mouse cursor. In our dosbox builds, everything works fine, until your press somewhere close to corner of game screen (N900's screen is wide, so games leave black bars to the left and right). Or the upper/lower corner of screen.

It happens often, for example, when you try to click anything on the "border" of game view. Then, mouse goes awkard and crazy. javispedro, I went through everything that was written on TMO (mostkly by you) about touchpad->cursor handling in dosbox, and I think I understand how it works - the problem is, that even if relative cursor movement is exactly as it should (cursor follow touch point on screen perfectly), it goes apeshit and desync as soon as we touch border, on purpose or not. It seems like bug in implementation to me, rather than limitation of dos mouse handling.

Anyway, android builds handle it via some patch, that makes touchscreen behave like notebook's touchpad - cursor doesn't "jump" anywhere when you touch screen, it moves only when you move stylus/finger after touch. Clicking occur on tap (no matter where you tapped), keeping finger on screen after tap counts as holding mouse button (just like it works now for us, too).

I guess they've made it this way due to limitations of capacity screens, but it works awesomely (even betterj on our resistive screen, if used via nitdroid and android dosbox builds. I would *love* to see this mouse control scheme ported to our dosbox build, it makes all cursor problems go away. No matter what relative cursor screen game/program have hardcoded, you just get it going like you would have while playing with dosbox on notebook.

/Estel

Re: [Pre-Announce] FastDOSBox 1.6
 

As stated, 3 mouse patches are disabled in my build. they are in source archive, just uncomment lines in debian/patch/series. i disabled them as in the game i tested it caused an offset to clicks.

dosbox turbo seems to have extra config option for gpu rendering according to sites performance page. i've seen some talk about replacing drawing code on pi with gl calls. at the moment, from what i've read, it renders to texture in sdl and then displays on screen. there may be some gain in direct rendering, maybe not.

Re: [Pre-Announce] FastDOSBox 1.6
 

One of the "mouse patches" was an implementation of the PS2 "tablet" mouse protocol that MS used in their Windows for Pen Computing stuff. I used that in Win3.x for my ... "work" ... without any problems.

So no idea about the mouse going apeshit, but it certainly didn't happen with every program. Maybe those programs reactly wrongly to "out of bound" coordinates or god knows.

Re: [Pre-Announce] FastDOSBox 1.6
 

okay, gonna give a different build a try.

mh-t created a series of updated dynrec patches for arm back in march 2012. one of the main changes was support for armv7, which has been commited upstream. these do *not* feature in 0.74 or fastdosbox.

I've made a snapshot of the latest upstream version of vanilla dosbox. I'm need to rework the patches again so please be patient.

Re: [Pre-Announce] FastDOSBox 1.6
 

I know nothing about windows 3.1, but every single dos game that use mouse (and have cursor) that I've tried behave the way I've described. Darklands, plentora of C&C, Dune II, MAX1 and MAX2, Tribes, all SimCities... And dozens of other.

It *'might* not seem like that at start, but try, for a while, to do something around the very border (even the upper/lower one, where we doesn't have black stripes!). Mouse starts to wander off the clicked point pretty quickly.

No idea if it is related to your windows-oriented patches, but when you mention it, I seem to recall that it might not be the case with more ancient builds od DosBox for Maemo (I could swear I played a hell out of Darklands without such weird things, once), so might be worth trying.

Anyway, the notebook-touchpad like behavior - at least as optional thing - still seems fairy superior way of controlling any mouse-related games (I would say that it is better for windows programs too, but it's up to personal prefferences, too). If anyone would be able to adapt it from Androbuilds and make an option in dosbox.conf, it would help much.

/Estel

Re: [Pre-Announce] FastDOSBox 1.6
 

All patches done against latest commit, built on second attempt (:mad: forgot some stupid + signs).

I'm afraid as I don't know how to differentiate between arm platforms in configure.ac, so the mod I've done to the patch means it won't support armv4le. This would need to be fixed for diablo.

I've done a very basic test of asset loading for a game which seems faster, but mouse was messed up. Doing another build with some patches disabled, then I'll post both to test via dropbox.

Edit:

Back up your dosbox.conf first! It removed my config

Both with and without patches, both not working right. One mouse is to far left with them, too far above without. Try them for timedemos or whatever.

rules file needs a little work but does the job for now.

https://www.dropbox.com/sh/esrcgscp2...nGsD4o79U_6EMa