Zitat:

---

Original von Holger:

Zitat:

---

Original von MaikG:
Habs erst mit MEMF_CLEAR versucht, mit Chip und dann mit
beiden. Ich bekomme nur eine graue Linie.

---

Laß mich raten, Deine Hintergrundfarbe ist grau?

Was hast Du denn erwartet?

mfg

Nachtrag: Wenn ich mich recht entsinne, beherrschte die CV64 das konvertieren von True/Pseudocolor in die 8Bit-Werte passend zur jeweils aktuellen Palette. Bei anderen Grafikkarten kannst Du das nicht erwarten...

[ Dieser Beitrag wurde von Holger am 11.12.2005 um 20:19 Uhr editiert. ]

---

Was er erwartet hat? Das ReadPixelLine8() die korrekten Palette-Werte in sein Array schreibt. Das kann allerdings nicht funktionieren, wenn er "irgendwas" als Quell-RastPort angibt (rp = *win->RPort).

Mit der CV64 hast Du insofern Recht, wenn denn ROMBLER drauf sitzt. Ansonsten wird das von der GraKa-Software gehandhabt (Stichwort WriteChunkyPixels() und deren Fähigkeit, Hardware für die Konversion zu benutzen, sofern vorhanden. Ansonsten Software). Inzwischen sind CGFX/P96 so weit, daß die Palette-Emulation in allen Modi sehr gut funktioniert. Sonst würde kein Programm, welches auf Paletten-Indizes basiert, auf einem HighColor/TrueColor-Bildschirm vernünftig laufen.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Holger:

Zitat:

---

Original von whose:
Öhm, ist ja richtig, daß es noch schneller ist, gar keine dieser Operationen durchzuführen, sofern das machbar ist. Hier gings aber um Read-/WritePixelLine8() sowie WritePixelArray8(), und diese Funktionen benötigen nun einmal ihre Daten in einer durch 16 teilbaren Anzahl.

---

Wo man aber weder Multiplikation/Division, noch shift benötigt.

---

Zitat:

---

Zitat:

---

Das man mit (((width+15)>>4)<<4) eine Eigenschaft von Integerzahlen in ihrer binären Repräsentation ausnutzt, ist dabei doch nur natürlich. Und auf 68K-Maschinen ist das schneller als die entsprechenden logischen Operationen. Streng genommen eigentlich auf nahezu allen älteren CPUs.

---

Das will ich doch mal sehr bezweifeln. Auf dem 68060 beanspruchst beide integer-Einheiten mit von einander abhängigen Operationen, auf dem 68000 hängt die Ausführungszeit von der shift-Weite ab, und ab irgendwo dazwischen ein Prozessortyp existiert, bei dem zwei shift-Operationen tatsächlich schneller als eine AND-Operation sind, und der tatsächlich in einem realen AMiga verbaut wurde, vielleicht, ich glaube es aber eher nicht.

---

Du denkst aber hoffentlich noch an die NOT-Operation, die auf das AND folgt? Sieh Dir das Ganze mal als Assembler-Quelltext an, beide Versionen. Dann urteile, was mehr und was weniger Zyklen benötigt. Ich glaube kaum, daß sich die Gurus das aus Jux und Dollerei ausgedacht haben, oder weil die etwas gegen "saubere" Programmierung hatten. Das hatte (wie eigentlich immer) seinen ganz speziellen Grund.

