Latest DOSBOX : with PPC dynamic recompiler and stuff , right there!

@kas1e
Quad g5 mate 32bit dosbox patched frameskip 0

timedemo demo2

quake 320x200 scaler none 16.1 fps
quake 320x200 scaler normal 2x 15.2 fps

dosbox cpu 486_slow
quake 320x200 scaler none 16.2 fps
quake 320x200 scaler normal 2x 15.5 fps


i tested mdk with pentium_slow options the speed are exactly like qemu. and this is good

tested needfor speed, vrsoccer, dukenukem all are really good enjoyable.

i will check on debian PPC64 because on mate dosbox use 2 threads ... 2 cores :-O im courious there on debian

@all
Color issues were fixed! (press open in new tab for all images for full size).

Earth2140 (with x2 scaling):



The 11th hour (also with x2 scaling):



Screamer2 (with hq2x scaling):



And our Hugi diskmag from which those bugs were noticed (also x2 scaling):



Should say with PPC JIT now it looks like the whole world of new stuff. Especially that one in the middle/late of 90x, close to 2000, when on amiga big-titles almost never happens, but many of them start to happens on PC.

I will prepare new version with that and other fixes today.

@kas1e

That's very cool
Then how it was solved the problem, did they need to "hacked" sdl at the end or it was a direct fix in dosbox ?

@samo
Quote:

In end it was fixed in DOSBox, but before there was everything, and that we don't know what we talk about, and that all SDLs bad and Wii one "right", and so on. But then, we keep flood topic with all kind of info, Zukow bring some ideas, then another developer of some DOSBox fork called DOSBox-staging start to help me with that: https://github.com/dreamer/dosbox-staging/issues/144

And in end, at the same time, just in 1 hour of differences and Dreamer (who works on a fork) found how to fix it, and Jmarsh who keeps repeating that we all wrong fix it in the same manner right in the DOSBOX's repo. There still some issues left, like when you press ctrl+f5 to capture screenshot it still in wrong look, and as I aware recording of audio in the video are non-big-endian aware, but that of course not of a big deal since the main issue with video modes fixed.

@kas1e
Good job!
i dont know if is possible to hack system timer speed on Dosbox ... but if possible try to set it with different value there.

on softwindows i have have this result with a small hack
https://youtu.be/h3j-5i1GO3g?t=168

the machine will gave in console eg 10 fps on quake but in reality it will be 1800 fps...
this had make me have on G5 f1gp 2 at super great performaces
https://www.youtube.com/watch?v=fIruG7qnpfY&t=17s

@all
New version for some fast tests before it goes to os4depot:

http://kas1e.mikendezign.com/aos4/dosbox/DOSBox_r2.lha

What new:

-- alt+enter to switch window/fullscreen fixed (SDL2, (c) Capehill)
-- build with native threads instead of pthreads (SDL2, (c) Capehill)
-- added 3 unofficial types of scalers: normal4.x, normal5.x, and normal6.x: they good for those who want to make big scaling for modes such as 1920x1080, 1920x1200 and more. As our SDL2 use "compositing", we have scalers for free. So have big ones make sense as well.
-- fixed a big bug about colors being rendered wrong in 15,16 and 32 bit video modes (hugi, the 11th hour, screamer2, earth2140, tomb raider and all others which may use more than 8bit). Thanks to all people involved: jmarsh, dreamer, zukow and others
-- in default config "joysticktype" set to "auto" (so detect joystick by default). Sometime it may cause some issues in some games, so if you see some "auto pressing" then disable joystick for that game.


Plz give it a go if all still allright

Thanks!

@kas1e

Before if i remember correctly i had a fixed rate at 2.5 using PCPBench with Dynamic core

Now PCPBench give me a good 2.7 ... first time i've started, it even give me a great 2,9 ..
... however at second, third, fourth etc runs it turned out to a fixed rate of 2.7 ;-/

It means that 2.7, is probably the most realistic speed result under Sam440 .. and yes this also means that this new binary is for sure a little faster compared to the old release 1

I did a few experiment trying to change:

scaler=normal2x --> to none

Apparently there is no speed difference in PCPBench, but certain game appear a bit (but only a tiny bit) faster .. but who know, maybe is merely a placebo effect ?

No noticiable difference of speed turning from fullscreen to window and viceversa, even if by setting "none" in scaler will reduce the window mode in a sort of 320*240 window .. so scaler none is for sure a (working) lower resolution compared to normal2x, but unfortunely this doesn't influence the speed

- Iconification as usual work, just when you iconify DOSBox, the name of the icon will took the dosbox path instead of just the name of the exe (dosbox)
Don't remember if that one was already reported or not

Now that navive sdl thread work as expected, maybe for next binary you can try also to use -O3 to compile .. even a 0.001% of optimization could be nice in our slow machines

Still now testing some more

@Samo
Quote:

Those speed tests all a bit vague with JIT. For example, you can play with the "cycles" option, and you will have a much higher FPS, while visually all will be the same. For example, set cycles to 100000, and run PCPBench. Visually all will be the same, but reporting results will be higher.

Quote:

Scaler does not influence speed because it uses SDL2's compositing which gives us scalers for free without speed loss. So you can use any scaling (at least those normal2x, normla3x, etc) without speed loss.

