|
Das deutsche QBasic- und FreeBASIC-Forum Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
|
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
REZK
Anmeldungsdatum: 28.10.2004 Beiträge: 109 Wohnort: Stuttgart
|
Verfasst am: 13.11.2004, 12:25 Titel: befehle neu schreiben |
|
|
Hallo
Ich habe vor ein Spiel zu schreiben, bei dem es stark auf die Geschwindigkeit ankommt. Bei welchen Befehlen lohnt es sich, eine Subroutine in Assembler zu schreiben, die das gleiche leistet wie der jeweilige befehl. Lohnt es sich schon bei pset (bzw. poke), oder erst bei line???
Hat jemand schon Erfahrungen damit gemacht, auch, ob es sich überhaupt lohnt (Geschwindigkeitsmäßig)??
Danke und Gruss, REZK _________________ Meine sämtlichen QB Projekte findet ihr hier |
|
Nach oben |
|
|
Sebastian Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 5969 Wohnort: Deutschland
|
Verfasst am: 13.11.2004, 13:01 Titel: Je mehr ASM desto besser |
|
|
Hallo.
Ich habe versucht mein Jump'n'Run Game für QBC ganz ohne irgendeine (ASM-)Lib zu programmierern. Hat auch geklappt, aber der Grafikaufbau ist dadurch recht zäh und der Spielspaß geht dadurch ganz schön verloren...
Ich habe mit PSET und PCOPY gearbeitet und würde keinem raten, damit ein größeres Spiel zu machen. Schreib dir für PSET eine ASM-Routine und auch für evtl. PCOPY und so weiter. Oder du nimmst die AK-Lib. Sie ist in den SVGA-Modi seehr schnell.
Viele Grüße!
Sebastian _________________
Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen! |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 13.11.2004, 14:45 Titel: |
|
|
Heutige PCs mit ihren 2,5 GHz und mehr sind mittlerweilen so schnell, dass selbst ein unkompiliertes QBasic-Programm unter QBASIC.EXE (V1.1 von DOS 5.x/6.x) wesentlich schneller als ein mit reinem Assembler programmierter Commodore 64 arbeitet. Von diesem Aspekt her betrachtet kann man also ganz gut auf irgendwelche Assemblerroutinen verzichten - es sei dem, dass man ausdrücklich sehr niedrige Systemvoraussetzungen festlegt oder ganz extrem rechenaufwändige Operationen verwendet, welche vor zehn Jahren noch völlig undenkbar gewesen wären.
Als Beispiel kann man mein Labyrintspiel auf heutigen Maschinen schon ganz gut ohne Compilierung spielen.
Ansonsten mein Tipp: Mit SCREEN 7 läuft es sonst auch recht schnell, weil nicht so viele Daten im Grafikspeicher verschoben werden müssen.
@REZK: CPU und Taktfrequenz Deines QB-Entwickler-PCs? _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
REZK
Anmeldungsdatum: 28.10.2004 Beiträge: 109 Wohnort: Stuttgart
|
Verfasst am: 13.11.2004, 14:51 Titel: PC |
|
|
Mein PC ist ein Pentium 2 mit 45oMhz , 786MB RAM und SCSI.
Ich habe mir überlegt, über kurz oder lange einen 3d ego shooter zu programmieren (nicht so gross und profesionell wie die ebenfalls unter qb gecodeten "mux" oder "capture the flag" oder "return to marchfeld"), und da mux selbst auf meinem rechner und trotz der verwendung von asm routinen recht langsam läuft, dachte ich, ohne asm routinen nicht auskommen zu können...........
REZK _________________ Meine sämtlichen QB Projekte findet ihr hier |
|
Nach oben |
|
|
dreael Administrator
Anmeldungsdatum: 10.09.2004 Beiträge: 2507 Wohnort: Hofen SH (Schweiz)
|
Verfasst am: 13.11.2004, 15:22 Titel: Zahlentypen! |
|
|
Viel wichtiger als Assemblerroutinen oder weiss ich wie schnelle Hardware sind vor allen Dingen effiziente Algorithmen. Beispiel aus meiner Sammlung ist die Billard-Simulation: Dank der Verwendung einer sog. Halde (Heap) erspare ich mir eine Sortierung, womit dieses Programm auch auf einem 286er noch vernünftig läuft.
Speziell bei QBasic einige Punkte, mit denen man ebenfalls Einfluss auf die Performance nehmen kann: Der häufigste Fehler ist die Tatsache, dass viele sich gar keine Gedanken über die Datentypen machen. Beispiel:
Machen wir eine Analyse: Weil das "i" kein %/&/!/#/$ hat, verwendet QB die DEFxxx-Voreinstellung, welche bei fehlender DEFxxx-Anweisung immer
ist. Also wird unser FOR-Statement als
ausgeführt. Weil Integer und Singe (Float) noch nicht kompatibel sind, muss es unser BASIC als
Code: | FOR i!=CSNG(1) TO CSNG(10) |
ausführen. Das generelle Problem: Wir verwenden hier quasi teuren, rostfreien Stahl (=Fliesskommaarithmetik) für etwas, wo billiges Gartenzauneisen (=ein 16-Bit Integer) ebenso ausreichen würde. Somit löst also ein
oder ein
Code: | DEFINT a-z
FOR i=1 TO 10 |
die vorhin diskutierten Probleme eigentlich vollständig. Umgekehrt sollte man niemals
schreiben, sondern
weil man damit eine überflüssige CSNG()-Operation eliminiert. Aus diesem Grund empfehle ich eigentlich jedem, den Pascal/Modula-2/ADA-Programmierstil zu praktizieren (dort müssen Typen immer explizit umgewandelt werden), weil man sich so die Zahl der versteckten Umwandlungsoperationen besser bewusst wird und diese vermeidet.
Übrigens konnte ich in der Vergangenheit sogar messbar mit Testprogrammen den CPU-Mehraufwand nachweisen. _________________ Teste die PC-Sicherheit mit www.sec-check.net |
|
Nach oben |
|
|
|
|
Du kannst keine Beiträge in dieses Forum schreiben. Du kannst auf Beiträge in diesem Forum nicht antworten. Du kannst deine Beiträge in diesem Forum nicht bearbeiten. Du kannst deine Beiträge in diesem Forum nicht löschen. Du kannst an Umfragen in diesem Forum nicht mitmachen.
|
|