DGL • Thema anzeigen - Uhrzeit in Milisekunden rauskriegen

Uhrzeit in Milisekunden rauskriegen

Moderator: DGL-Team

Seite 2 von 2

[ 25 Beiträge ]

Gehe zu Seite Vorherige 1, 2

Vorheriges Thema | Nächstes Thema

Autor

Nachricht

SDH.Prod

Betreff des Beitrags:

Verfasst: Di Apr 14, 2009 19:40

DGL Member

Registriert: Sa Okt 18, 2008 11:59
Beiträge: 180

Naja wie bereits gesagt:
WENN EIN MANN SICH EINMAL FÜR WAS ENTSCHIEDEN HAT, DANN ÄNDERT ER AUCH NICHT SEINE MEINUNG.

Aber danke für die Zusammenfassung.

Warum ist der WindowsZeiter (YEAR, EINDEUTSCHEN FÜR DEN SIEG!) eigentlich so unpräzise?

Nach oben

Ziz

Betreff des Beitrags:

Verfasst: Di Apr 14, 2009 22:21

DGL Member

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL

Da kann Windows nichts dafür - den Counter gibts schoon seit Doszeiten und der IST halt mit ca. 18 Steps die Sekunde getaktet.

_________________
Denn wer nur schweigt, weil er Konflikte scheut, der macht Sachen, die er hinterher bereut.
Und das ist verkehrt, denn es ist nicht so schwer, jeden Tag zu tun als ob's der letzte wär’.
Und du schaust mich an und fragst ob ich das kann.
Und ich denk, ich werd' mich ändern irgendwann.
_________________Farin Urlaub - Bewegungslos

Nach oben

SDH.Prod

Betreff des Beitrags:

Verfasst: Di Apr 14, 2009 23:07

DGL Member

Registriert: Sa Okt 18, 2008 11:59
Beiträge: 180

Türlich kann Gates was dafür...

... warum läuft der immernoch wie bei DOS? Ich meine: eine Abwärtskompatibilität zu DOS braucht heut wohl keiner mehr, also warum wurde der nicht aufegebessert?

Oder ist das wie eine Kette zu betrachten?
Win95 hat den wegen DOS kompatibilität,
Win98 hat den wegen Win95,
2000/NT wegen Win98
und XP wegen 2000/NT oder wie? (Ja, es kann sein das ich ein BS vergessen habe/ eins verwechselt habe).

Man hätte da sicher doch auch beide, den alten und einen alternativen neuen machen können.

Nach oben

Ziz

Betreff des Beitrags:

Verfasst: Mi Apr 15, 2009 06:13

DGL Member

Registriert: Di Sep 20, 2005 13:18
Beiträge: 1054
Wohnort: Dresden
Programmiersprache: C, C++, Pascal, OPL

Hat man doch. Der neue ist der "High Performance Counter/Timer". Der Zugriff auf diesen ist doch nun wirklich sehr simpel (zwei Funktionen aus der Standard-API, eine einfache Division, fertig)

Nach oben

Kyro

Betreff des Beitrags:

Verfasst: Mi Apr 15, 2009 15:22

DGL Member

Registriert: So Okt 26, 2003 20:07
Beiträge: 249

SDH.Prod hat geschrieben:

