amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Suche [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- 2 Ergebnisse der Suche: 35 Treffer (30 pro Seite)
AC-FoX   Nutzer

03.12.2002, 20:07 Uhr

[ - Direktlink - ] 		Thema: schnelles ein/ausblenden bei 16bit
Brett: Programmierung

Ja, für die in C nicht wirklich gut implementierbaren Funktionen wie Rotate oder Swap ist Inline-Assembler schon sinnvoll.
Bei der geringen Komplexheit der gesamten Fade-Routine wär es auch sinnvoll, sie komplett in ASM zu schreiben.
Dann würde man auch das Laden der Daten über ein movem.l abwickeln, dbra für die Schleifencounter, Preload der nächsten Daten vor Schleifenende, und und und...
Hat eigentlich schon jemand ausprobiert, ob der Code funktioniert?

Gruß,
FoX
 
AC-FoX   Nutzer

02.12.2002, 19:11 Uhr

[ - Direktlink - ] 		Thema: schnelles ein/ausblenden bei 16bit
Brett: Programmierung

Jaaaaa 'türlich, Inline-Assembler! Aber das kann ja jeder ;-)
Eigentlich wär die ganze Routine eine Sache für einen einzigen ASM-Code.
Aber ASM ist eben CPU-abhängig, und der PPC hätte gerade für den Byte-Swap beim Laden und Speichern einen perfekt zugeschnittenen Befehl - wieder zwei Taktzyklen pro 2 Pixel gespart - hehe.
Und Micha wollte ja reinen C-Code, und portierbar ist es auch noch, wenn man mal den Grafiksystem-Kram anpaßt.

Gruß,
FoX
 
AC-FoX   Nutzer

02.12.2002, 15:46 Uhr

[ - Direktlink - ] 		Thema: schnelles ein/ausblenden bei 16bit
Brett: Programmierung

Also meine tmpbm und scrbm sind nicht auf die Weise angelegt, wie es Thomas gemacht hat. tmpbm ist mit AllocVec(800*600*2, MEMF_ANY); angelegt, und scrmb über AllocBitMap() mit dem gleichen BitMap-Format wie die Screen-BitMap (scrbm != Datenanfang, nicht vergessen). Ganz mutige können auch direkt die Screen-BitMap locken und sie gleich als Ziel des Algorithmus angeben. Dann wird aber ein sichtbarer Durchlauf entstehen, da der RasterBeam schneller sein wird, als die CPU bei Lesen bzw Schreiben in den Grafikspeicher.
Vor dem ersten Durchlauf also Screen-BitMap locken, Format feststellen und in tmpbm kopieren, dann freigeben. In jedem Durchlauf von der tmpbm nach scrbm "abdunkeln", die Screen-BitMap locken, die scrbm reinblitten und wieder freigeben.

Grüßli

[ Dieser Beitrag wurde von AC-FoX am 02.12.2002 editiert. ]
 
AC-FoX   Nutzer

02.12.2002, 15:14 Uhr

[ - Direktlink - ] 		Thema: schnelles ein/ausblenden bei 16bit
Brett: Programmierung

Ich hab hier mal ne Idee zu einer Abdunklung auf Shiftbasis:

//CODE Anfang
...
LONG data1;
LONG data2;
LONG data3;
LONG data4;
WORD *tmpbm;
WORD *scrbm;
LONG i;
LONG w, h;
LONG mask;
BYTE shiftcount; //müßte übergeben werden, als Durchlaufzähler
...
w=800;
h=600;

i=shiftcount;
mask=-1; //alle bits auf 1 setzen
while(i)
{
mask>>=1;
mask&=0x7bef7bef;
i--;
}

//schleife über Höhe, Pointer auf tmpbm und scrbm setzen
i=(w/8); //bzw (w>>3);
while(i)
{
data1=*(LONG*)tmpbm++; //rumcasten in C und Postinkrement...
data2=*(LONG*)tmpbm++;
data3=*(LONG*)tmpbm++;
data4=*(LONG*)tmpbm++;

data1>>=shiftcount;
data1&=mask;
*(LONG*)scrbm=data1;
scrbm+=2; //tja, ähm pointerarithmetik in C, der achtet auf BYTE, WORD und LONG, komisches Ding :)

...//gleiches für data2,3,4

i--;
}
//close schleife über höhe
...
//CODE Ende

Hierbei muß man pro LONG (also zwei Pixel) nur einmal shiften, und ein AND anbringen. Das AND 0x7bef7bef ist binär 2x0111101111101111. Es maskiert also das nach unten geshiftete Bit der jeweiligen Farbanteile weg. Je nach Durchlaufzähler wird also die mask weniger Einsen enthalten und mehr geshiftete Bits wegmaskieren.
Der Code funktioniert für Width mit mindestens Modulo 8, das paßt ja ziemlich gut für 800 :)
Außerdem kann man gleichzeitig RGB16 und BGR16 verarbeiten. Für RGB16_PC und BGR16_PC müßte man den gleichen Code nochmal machen, und noch ein LSB-MSB Switch machen:
data=(((data << 24) & 0xff000000))| ((data << 8) & 0x00ff0000) | ((data >> 8) & 0x0000ff00) |((data >> 24) & 0x000000ff));
nach dem Laden des Wertes aus der tmpbm und vor dem speichern in die scrbm machen. Alternativ geht auch ein
rotl.w #8,d1
swap d1
rotl.w #8,d1
wenn man das in C hinbekommt ;)

