cgboard - classic games
Dosbox und deren Forks? - Druckversion

+- cgboard - classic games (https://cgboard.raysworld.ch)
+-- Forum: Oldgames - Talk (https://cgboard.raysworld.ch/forumdisplay.php?fid=57)
+--- Forum: Emulatoren, Plugins und Frontends (https://cgboard.raysworld.ch/forumdisplay.php?fid=48)
+--- Thema: Dosbox und deren Forks? (/showthread.php?tid=25898)

Seiten: 1 2 3 4

RE: Dosbox und deren Forks? - Mustrum - 26.04.2020

(26.04.2020, 08:20)Juttar schrieb: Was ist das für 1 langer Changelog in DOSBox r4337? Geschockt Ich versteh' zwar kein Wort davon, wollte es aber trotzdem mal hier erwähnt haben.

Zitat:2020-04-25 20:05  qbix79

* [r4337] acinclude.m4, include/bios.h, include/bios_disk.h,
  include/callback.h, include/control.h, include/cpu.h,
  include/cross.h, include/debug.h, include/dma.h,
  include/dos_inc.h, include/dos_system.h, include/dosbox.h,
  include/fpu.h, include/hardware.h, include/inout.h,
  include/ipx.h, include/ipxserver.h, include/joystick.h,
  include/keyboard.h, include/logging.h, include/mapper.h,
  include/mem.h, include/midi.h, include/mixer.h, include/mouse.h,
  include/paging.h, include/pci_bus.h, include/pic.h,
  include/programs.h, include/regs.h, include/render.h,
  include/serialport.h, include/setup.h, include/shell.h,
  include/support.h, include/timer.h, include/vga.h,
  include/video.h, scripts/dosbox-installer.nsi,
  src/cpu/callback.cpp, src/cpu/core_dyn_x86.cpp,
  src/cpu/core_dyn_x86/cache.h, src/cpu/core_dyn_x86/decoder.h,
  src/cpu/core_dyn_x86/dyn_fpu.h,
  src/cpu/core_dyn_x86/dyn_fpu_dh.h,
  src/cpu/core_dyn_x86/helpers.h, src/cpu/core_dyn_x86/risc_x64.h,
  src/cpu/core_dyn_x86/risc_x86.h, src/cpu/core_dyn_x86/string.h,
  src/cpu/core_dynrec.cpp, src/cpu/core_dynrec/cache.h,
  src/cpu/core_dynrec/decoder.h,
  src/cpu/core_dynrec/decoder_basic.h,
  src/cpu/core_dynrec/decoder_opcodes.h,
  src/cpu/core_dynrec/dyn_fpu.h, src/cpu/core_dynrec/operators.h,
  src/cpu/core_dynrec/risc_armv4le-common.h,
  src/cpu/core_dynrec/risc_armv4le-o3.h,
  src/cpu/core_dynrec/risc_armv4le-thumb-iw.h,
  src/cpu/core_dynrec/risc_armv4le-thumb-niw.h,
  src/cpu/core_dynrec/risc_armv4le-thumb.h,
  src/cpu/core_dynrec/risc_armv4le.h,
  src/cpu/core_dynrec/risc_armv8le.h,
  src/cpu/core_dynrec/risc_mipsel32.h,
  src/cpu/core_dynrec/risc_x64.h, src/cpu/core_dynrec/risc_x86.h,
  src/cpu/core_full.cpp, src/cpu/core_full/ea_lookup.h,
  src/cpu/core_full/load.h, src/cpu/core_full/loadwrite.h,
  src/cpu/core_full/op.h, src/cpu/core_full/optable.h,
  src/cpu/core_full/save.h, src/cpu/core_full/string.h,
  src/cpu/core_full/support.h, src/cpu/core_normal.cpp,
  src/cpu/core_normal/helpers.h, src/cpu/core_normal/prefix_0f.h,
  src/cpu/core_normal/prefix_66.h,
  src/cpu/core_normal/prefix_66_0f.h,
  src/cpu/core_normal/prefix_none.h, src/cpu/core_normal/string.h,
  src/cpu/core_normal/support.h, src/cpu/core_normal/table_ea.h,
  src/cpu/core_prefetch.cpp, src/cpu/core_simple.cpp,
  src/cpu/cpu.cpp, src/cpu/flags.cpp, src/cpu/instructions.h,
  src/cpu/lazyflags.h, src/cpu/modrm.cpp, src/cpu/modrm.h,
  src/cpu/paging.cpp, src/debug/debug.cpp, src/debug/debug_gui.cpp,
  src/debug/debug_inc.h, src/debug/debug_win32.cpp,
  src/debug/disasm_tables.h, src/dos/cdrom.cpp, src/dos/cdrom.h,
  src/dos/cdrom_aspi_win32.cpp, src/dos/cdrom_image.cpp,
  src/dos/cdrom_ioctl_linux.cpp, src/dos/cdrom_ioctl_os2.cpp,
  src/dos/cdrom_ioctl_win32.cpp, src/dos/dev_con.h,
  src/dos/dos.cpp, src/dos/dos_classes.cpp,
  src/dos/dos_devices.cpp, src/dos/dos_execute.cpp,
  src/dos/dos_files.cpp, src/dos/dos_ioctl.cpp,
  src/dos/dos_keyboard_layout.cpp, src/dos/dos_memory.cpp,
  src/dos/dos_misc.cpp, src/dos/dos_mscdex.cpp,
  src/dos/dos_programs.cpp, src/dos/dos_tables.cpp,
  src/dos/drive_cache.cpp, src/dos/drive_fat.cpp,
  src/dos/drive_iso.cpp, src/dos/drive_local.cpp,
  src/dos/drive_overlay.cpp, src/dos/drive_virtual.cpp,
  src/dos/drives.cpp, src/dos/drives.h, src/dosbox.cpp,
  src/fpu/fpu.cpp, src/fpu/fpu_instructions.h,
  src/fpu/fpu_instructions_x86.h, src/gui/dosbox_logo.h,
  src/gui/midi.cpp, src/gui/midi_alsa.h, src/gui/midi_coreaudio.h,
  src/gui/midi_oss.h, src/gui/midi_win32.h, src/gui/render.cpp,
  src/gui/render_glsl.h, src/gui/render_loops.h,
  src/gui/render_scalers.cpp, src/gui/render_scalers.h,
  src/gui/render_simple.h, src/gui/render_templates.h,
  src/gui/render_templates_hq.h, src/gui/render_templates_hq2x.h,
  src/gui/render_templates_hq3x.h, src/gui/render_templates_sai.h,
  src/gui/sdl_gui.cpp, src/gui/sdl_mapper.cpp, src/gui/sdlmain.cpp,
  src/hardware/adlib.cpp, src/hardware/adlib.h,
  src/hardware/cmos.cpp, src/hardware/dbopl.cpp,
  src/hardware/dbopl.h, src/hardware/disney.cpp,
  src/hardware/dma.cpp, src/hardware/gameblaster.cpp,
  src/hardware/gus.cpp, src/hardware/hardware.cpp,
  src/hardware/iohandler.cpp, src/hardware/ipx.cpp,
  src/hardware/ipxserver.cpp, src/hardware/joystick.cpp,
  src/hardware/keyboard.cpp, src/hardware/memory.cpp,
  src/hardware/mixer.cpp, src/hardware/mpu401.cpp,
  src/hardware/opl.cpp, src/hardware/opl.h,
  src/hardware/pci_bus.cpp, src/hardware/pci_devices.h,
  src/hardware/pcspeaker.cpp, src/hardware/pic.cpp,
  src/hardware/sblaster.cpp,
  src/hardware/serialport/directserial.cpp,
  src/hardware/serialport/directserial.h,
  src/hardware/serialport/libserial.cpp,
  src/hardware/serialport/libserial.h,
  src/hardware/serialport/misc_util.cpp,
  src/hardware/serialport/misc_util.h,
  src/hardware/serialport/nullmodem.cpp,
  src/hardware/serialport/nullmodem.h,
  src/hardware/serialport/serialdummy.cpp,
  src/hardware/serialport/serialdummy.h,
  src/hardware/serialport/serialport.cpp,
  src/hardware/serialport/softmodem.cpp,
  src/hardware/serialport/softmodem.h,
  src/hardware/tandy_sound.cpp, src/hardware/timer.cpp,
  src/hardware/vga.cpp, src/hardware/vga_attr.cpp,
  src/hardware/vga_crtc.cpp, src/hardware/vga_dac.cpp,
  src/hardware/vga_draw.cpp, src/hardware/vga_gfx.cpp,
  src/hardware/vga_memory.cpp, src/hardware/vga_misc.cpp,
  src/hardware/vga_other.cpp, src/hardware/vga_paradise.cpp,
  src/hardware/vga_s3.cpp, src/hardware/vga_seq.cpp,
  src/hardware/vga_tseng.cpp, src/hardware/vga_xga.cpp,
  src/ints/bios.cpp, src/ints/bios_disk.cpp,
  src/ints/bios_keyboard.cpp, src/ints/ems.cpp, src/ints/int10.cpp,
  src/ints/int10.h, src/ints/int10_char.cpp,
  src/ints/int10_memory.cpp, src/ints/int10_misc.cpp,
  src/ints/int10_modes.cpp, src/ints/int10_pal.cpp,
  src/ints/int10_put_pixel.cpp, src/ints/int10_vesa.cpp,
  src/ints/int10_video_state.cpp, src/ints/int10_vptable.cpp,
  src/ints/mouse.cpp, src/ints/xms.cpp, src/ints/xms.h,
  src/libs/zmbv/drvproc.cpp, src/libs/zmbv/zmbv.cpp,
  src/libs/zmbv/zmbv.h, src/libs/zmbv/zmbv_vfw.cpp,
  src/libs/zmbv/zmbv_vfw.rc, src/misc/cross.cpp,
  src/misc/messages.cpp, src/misc/programs.cpp, src/misc/setup.cpp,
  src/misc/support.cpp, src/shell/shell.cpp,
  src/shell/shell_batch.cpp, src/shell/shell_cmds.cpp,
  src/shell/shell_misc.cpp, src/winres.rc: time keeps ticking
Das ist ein Sourcecode-Tree, kein Changelog Big Grin

Keine Ahnung ob es überhaupt ein CL von der SVN-Version gibt, von wo hast du das her?
Auf https://sourceforge.net/p/dosbox/code-0/HEAD/tree/dosbox/trunk/ gibt es nur ein Changelog von Dezember 2019

RE: Dosbox und deren Forks? - Juttar - 26.04.2020

(26.04.2020, 16:17)Mustrum schrieb: Keine Ahnung ob es überhaupt ein CL von der SVN-Version gibt, von wo hast du das her?

Von hier.

RE: Dosbox und deren Forks? - Mustrum - 26.04.2020

Eigenartig, das ist lediglich eine Art Commit-Log.
https://sourceforge.net/p/dosbox/code-0/4337/

Edit 1: Ich sollte auch lessen was der Titel der Commits ist: „time keeps ticking“
Es wurde in der Revision 4337 lediglich die Jahreszahl (2020) in allen Dateien aktualisiert, also nichts wichtiges. Wink

Code:
--- a/dosbox/trunk/include/bios.h
+++ b/dosbox/trunk/include/bios.h
@@ -1,5 +1,5 @@
/*
- *  Copyright (C) 2002-2019  The DOSBox Team
+ *  Copyright (C) 2002-2020  The DOSBox Team

Edit 2: Der Changelog kommt übrigens von hier. Wink

RE: Dosbox und deren Forks? - Juttar - 26.04.2020

(26.04.2020, 17:10)Mustrum schrieb: Es wurde in der Revision 4337 lediglich die Jahreszahl (2020) in allen Dateien aktualisiert, also nichts wichtiges. Wink

Ach so. Damit bin ich jetzt im Bilde. Smile

(26.04.2020, 17:10)Mustrum schrieb: Der Changelog kommt übrigens von hier. Wink

Stimmt. Daher hatte ich den Link ursprünglich. Hatte ihn aber mittlerweile als Lesezeichen gespeichert und den Ursprung vorübergehend vergessen. Rolleyes

RE: Dosbox und deren Forks? - Traxx Amiga EP - 26.04.2020

Jedes Jahr das gleiche Spiel. Wink

RE: Dosbox und deren Forks? - Glurak - 30.04.2020

Man kann eigentlich sagen das die Original Entwickler der Dosbox das Projekt selbst mega ausbremsen.
Es gibt so viele Entwickler die gern einfach das ganze ding Modernisieren wollen würden aber nicht können.

Bin frog das Staging jetzt ihr eigenes Ding durchziehen und es denen nicht mehr interessiert was die machen. Dosbox-X order Staging. Das Original Project ist leider einfach nur noch veraltet.

Weis der Geier warum man unbedingt noch Win 9x supporten muss.

RE: Dosbox und deren Forks? - Heinrich Reich - 01.05.2020

(30.04.2020, 14:43)Glurak schrieb: [...]
Weis der Geier warum man unbedingt noch Win 9x  supporten muss.

Das finde ich ehrlich gesagt ganz gut, weil es sich hervorragend zum Gegentesten auf dem Retrorechner eignet. Allerdings ist der aktuelle Stand dafür schon ausreichend. Spielereien wie Shader-Support braucht man da nicht unbedingt Wink.

RE: Dosbox und deren Forks? - Glurak - 01.05.2020

Ich verstehe den sinn aber nicht?  99% der Dos games laufen sowieso auf win 9x systemen. Da brauch man keinen Emulator.

Es geht hier auch nicht um Shader support.

Sondern um einfach mehr Performance durch das updaten der Programmiersprache.  Dos box könnte fast 60% mehr performance haben wenn es schlicht modern wäre von seiner Sprache her.  So wie ich das auch verstanden habe will Staging genau das machen.  einfach mal auf C++11 gehen Smile  wenn man bedenkt das es mittlerweile c++20 gibt sieht man wie veraltet dosbox mit c++6 ist


Z.b. Würde es Multithread support bringen :-) bzw ermöglichen.

RE: Dosbox und deren Forks? - Heinrich Reich - 02.05.2020

Da kenne ich mich ehrlich gesagt zu wenig aus. Für einen DOS-Emulator finde ich die Performance ausreichend (sollte ohnehin mit besserem Host-System automatisch steigen).
Aber solange WinXP noch unterstützt wird, bin ich schon zufrieden WinkBig Grin (und bitte nicht so viel Redistributable-Müll Zunge raus).

RE: Dosbox und deren Forks? - Juttar - 02.05.2020

64-Bit-Unterstützung würde ich mir eventuell wünschen. Ja, der Daum-Build besitzt welche. Läuft aber leider nicht mit XP. Ansonsten bin ich mit der Geschwindigkeit auch sehr zufrieden. Bei Bleifuß Rally flitzen die Karren nur so durch die Gegend. Und das auf meinem Uralt-Ivy-Bridge-i7! Fröhlich

RE: Dosbox und deren Forks? - Cebion - 02.05.2020

Wer nutzt denn heute noch XP?

RE: Dosbox und deren Forks? - Retro-Nerd - 02.05.2020

XP eignet sich eh nicht mehr für brauchbare Emulation. Da hat sich gerade bei den Grafik- und Sound APIs soviel zum besseren getan. Windows 10 ist top für Emulation, geht für mich kein Weg dran vorbei.

RE: Dosbox und deren Forks? - Rayman - 05.05.2020

@Andi hast du dosbox-staging in der Zwischenzeit mal ausprobiert? Wie steht es um das pixel perfect feature, gibts das dort?

RE: Dosbox und deren Forks? - Andi - 06.05.2020

@Rayman: Hab ich. Vielleicht mache ich etwas falsch, aber... bei mir sieht das nicht besonders gut aus. Angeblich muss man in der Config
bei "output" "texturepp" angeben (https://github.com/dosbox-staging/dosbox-staging/pull/185/commits), aber das ändert leider kaum etwas. Zumindest ist für mich das Bild nicht annähernd so scharf. Außerdem wird auch nicht der Fenstermodus von DOSBox skaliert - unabhängig davon, was ich einstelle. Das Fenster bleibt also winzig. Hast du es etwa auch mal versucht?

Edit: Eine neue Version ist erschienen und jetzt gibt es auch ein paar weitere Informationen. "Pixel-perfect scaling mode" scheint tatsächlich nur im Vollbildmodus zu funktionieren.

Zitat:Pixel-perfect scaling mode

Pixel-perfect output scales the image by the largest integer multiplier that fits within your monitor's native resolution. For example, given a 1920x1080 monitor and a 320x200 game requiring aspect-correction, each of its pixels would be scaled by 4x5 to produce a 1280x1000 image. This preserves the original artwork without any edge blurring.

To enable pixel-perfect output, apply the following settings to the indicated [section]s of your dosbox-staging configuration file, as follows:

[sdl]
fullscreen = true
output    = texturepp

[render]
scaler  = none
glshader = none

Gibt aber immerhin einige gute Erweiterungen, wie zum Beispiel Nuked OPL: https://dosbox-staging.github.io/v0-75-0/#pp

RE: Dosbox und deren Forks? - Rayman - 07.05.2020

Also ich weiss nicht ob ich vielleicht etwas falsch mache, aber im Vergleich mit DOSBox ECE r4301 hat die ECE-Version eindeutig die Nase vorn. Hier der Vergleich.

1. dosbox-staging 0.75.0 mit aktiviertem pixel-perfect im Vollbild (ist doch verzerrt...):
[Bild: dosbox-staging_fullsctikb1.png]

EDIT: Problem wurde mit Version 0.75.1 gelöst Smile

2. DOSBox ECE r4301 pixel-perfect im Vollbild (im realen Vollbildmodus hat das Bild die gleiche Grösse, ist einfach mittig ausgerichtet) und dosbox-staging 0.75.0 im kleinen Fenster im Vordergrund, wo das korrekte Seitenverhältnis widerspiegelt wird:
[Bild: dosbox-staging_vs_dosnfj3b.png]

Es fällt auf, dass das Seitenverhältnis bei der dosbox-staging 0.75.0 im Vollbild in meinen Augen nicht mehr stimmt. Habe die empfohlenen Einstellungen so übernommen:

Code:
[sdl]
fullscreen = true
output     = texturepp

[render]
scaler   = none
glshader = none

Mfg
Rayman

RE: Dosbox und deren Forks? - Heinrich Reich - 08.05.2020

Im ersten Moment hatte ich jetzt eher den Eindruck, dass es auf dem Bild der DOSBox ECE verzerrt ist (weil Guybrush so dick aussieht Big Grin). Aber am Mond sieht man die Stauchung beim Bild der Staging gut.

RE: Dosbox und deren Forks? - Gatherer of data - 10.05.2020

Die Stauchung (Aspect Correction) ist im Normalfall ja auch korrekt. Es gibt aber Ausnahmen, das dürften zumeist Spiele sein, die in Europa entwickelt wurden.
Bez. der Lucasfilm Titel wurde das schon im ScummVM Forum diskutiert.

https://forums.scummvm.org/viewtopic.php?f=1&t=14460

Demnach sollen Kreise mit Korrektur falsch aussehen, andere Elemente nicht.


Vielleicht verstehe ich das jetzt falsch, aber so wie ich das deute, heißt Pixel Perfect bei der Staging wie beschrieben 4x5 (sehr nahe an 4:3 = Aspect Correction), bei der ECE dagegen 5x5 (keine Korrektur).

"Keine Verzerrung" bedeutet in dem Kontext das keine Faktoren wie 3,5 bei der Skalierung verwendet werden.

RE: Dosbox und deren Forks? - Glurak - 11.05.2020

Runde Objekte sind immer das beste Mittel um heraus zu finden ob die Aspect Ratio die richtige ist ^^.


Und es gibt halt spiele die da seltsam sind. Selbst auf dem SNES.

RE: Dosbox und deren Forks? - tomwatayan - 11.05.2020

Sind sie ja eben nicht, wenn unterschiedliche Designer dransaßen und der eine seine Elemente für eine 4:3-Anzeige korrigiert hat, der andere seine in einer 1:1-Pixelratio gezeichnet hat. Was wohl bei Monkey Island der Fall ist, weil das Kirchenfenster und die Kirchturmuhr besser zu einer 4:3-Ratio passen, der VGA-Mond aber besser zu einer 8:5-Ratio.

RE: Dosbox und deren Forks? - Juttar - 29.08.2020

Nach über zwei Monaten gibt es wieder ein wenig Bewegung in den Entwicklerversionen von DOSBox - von r4356 auf r4358. Gespannt bin ich auf

Zitat:[r4357] src/dos/cdrom_image.cpp: Discard buffer contents at start of CDDA playing. Prevents initial sound blips.

Bei mir fiept es nämlich bei Bleifuß etwas. Ich hoffe, das wird durch die neue SVN behoben. Ich muß allerdings noch warten, bis das Update bei meiner Download-Quelle angekommen ist. Rolleyes