Beiträge von BeRo

Das Problem zumindest bei SDL 1.2.x ist unter anderem dass der ganze OpenGL Kram in gleichem Thread ablaufen muss wie das gesamte UI-Handling und das Abfragen der Eingabegeräte. Also wenn der Grafiktreiber selbst beim bloßen Verarbeiten der OpenGL Commands beim FrameFlush den Programmablauf zu sehr lange blockt, kann es dann näturlich mal zu Soundaussetzern kommen.

Zitat von Retro-Nerd

Ah, die Swap Funktionen. Macht Sinn.

Zu der Input Lag Geschichte: So richtig kann ich da noch keinen Unterschied zwischen Whole/Half/Quarter Frames feststellen, aber da bist du ja noch dran.

Also das Doublebuffering muss dann auch ausgeschaltet werden und sowie evtl. auch VSync, je nach wie der jeweilige Grafiktreiber das VSync handhabt.

Bei WholeFrames werden die Eingabegeräte jede 20ms (50Hz) abgefragt, bei HalfFrames werden die Eingabegeräte jede 10ms (100Hz) abgefragt, und bei QuarterFrames werden die Eingabegeräte jede 5ms (200Hz) abgefragt.

Also wenn das VSync des Grafiktreibers jedoch den Programmablauf solange immer bis zum nächsten VSync blockt und dann erst das neue Frame darstellt, dann werden die Eingabegeräte trotzdem weiterhin immer fast nahezu nur jede 20ms (50Hz) abgefragt, da die Zeitpunktprüfbedingungen für die 5ms, 10ms, 15ms Zeitrastereinteilungen dann meist nahezu nie eintreffen, sondern VSync-bedingt dann fast nahezu immer nur die 20ms Intervalzeitpunktprüfbedingung.

Build 712 ist online. Changelog:

Denn ein paar evtl. wichtige Einstellungen dazu hatte ich bisher vergessen mit einzubauen.

Build 711 ist online. Changelog:

Zitat von Retro-Nerd

Irgendwas stimmt mit der Joystick Erkennung seit einiges Betas nicht. Das ist mir erst gestern nacht aufgefallen. Als Test mal Hawkeye von Lurid & Tricycle ausprobieren. Da kann man im Spiel per F-Tasten die Waffen auswählen. Sobald ich einmal per Joybutton schiesse springt man IMMER zu ersten Standardwaffe zurück. Sofern ich die entsprechende F-Taste gedrückt halte behalte ich auch die gewählte Waffe.

Auch kann man im Spiel die Waffen noch per gedrücktem Feuerbutton und links-rechts Bewegungen auswählen, dass funktioniert auch nicht so richtig.

Zitat von Tracker5423

Bei Prince Of Persia (Cartridge) habe ich ein ähnliches Problem wenn ich nach links gehen will startet der das level neu! bei älteren builds ist das nicht so zum Beispiel bei Build 694! Vermutlich hängt es damit zusammen:

Ja, ich bin schon längst am fixen und sowie am implementieren eines Joystickeinstellungsmenü

Zitat von internium

[offtopic]Volllast sollten die Kisten schon mehrere Stunden abkönnen, da man manchmal halt einfach auch die Leistung für was brauch. i7 und zwei GPU ist natürlich eine Königsdisziplin für ein Kühlsystem auf engsten Raume[/offtopic]

[offtopic]Naja mein derzeitiges Hauptnotebook ist halt so ein 17 Zoll Desktop Replacement Notebook von Dell (Dell XPS 17 L702X), wie gesagt mit einer Intel i7 Quadcore CPU, Intel HD3000 iGPU in der i7 CPU und NVIDIA Geforce GT555M 3GB GPUs zwei SATA Platten (eine 500GB HDD und eine 120GB SSD), 16GB DDR3-1333 RAM, 2x USB3.0, 2x USB 2.0, 1x eSATA, 1x HDMI, 1x DisplayPort etc. Zudem kommt bei diesem Notebookmodell noch ein undokumentiertes Feature hinzu, dass das interne Display, der HDMI Port und der DisplayPort dank den zwei GPUs alle drei gleichzeitig angesteuert werden können, sprich ich habe hier mit dem Notebook ein 1600x900 @ internes 17 Zoll Display + 1920x1200 @ externer 24 Zoll TFT + 1920x1080 @ externer 24 Zoll TFT DreiMonitorSystem aufgebaut, was näturlich auch die beiden GPUs wieder mehr belastet als gewöhnlich, sprich die Intel HD3000 iGPU in der i7 CPU und sowie die zusätzliche extra dedizierte NVIDIA Geforce GT555M 3GB GPU. Da kann dann näturlich was recht schnell sehr warm bzw. heiß werden.[/offtopic]

Build 710 ist online. Changelog:

Zitat von angryking