Hat noch jemand ne schnellere Idee? Evtl kann man noch was am Preload der datax was machen. Ein 040 ist ja keine superskalare CPU. Muß eben der Compiler etwas optimieren ;)
Der Code ist auch nur rein hypothetisch, hab ihn nicht ausprobiert - typische Mittagspausen-Beschäftigung...

Gruß,
FoX

[ Dieser Beitrag wurde von AC-FoX am 02.12.2002 editiert. ]
 
AC-FoX   Nutzer

30.11.2002, 19:57 Uhr

[ - Direktlink - ] 		Thema: schnelles ein/ausblenden bei 16bit
Brett: Programmierung

Hmm, also WriteRGBPixel() dürfte nicht so schnell sein, wie ein eigener Code, der genau auf deine Bedürfnisse zugeschnitten ist.
Ich bevorzuge bei zeitkritischen Operationen direkten Zugriff auf den Grafikspeicher. Das Problem dabei ist, daß der Grafikspeicher in verschiedenen Formaten vorliegen kann.
Wenn ich mal bei CGX nachschaue, finde ich da die Formate RGB15, BGR15, RGB15PC, BGR15PC und das gleiche für 16bit.
Wenn du dich auf 16bit beschränkst, wrden immer noch 4 verschiedene, aber fast identische Kernroutinen übrig bleiben.
Die Idee mit Buffern ist an sich schon sehr gut. Nur würde ich am Anfang den Buffer vom Screen lesen, und zwar indem ich den Inhalt direkt reinkopiere (auf ScreenWidth und BytesPerRow achten).
Dann würde ich von diesen Daten ausgehend für jedes Fade-Bild Abstufungen berechnen.
1. Daten aus Buffer lesen
2. Abhängig von Format zerlegen (RGB16 und BGR16 sollte gleich sein, da ja alle Komponenten gleichmässig abgesenkt werden)
3. Abhängig vom Fade-Counter (1, 2 oder 3. Durchgang?) die Werte vermindern
4. Daten in Grafikspeicher schreiben
Das Ganze könnte bei schöner Programmierung (bestenfalls in Assembler :) fast genauso schnell sein wie Copy-Speed.
Beachte, daß das Ergebnis des fadens nicht zurück in den Buffer, sondern nur in den Grafikspeicher geschrieben wird.
Beim Zerlegen der Daten in die Einzelteile braucht man ein OR und ein Shift. Zum Berechnen reicht ein Minus, bzw ein Shift. Minus braucht leider noch eine Null-Abfrage, sonst würde man ja negative Werte erzeugen.
Wieder mit Shift und OR zusammenbasteln, und rausschreiben.
Evtl kann man gleich zwei WORDs zusammen in einer LONG Operation berechnen, indem man geschickt ORs einsetzt. Bei Assembler könnte man auch mehrere Register mit Daten vollladen und bearbeiten, um weniger Load/Store Verluste in den Taktzyklen hat. Alle zugleich laden, nacheinander berarbeiten, und sofort, wenn man ein Ergebnis hat, das Register in den Speicher schreiben.
Aber das größte Problem dürfte immernoch die Geschwindigkeit sein. 800x600x2 Bytes macht lockere 937,5 KB. Grafikdurchsatz zur BVision mit LONG Write ist IIRC so bei 12 MB/sek. Das Maximum würde da bei 13 fps liegen, vorrausgesetzt, der RAM-Speed stimmt.