Schaden kanns jedenfalls nicht, wenn man ihm erklärt, was da genau passiert und warum, und ich denke, er wird sich die von Dir vorgeschlagene Variante auch schon mal in Binärrepräsentation angesehen haben. Wenn nicht, wird er es spätestens jetzt tun, denk ich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:
Es geht nicht :-(


struct Window *win;
struct RastPort temprp;
struct RastPort *rp;
UBYTE *LinieS; /* Speicher für Linien zwischenpufferung*/

Fenster öffnen, Font öffnen...

LinieS = AllocVec((((304+15)>>4)<<4), MEMF_CHIP+MEMF_CLEAR);
if (LinieS)
{
temprp = *win->RPort;
temprp.Layer = NULL;
temprp.BitMap = AllocBitMap (304,1,8,0,NULL);
ReadPixelLine8 (rp,20,40,304,LinieS,&temprp);
WritePixelLine8 (rp,20,41,304,LinieS,&temprp);
FreeBitMap (temprp.BitMap);
FreeVec(LinieS);
}

Habs erst mit MEMF_CLEAR versucht, mit Chip und dann mit
beiden. Ich bekomme nur eine graue Linie.
Ich hatte auch noch 324 u. 323 statt 304 probiert.

---

Ok, also als erstes solltest Du etwas bei den MemType-Flags ändern. Korrekt lautet das

MEMF_CHIP|MEMF_CLEAR

also ODER-verknüpfen.

Des weiteren hast Du einen winzig kleinen Fehler in

temprp = *win->RPort;

Der * gehört da nicht hin, denn damit erreichst Du genau das, was bei temprp ohne &-Operator passiert. Es wird der Inhalt der RastPort-Struktur übergeben, nicht der Zeiger auf den Beginn dieser Struktur.

Deswegen erhältst Du auch die graue Linie. Das, was da als scheinbarer RastPort übergeben wird, zeigt irgendwohin im Speicher, da die Linie grau wird, offensichtlich ein Bereich, welcher mit 0 gefüllt ist. Bemerkenswerterweise wird ja trotzdem eine Linie gezeichnet, obwohl rp "irgendwohin" zeigt, nur nicht auf den RastPort des gemeinten Fesnters. Frag mich aber jetzt nicht, warum da sichtbar gezeichnet wird. Vermutlich ein (ungewollter) Seiteneffekt der Struktur.

Nimm den * bei *win->RPort weg, dann sollte es funktionieren.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:
Struct hab ich noch nicht kapiert, gabs unter basic nicht.

da war das halt rp&=PEEKL(mywin&+rport) - irgendwas definieren musste
ich nicht...

---

Zitat:

---

Gut mit den #?8 Funktionen bekommt man also nur die ersten 256 Farben
der Workbench.

---

*hüstel* nein, Du bekommst die maximal möglichen 256 Farben der Palette der Workbench, sofern vorhanden. Und das sogar in Modi, die gar keine Palette im herkömmlichen Sinn bieten.

Bietet der Bildschirm aber weniger als 256 Farben, bekommst Du auch dementsprechend nur kleinere Palettenindizes, z.B. bis maximal 128, sofern die Farbtiefe des Bildschirms so eingestellt ist. Du solltest immer daran denken, daß die Bittiefe durchaus auch mal kleiner als 8 sein kann.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von MaikG:

Aha, dieses Shiften << >> hab ich noch nie gemacht, von daher
ist die gleichung für mich etwas unbekannt.

---

Nun weißt Du, wozu das gut ist Wie gesagt, das kann man auch bei anderen Gelegenheiten gut gebrauchen.

Zitat:

---

> Dafür wird u.A. auch temprp benötigt.

Aber da reicht dann dieses
struct RastPort temprp;
Muss ich also nichts weiter damit machen?

---

Zitat:

---

>Die 8, die hinter den Funktionsnamen steht, deutet darauf hin,
>daß diese Funktionen mit einer Farbtiefe von max. 8Bit (!)
>arbeiten.

Die Linie darf nur max. 8 Bit tief sein, das es in einem Fenster
auf der Workbench mit 16 Bit ist stört ja nicht, wenn ich das
richtig verstehe. Hab ja schon kurz die WritePixelArray8 benutzt.

---

Nein, es stört nicht (CGFX/P96 "emulieren" auch auf Screens >8Bit eine 8Bit-Palette). Du bekommst in jedem Fall nur Palette-Indizes zurück, also 8Bit-Einträge. Es kann Dir natürlich passieren, wenn Du die ...8()-Funktionen und CGFX/P96-Funktionen (also die ohne 8 ) mischst, daß Du dann eine 0 zurückbekommst. Also Obacht und darauf testen. Ist zwar nicht offiziell so dokumentiert, aber ich meine, bei ReadPixelLine8() käme als "count" 0 bzw. eine Zahl kleiner als Deine Linienbreite, wenn sich kein Palette-Index zuweisen läßt

Beim Setzen einer Linie passiert das Gleiche, es wird von WritePixelLine8() nur eine Linie mit den Farben der entsprechenden Paletten-Indizes aus Deinem Array gezeichnet.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 11.12.2005 um 00:21 Uhr editiert. ]

Zitat:

---

Original von Supimajo:

Möge jeder Mitleser sich sein eigenes Urteil bilden. Aber in meinen Augen hast du keinen blassen Schimmer von der Aufgabe und der Verantwortung, die der Status eines Moderators mit sich bringt und bist demzufolge hier absolut fehl am Platz.

---

Auch Du lernst ungern dazu, kann das sein? Als ob es nicht genügt hätte, eine Aktion öffentlicher Demontage zu starten und die wieder zurückzuziehen, jetzt geht das hier wieder los, nur diesmal subtiler.

Du hättest Dir diesen letzten Absatz sparen können und Dein Manifest zur Diskussion stellen, das hätte vollauf genügt, da bin ich mir sicher.