Hm, das dürfte aber nicht passieren. Eine CPU sollte auch unter Vollast nie so heiss werden.
Damit das nicht passiert, reinige ich öfters mal das Innenleben meiner Geräte.
Ebenso verzichte ich auf Overclocking, im Gegenteil, ich untervolte meine Geräte. Der Laptop läuft anstatt mit 1.25V nur mit 1.0V, und das absolut stabil. Die Temperatur sinkt dadurch erheblich.

Ok, ganz schön Offtopic jetzt.

Ich overrclocke auch nicht, und es ist trotzdem bei mir passiert, da ein Kühlsystem bei einem Notebook mit viel Hardware auf engster Raum (flotte Intek i7-CPU, zwei GPUs, gleich zwei HDDs, 16GB RAM, etc.) wohl irgendwo auch früher seine Grenzen hat als bei einem Desktoprechner, speziell an heißen Tagen. Sprich bei mir hat wohl die NVIDIA GT555M GPU die i7 CPU mit aufheizt, da durch den Bug im SleepTimer plötzlich echte 500 bis 720 FPS VSync-freie Frames (keine virtuellen wie beim Warpmode) rausgehauen wurde, wodurch die GPU heiß wurde und die CPU gleich direkt mit, da die i7-CPU quasi fast direkt neben der NVIDIA GPU sitzt. Und das HDD-SMART-Monitoring-Tool hat dann auch Alarm gemeldet, dass eine HDD von den zwei HDDs im Notebook zu schnell zu warm wurde, wohl auch durch die GPU.

Zitat von nrww

Läuft Dein Emulator auf Windows 7 ja oder?

Ja näturlich, warum denn auch nicht? Ich arbeite an Micro64 ja auch primär unter einer 64-bit Windows 7 Installation.

Build 709 ist online. Changelog:

Das ist ein sehr wichtiger Bugfix Denn der Bug in Micro64 hatte es geschafft, als Micro64 im Menümodus war, jetzt eben heute um ca. 08:20 Uhr die Zwangsabschaltung meines Notebook bzw. des Intel i7-Prozessors auszulösen, da der SleepTimer mit der Änderung im Build 708 im Menümodus nicht mehr korrekt funktionierte, wodurch die CPU Last auf 100% anstieg, und somit die CPU Temperatur überraschend sehr schnell (laut SiW, System Information for Windows, in der Sensors Anzeige) von den normalen 52° Grad Celsius auf weit über 100° Grad Celsius anstieg, und somit auch erstaunlich schnell nach wenigen Sekunden, nachdem ich das MIcro64 Menü geöffnet hatte, irgendwann das System zwangsabgeschaltet wurde.

Zitat von internium

Nutzt du eigentlich 1.2 oder 2.0 der SDL?

Für die Releasebinaries noch SDL 1.2.x, da SDL 1.3/2.0 von der API her und sowie selbst noch unstable ist. Aber der gesamte Micro64 Code ist bereits auch für SDL 1.3/2.0 kompilierbar.

Zitat von internium

Vielleicht kennt du, außer Wikipedia, ein paar gute Seiten wo das mithilfe von C oder C++ Step by Step erklärt ist, so für die dummen Menschen? Ich nutze ungern am Anfang Libs, da ich wirklich verstehen will was ich da mache.

Da fallen mir so auf die schnelle folgende Seiten ein:

http://musicdsp.org/
http://www.dsprelated.com/dspbooks/filters/
http://www.dspdimension.com/
https://ccrma.stanford.edu/~jos/Interpolation/
und das http://www.kvraudio.com/forum/viewforum.php?f=33 KVRAudio DSP and Plug-in Development Unterforum

eben die üblichen Verdächtigen zu dem Thema halt

Build 708 ist online. Changelog:

Zitat von angryking

Danke, das beantwortet meine Frage deutlich.

Ich bin bloss überrascht, weil ja in der letzten kurzen Zeit extrem viele Neuerungen hinzu gekommen sind, so konnte ich mir die vielen Jahre zuvor kaum erklären.

Naja, ich habe ja auch andere Sachen zu tun. z.B. BeRoTracker, zig VST(i)-Audio-Plugin-Krams, Software Synthesizer und Sequencer Sachen, und zig andere Projekte (inkl. BeRoEXEPacker, BeRoChess, BESEN, etc.), zig Android-App-Sachen, und nebenbei mache ich auch noch elektronische Musik (und das nur mithilfe eigener selbst entwickelter Software). Und ich habe dann zudem noch einen echten Job.

Sprich ich kann nicht immer meine ganze Zeit für Micro64 einteilen.

Zitat von angryking

--> http://www.try2emu.net.pl/pl/4…o64-10020120705-Build-707

Was mich aber jetzt wirklich interessiert: Wird an dem Emu tatsächlich seit 2003 gearbeitet?