Viel Spaß,
FoX
 
AC-FoX   Nutzer

04.11.2002, 19:31 Uhr

[ - Direktlink - ] 		Thema: Einklinken in Interruptroutinen
Brett: Programmierung

Für das AmigaOS gibt es die Befehle
AddIntServer()/RemIntServer() sowie
SetIntVector()
Hierbei ist zu beachten, daß ein Server, bei "geteilten" Interrupts eingesetzt wird, also mehrere Server auf ein und denselben Interrupt reagieren (z.B. VertBlank), und Vectoren exklusiv an einen Interrupt gebunden werden.
SetIntVector() gibt auch noch die Addresse des bisherigen Int-Vectors zurück, den man wieder einsetzen muß, wenn man den eigenen Int-Vector wieder entfernt.

Gruß

 
AC-FoX   Nutzer

23.10.2002, 01:06 Uhr

[ - Direktlink - ] 		Thema: Starten eines neuen Prozesses
Brett: Programmierung

So, hier mal ein kleines testprog:

---start---
#include <exec/exec.h>
#include <proto/exec.h>
#include <dos/dos.h>
#include <dos/dostags.h>
#include <proto/dos.h>
#include <stdio.h>

struct Task* MainTask;
const char taskname[] = "testtask";

void taskfunc(void)
{
int i;

for(i=0; i<10; i++)
{
printf("..n");
}

Signal(MainTask, SIGBREAKF_CTRL_D);
}

int main(int argc, char** argv)
{
MainTask=FindTask(NULL);

CreateNewProcTags( NP_Entry, (APTR)taskfunc,
NP_Name, taskname,
TAG_END);

while(!(CheckSignal(SIGBREAKF_CTRL_D) & SIGBREAKF_CTRL_D))
{
printf(";");
}

printf("n");

exit(0);
}
---end---

Der Effekt tritt nicht immer auf, aber so nach etwa 5 mal ausprobieren hintereinander ist bei mir die CON: ruiniert.
Wenn man übrigens die New-Line Escape Sequence im Subtask wegläßt, dann kommt von dort u.U. gar kein Text mehr. Zumindest bei mir überschreibt dann der Haupttask mit seinem printf() die Subtask-Ausgabe.
Wie gesagt, es ist eine nette Fehlerquelle bei Programmierung mit Sub-Prozessen. Da es auch nicht immer bei 100% der Fällen auftritt macht es sich auch sehr gut bei der Fehlersuche :)

Grüzi
 
AC-FoX   Nutzer

22.10.2002, 21:54 Uhr

[ - Direktlink - ] 		Thema: Starten eines neuen Prozesses
Brett: Programmierung

Zitat:
Run benutzt das gleiche Shell-Fenster. Ich habe gerade WinUAE zum Absturz gebracht mit

Einfacher Absturz oder schönes Durchlaufen der CON:?

Zitat:
Scheint aber nur in Streßsituationen aufzutreten.

Ich vermute, daß das Ausführen der Write() Funktion von Prozess 1 vom Task-Switch unterbrochen wird und dabei zumindest ein Strukturelement durch das zweite Write() aus Prozess 2 überschrieben wird. Naja, man steckt ja nicht drin.
Bei meinen Programmen hat der Rechner immer Streß ;)

Grüzi
 
AC-FoX   Nutzer

22.10.2002, 14:16 Uhr

[ - Direktlink - ] 		Thema: Starten eines neuen Prozesses
Brett: Programmierung

Zitat:
Das glaube ich dir nicht. Sonst würde ja folgendes Script amok laufen:

run dir
run dir
run dir
run dir
run dir
run dir
run dir
dir

Ich sitze jetzt grad nicht am Amiga, aber wird bei run nicht eine neue CON: vom System geöffnet, die den Output des neuen Prozesses aufnimmt? Bei einem CreateNewProcess() ohne Angabe eines definierten Dateistromes wird der des Mutter-Prozesses verwendet. Wenn jetzt beide Prozesse gleichzeitig und evtl auch sehr schnell hintereinander printf() machen, dann kann das die CON: überlasten.