ich mache ja meine Animationen ja durch eine Anfangszeit Variable und berechne daraus sozusagen den Fortschritt (hab ich mir selbst ausgedacht.
Aber welche Methode ist denn eigentlich üblich?

Also normalerweise verwendet man für alle Instanzen die Zeit z.B seit dem letzten Rendervorgang. Wenn du es so machst musst du die Delta-Zeit nur einmal für alles ausrechnen und dann an deine Animationen weitergeben. Pausieren tust du dann einfach in dem du einer Animation für x Rendervorgänge oder t Sekunden mal keine Delta-Zeit gibst. Also grob so:

Code:

 
class MyAnimation
{
   private single MyProcess;
 
   public void Update(single DeltaTime)
   {
      MyProcess += DeltaTime;
      // evtl. noch anderes Updaten
   }
 
   public void Render()
   {
      // In Abhängigkeit von MyProcess rendern
   }
}

Immer vom Programmstart auszugehn ist unnötig umständlich..

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Nach oben

Gento

Betreff des Beitrags:

Verfasst: Mi Apr 15, 2009 18:18

DGL Member

Registriert: So Apr 01, 2007 17:51
Beiträge: 42
Wohnort: Hamm/Westf.

<Da kann Windows nichts dafür - den Counter gibts schoon seit Doszeiten und der IST halt mit ca. 18 Steps die Sekunde getaktet.>

Genau genommen wird alle 18,2 Sekunden eins hochgezählt.
Damit wird ein IRQ ausgelöst und vom Bios des Motherboard's abgearbeitet.

Damals unter Dos usw sehr nützlich , weil auf selbst erstellte Zeilen umgelenkt werden konnte.
Ich hatte das damals benutzt für Mausanzeige SVGA im Protected mode.Gabs damals nur im Real mode :shock:

Diese 18,2 "Tick's" konnten per Soft auf KHZ hochgestellt werden und sollte Heuer auch noch mit Klimmzüge gehen.

Gento

Erinnerungen an 1998 :wink:

Code:

UNIT IRQ; 
{$F+}
{$D-}
{$S-}
{$O-}
{$R-}
{$Q-}
INTERFACE
    USES Dos; 
CONST
    Systemuhr   = 0; Tastatur    = 1; Slave       = 2; RS23_2      = 3; 
    RS232_1     = 4; LPT2        = 5; Disketten   = 6; LPT1        = 7; 
    Echtzeituhr = 8; Irq2        = 9; Reserviert_0=10; Reserviert_1=11; 
    PS_2        =12; Koprozessor =13; Festplatte  =14; Reserviert_2=15; 
    Interrupt_Vector: ARRAY[Systemuhr..Reserviert_2] OF byte =
     ($08,  { Time Of Day } $09,  { KeyBoard } $0A,{ PC/AT =  Slave PIC }
      $0B,  { COM2:       } $0C,  { COM1:    } $0D,{ LPT2: AT) }
      $0E,  { Diskette    } $0F,  { LPT1     } $70,{ Real Time Clock }
      $71,  { IRQ2        } $72,  { Reserved } $73,{ Reserved }
      $74,  { PS_2_Maus   } $75,  { CoProces } $76,{ Fixed Disk Controller }
      $77   { Reserved    } ); 
VAR Interrupt_Adresse: ARRAY[Systemuhr..Reserviert_2] OF Pointer; 
   Timer_Pro_Sekunde        :Word; 
   Timer_Zaehler            :Word; 
   Timer_Merker             :Word; 
   Alte_Interrupt_Adresse_1C:Pointer; 
   Alte_Interrupt_Adresse_6B:Pointer; 
   Alte_Interrupt_Adresse_33:Pointer; 
 
CONST
   Interrupt_Masken_Register       = $21;  { Port address for the interrupt mask register. }
   Interrupt_ACK_Register          = $20;  { Place to send the end-Of-Interrupt code. }
   Interrupt_Masken_Register_Slave = $A1;  { Port address of Slave interrupt mask register. }
   Interrupt_ACK_Register_Slave    = $A0;  { Slave Interrupt Controller ack register }
   EOI                             = $20;  { end-Of-Interrupt Code sent to the mask regs. }
 
PROCEDURE AcknowledgeInterrupt;  { AT ONLY!   Works on PC/AT class machines }
PROCEDURE Hardware_Interrupt_Sperren(Ir : Byte); 
PROCEDURE Hardware_Interrupt_Freigeben(Ir : Byte); 
PROCEDURE Interrupt_IQR_8_1C_Taktfrequenz_Veraendern(Frequenz:Word); 
PROCEDURE Interrupt_IQR_8_1C_Taktfrequenz_Restorieren; 
PROCEDURE Mein_Interrupt_auf_IQR_1C_Installieren(Proc:Pointer); 
PROCEDURE Mein_Interrupt_von_IQR_1C_Entfernen; 
PROCEDURE Reset_Interrupts; 
 
IMPLEMENTATION
VAR
   Zaehler                  :Byte; 
   AltExit                  :Pointer; 
PROCEDURE AcknowledgeInterrupt;  { AT ONLY!   Works on PC/AT class machines }
BEGIN
 ASM
 CLI                                    { Interrupts Off }
 MOV AL, EOI                            { Get end-Of-Interrupt Value }
 OUT Interrupt_ACK_Register, AL         { Send it }
 MOV AL, EOI                            { Get end-Of-Interrupt Value }
 OUT Interrupt_ACK_Register_Slave, AL   { Send it }
 STI                                    { Interrupts On }
END; 
END; 
 
PROCEDURE Hardware_Interrupt_Sperren(Ir : Byte); 
BEGIN
 ASM
 CLI
