|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Search | [ - Search - New posts - Register - Login - ] |
|
||||||
|
jolo
User
2023-02-23, 21:11 h [ - Direct link - ] |
topic: Workbench release. ??? Hä?
Board: Amiga, AmigaOS 4 Zitat: Wenn Du AltWBench meinst - ich habe es nicht gefunden. ;-) Zitat: Klugscheißermodus an: Das konnte mein A2000 mit Kickstart v33 auch - nur beim Kaltstart musste ich per Diskette den "kickstarten". Danach war resetfest die benötigte Software eingespielt. Klugscheißermodus aus. ;-) Aber Recht hast Du. Die Software zum Booten von einer Harddisk gab es auch im v33 ROM, jedoch war diese fehlerhaft - deshalb klappte das nicht. Zitat: Aus dem Stand: L:Shell-Seg L:Newcon-Handler L:FastFileSystem Diverse neue Druckertreiber. Ein paar CLI-Kommandos wurden überarbeitet. Paar Bugs in Graphics gefixt und ein paar weniger, hinzugefügt. Zitat: Es ist kein Bug. Bugs wurden mit Setpatch abgemildert oder ausgemerzt. "Workbench Release 1.2" wird vom dem Prozess, der den grafischen Dateimanager ("Workbench") darstellt, generiert - und dieser ist nicht in seiner Funktionalität für Kickstart v34 verändert worden, somit stimmt die Versionierung. Da aber die gesamte Software um das Betriebssystem herum unter Umständen auch als "Workbench" bezeichnet wurde, musste das beim Endkunden aufstoßen, ergo hat man LoadWB einen Patch verpasst - und nicht nur diesen... Zur Verdeutlichung - die meisten Ungereimtheiten hat Commodore Amiga selbst verschuldet. Kickstart bezeichnet eigentlich einen Bootstrap-Prozess bei dem die Hardware in einem bestimmten Zustand versetzt wird um ein Programm ausführen zu können. Warum das gesamte WOM/ROM und die Disk-residenten Module als Kickstart bezeichnet wurden, müsste man in Erfahrung bringen, aber ich denke, dass nicht einmal die Entwickler der zweiten Generation das wissen. Mit Workbench bezeichnete selbst Commodore Amiga zwei ganz unterschiedliche Dinge; zum einem die grafische Schnittstelle zum Benutzer, in Form eines Dateimanagers (WorkBench, ab AmigaOS 1.2 umgetauft in Workbench), zum anderen aber die gesamte Palette an Software auf der Boot-Disk (Workbench-Disk). Zu meiner aktiven Zeit sprachen wir das Wort AmigaOS eigentlich eher selten aus; Amiga war die Hardware, also die Kiste vor uns, Kick 1.x stand für das Betriebssystem und Workbench entweder für die Werkbank (Dateimanager), die wir äußerst selten nutzten, oder für die Software auf der Boot-Diskette. Erst mit dem Erscheinen von AmigaOS 3.5/3.9 änderte sich das. Mein A2000 lief unter Workbench 1.3 jedoch mit Kick 1.2, wobei der Dateimanager nach wie vor der, der "Workbench" 1.2" war. Mein A4000 dagegen lief unter Workbench 3.0 mit Kick 3.0. Da wurde nicht über AmigaOS in der Version x.x gesprochen. Das war nicht nur in meiner Sprachregion so, sondern auch bei Treffen im Ausland. Zudem, wer sich mal mit den alten Handbüchern, die mit ihren Amiga ausgeliefert wurden, auseinander setzt, wird feststellen, dass es immer wieder Querverweise auf das Workbench-Handbuch gab, da dort ein umfangreiches Glossar zu finden war. Ergo wurde der/die Endnutzer/in immer mit "Workbench" beschallt. Dass das irgendwann zu einem Selbstläufer wird, versteht sich von selbst. -- Stupid mistakes are always made by others - we only make unavoidable errors |
|||||
|
jolo
User
2023-02-20, 13:25 h [ - Direct link - ] |
topic: Workbench release. ??? Hä?
Board: Amiga, AmigaOS 4 @kadi schon 1989, als ich meinen Amiga500 mit Workbench 1.3 bekam, viel mir der Schriftzug "Workbench release. 874248 free memory" in der Screenleiste auf. "Workbench release."? Hä? Workbench 1.2 und 1.3 unterscheiden sich in der Funktionalität nicht. Für Kickstart v34 (aka Workbench 1.3) enthät LoadWB einen Patch ( SetWindowTitles() ), der die Bildschirmtitel untersucht und " 1.2." mit den Zeichen ". " überschreibt. Siehe Aminet AltWBench/AltLoadWB.c und AltWBench/WBenchPatch.a Falls Du LoadWB durch AltLoadWB ersetzt und mit dem Argument "nopatch" aufrufst, siehst Du den originalen Schriftzug "Workbench release 1.2." auch unter Kickstart v34. |
|||||
|
jolo
User
2019-09-23, 12:21 h [ - Direct link - ] |
topic: Bild aus struct Image + UWORD *ImageData in Malprogramm laden - wie?
Board: Amiga, AmigaOS 4 @Reth Da Du ein 16-Bit-Array hast (ich hoffe in Form eines Quellcodes!), hast Du schon einmal die Daten, also müsste ein RAW-Loader die Grafik unter Falschfarben schon darstellen können, sofern die Breite als Mehrfaches von 16 von Dir spezifiziert wurde und "PlaneOnOff" nicht benutzt wurde. Breite (in Pixels) PLUS 15 AND -16 = tatsächliche Breite (mehrfaches von 16 ('WORD aligned')) Höhe, bleibt Höhe Beispiel: (49 Pixels + 15) & -16 = 64 (tatsächliche Breite) In der Shell kann man das kurz errechnen: 1> eval 49 + 15 & -16 Da ein "Image" nichts über Farben aussagt, musst Du aber im Programm nachschauen, welche Farben benutzt wurden. Ein "Image" ist meist aber ein platzsparendes Format, in welchen nur Daten einfließen, die für eine gesamte "Bitplane" nicht null oder eins sind. Bei einem einfarbigen "Image" wäre "PlanePick" 1 und "PlaneOnOff" 0, bei einem zweifarbigen "Image" aber "PlanePick" 3 und "PlaneOnOff" 0, sofern Du alle vier Farbstifte für die Grafik verwendest. Verwendest Du aber nur die Farbstifte eins und drei, dann wäre "PlanePick" 2 und "PlaneOnOff" 1, wobei nur eine "Bitplane" durch "ImageData" abgedeckt werden müsste. PlanePick = 2 (Daten für Bitplane 1 (%10) kommen aus "ImageData", Daten für "Bitplane" 0 (%01) sind nicht spezifiziert) PlaneOnOff = 1 (setze alle Bits der "Bitplane" 0 (%01) auf eins) heißt, eine 2 "Bitplane" aka 4 Farb-Grafik, wobei alle Bits der "Bitplane" 0 auf eins gesetzt werden, und nur "Bitplane" 1 die eigentlichen Daten enthält (Bit in "PlanePick" ist gesetzt aber Bit in "PlaneOnOff" gelöscht, so dass hier die tatsächlichen Daten aus "ImageData" gelesen werden müssen). Für eine 8-Farben-Grafik, wobei alle Daten aus "ImageData" entnommen werden müssten, würde PlanePick : 7 (%111) ("Bitplane 2, 1 und 0 gesetzt) PlaneOnOff : 0 (%000) (keine einzige "Bitplane" von vornherein eingefärbt) sein. Für AdPro müsstest Du die "ImageData" Daten aber ohne die "Image Struct" als Binärformat aufbereiten, anhand von "PlanePick" und "PlaneOnOff", und dann sichern um diese dann wiederum als RAW einladen. Ich würde aber vorschlagen, ein Programm zu schreiben, das die ASCII-Daten ausliest und als "Brush" speichert - inklusive fest verankerter Farben des Programms - ist einfacher. Noch einfacher ist es aber, das Programm zu kompilieren und auszuführen um dann mittels AdPro die Grafik aus dem laufenden Programm zu übernehmen (Screenshot) - also die Dummy-Methode, wie von Thomas vorgeschlagen. Anbei, Thomas, bist Du auf "PlanePick/PlaneOnOff" in Deinem Beispiel eingegangen? Ich habe schon häufiger Quelltexte gesehen, die immer nur anhand von "Image Depth" die Daten speicherten, was oft nur Müll ergibt. Grüße |
|||||
|
jolo
User
2016-08-06, 15:31 h [ - Direct link - ] |
topic: AmigaBASIC-Objekte in anderes Format konvertieren
Board: Amiga, AmigaOS 4 Ich kann nur spekulieren, aber da Shapes (der C16/Plus 4 lässt grüßen) auf dem Bob-Record aufbauen, denke ich, dass man keine Farben definieren muss - also die Farben nicht mit dem Objekt selber abgespeichert werden, es sei denn, man speichert das Objekt als Sprite, wobei dann allerdings nur vier Bytes auch nur drei Farben aufnehmen können (R4B4G4 - 12 Bit!) - ich denke, dass die transparente Farbe ausgespart wird. Ist aber nur eine Vermutung. Hier die vordefinierten Farben des Kickstart v33/v34. code:Bitplane Nummer Farbe Klartext 0 0 $05A Blau 1 1 1 $FFF Weiß 1 2 2 $002 Schwarz 1 3 $F80 Orange 3 4 $00F Blau 2 5 $F0F Pink 6 $0FF Türkis 7 $FFF Weiß 2 4 8 $620 Dunkelbraun 9 $E50 Orange 10 $9F1 Hellgrün 11 $EB0 Ocker 12 $55F Hellblau 13 $92F Violett 14 $0F8 Neongrün 15 $CCC Hellgrau 2 5 16 $000 Schwarz 2 17 $E32 Rot 18 $000 Schwarz 3 19 $F96 Fleischfarben 20 $444 Dunkelgrau 1 21 $555 Dunkelgrau 2 22 $666 Mittelgrau 1 23 $777 Mittelgrau 2 24 $888 Mittelgrau 3 25 $999 Mittelgrau 4 26 $AAA Mittelgrau 5 27 $BBB Hellgrau 1 28 $CCC Hellgrau 2 29 $DDD Hellgrau 3 30 $EEE Hellgrau 4 31 $FFF Weiß 3 Das erste Hardware-Sprite (OCS-Sprites: maximal 16 Bits breit und 4 Farben, alle in Bitplane 5 angesiedelt) übernimmt immer die Farben der Bitplane 5, also standardmäßig transparent (Schwarz 2 wird nicht dargestellt), Rot, Schwarz 3 und Fleischfarben. Öffnet man einen eigenen Bildschirm unter OS 1.2, 1.3, muss man auch zwingend die Farben (z.B. mit LoadRGB4()) verändern, ansonsten erhält man wieder diese vordefinierten Farben. In wie weit das Werkzeug zum Erstellen der Shapes das beim Abspeichern der Daten berücksichtig, kann ich nicht sagen. Um AmigaBasic und Basic im Generellen, habe ich immer einen großen Bogen gemacht. Ich denke aber, dass man bei einer veränderten Farbpalette ohne den zugehörigen Basic-Quellcode nicht wirklich ein eins-zu-eins Abbild schaffen kann, da nur im Quelltext selber die Farben definiert sind - wozu soll man bei einem Bob (AmigaBasic nennt diese Shapes) denn eine Farbpalette mitgeben? Bobs sind nur binäre Datenwörter ohne Farbinformationen - das Remappen muss man heutzutage (True/Hicolour/256 Farbpalette) schon selber vornehmen. Aber wie gesagt, ohne den AmigaBasic-Quelltext, der die Farben definiert, wird es schwer. Thomas, vielleicht helfen Dir die oben vordefinierten Farben ein bisschen weiter. |
|||||
|
jolo
User
2013-10-13, 17:35 h [ - Direct link - ] |
topic: CRYENGINE Free SDK ist das was für unseren Amiga Plattform?
Board: Amiga, AmigaOS 4 @xXSoul-Reaver-2006Xx: Wenn Du Microsoft dazu bewegen kannst, DirectX und speziell Direct3D auf die jeweilige Plattform zu portieren... Jetzt mal im Ernst, nein, ist nutzlos. |
|||||
|
||||||
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|