Zitat:
Außerdem, was ist "ploten" ?

Wenn man es geschafft hat, die CON: zu trashen, dann ist sie in einem Modus, in dem sie einen unendlich großen String ausgeben will. Deshalb läuft der "Lese-Pointer" vom Anfang des korrekten Strings an durch den ganzen Speicher und printed alles in die CON:, was ihm da über den Weg läuft. Sieht lustig aus, läßt sich aber nicht mehr abstellen.
Ich kann ja mal ein Beispielprogramm machen.

Grüzi
 
AC-FoX   Nutzer

22.10.2002, 14:04 Uhr

[ - Direktlink - ] 		Thema: BitMap Breite
Brett: Programmierung

Zum Kopieren aus einem Buffer in eine BitMap nimmst du dir den Startpointer der Bitmap und die BytesPerRow Angabe, die dir das System mitteilt. Dann kopierst du aus deinem Buffer jede Zeile einzeln. Nach dem Kopieren der Zeile addierst du auf den BitMap-Startpointer die BytesPerRow und hast die Zieladdresse für den Anfang der zweiten Zeile.
Die BytesPerRow Angabe ist extrem wichtig. Sie ist in etwa so definiert:
BytesPerRow ist die Anzahl der Bytes, die man addieren muß, um von einem Bildpunkt zum darunter liegenden zu kommen.
Wenn du jetzt eine 100 Pixel breite Bitmap anlegst, diese aber intern auf 112 Breite läuft (wegen WORD Breite), dann wird dir auch 112 als BPR zurückgegeben. Die restlichen 12 Pixel verschwendest nicht du in deinem Buffer, sondern die werden im Grafikspeicher frei gelassen. Ein weiteres Beispiel für BPR ist Interleaved Grafik auf den Customchips. Da folgt auf eine Zeile einer BitMap erstmal je eine Zeile der anderen BitMaps. Die BPR Angabe ist dann ein Vielfaches der eigentlichen BitMap-Breite.

Grüzi
 
AC-FoX   Nutzer

21.10.2002, 19:50 Uhr

[ - Direktlink - ] 		Thema: Starten eines neuen Prozesses
Brett: Programmierung

Eine weitere Fehlerquelle ist es auch, daß deine beiden Prozesse gleichzeitig auf die selbe CON: schreiben. Sowas verkraftet die CON: nicht und fängt an, den Speicherinhalt zu ploten.

Grüzi
 
AC-FoX   Nutzer

30.09.2002, 01:47 Uhr

[ - Direktlink - ] 		Thema: Wing Commander II auf dem Amiga?
Brett: Programmierung

Der Vorteil von OpenSource ist der, daß man die Quelltexte hat/kennt. Dadurch kann man sich auf das Portieren konzentrieren.
Soweit ich weiß, sind aber die Wing Commander Spiele von Origin nicht freigegeben worden. Das heißt, man müßte schon mit reverse-engineering arbeiten, um den Code von WC zu bekommen und was Amiga-mässiges draus zu machen.
Und sowas ist wohl erstens illegal und zweitens so aufwendig, daß eher Wing Commander Teil 5 rauskommt, bis man auch nur einen Teil fertig hat.

Grüßli
 
AC-FoX   Nutzer

26.09.2002, 00:10 Uhr

[ - Direktlink - ] 		Thema: keine IFF-Bilder!
Brett: Amiga, AmigaOS 4

Ähm mal langsam :)
Auch wenn du es nicht geschrieben hast, nehme ich mal an, daß du damit meinst, daß immer, wenn du ein ILBM Bild mit einem Anzeigeprogramm anschauen willst, sich ein PAL Bildschirm öffnet.
So, da wäre hilfreich anzugeben, mit welchem Programm du dir das Bild anschaust. Ist es vieleicht Multiview?
Zum Anderen mußt du auch darauf achten, daß du keine HAM Bilder verwendest. Denn HAM Bilder können nicht auf Grafikkarten ausgegeben werden. Zumindest müßten sie vorher umgerechnet werden.
Dann könnte es noch ein Problem geben, weil ILBM-IFF Dateien oft auch den Bildschirmmodus mitspeichern, auf dem das Bild angezeigt werden soll.
Evtl solltest du also Multiview nehmen, oder ein programm verwenden, bei dem man sich den Bildschirmmodus aussuchen kann, auf dem Das Bild angezeigt werden soll.