Quote:

Only when using in runindos probably, in all other cases all fine. Need somehow to reproduce it from pure shell.

Quote:

Yep, next time will try that.

So if all works, then will upload that one today.

Works here on my X1000 :D

@328gts

Hi I also get 19.0 on pcpbench but in 320x200 mode. What is your pcpbench score at 640x400?
Thanks.

@all
Interesting that CPU usage never goes above 60% on my X1000 when running PCPBench?

@ddni
cycles=auto is the thing you need to change if you want more cpu loading. Like set cycles=100000 or 50000, you will see much better fps results in pcpbench, but visually all will be the same. Probably cycles=auto already handle all well, dunno.

What for sure is that sometime you need to change cycles to lower them or to rise for some games, but for most cases "auto" is fine

@all
Uploaded last new version to os4depot.

@kas1e Thanks! Tweaked to get more CPU load. Noticable improvement in some of those DOSbench speed tests.

What are your thoughts on an Altivec enabled build for X1000? Would it make any difference to performance?

@ddni

Is Altivec supported in OS4 port of SDL ?

@kas1e

Ogg music tracks do not work. In Hom & M II Gold from GOG, I only have MIDI sound. Under DOSBox on a PC, an opera CD is played.

Zukow says you have to do it

#define C_SDL_SOUND 1 in config.h

@mufa
Quote:

How to check if it works/not? I tried to just do that:

imgmount d hero2.cue -t iso
run heroes2.exe of a previously installed game
than in the game I just swap from midi to "cd w/o opera" music from CD start plays. Then swap to "cd with opera" nothing changes, music continues plays. The same when I do check over DOSBox on win32.

And that is the same if I compile with or without SDL_Sound.

Maybe I should somehow else check that it works/not works?

That all with original heroes2, maybe GOG's version is different somehow?

EDIT: already ported SDL_sound to SDL2 for now (in os4depot query), but need to know how to reproduce issues in dosbox without it, so to see if it will make difference (because DosBox binary will be bigger now a little, so need some reproduce that something didn't work without and work with).

@samo79

Hi Samo,
I don’t think AltiVec is in any current OS4 SDL build, however on OS4Depot it is stated that it may work in private builds... It would be interesting to explore that.

@ddni

Yep i read that in readme .. private build is a bit obscure term
Personally I will not able to try that, but if your signature is correct you have an X1000 so eventually you will be able to test ... still would be interesting to see what benefits could have a program like dosbox with Altivec enabled

@kas1e

The GOG version is copied to the HoM & M II catalog, the Music subdirectory, where there are music tracks in OGG. It also copies some other things, such as the homm2.gog file (which is actually an ISO image) and homm2.ins.

I copied the entire installation of the game from the computer to the Amiga. I changed the name homm.gog to homm.iso. I added to dosbox.conf:

imgmount d ".. \ homm2.iso" -t iso -fs iso

the game works but only supports MIDI.

Once again I analyzed the configuration of the GOG game in the PC version and found an entry there

imgmount d ".. \ homm2.ins" -t iso -fs iso

this INS file contains a list of music tracks:

BINARY "homm2.gog" FILE
TRACK 01 MODE1 / 2352
INDEX 01 00:00:00
MP3 "music \ homm2_01.ogg" FILE
AUDIO PATH 02
INDEX 01 00:00:00
MP3 "music \ homm2_02.ogg" FILE
TRACK 03 AUDIO
INDEX 01 00:00:00
"Music \ homm2_03.ogg" MP3 FILE

however, when I changed the entry on the PC, I received the message:















Changing the file extension from INS to CUE also did not help. Editing the ins Binary file "homm2.gog" to ISO, BIN associated with changing the ISO image extension did not help either.

@mufa
Found that we can't mount that "ins" file pointed on ogg files because of indeed missing support of SDL_Sound, so as i yesterday made SDL2 port of SDL_Sound, made a test version of Dosbox with it : and it can mount that "ins" file then.

Through, sound is totaly distored like wrong endianes. Probabaly because of DOSBox's "AUDIO_S16" usage, will check this out.

@all
New version to check before os4depot upload:

http://kas1e.mikendezign.com/aos4/dosbox/DOSBox_r3.lha


-- compiled with -O3 instead of -O2 (need testing if it not worse)

-- big-endian fixes for "vgaonly" driver. Now colors render correctly (c) jmarsh

-- big-endian fixes for saving screenshots via "ctrl+f5" in 15/16/32bit modes (c) dreamer & jmarsh

-- big-endian fixes for video recording via "ctrl+alt+f5" for broken sound (c) dreamer
The codec used there are ZMBV (Zip Motion Blocks Video) developed especially for DosBox as DosBox Capture Codec.
To play it on AmigaOS4 directly without conversion you may use Mplayer.
On Windows best to use LAV filters and MPC-HC as VLC has bugs in that codec, BSPlayer not very kind too.

-- replaced CD_ROM based code from the original DOSBox in favor of code from "DOSBox-staging" fork, where after a lot of testing everything was rewritten to be big-endian aware.
That gives us the ability to:
1). play music files from HDD as CDDA tracks (so things like GOG's HMM3 works).
2). play them without distortion

Check it plz, thanks!