Forum Replies Created
-
Posts
-
This is all great and everything but again I reiterate, this problem only started happening for me a couple updates ago.
Therefore it has to be a regression.
I did also upgrade my phone to Android 9 a few months ago and haven’t used Magic DosBox too much since. But I’m fairly sure the choppiness began with a recent Magic DosBox update not an Android update a lot further back.
No look I’m sorry but this problem is definitely real, no more weaseling out with battery optimization and all the rest of it; didn’t help.
I’ve now encountered the same issue with Tyrian 2000, Ultima VIII and SWOS 96-97; games which never had choppiness before.
Good news though is that it’s not really a problem with the emulator becoming slower or something. The issue is only apparent when the performance is set to auto or max. When set to custom and a suitable cycle value manually, the games all play perfect. So it seems that the regression has been solely in the algorithm that decides on the appropriate amount of cycles to emulate for a given game.
I really do suggest that you take notice this time admin. What are new customers going to think when they start using Magic DosBox leaving games on default settings, and see that it runs most of them like crap?
That IS quite the tip there Al ex! Might work for a number of other emulators I have actually.
I’ll try it out later, hopefully it will help.
In the meantime I got Alien Breed to run smooth by simply changing its power setting manually, as opposed to leaving it on auto.Same problem since the update I’m afraid.
In some cases restarting helps but the choppiness comes back.Nokia 8 running Android 9. Tried with World Rally Fever and Alien Breed.
Please, fix. Magic DosBox is unplayable at the moment.
admin, just enable it.
Sure it doesn’t work well when those 8-directions are used to move the character in some tile-based game, but if those 8 directions are mapped to say a flight-sim hatswitch, or for that matter to a character’s movements in a fully 3D game; then I don’t think it would matter much.
One more quick suggestion – maybe add a mapping for joystick for the ‘neutral’ position too; that’s to say the neutral position of a joystick that it automatically returns to when you take your hand/thumb off of it. If this mapping is set to a key or action, then it is fired when the neutral position is switched back to from a non-neutral position (such as top, left, etc…).
This is useful when you want a gamepad analogue stick to emulate the functionality of a joystick’s hatswitch; as their behaviour in games are typically such that you only look in a certain direction while your thumb is pushing the hatswitch in that direction. As soon as you take your thumb off the hatswitch, the view snaps back to forward/normal.
What I’m trying to say is – just put the 8-way joystick mode back in as it was (in the beta release you gave me), without trying to fix it.
It’s no good for Eye of the Beholder but its still useful in some other games.That 6-way joystick mode looks very promising too.
Second point is hard. If I remember well, I added possibility for increasing dead zone. Having dead zone at maximum reduced this problem, however problem was not removed. I want fix that.
Yes solving the problem is hard; but that’s not what I’m asking.
The problem is that the wrong actions would be fired in the process of moving the analogue stick.
For Eye of the Beholder it was a problem, as it meant that your character would move in the wrong direction and could fall into a pit or whatever.
However when it comes to emulating something like a joystick’s hat-switch; switching views in a flight-sim – then it’s not a problem at all; momentarily looking in the wrong direction is fine as long as the correct direction is looked to afterwards; once the joystick reaches the end of its movement.And once the joystick approaches the end of its movement figuring out which of the 8 sectors its location falls under is easy.
x: 0 y: 0 is top-left (and several dozen pixels around those co-ordinates too)
x: width/2 y: 0 is top
x: width y: 0 is top-right
etc…So just reactivate the 8-way mode in the condition that it was when we gave up testing it; and add a note warning the user not to assign any of the directions to any critical actions as they can and do fire by accident.
Is something like this implemented in other emulators? Maybe I can contact author and ask. I need example.
I’ll keep my eyes peeled.
Any emulator of a console that has a directional pad, and that allows that directional pad to be mapped to an analogue stick on a bluetooth controller; is a potential candidate. So RetroArch and probably some of the Genesis/SNES/NES emulators.
What we’re really looking for, to abstract the problem a bit, is code that can convert continuous analogue motion into a small range of discrete digital inputs.
And it has to do so taking into account how people use their thumbs to move the analogue stick.Maybe look at some open source fighting games with analogue stick support? Dunno
Ok, I was thinking about point 3. It can be done in two ways. First way is harder and I will not work on that now, however second way is easy and can be done quickly. You can bind to gamebutton button special action called “modifier”. Then if is this modifier pressed, we can check other buttons for that modifier and execute another actions. But gamepad button with bounded “modifier” cannot be used for something else.
Yes this is what I was requesting exactly.
Other way allows bind to f.e A to L1. And you can do another action with L1+R1 for example. But this needs various delays for checking. This is harder for implementation and I wont work on that now. Anf these delays may be not welcome by shooters or other quick actions.
So like mapping actions to combos; also a great idea – but as you mention it sounds like a considerable amount of work. The modifier button ought to suffice for the time being.
Hey man thanks a bunch for your efforts.. looking at your .dat file, I figured it out in the end.
In my .cue file the .ogg files were defined as such:
FILE “02.ogg” OGG
TRACK 02 AUDIO
INDEX 01 00:00:00Whereas in your .dat file it was like this:
FILE “02.ogg” MP3
TRACK 02 AUDIO
INDEX 01 00:00:00So the .ogg files were defined as MP3 files in the .dat, and that was why it worked. When they are defined as OGG files, the .cue/.dat file isn’t parsed and throws an error.
Hope that helpsI havent tested it on desktop DosBox but I would assume it works based om the fact that this is the default Steam install and config for this game.
Could you link me the .cue/.dat file from the GOG version?
And what did you do to mount the image – imgmount on the .dat file?
Maybe you can post your config as well please.Update on this – I tried Nova Launcher, and it works just fine, the names stick even after restart.
I think I’ll just stick to the Nova Launcher, given that not only Magic DosBox had this problem but also DraStic, and the shortcuts I created to launch ROMs in other emulators via the xShortcut app.