Grüzi
 
AC-FoX   Nutzer

25.09.2002, 23:16 Uhr

[ - Direktlink - ] 		Thema: Der Dereferenzierungsoperator
Brett: Programmierung

Alsooooooo
Am Anfang waren die Dinosaurier, doch die starben aus, weil sie zu fett waren...

Die Pointergeschichte wieder :)

"Jetzt stelle wir uns mal janz doof. Wat is denn so ein Pointer, und wat macht der so den lieben langen Tag?"
Eine Variable, die ma mit "int x" anlegt, ist nichts weiter, als ein Speicherbereich (in diesem Falle 4 bytes, weil 32 bit zahl), in dem eine Zahl abgespeichert werden kann.
Dieser Speicherbereich hat eine Addresse. Also wie eine normale Hausaddresse. Und jetzt kommt der Trick. Eine Addresse, die man speichern oder verarbeiten will, ist auch eine 32bit Zahl.
So, und diese Addressenangabe kann man jetzt eben auch wieder in einer Variable speichern.

"So und dat iss nu ein Pointer?"
Deine Variable x, beinhaltet also die Zahl 20. Die Variable y beinhaltet die Addresse, an der die variable x im Speicher liegt. Das wäre irgendwas wie z.B. 0x4c674680.
Wenn du jetzt ein x=20; machst, dann wird an diese Speicherstelle die zahl 20 geschrieben. Der Compiler weiß selbst, wo er hinschreiben muß.
Du kannst aber auch *y=20; machen. In diesem Fall ist y immernoch die Adresse auf x (also 0x4c674680). Durch den Dereferenzierungsoperator weiß jetzt der Compiler aber, daß er nicht direkt diesen Wert überschreiben darf, sondern, daß y nur ein Pointer ist.
Er nimmt also die Zahl 0x4c674680 und interpretiert es als Addresse. Und an diese Addresse schreibt er jetzt den Wert 20. Deshalb bekommst du auch 20 als resultat, wenn du x abfragst.

"Ja, aber wat hat denn jetzt scanf() wieder für ein Problem? Des versteh ich nett!"
Die Funktion übernimmt Parameter als Eingangswerte. Du könntest x irgendeiner Funktion übergeben, aber dann würde nur der Wert, der in x gespeichert ist, übergeben. Doch die Funktion soll ja den Wert in x verändern. Also interessiert es sie nicht, was früher mal in x stand, sondern sie braucht die Information, wo x ist, damit sie den neuen Wert dorthin schreiben kann.
Bei scanf("%i",x); sagst du der Funktion also eigentlich scanf("%i",20);. Und das ist natürlich total nutzlos.
Bei scanf("%i",&x); sagtst du scanf("%i",0x4c674680);. Das ist genau das gleiche wie scanf("%i",y);.
Man beachte den Unterschied zu scanf("%i",*y);. Denn das wäre ja wieder 20 als Parameter.
Auch falsch ist scanf("%i",&y);. Denn in dem Fall übergibst du die Addresse von y. Prinzipiell nicht schlecht, aber dann würde die Funktion scanf den neuen Wert nicht in x speichern, sondern in y.
Ganz schlimm wirds bei scanf("%i",x);. Hier übergibst du die zahl 20 als Addresse. Dann schreibt scanf auch an die Addresse 20 im Speicher. Das könnte zu ganz miesen Abstürzen führen, und wirft mindestens einen Enforcer Hit.
Was ein Enforcer Hit ist, das erzähl dir ich in der nächsten Folge von "Programmieren leicht gemacht und umsonst".

Grüzi

[ Dieser Beitrag wurde von AC-FoX am 25.09.2002 editiert. ]
 
AC-FoX   Nutzer

25.09.2002, 22:15 Uhr

[ - Direktlink - ] 		Thema: Der Dereferenzierungsoperator
Brett: Programmierung

Also dann erzähl mal, welche Konstellation du mit nicht-lauffähig meinst.
scanf("%i",*y); sollte nicht funktionieren, da y ja schon ein Pointer ist.
scanf("%i",y); müßte funktionieren, da der Wert von y die Addresse von x ist.
Dementsprechend müßte auch scanf("%i",&x); funktionieren.

Grüßli
 
AC-FoX   Nutzer

25.09.2002, 21:27 Uhr