Aber nein, zusätzlich zu Deiner eigenen (und Dir weiterhin unbenommenen) persönlichen Meinung kommt mal wieder was mit Scheinlogik und Absolutheitsanspruch in Verbindung mit Demontagedrohungen. Laß das doch endlich mal und erweise Dich auch hier als der faire und sachliche Diskussionspartner, der Du oft genug bist!

Wenn Maja sich als dieses Postens auch in den Augen anderer als unwürdig erweisen sollte, wird sich das schon zeigen. Du mußt das nicht durch Scheinlogik forcieren (Stichwort: demzufolge).

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 27.11.2005 um 02:48 Uhr editiert. ]

Zitat:

---

Original von Maja:
@AndreasM:

> Dann solltest Du vielleicht Deinen Moderatoren Posten abgeben...
> Oder wie willst Du sicherstellen das keine illegalen Inhalte im
> Forum landen?

Ich entschuldige mich untertänlichst, dass ich nicht allwissend bin und es gewagt habe, eine kurz hingeworfene Aussage von dir als nicht aussreichend zu empfinden.

Was den "Ton" betrifft. Ich konnte nicht Ahnen, dass du so empfindlich bist, sonst hätte das Ganze mit etwas Honig garniert.

*nichtzufassenmanchmal*

---

Zitat:

---

@Supimajo

Ich warte jetzt nur noch auf die nächste Prangeraktion von dir. Gibst dir ja wieder redlich Mühe, mich rauszuekeln. Ich muss dich aber enttäuschen. Ich fühle mich in keinster Weise belastet. Auch nicht von deiner Meinung über mich.

---

Das ist genauso ein Unding. Die Prangeraktion ist passiert, Supimajo hat sich sehr wort- und gestenreich dafür entschuldigt und Euch voll rehabilitiert. Was gibt es da jetzt noch drüber zu mäkeln? Willst Du ihm das wie ein trotziges Kind jahrelang nachtragen? Sei mir nicht bös, aber mit einem solchen Habitus sollte man keine Stelle in einer Gemeinschaft einnehmen, die auf Mäßigung und Ausgleich gerichtet ist.

Könnte man sich nun endlich mal darauf einigen, daß AndreasM seine Aussage keineswegs leichtfertig in den Raum gestellt hat und das auch Moderatoren nicht unfehlbar sind? Das wäre mal ein echter Fortschritt hier...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von bernd_roesch:
Ich habe nur das allererste amidev benutzt.(dauert ja sehr lange mit 68k modem runterzuladen)

Ich habe die (hyper)layers.library von AROS damit compiliert um damit mal die OS3.1 layerslibs
zu ersetzen.das compilieren habe ich hinbekommen,aber beim linken kommt der linker fehler _kprintf
fehlt.andre errors bekomme ich keine

Ich habe dann das lib verzeichniss nach text durchsucht,aber fand keinen Befehl kprintf.

irgendwie fehlt der bei amidev.hat da jemand ne lib dafür.Mein alter Aztec C hatte den Befehl auch,
müsste also in C linkerlib sein.nur die linker libs sind nicht kompatibel,so das ich das aztec C zeugs nicht nutzen kann

irgendwie gab es mal ne amigalib wie ich mich dunkel erinner wo auch andre amiga typische sachen drin waren

---

kprintf() befindet sich meines Wissens nach in der debug.lib, also gesondert von der amiga.lib, welche Du meintest. Muß ich mal nachschauen, wo die in AmiDevCpp abgeblieben ist. Sobald ich wieder zu Hause bin, kümmere ich mich darum.

@Kaesebroetchen:

Wie TerA zeigte, paßt also die ganze Geschichte doch noch nicht. crt0.o gehört zum GCC. Ich vermute mal, daß das der CygWIN-Part des ganzen Pakets ist, oder? Klingt jedenfalls wahrscheinlich, nachdem es bei mir problemlos läuft, ich hatte es ja schon einmal installiert. Was ich allerdings nciht begreife ist, daß es einwandfrei funzt, obwohl sich nun alles auf einer ganz anderen Partition befindet

Also noch Nacharbeit an den Pfaden...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Kaesebroetchen:
@whose:
Das Intuition Beispiel sollte sowohl mit C als auch C++ kompilieren.
Bei mit trat zwischenzeitlich bei C++ der Fehler "crt0.o not found" und bei C "Segmentation fault" auf.

---

Hier gabs keine Probleme. Vorher alte Installation auf C: beseitigt und auf D: installiert, Anwendungsdaten habe ich aber drin gelassen, um zu prüfen, ob der Installer korrekt arbeitet. Tut er, die Daten werden überschrieben. Compilieren geht problemlos, sowohl im C- als auch C++-Modus.

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Kaesebroetchen:
@Alle