END; 
  IF Ir > 7 THEN
   Port [Interrupt_Masken_Register_Slave] := Port [Interrupt_Masken_Register_Slave] OR (1 SHL (Ir - 8))
  ELSE
   Port [Interrupt_Masken_Register] := Port [Interrupt_Masken_Register] OR (1 SHL Ir); 
  ASM
   STI
  END; 
END; 
 
PROCEDURE Hardware_Interrupt_Freigeben(Ir : Byte); 
BEGIN
 ASM
 CLI
END; 
  IF Ir > 7 THEN
   Port [Interrupt_Masken_Register_Slave] := Port [Interrupt_Masken_Register_Slave] AND ((1 SHL (Ir - 8)) XOR $00FF)
  ELSE
   Port [Interrupt_Masken_Register] := Port [Interrupt_Masken_Register] AND ((1 SHL Ir) XOR $00FF); 
  ASM
   STI
  END; 
END; 
 
PROCEDURE Interrupt_IQR_8_1C_Taktfrequenz_Veraendern(Frequenz:Word); 
CONST Grenze=25000; 
VAR  IZaehler:Word; 
BEGIN
 Asm
 Cli
END; 
  IF Frequenz>Grenze THEN Frequenz:=Grenze; 
  Timer_Pro_Sekunde:=Frequenz; 
  IZaehler:=1193180 DIV Frequenz; 
  Port[$43]:=$36; 
  Port[$40]:=Lo(IZaehler); 
  Port[$40]:=Hi(IZaehler); 
  Timer_Zaehler:=Round(Timer_Pro_Sekunde/18.2); 
  Timer_Merker:=Timer_Zaehler; 
  Asm
   Sti
  END; 
END; 
 
PROCEDURE Mein_Interrupt_auf_IQR_1C_Installieren(Proc:Pointer); 
BEGIN
 GetIntVec($1C,Alte_Interrupt_Adresse_1C); 
 SetIntVec($6B,Alte_Interrupt_Adresse_1C); 
 SetIntVec($1C,Proc); 
END; 
 
PROCEDURE Mein_Interrupt_von_IQR_1C_Entfernen; 
BEGIN
 SetIntVec($1C,Alte_Interrupt_Adresse_1C); 
 SetIntVec($6B,Alte_Interrupt_Adresse_6B); 
END; 
 
PROCEDURE Interrupt_IQR_8_1C_Taktfrequenz_Restorieren; 
BEGIN
 Asm
 Cli
END; 
  Port[$43]:=$36; 
  Port[$40]:=0; 
  Port[$40]:=0; 
  Asm
    Sti
  END; 
END; 
{--------------------------------------------------------------------------}
PROCEDURE Reset_Interrupts; 
BEGIN
 FOR Zaehler:=Systemuhr TO Reserviert_2 DO
  SetIntVec(Interrupt_Vector[Zaehler],Interrupt_Adresse[Zaehler]); 
 SetIntVec($1C,Alte_Interrupt_Adresse_1C); 
 SetIntVec($33,Alte_Interrupt_Adresse_33); 
 SetIntVec($6B,Alte_Interrupt_Adresse_6B); 
 Interrupt_IQR_8_1C_Taktfrequenz_Restorieren; 
END; 
{--------------------------------------------------------------------------}
PROCEDURE Abschlussroute; 
BEGIN
 Reset_Interrupts; 
 Hardware_Interrupt_Freigeben(PS_2); 
END; 
{--------------------------------------------------------------------------}
BEGIN
 AltExit:=Exitproc; 
 ExitProc:=@Abschlussroute; 
 FOR Zaehler:=Systemuhr TO Reserviert_2 DO
  GetIntVec(Interrupt_Vector[Zaehler],Interrupt_Adresse[Zaehler]); 
 GetIntVec($1C,Alte_Interrupt_Adresse_1C); 
 GetIntVec($33,Alte_Interrupt_Adresse_33); 
 GetIntVec($6B,Alte_Interrupt_Adresse_6B); 
END.
 

Nach oben

TAK2004

Betreff des Beitrags:

Verfasst: Do Apr 16, 2009 11:39

DGL Member

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2623
Wohnort: Berlin
Programmiersprache: Go, C/C++

Hehe, nice to know.