[ - Direktlink - ] 		Thema: Der Dereferenzierungsoperator
Brett: Programmierung

Öhm, wo kommt denn das "z" her? Ich denke mal, das soll "y" heissen, oder?
Das zu %i gehörende Argument ist vom Typ int*. Es ist also vollkommen korrekt, einen Pointer bei scanf anzugeben. Die Funktion muß ja die Speicherstelle wissen, wo sie das Ergebnis hinschreiben soll.

Grüzi
 
AC-FoX   Nutzer

03.09.2002, 21:09 Uhr

[ - Direktlink - ] 		Thema: to stack or not to stack?
Brett: Amiga, AmigaOS 4

AMIGA OS DOS Handbuch:

"Stack-Größe innerhalb der aktuellen Shell anzeigen oder festlegen"
[...]
"Jede Shell besitzt eine spezifische Stack-Größe"

Der befehl stack wirkt sich also nur auf die aktuelle Shell aus. Bei der startup-sequence dürfte das die Shell[0] sein? Na jedenfalls ist es bestimmt nicht die Shell, mit der du deine PPC-Spiele startest.
Der Stack-Speicher wird im FAST-Ram angelegt.

Grüßli
 
AC-FoX   Nutzer

26.08.2002, 04:21 Uhr

[ - Direktlink - ] 		Thema: PowerASM
Brett: Programmierung

PowerASM
1997 von Sam Jordan
copyright HAAGE & PARTNER Computer GmbH

Du hast dir die Antwort also selbst schon gegeben. Auf der Homepage von H&P steht im OnlineShop ein Preis von 99 Euro. Einfach nur mal nachschauen - kostet ja nix.

Gruß,
FoX
 
AC-FoX   Nutzer

05.06.2002, 17:10 Uhr

[ - Direktlink - ] 		Thema: Big Endian
Brett: Programmierung

Eine Endian-Konvertierung braucht auf einem 68k Prozessor drei Taktzyklen für eine 32 bit Zahl und nur einen Taktzyklus für eine 16 bit Zahl. Der PPC hat extra eine Option, schon beim Laden einer Zahl aus dem RAM, innerhalb des Ladebefehls, eine Endian-Umwandlung durchzuführen. Gilt natürlich nur, wenn man auf Assembler-Ebene programmiert. In einer C-Implementation können da schon 4-12 CPU Befehle allein durch eine Konverter-Funktion ausgelöst werden - nicht gerechnet den Funktions-Overhead, falls man den Code nicht als inline einbindet.
Die 5%, die der PPC also langsamer sein soll sind also höchstens ein
Mittelwert und durch "angepaßte" Programmierung fast vermeidbar. Wenn jedoch durchgängig alle Systemstrukturen Little-Endian sein müssen, dann sollte man dem C-Compiler eine extra Direktive spendieren, damit er schon auf CPU-Ebene eine Endian-Konvertierung durchführen kann. Evtl geht da aber auch ein prozessorspezifisches "inline __asm LONG EndianConvertLONG(LONG value __asm("d0"))".

My 2 bits :)
 
AC-FoX   Nutzer

02.06.2002, 16:20 Uhr

[ - Direktlink - ] 		Thema: Big Endian
Brett: Programmierung

Bezeichnet die Art und Weise, wie Zahlenwerte, die größer als ein Byte sind, im Speicher abgelegt werden.
Neben Bytes (8-bit breit) gibt es noch Words (16-bit breit) und Longs (32-bit breit) als grundlegende Datentypen.
Im Rechner ist der Speicher jedoch nur in Bytes adressiert. Wenn man jetzt ein Word oder Long aus dem Prozessor in den Speicher legt, gibt es zwei Möglichkeiten, in welcher Reihenfolge die 2 oder 4 Bytes, aus denen das Word oder Long besteht, geschrieben werden.
Beim Big Endian Mode oder auch MSB (most significant byte first) wird das höchste Byte in die unterste Speicherstelle gelegt. Beim Little Endian Mode oder LSB (least significant byte first) wird das unterste Byte zuerst geschrieben.
Stell dir vor, du hast die Zahl 12345678. Und es passen nur jeweils zwei Ziffern in eine Speicherstelle im RAM. Im Big Endian Mode würde dann im Speicher stehen (beim untersten Byte angefangen zu lesen) "12345678". Im Little Endian Mode würde da "78563412" stehen - die am wenigsten wichtigen Ziffern "78" sind hier also zuerst in den Speicher geschrieben worden.
Das IMHO viel intuitivere Big Endian wird von den 68k, den PowerPC und weiteren Prozessoren als normaler Arbeitsmodus benutzt.
Little Endian wird vor allem bei der x86 Prozessor-Linie benutzt - aber die sind ja sowieso nicht ganz dicht :)
Die Probleme mit dem Endian-Mode treten vor allem bei Dateiformaten auf, bzw beim Konvertieren von binären Dateien eines anderen Rechnersystems auf. Das Umwandeln von einem Typ in den anderen kostet nicht viel Rechenzeit. Allerdings ist die Frage, wann und wie man konvertiert meist eine willkommene Quelle für Bugs.