Ich würde schon gerne wissen, ob jetzt alles fehlerfrei funktioniert.
Hat mal jemand die letzte Version (v0.4) getestet ?

---

Hab sie nur kurz und unvollständig antesten können (wg. Mangel an geeigneten C++-Quellen vor allem ). C-Quellen werden aber anstandslos kompiliert (sogar mit den nervigen Makros )

Bisher habe ich aber keine eklatanten Mängel bemerkt. Ich werd morgen auch noch mal den Verzeichnisbaum kontrollieren, ob jetzt alles sein Richtigkeit hat, im groben Überblick sah es aber gut aus.

Gute Arbeit!

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Kaesebroetchen:

Zitat:

---

Nee, das meinte ich nicht. Der Crosscompiler läuft dann doch ein wenig fixer als der native GCC. So ne Art "Docking Port" in WinUAE, um ausführbare Programme direkt an WinUAE zu übergeben war die Idee, die dahinter steckt. Also quasi eine noch engere Zusammenarbeit zwischen DevC++ und WinUAE. Müßte man mal mit Bernd Roesch bekaspern, wenn er nicht gerade wieder auf einem "OS4 ist unvollständig"-Trip ist. Dann könnte man evtl. sogar Debugging aus DevC++ heraus ermöglichen...

---

Vielleicht fragst du ihn gleich mal ?

---

Ich weiß nicht, ob er mich noch lieb hat, nachdem ich ihn wegen seiner Sprüche zu OS4 mal auf die Füße getreten bin

Zitat:

---

Zitat:

---

Meinst Du denn, daß das Paket inzwischen für die Allgemeinheit tauglich ist? Ich meine, ja. Nachdem die Verzeichnisstrukturen jetzt stimmig sind und keine größeren Probleme aufgetaucht sind... ein Eintrag ins AN wäre da angebracht, damit das auch die mitkriegen, die hier im Forum selten mitlesen

---

Ich will vorher noch die Fehler beseitigen, die Holger angesprochen hat.
Die sind nämlich doch noch drin. Ich hatte mich da wohl vertan (sorry Holger).
Außerdem will ich das Installationsprogramm noch soweit anpassen, das man zumindest zwischen deutsch und englisch wählen kann.

Ein paar hübschere Programmvorlagen wären sicher auch nicht verkehrt...

---

Ok, dann beheb mal die Fehler noch und wenn Du noch Pakete sehen möchtest, sag einfach mal, welche. Ein bissi Zeit zum Zusammenstellen und Testen müßte ich finden, denke ich

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233

Zitat:

---

Original von Kaesebroetchen:
@whose:
Eigentlich dachte ich, das ich daß schon erledigt hätte mit der -s Option. Bei mir waren die erzeugtem Executables jedenfalls um mehr als die Hälfte kleiner als am Anfang.
Guck mal ob in Werkzeuge->Compiler Optionen auf der ersten Seite unten bei "diese Befehle der Linker Kommandozeile hinzufügen" ein "-s" eingetragen ist und das Häkchen aktiviert ist.

---

Jup, daran lags, nun ists besser mit der Größe

Zitat:

---

Zitat:

---

Jetzt wärs noch endgeil, könnte man die Programme direkt zum WinUAE schicken, ohne das man extra die PC-Laufwerke einbinden muß

---

Dann könnte man aber aus devcpp auch gleich den nativen gcc ausführen, und die Programme womöglich noch debuggen...

---

Nee, das meinte ich nicht. Der Crosscompiler läuft dann doch ein wenig fixer als der native GCC. So ne Art "Docking Port" in WinUAE, um ausführbare Programme direkt an WinUAE zu übergeben war die Idee, die dahinter steckt. Also quasi eine noch engere Zusammenarbeit zwischen DevC++ und WinUAE. Müßte man mal mit Bernd Roesch bekaspern, wenn er nicht gerade wieder auf einem "OS4 ist unvollständig"-Trip ist. Dann könnte man evtl. sogar Debugging aus DevC++ heraus ermöglichen...

Übrigens: Die DevPak-Anleitung ist klasse! Meinst Du denn, daß das Paket inzwischen für die Allgemeinheit tauglich ist? Ich meine, ja. Nachdem die Verzeichnisstrukturen jetzt stimmig sind und keine größeren Probleme aufgetaucht sind... ein Eintrag ins AN wäre da angebracht, damit das auch die mitkriegen, die hier im Forum selten mitlesen

Gibt sicher noch mehr Leute, die DevC++ als gutes Entwicklungswerkzeug sehen und gebrauchen könnten...

Grüße

--
---

µA1 PPC 750GX-800
A4000 PPC 604e-233