raps schrieb:
hustbaer schrieb:
Ja, an Lookup-Tables für Multiplikationen hab' ich jetzt nicht gedacht.
auf 8086 mit 4.77MHz hast du Po2 verwendet, weil indizieren in eine nicht Po2 palette von sprites schon zuviel der Muls waere.
Kann man allerdings auch über nen einfachen Lookup-Table machen.
problem ist nur dass deine LUT zur compile zeit nicht bekannt ist, muestest du also im 'level' ablegen. haettest also lookup zum lookup, dann lookup, dann erst zugriff auf das asset. waere in alten zeiten schon ein wenig aufwendig (zumal es vermutlich nicht mit 16bit getan waere, also 32bit reads (seg:offset) und das mehrmals.
verstehe ich grad nicht was du meinst. du kannst in jedem fall den shift durch einen einzigen lookup ersetzen. wenn die frame-anzahl bekannt ist, dann kann der table auch auf einer konstanten adresse sitzen, so dass kein load nötig ist um die table-startadresse zu laden. ob die werte bereits vom compiler/linker beim bauen reingeschrieben werden, oder erst beim laden des levels, spielt dabei ja keine rolle.
u.u. kann man sich sogar die addition der "base address" sparen - wenn man flat-mode verwendet bzw. sowieso alles in 64KB platz hat kann man ja fertige adressen in den table reinschreiben.
klar, es wäre etwas mehr aufwand, und so lange kein guter grund dafür spricht wird man es dann nicht machen. rein von der geschwindigkeit her sehe ich da aber kein echtes problem.
ich hatte neben jeder meiner c zeilen die anzahl der zyklen stehen und alles was ein wenig zeit brauchte, von simplen clear, ueber memcpy etc. wurde dann eh frueher oder spaeter in assembler gewandelt. pro sprite 10cycles oder so verschwenden haette einem programmiererherz wehgetan ;), heute schert sich die welt nichtmal bei pixelshadern so drum wie damals beim cpu code.
da hast du sicher auch recht. ich glaube nur dass damals z.T. auch sachen optimiert wurden, die schon damals egal waren. weil es damals einfach OK war dinge bis zum abwinken zu optimieren, und optimieren macht spass, also optimiert man einfach alles - egal ob es sinn macht oder nicht.
10 zyklen pro sprite sparen, wenn das zeichnen des sprites insgesamt 50-100 zyklen braucht ist ja noch OK. 10 zyklen sparen wenn das zeichnen >= 1000 zyklen braucht ist mMn. sinnfrei. bzw. war es auch damals schon.
Bei Rotation etc. hast du natürlich recht - das geht mit beliebigen Grössen überhaupt nicht gut, weil man zu oft multiplizieren müsste. Wobei man natürlich auch hier wieder LUTs verwenden könnte - langsamer als mit power-of-two Grafiken wird das aber vermutlich auch sein.
fuer performance haette man damals alles getan, das ist heute irgendwie schwer rational zu erklaeren.
ja... ich hab die zeit ja noch am rande miterlebt. ich hab' zwar damals keinen produktiven code geschrieben, aber ich hab' am amgia 500 zu programmieren angefangen (erst assembler, später dann C). waren zwar alles nur hobby-projekte, und kaum etwas ist wirklich fertig geworden. aber was man da alles machen konnte (und auch gemacht hat) um performance zu schinden ist mir zumindest nicht ganz fremd.