Gruß
 
AC-FoX   Nutzer

15.03.2002, 01:57 Uhr

[ - Direktlink - ] 		Thema: DivX ?
Brett: Amiga, AmigaOS 4

Tja, ist wohl ne alte Weisheit, daß bei einem Video-Playback der Sound flüssig sein muß und die Grafik dazu synchronisiert wird. Und wenn eben die Grafik nicht mehr schnell genug ist - skippen. Ganz einfach, oder? :)

Grüzi
 
AC-FoX   Nutzer

07.01.2002, 22:28 Uhr

[ - Direktlink - ] 		Thema: Bitte Leute !!!
Brett: Get a Life

Wenn es nicht so ein tragisches Licht auf die Gemeinde werfen würde, könnte man sich über sowas nur noch kaputtlachen.
Mal schauen, das Treker Profil wurde um 18:19 Uhr erstellt, OxygeneIV um 19:13 Uhr. Hier macht sich jemand einen Spaß. Er hat wohl garantiert selbst einen Amiga und will nur mal etwas "Luft" aufwirbeln. Beide anonymen Profile werden IMHO von ein und dem selben User benutzt.
Aber jeder Amiga User, der sowas liest, wird bis aufs Blut gereiz und bekommt seine Finger nicht mehr unter Kontrolle, bis er einen Kommentar abgegeben hat. Selbst die besten Ratschläge, sich doch seinen teil nur zu denken und NICHTS zu schreiben werden zugunsten Ehrenrettung über Bord geworfen.
Am lustigsten sind noch die Replys, die versuchen, dem Treker ein gutes Benehmen einzuimpfen. Leute, das ist ein Fake! Der unbekannte Autor lacht sich sein Fortpflanzungsorgan ab, wenn er sowas liest. Jungs, seid ihr leichtgläubig. Treker hat meiner Meinung einen ziemlich schrägen Humor, aber die leute sind so lustig, wie sie voll darauf einsteigen :)
Ach ja. Ich habe den Müll nicht verzapft, aber für den Streich wird mir Treker fast schon sympatisch - :-D

Gruß,
AC-FoX
 
AC-FoX   Nutzer

27.11.2001, 16:59 Uhr

[ - Direktlink - ] 		Thema: Ich vermisse Ein Threads! Petra hast du es gelöscht ???
Brett: Forum und Interna

Hallo Archeon,

schau doch auf die zweite Seite des Forums, da ist noch ein Thread, der genauso heißt.

Gruß
 
AC-FoX   Nutzer

15.11.2001, 22:04 Uhr

[ - Direktlink - ] 		Thema: RGB-Werte umrechnen?
Brett: Amiga, AmigaOS 4

Denk dir mal statt des Smileys eine 8 und eine geschlossene Klammer danach. Wurde hier als Smiley interpretiert.

Gruß
 
AC-FoX   Nutzer

15.11.2001, 22:02 Uhr

[ - Direktlink - ] 		Thema: RGB-Werte umrechnen?
Brett: Amiga, AmigaOS 4

Hallo Torben,

also eigentlich brauchst du nur die 3 Bytes wieder aus dem 32 bit Int extrahieren.
Beispiel:

BYTE blue(RGB)
{
return (0xff & RGB);
}

BYTE green(RGB)
{
return (0xff & (RGB >> 8) );
}

BYTE red(RGB)
{
return (0xff & (RGB >> 16));
}