Wieso Windows immer noch dos in Windows hat, ist der gleiche grund, wieso in windows auch immernoch nt, und 32 bit emulator in 64Bit gibt.
Windows bleibt abwährtskompatibel und verliert dadurch viel stabilität, sicherheit und eine menge code aber es läuft halt die alte Managment, Cad, Animations und so weiter Software noch.
Windows macht kleine Schritte und überlegt mit guten Erfolg(wie ich finde) sehr genau, wann sie welche API durch neue ersetzen.
Der Versuch mit Vista das Sicherheitskonzept auf das von Linux an zu passen ging in die Hose, da an einigen Punkte man nicht mit der Kritik des Benutzers gerechnet hat und das nicht alle Firmen mit ziehen. Ein Beispiel ist das Treiber Zertifikatssystem, welches sich auf alle 5 Layer in Windows Vista etabliert hat. Mit Windows 7 wurde dieses aber in den unteren Layern aufgelockert, da es dort zu so starken Problemen kam, dass diese ein Deadlock verursachen konnten(Beispiel:Festplattentreiber ist nicht zertifiziert, dann kann das System bei Ruhemodus nie wieder hoch kommen und windows ->muss<- neu installiert werden). Treiberzertifikate sind eine gute Idee aber Windows hatte es falsch gemacht, daraus gelernt und entsprechend änderungen geplant. Die Problematik von Softwaresicherheit wurde auch aus der Rümpelkammer hervorgekrammt und man hatte dann nachträglich für Vista und XP ein neuen Security API für Prozesse hoch gezogen. Damit kann man z.B. einen Sicherheitscontext am anfang des Programmes erstellen und einige Sicherheitsaspekte festlegen, wie z.B. das lesen von Speicher für anderen Prozessen verbieten oder das Thread Hooking(welches 99% aller spiele sabotagen verwenden) von aussen. Problematiken wie ausgetauschte DLLs(z.B. opengl32.dll) die eigenen code einschleusen und dann als dependencie die echte nachträglich laden waren schon vorher einfach zu entdecken und gegen zu sichern, da die dll API auch erlaubt zu schauen wieviele treffer in allen DLLs des einen Symbols es gibt und man sogar festlegen kann, dass er z.B. nur das Symbol aus der ersten geladenen DLL nehmen darf und nicht aus der 2.
Obwohl DirectX Input mit DX10 rausgeflogen ist, gibt es immer noch die dxinput8.dll mit jeder DX installation, um abwährtskompatibel zu bleiben aber es ist als obsolet makiert und wird nicht mehr gepflegt.
Es passiert halt schon ne menge aber aufgrund der Kompatibilität bleiben die alten Systeme bestehen und die neuen werden nur sehr selten genutzt bzw. man weiß garnicht, dass sie existieren.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nach oben

Markus

Betreff des Beitrags:

Verfasst: Do Apr 16, 2009 22:43

DGL Member

Registriert: Fr Mär 30, 2007 18:35
Beiträge: 331

Auch wenn das nichts mit dem Thema zu tun hat, aber seit wann werden denn 32-bit Programme in einem 64-bit Windows "emuliert"? Da passiert meines Wissens nichts außer dass API-Aufrufe zum Kernel auf die 64-bit Version gewrapped werden, oder liege ich da falsch? (Natürlich meine ich nicht die Itanium Prozessoren).

Nach oben

TAK2004

Betreff des Beitrags:

Verfasst: Fr Apr 17, 2009 00:31

DGL Member

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2623
Wohnort: Berlin
Programmiersprache: Go, C/C++

Das wäre wirklich sehr schön aber was du meinst geht nur, wenn man ein 32bit system auf einem anderem 32bit system wiedergeben will oder 64 auf 64.
Für 32Bit hat man ja andere stacks und unterschiedliche variablengrößen als für die 64Bit, da läuft ein minikernel mit einen eigenen dll Sammlung(.../SysWOW64/*.*) unter 64bit Windows und der wirkliche Kernel mit dll Sammlung(.../system32/*.*). Mehr infos findest du hier http://en.wikipedia.org/wiki/WOW64
Ziemlich verwirrend, wenn man überlegt, dass 64bit dll's in system32 liegen, da ja 32 eigentlich für 32Bit steht.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Nach oben

Markus

Betreff des Beitrags:

Verfasst: Fr Apr 17, 2009 17:42

DGL Member

Registriert: Fr Mär 30, 2007 18:35
Beiträge: 331

Zitat:

No emulation is required for WOW64 on x86-64 (x64).

Nach oben

Seite 2 von 2

[ 25 Beiträge ]

Gehe zu Seite Vorherige 1, 2

Foren-Übersicht » Programmierung » Allgemein

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.