quake2 gp2x fps frage


lockwood

Member
Joined
Dec 27, 2005
Messages
309
Wieso hat die quake2 gp2x version nur 5a6 fps?
Man kann doch so programmieren sodas die grafik ein bischen runtergeschraubt wird?
 
Mach doch ;)

(Soll heißen so einfach ist das sicherlich nicht und irgndjemand muss es tuen.. und wenn du denkst dazu hab ich keine lust/zeit/wissen denken das sicher viele andere auch)
 
lockwood said:
Wieso hat die quake2 gp2x version nur 5a6 fps?
Man kann doch so programmieren sodas die grafik ein bischen runtergeschraubt wird?
Das wären aber große Einschnitte in die Engine.
Und da muss man erst mal alles hinfummeln.
Und unter 320x240 pixel kann man auch nicht wirklich gehen, weil es dann ein wenig Matschig aussieht.
 
wieso q1 läuft doch auch nur in 200*200 pixel und wird mittels des hardware scalers auf die 320*240 pixel hochgerechnet
 
lockwood said:
es muss nur noch effizienter für dem gp2x umprogrammiert werden.

nur noch.
das heisst es dierekt an die hardware ranzuschreiben, und das ist afaik nicht so leicht. ansonsten wäre es sicher schon released worden oder?
 
Eviscares said:
lockwood said:
es muss nur noch effizienter für dem gp2x umprogrammiert werden.

nur noch.
das heisst es dierekt an die hardware ranzuschreiben, und das ist afaik nicht so leicht. ansonsten wäre es sicher schon released worden oder?

da hasste recht. Das ist sau schwer. Ich hab mir noch mal die source codes angeguckt und jetzt hab ich die folgenden fragen:

Welche art von Models,textures und objects werden hier im source benutzt die conventiert wurden?
 
.eg said:
lockwood said:
es muss nur noch effizienter für dem gp2x umprogrammiert werden.
Der Source existiert, viel Spass dabei ;)

In der Ausbildung hatte ich Assembler (X86). Das ist sehr effektiv wenn man das Letzte aus der Hardware holen will aber es war so mit das übelste, was ich da je lernen musste. *örk*

Falls wer die Skills hat und sich reichlich mit ARM Assembler auskennt, könnte Quake 1 sicher flüssig in 320x240 bei 30FPS laufen.

Aber wie gesagt, Assembler is wirklich nix, was irgend wie Spaß macht zu coden. :wink:

Hm... wenn man John Carmack nen GPX2 zukommen lässt... ob der sich hinsetzt und mal eben nen geschmeidigen Port seiner Quake-Engine aus dem Hut zaubert? :D
 
Fusion_Power said:
.eg said:
lockwood said:
es muss nur noch effizienter für dem gp2x umprogrammiert werden.
Der Source existiert, viel Spass dabei ;)
Wuensch ich dir auch *bg*.
Fusion_Power said:
In der Ausbildung hatte ich Assembler (X86). Das ist sehr effektiv wenn man das Letzte aus der Hardware holen will aber es war so mit das übelste, was ich da je lernen musste. *örk*
Och naja. Der ARM ist ja ein RISC Prozessor, da gibts nicht so viele Befehle wie bei x86. Bei x86 hat man auch immer das Problem, dass man beim Assembler sehr stark aufpassen muss wie man optimiert (Pipelines, Caching, etc.).
Hab schon einiges an unterschiedlichen Assemblerdialekten hinter mir - man arbeitet halt auf unterstem Level...
Fusion_Power said:
Falls wer die Skills hat und sich reichlich mit ARM Assembler auskennt, könnte Quake 1 sicher flüssig in 320x240 bei 30FPS laufen.
Sicher. Wenn man das machen moechte sollte man aber nie versuchen alles zu optimieren. Da muss erstmal ein Benchmarking her, wo man dann die Stellen erkennt, an denen sich eine Optimierung ueberhaupt lohnt.
Das sind hauptsaechlich Routinen, die haeufig aufgerufen werden oder Routinen, die eine lange Bearbeitungszeit haben.
 
Mal ne evt. etwas allgemeinre Frage: Seit ihr sicher, dass ihr besseren/optimierteren ASM-Code schreiben koennt als ein Compiler(in unserem Fall GCC)?
 
.eg said:
Mal ne evt. etwas allgemeinre Frage: Seit ihr sicher, dass ihr besseren/optimierteren ASM-Code schreiben koennt als ein Compiler(in unserem Fall GCC)?
Es ist immer moeglich effektiveren Code zu schreiben, als ihn ein Compiler produziert (zumindest bis jetzt).
Es hat schon seinen Grund, warum Compiler Optimierungsstufen haben, die sich zum Grossteil gegenseitig ausschliessen. Die Compiler greifen auch nur auf vorgegebene Funktionsbibliotheken zurück - und den Sinn hinter dem C-Code verstehen sie auch nicht. Somit können sie nur stur nach einem vorgegeben Schema "optimieren".
Allerdings wird es für einen ungeübten Programmierer schwer, besser als der Compiler zu sein. Man sollte auch nicht unbedingt versuchen den Code zu verstehen, den der Compiler generiert hat - der ist meist nicht wirklich schön... :wink:
Zudem produziert der GCC nicht unbedingt den schnellsten Code. Im Automotive-Bereich wird daher für den ARM viel der Compiler von GreenHills verwendet. Aber auch der hat seine Probleme... es ist immer wieder schön, wenn der Code auf irgendeiner Optimierungsstufe plötzlich nicht mehr funktioniert... :(
Wie Octoate schon schrieb, bei größeren Projekten sucht man sich eigentlich nur die problematischen Codestellen heraus und versucht diese durch eigenen ASM-Code zu ersetzen.

Bye,
Cranium
 
boeseronkel2k said:
wieso q1 läuft doch auch nur in 200*200 pixel und wird mittels des hardware scalers auf die 320*240 pixel hochgerechnet
Aber darunter wird es echt unschoen und wenn man das Bild auch runter scaliert kriegt man Augenkrebs ^^.
lockwood said:
und die level?
Du meinst die maps?
 
jup alles wie im orginal...
die level sind übrigens BSP, was auch von allen quake basierenden engines genutzt wird.
 
abgesehen davon bestehen die "level" aus meheren maps die glaube ich mit scripts aneinader greiht wurden.
 
hmm wenn ich mal meine quake2 cd irgendwann wiederfinde (hab ne riesige kiste mit cds irgendwo im keller ;) ) dann probier ich das mal bei 300mhz... ich würde mich über 10 fps sehr freuen, das ist aber glaube ich fast ein wenig zu optimistisch

EDIT: Yeah gefunden, also bei 300Mhz läuft es eigentlich ganz spielbar...
kann mich erinnern das ich quake damals auch mit der geschwindigkeit aufm gp32 gezockt habe.
 
Back
Top