Das sollte klappen, wenn man mal animmt, daß du eine Ganzzahl übergibst, die 0RGB organisiert ist.
Mit dem (0xff & ..) maskierst du genau ein Byte aus, das zurückgegeben wird. Mit dem (RGB >> ...) shiftest (schiebst) du die Ganzzahl die entsprechende Anzahl von Stellen nach rechts.

Gruß
 
AC-FoX   Nutzer

10.08.2001, 13:48 Uhr

[ - Direktlink - ] 		Thema: Neue Site für PPC , PCI und Warp 3D
Brett: Amiga, AmigaOS 4

Hi Falke

schoene Sammlung von Tools. Aber noch ein paar Fehler auf der Seite. In der Games Sektion sind einige Links nicht richtig gesetzt.
WipeOut hat gar keine URL und wenn man sich ueber Tales of Tamar informieren moechte, wird man zu clickboom geschickt, da muss natuerlich http://www.tamar.net rein :) )
Achja, neueste Warp3D ist V4.2
Ansonsten sehr gut gelungen :look:

Gruss
 
AC-FoX   Nutzer

09.08.2001, 16:03 Uhr

[ - Direktlink - ] 		Thema: Hydra Ethernet und Twisted Pair aber wie ?
Brett: Amiga, AmigaOS 4

@ Daniel
Na du bist ja vieleicht lustig. Ich als einziger, der sich hier noch erinnert, was eine Hydra Amiganet ist, und versucht, bei dem Problem zu helfen, bin also nur jemand, der aus lauter Langeweile Postings schreibt? :angry:
Ich kann doch auch nix dafuer, dass sich die Netzwerkkarte mit den verschiedenen Revisionen aendert.
Wie soll man denn deiner Meinung nach sonst auf so einen Hilferuf reagieren? Kann ich wissen, ob meine Ratschlaege Infinity wirklich helfen? Bin ich jetzt der Buh-Mann, weil ich daneben gelegen hab?
Zum Helfen braucht es eben etwas Kommunikation. Jetzt ist mir auch klar, dass ich ihm nicht helfen kann, weil meine Erfahrungen mit der Karte fuer ihn nicht nutzbar sind.
Aber dass ich versucht habe, ihm dabei zu helfen, sein Problem in den Griff zu bekommen, muss ich mir doch jetzt nicht als negativ ankreiden lassen.
Zumindest ist dein Beitrag auch einiges davon entfernt, zur Problemloesung beizutragen - Eigentor :P

Gruss
 
AC-FoX   Nutzer

08.08.2001, 17:15 Uhr

[ - Direktlink - ] 		Thema: Hydra Ethernet und Twisted Pair aber wie ?
Brett: Amiga, AmigaOS 4

Tja, ich weiß leider nicht mehr, welche Version meine alte Hydra hatte. Aber sie hatte definitiv keinen AUI Stecker, sondern BNC und RJ45, sowie eine Jumperleiste zum Umschalten.
Schon mal im "Big Book of Amiga Hardware" nachgeschaut?
Eigentlich haben alle modernen Netzwerkkarten eine automatische Umschaltung und erkennen, an welchem Anschluß was hängt. Ist auch nur ein Anschluß belegt, also entweder BNC oder TP?

Gruß
 
AC-FoX   Nutzer

08.08.2001, 13:07 Uhr

[ - Direktlink - ] 		Thema: Hydra Ethernet und Twisted Pair aber wie ?
Brett: Amiga, AmigaOS 4

Ich hatte frueher mal eine Hydra Ethernet Karte. Soweit ich mich erinnern kann, musste man eine ganze Batterie von Jumpern umstecken, um von BNC auf TP Modus umzuschalten. Schau mal in die Naehe das Anschlussbleches. Da sollte eine Reihe von ca 8-10 Jumpern sein. Oder schau mal ins Handbuch (falls du es gerade zur Hand hast).

Viel Glueck
 
AC-FoX   Nutzer

20.07.2001, 21:51 Uhr

[ - Direktlink - ] 		Thema: Shogo - Level 22 - Ich werde noch wahnsinnig
Brett: Amiga, AmigaOS 4

Nein, wirklich???
 
 
-1- 2 Ergebnisse der Suche: 35 Treffer (30 pro Seite)

Suchbegriffe
Schlüsselwörter      Benutzername
Suchoptionen
Nur in diesen Foren suchen
   nur ganze Wörter
Nur Titel anzeigen
alle Treffer anzeigen

.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.