Ja, BeRoC64 ( 2003 - 2005 ) -> Brotkästchen ( 2006 ) -> Micro64 ( 2007 - heute ) und BeRoC64 ( 2003 - 2005 ) -> Hyper64 ( 2008 ), wobei das Urprojekt BeRoC64 selbst bisher nie public verfügbar war, bis jetzt:

http://micro64.de/extradownloads/history/

Da findet man auch nun eine sehr frühere EXE von micro64, wo die micro64.exe (Build 55) selbst noch unter 64k groß war, trotz bereits dem heute bekanntem F9-Menü.

Aber achtung, Virenscanner können da einen FalsePositiveAlarm melden, weil diese EXE Dateien, wie in der Demoszene üblich, gepackt sind.

Und ich habe schon früher einen selbst-bootenden sehr einfachen zeilenbasierten und Opcode-für-Opcode-basierten C64 Emulator inkl. FAT12 Bootsektor für den 320x200x256 13h Grafikmodus in reinem 16-bit x86 Assembler mal angefangen, aber das kann ja man nicht zur Micro64-Historie mitzählen, da es eine völlig andere Codebasis ist, als die gesamte BeRoC64+Brotkästchen+Micro64+Hyper64 Codebasis.

Sprich Micro64 enthält immer noch paar Codezeilen aus den BeRoC64 Zeiten, und noch ein Großteil der Codezeilen aus den Brotkästchenzeiten.

Die heutige Binaries von micro64 sind auch nur so groß wegen den 3D Modellen und Texturen (für ALT+T), für den Diskettenlaufwerk-Soundsampleskram, für die Reflektiontexturen, etc. sonst wären die Binaries bis Build 704 heute immer noch recht klein gewesen (so in Richtung 96kb bis 192kb, grob geschätzt, da ich es bisher nie wieder probiert habe, den ganzen AddOn Datenkram nicht als Constant-Byte-Arrays mit ein zu kompilieren), aber ab Build 705 kam ja der NEMO Networkmonitor Kram mit rein, wo die Binary durch eine riesige Netzwerklibrary (namens Synapse) codetechnisch stark was größer wurde, und ab 706 wegen meiner eigenen BRRE RegExp Library codetechnisch wieder bisschen stark größer geworden ist.

Build 705 ist online. Changelog:

Build 704 ist online. Changelog:

Zitat von pi64

c'mawn... die reflection emu muss natürlich die webcam nutzen, um das geschehen vor dem monitor zu spiegeln!

Dafür bietet SDL 1.2.x selbst aber leider keine API

Zitat von pi64

die floppy sounds sind auch klasse, nur klingts noch nicht ganz so wie beim original. kann man die sounds irgendwo austauschen?

Nein, leider nicht, da die Sampleloopoffsets zum einen von mir hardgecodet sind, und zum anderen die Samples so von mir fein-getunt worden sind, so dass diese auch für "1541 Music" mithilfe einem Granularsynthese-ähnlichen Ansatz noch ungefähr grob was taugen.

Zitat von pi64

sonst drei daumen hoch!

Danke

Build 702 ist online. Changelog:

Zitat von internium

Wo werden eigentlich die Snap- und Screenshots gespeichert?

Noch garnicht, das sind noch reine Dummy Menueinträge, da dem Menüsystem noch eine Art von Save-File-Dialog fehlt.

Ich konzentriere mich bei Micro64 bisher hauptsächlich eher auf die Emulation selbst, als die UI u.A. das Menüsystem weiter auszubauen, was ich auch schon seit Ewigkeiten vor mir hinaus schiebe, was vor allem aber auch für das geplante neue Debugger/Monitor Feature benötigt wird, dass es mal endlich von mir erledigt wird.

Zitat von internium

@Rayne: Ja mein Laptop geht da auch an seine Grenzen bei Full GPU. Bildverzerrung macht er noch mit, aber wenn ich auf High Resolution umschalte dann geht er doch schon in die Knie und die Demos haben Aussetzer. Ich habe einen i3 mit 2.2Ghz und eine 410M von Nvidia drinne, in dem Schleppi. Desktop kann ich leider nicht testen, da wir keinen mehr im Haushalt haben, höchstens noch nen FullHD TFT aber das bringt ja in diesem Falle nix.

"High Resolution" bringt nur bei Bildschirmen mit extrem hohen Auflösungen was, so ab 2304x1152 Auflösung / micro64 Fenstergröße. Bei niedrigen Auflösungen bzw. micro64 Fenstergrößen kann es höchstes nur den Moiré-Effekt einbeflussen, egal ob positiv oder negativ, denn das bewertet dann ja eh jeder selbst seinem persönlichen Geschmack nach jeweils anders.

Zitat von internium

EDIT: Was auch noch fehlt sind wie in Cathode die Reflexionen der Umgebung.

Das kommt eventuell ja noch später.