|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
|
uho
Nutzer
18.03.2008, 19:04 Uhr [ - Direktlink - ] |
Thema: V: Hardware, Software, Bücher, Zeitschriften, ...
Brett: Kleinanzeigen (keine Auktionen!) Hallo FlipFlop, würde gerne alle Kickstart-Magazine ab 1/1989 nehmen ! (Kann man Dich auch per Mail erreichen ?) Gruß uho |
|||||
|
uho
Nutzer
12.03.2008, 22:24 Uhr [ - Direktlink - ] |
Thema: V: 64Mb PS/2-Riegel
Brett: Kleinanzeigen (keine Auktionen!) Hallo, vielen Dank für den vielen Speicher !!! Wenn ich bedenke, daß ich - als der Speicher für meinen A500+ schon etwas "billiger" war - noch knapp 6000 DM hätte hinblättern müssen - pro Riegel, versteht sich - lernt man die schlechten Eigenschaften von Winshit (u.a. exorbitante Speicherverschwendung) erst richtig zu würdigen. Was für den PC-Nutzer nur noch Elektronikschrott, ist für uns eine kaum auszuschöpfende, wertvolle Byte-Quelle. Also nochmals danke. War 'ne klasse Aktion! Gruß uho |
|||||
|
uho
Nutzer
12.03.2008, 22:16 Uhr [ - Direktlink - ] |
Thema: Suche einige Amigatitel :)
Brett: Amiga, AmigaOS 4 Hallo, ist zwar schön, daß ihr alle so hilfsbereit seid. Andererseits hat sich jeder, der hier antworten konnte, als Nicht- AmigaOS- _Nutzer_ geoutet. Pfui ! Schämt Euch ! Gruß uho |
|||||
|
uho
Nutzer
03.03.2008, 20:14 Uhr [ - Direktlink - ] |
Thema: Eigene IP ermitteln?
Brett: Programmierung Hallo, hab zwar mit Netzen nicht viel am Hut, aber zum Schmunzeln ist der Thread allemal. Jedenfalls hab ich die zuerst genannte Webseite auch mal aus- probiert und dabei festgestellt, daß nur die Hälfte meiner IP veränderlich ist - wohl providerspezifisch. Es heißt ja immer, daß sich die IP komplett ändert. Was mich aber sehr wunderte, wie diese Seite sowohl meinen Browser incl. Version als auch mein Betriebssystem (!!) kannte. In den Einstellungen von IB hab ich keine derartigen Angaben gefunden. Oder habe ich nur nicht richtig gesucht ? Kann man diese Meldungen beeinflussen ? Gruß uho |
|||||
|
uho
Nutzer
24.02.2008, 16:59 Uhr [ - Direktlink - ] |
Thema: Draco DV-Modul zum PC
Brett: Amiga, AmigaOS 4 Hallo julius, hab mal meinen Vater befragt; die Sache läuft folgendermaßen: In MovieShop >RAmiga< + >e< tippen, im sich öffnenden Fenster "dvmode out". Diese Einstellung wird leider andauernd vergessen, so daß sie direkt vor jedem Überspielen neu eingegeben werden muß. Das Video kann dann über Firewire problemlos in Edius eingelesen werden. @alle: Übrigens sind bei uns sehr fundierte - und großteils auf dem Amiga erstellte - Dokumentationen zur Motorradgeschichte der Firmen DKW und MZ - einst weltgrößte Motorradbauer - zu haben. Falls also jemand von Euch (oder eher: Euren Eltern) Interesse haben sollte: Einfach bestellen (VHS oder DVD). Highlight für Amiga-Fans: Das Logo unseres Film- und Videoclubs besteht aus einer Render-Sequenz, die mit Imagine erstellt wurde ! Gruß uho |
|||||
|
uho
Nutzer
12.02.2008, 12:26 Uhr [ - Direktlink - ] |
Thema: V: Unmengen Amiga Zeitschriften ab 1987
Brett: Kleinanzeigen (keine Auktionen!) Hallo, mich interesieren - 68000er+Kickstart -> Preis ? - ASpecial 89-91 -> Preis ? Würde - falls bezahlbar - auf jeden Fall letzteren Posten nehmen, bei günstigem Preis auch Ersteren. Gruß uho |
|||||
|
uho
Nutzer
27.01.2008, 19:12 Uhr [ - Direktlink - ] |
Thema: V: Amiga Hardware Kiste
Brett: Kleinanzeigen (keine Auktionen!) Hallo A-M, kleiner Tip: Mach' doch die Bilder so, daß sie nicht viel größer als 100k werden. So gehen die Kosten fürs Herunterladen des Bildes fast schon in den Euro-Bereich - von der notwendigen Geduld beim Download gar nicht zu reden ! Außerdem ist ein Bild dieser Größe selbst mit GraKa gar nicht mehr direkt anzeigbar... Gruß uho |
|||||
|
uho
Nutzer
23.01.2008, 14:39 Uhr [ - Direktlink - ] |
Thema: MO machts möglich: Partitionen >2GB unter AmigaOS 3.0
Brett: Amiga, AmigaOS 4 @thomas: Ja, da hast Du wohl recht. Hatte mich so über den Erfolg gefreut, daß ich nicht nachgerechnet hatte B-) Habe das mit meiner HD (4.03GB) verwechselt, bei der 30MB durch die 4GB-Grenze nicht nutzbar sind. Hatte allerdings immer gedacht, daß auch eine Partition <2GB sein muß. Das ist da nur bei Dateien der Fall - nur ggf. negative Angaben für den freien Speicher muß man bei >2GB in Kauf nehmen. Das nächste Mal werde ich erstmal drüber schlafen, wenn ich wieder im Freundentaumel bin ;-) Gruß uho |
|||||
|
uho
Nutzer
19.01.2008, 20:50 Uhr [ - Direktlink - ] |
Thema: S: Uhrenchip für A4000D
Brett: Kleinanzeigen (keine Auktionen!) Hallo, habe Probleme mit meinem A4K. Details s. Classic-Forum. Suche deswegen den Uhrenchip "RICOH RP5C01". Gruß uho |
|||||
|
uho
Nutzer
19.01.2008, 20:45 Uhr [ - Direktlink - ] |
Thema: MO machts möglich: Partitionen >2GB unter AmigaOS 3.0
Brett: Amiga, AmigaOS 4 Habe neuerdings ein 2.3GB-MO-LW (statt 640MB). Bei voller Ausnutzung der Größe wären 13288x2x40*2048/1024 (Zylinder*Köpfe*Sektoren) = 2.1771*10^9 Bytes nutzbar. Das sind 2076.25 MB bzw. 2.0276 GB - also knapp über der Grenze. Natürlich könnte man die Partition geringfügig verkleinern. Der Verlust betrüge hierbei nur 28.25 MB (bzw. 1.36 Prozent). Mehr als eine Partition pro Wechselmedium soll nicht empfehlenswert sein - auch wenn es mit dem Cyberstorm- Controller funktioniert. Das Problem ist hier eher prinzipieller Natur und würde erst mit noch größeren Medien interessant. Im Gegensatz zur Festplatte beträgt die Blockgröße bei MOs ab 640MB 2048 Bytes. Damit sollten also Partitionen bis 2x(2048/512)= 8 GB möglich sein, da der begrenzende Faktor ja die 32 (bzw. 31)-Bit-Zahl für die Blocknumerierung ist. Natürlich darf man keine Dateien >2GB erzeugen und sollte sich z.B. an negativen Größenangaben bei einigen Befehlen nicht stören - was hierbei aber nur relevant ist, wenn das Medium fast voll oder fast leer ist. Um zu testen, ob wirklich keine Daten verloren gehen, habe ich das Medium bis auf den letzten Block gefüllt. Hat geklappt - alles noch da. Sogar eine abschließende Behandlung mit ReOrg - was IMHO nur mit 512-Byte-Blöcken getestet wurde - hat keinerlei Daten zerstört. Apropos ReOrg: Um die Defragmentierung zu beschleu- nigen, wird dort Speicher allokiert. Bei mir leider nur die (langsamen) 16MB FastMem vom Board. Die 128MB von der Karte werden links liegen gelassen. Noch seltsamer: Bei MO-Medien werden 64MB allokiert - wohl bedingt durch die Blockgröße. Das ist ja dann sowieso Speicher von der Turbokarte dabei. Wieso wird da nicht gleich mehr alloziiert ? Ursprünglich hatte ich ja vermutet, daß irgendwo MEMF_FAST statt MEMF_PUBLIC alloziiert wird und habe versucht, ReOrg an entspr. Stellen zu patchen. Hat leider nicht funktioniert. Auch ist diese Theorie kaum mehr mit dem obigen Verhalten zu erklären. Wer hat diesbezüglich einen Tip ? Oder hat Kontakt zum Autor (aber der macht IMHO nix mehr aufm Amiga) ? Ob man das auf Festplatten übertragen kann, indem man auch dort die Blockgröße anhebt, habe ich nicht getestet. Möglich, daß es dort nicht funktioniert, da ja real mehr Blöcke existieren Auf jeden Fall muß man mit einem größeren Verschnitt bei kleinen Dateien rechnen. Allein durch die Icons kommen da schnell ein paar MB zusammen. Wer Interesse hat, kann ja weiterführende Untersuchungen anstellen. Aber bitte auf einer leeren Platte ;-) Gruß uho |
|||||
|
uho
Nutzer
15.01.2008, 17:03 Uhr [ - Direktlink - ] |
Thema: WB 3.1 einrichten
Brett: Amiga, AmigaOS 4 @DNA: Hallo, habe nochmal etwas genauer nachgemessen: Hier werden ca. 50 Icons/Sekunde (+/- 20% Meßfehler) angezeigt. Am 4000er mit GraKa ein Vielfaches - aber so schnell kann ich ich nicht mehr messen :-)) Es besteht kaum ein Unterschied zwischen HD und CF. Schießlich passen von den nur 1-2 Blöcke großen Icons ziemlich viele auf einen Zylinder. Und die angrenzenden werden ja auch noch schnell erreicht. Die Verarbeitung und Darstellung der Daten ist hier eher die Grenze. Apropos Grenzen: Hohe Farbtiefen stehlen Prozessor-Zyklen. Deswegen nutze ich die WB bei AGA nur in vier Farben. Bei der Bootzeit sieht's schon etwas anders aus: Da ist die HD 8 Sekunden nur halb so schnell - ca. 3 Sekunden werden zum Hochlaufen/Selbsttest benötigt, bevor die eigtl. Datenübertragung startet. Und die zu lesenden Daten liegen i.A. weiter auseinander. Gruß uho |
|||||
|
uho
Nutzer
14.01.2008, 23:16 Uhr [ - Direktlink - ] |
Thema: WB 3.1 einrichten
Brett: Amiga, AmigaOS 4 Hallo DNA, Icons - langsam ?? Gerade das AmigaOS ist für seine Effizienz bekannt - zumindest bis 3.1. Bei mir baut sich ein typ. Fenster (ca. 20 Icons) im Bruchteil einer Sekunde auf (1200er+Blizzard 030) - mit den mitgelieferten Icons, versteht sich. Btw, Bootzeit (mit CF-Card): 4 Sekunden. Allerdings hatte ich auf meinem A4k mal 3.5 getestet - selbst aufm 060er unbenutzbar - wie Winshit halt. Wenn Du über die "Geschwindigkeit" ab dieser Version aufwärts meckern würdest - aber so... Seltsam. Icons (bzw. deren Tooltypes) durch Ziehen ändern geht mit SwazInfo seht gut. Außerdem empfehlenswert: DragIt, MMB_Shift, PowerWB, WBUhr, ScreenTab, TWA, WarpWB. Und natürlich: Nicht zuviele Gimmicks zu installieren ;-)) Gruß uho |
|||||
|
uho
Nutzer
11.01.2008, 10:59 Uhr [ - Direktlink - ] |
Thema: Hilfe ! Uhr legt A4000D komplett lahm !
Brett: Amiga, AmigaOS 4 Hallo, habe zwischenzeitlich den Akku ausgebaut, geladen (Spannung jetzt bei 4V wie bei meinem anderen 4000er) und wieder eingebaut. Rechner läuft ohne Akku einwandfrei - Uhrzeit läßt sich wieder speichern, überlebt aber keinen Reset. Auch Thomas' ReststartClock hilft nicht. Mit Akku geht's ca. 5-15min, dann wieder gelber Schirm unt tot. Auch ausschalten hilt nicht - Rechner geht meist erst nach 'ner Stunde wieder. Hatte deswegen thermischen Defekt vermutet und die meisten Chips während der "Gelbphase" mitKältespray getestet - ohne Ergebnis. Auch den Buster hatte ich mal draußen. Das RAM ebenfalls. Ohne Chip-RAM leuchtet's tatsächlich grün - wenigstens klappt die Selbstdiagnose :-/ . So langsam gehen mir aber die Ideen aus. Wer hat noch einen Tip ? Gruß uho |
|||||
|
uho
Nutzer
07.01.2008, 18:07 Uhr [ - Direktlink - ] |
Thema: Hilfe ! Uhr legt A4000D komplett lahm !
Brett: Amiga, AmigaOS 4 Hallo zusammen, heute habe ich eine CF-Karte in meinem (Ersatz-)A4000D getestet (als Festplattenersatz - mit Adapter am IDE-Port). Hat auch auf Anhieb geklappt. Außerdem von Vorteil: Die Zeit bis zum Bootbeginn reduziert sich von 26 auf 1 Sekunde. Soweit - so gut. Also hab ich 3.1 installiert. Dann noch Land, Tastaturbelegung und Uhr eingestellt und... Hoppla ! Der Speicher-Button im Time-Einsteller war disabled. Das war in den ganzen Jahren noch nie da. Setdate in der Shell meldete "Objekt nicht gefunden" (und meinte damit wohl die battclock.resource) Der Akku konnte es nicht sein - den hatte ich erst letztes Jahr (erfolgreich) gewechselt. Allerdings hatte der Rechner längere Zeit gestanden. Kaltstart - Zeit lies sich speichern (ca.2.5V) - Warmstart (ca. 2.8V) - wieder das selbe Dilemma. Nun waren die Kontakte des ICs beim Uhrenaku aber schon letztes Jahr bischen in Mitleidenschaft gezogen worden. Also habe ich in einer ziemlich mühseligen Aktion (man kann nicht so gut ran und verätzte Pads sind kaum lötbar) alles (nochmals) gereinigt und neu verlötet. Kann auch keinen unterbrochenen Leiterzug entdecken. Wieder angeschaltet - mit der Uhr alles beim Gleichen, aber ansonsten voll funktionsfähig. Naja, dachte ich, vielleicht ist die Spannung gerade im verbotenen Bereich. Also hab ich das ganze Lötzeugs weggeräumt (ca. 15min) und dabei den Rechner laufen lassen. Akku-Spannung mittlerweile: ca. 3.3V. Jetzt sollte es also klappen. Doch ein Blick auf den Monitor lies meinen Mut sinken: Nur noch gleichmäßiges Grau ! Auch Reset und Kaltstart bringen nichts. Der Rechner ist absolut tot :-(( . Nur die CAPs-Lock-LED blinkt beim Affengriff kurz auf - die Power-LED wird aber nicht dunkler - der Reset kommt also nicht an. Der Bildschirm bleibt schwarz. Das kenne ich zwar schon von meinem 1200er. Hier liegt es aber an einem Wackelkontakt des CPU-Quarzes - lies sich bisher aber immer durch leichtes Antippen und anschließenden Reset beheben. Wäre auch ein unglaublicher Zufall, wenn dieses Quarz gerade heute den Geist aufgegeben hätte... Natürlich habe ich auch die CF-Karte testweise raus- genommen - erwartungsgemäß ohne Erfolg. Nun bin ich erstmal ziemlich ratlos. Schon erschreckend wie schnell ein Amiga ohne erkennbare Ursache keinen Mucks mehr tut. Sollte das dem Rechner, mit dem ich gerade diesen (inzwischen etwas länglichen) Hilferuf verfasse und der schon vieeel mehr Betriebsstunden (und einen vor Jahren getauschten Akku ;-) ) auf dem Buckel hat, ebenfalls passieren, dann könnte ich nicht nur keine Fragen mehr an Euch stellen, sondern mein geliebtes Hobby hätte sich mehr oder weniger erledigt... Vielleicht kennt ja jemand einen Schwachpunkt in diesem Zusammenhang (und idealerweise die Bezugsquelle für evtl. Ersatzteile) ? In der Hoffnung auf kompetenten Ratschlag Ein beunruhigter uho |
|||||
|
uho
Nutzer
06.12.2007, 16:48 Uhr [ - Direktlink - ] |
Thema: Primary- & Grown-Defect-List rücksetzen
Brett: Amiga, AmigaOS 4 Hallo, evtl. Diagnosetools des Herstellers bzw. DOS-Progs nutzen mir leider herzlich wenig - es sei denn, es gibt sie für AmigaOS ;-(( Wie gesagt, selbst Low-Level-Format hilft nichts. Bei HD-InstTools gibt's sogar eine Option, die Defekt-Liste zu ignorieren - ohne Resultat. Inzwischen habe ich im Aminet gestöbert und dort SCSIFormat gefunden. Das ist u.a. speziell für diesen Fall gemacht und sollte eigtl. sogar die PList ignorieren können - klappt aber auch nicht. Einzige Erklärung - neben falsch implementierter Software - wäre, daß die Blöcke tatsächlich nicht mehr beschreibbar sind. Aber durch einen zu schwachen Laser ? Irgendwie unlogisch - zumal auf den Medien ja deutlich erkennbare (hardsektorierte) Segmente zu erkennen sind - an der Synchronisation wird es also eher nicht liegen... Gruß uho |
|||||
|
uho
Nutzer
02.12.2007, 16:02 Uhr [ - Direktlink - ] |
Thema: Primary- & Grown-Defect-List rücksetzen
Brett: Amiga, AmigaOS 4 Hallo, nach vielen Jahren hat mein 640MB-MO-LW den Dienst so langsam quittiert - zumindest was den Schreib- vorgang angeht (Lesen geht noch einwandfrei). Da der Vorgang sich über Wochen erstreckte, ich die Optik mehrfach gereinigt und auch mit einem normalen CD-LW vor Jahren ähnliches erlebt habe, tippe ich auf Altertung des Lasers. Zum Lesen reichts noch, zum Erwärmen (Schreiben) aber nicht mehr. Daten habe ich dank SCSI (automat. Bad-Block-Remap) nicht verloren. Inzwischen habe ich ein 2.3GB-LW eingebaut - dank der Kompatibilität der MO-Laufwerke ist sowas möglich. Dumm ist nur, daß ich durch diverse Tests (wer entsorgt schon gerne eine nicht mehr käufliches LW ?) jetzt einige Medien mit (angeblich) hunderten defekter Blöcke sowohl in der Primary- als auch in der Grown-Defect- List habe. Die bekomme ich leider nicht mehr weg. Nicht mal ein Low-Level-Format hilft. Auch mit AZap habe ich schon versucht, die aufgelisteten Blöcke im RDB zu finden - ohne Erfolg. Oder sollte ich den RDB mit Nullen überschreiben und hoffen, daß das Medium dann noch formatiert werden kann ? Es geht hierbei nicht etwa um verlorene KByte, sondern v.a. darum, daß a) der Remap-Bereich begrenzt ist und beim Auftreten wirklicher Defekte erschöpft sein könnte, b) es einem nicht mehr auffällt, wenn zu einer Liste mit einigen hundert Einträgen ein paar dazukommen (Früherkennung von Defekten) c) die Lese-/Schreibrate bei den betroffenen Blöcken vom Mbyte- in den untersten KByte- Bereich absackt und gleichzeitig die Mechanik arg strapaziert wird, da die Reserveblöcke irgendwo am Rand zu liegen scheinen. Wer weiß Rat ? Gruß uho |
|||||
|
uho
Nutzer
11.11.2007, 10:38 Uhr [ - Direktlink - ] |
Thema: Warmstart per Befehl
Brett: Amiga, AmigaOS 4 @julius: Habe in meinem C-Verzeichnis den Befehl "Reboot" gefunden. Und da wir ja alle bischen retro sind, hier der Hex-Code zum abtippen: code:0000: 000003F3 00000000 00000001 00000000 ...ó............ 0010: 00000000 0000000C 000003E9 0000000C ...........é.... 0020: 08F90007 00DE0002 2C780004 4EEEFD2A .ù...Þ..,x..Nîý* 0030: 00245645 523A2072 65626F6F 74203339 .$VER: reboot 39 0040: 2E322028 33302E37 2E393229 00000000 .2 (30.7.92).... 0050: 000003F2 ...ò Sind nur 84 Bytes... Da viele Hex-Editoren die File-Größe nicht ändern können, kannst Du erst in einem ASCII-Editor (z.B. CEd) ein Dummy-File mit exakt 84 Bytes erstellen und dann die Bytes beispielsweise in AZap entsprechend ändern. Klar, man kann sowas auch per Mail schicken. Aber wo bleibt denn da der Spaß ? *gg* Gruß uho |
|||||
|
uho
Nutzer
03.11.2007, 17:56 Uhr [ - Direktlink - ] |
Thema: Registerzugriff in C
Brett: Programmierung @MaikG: Hier handelt es sich um einen ganz simplen Fehler: Assembler-Direktiven (Befehle, die für den Assembler, nicht für den Prozessor sind), müssen in der ersten Spalte - also ganz links - stehen. Die angegebene Fehlermeldung erscheint, wenn Leerzeichen und/ oder Tabs davorstehen. Übrigens ist AsmOne (bzw. dessen Grafikkarten-fähiges Pedant AsmPro) nicht einfach nur ein Assembler, sondern eine komplette Entwicklungsungebung mit grafischer Oberfläche, Monitor, Debugger und Vielem mehr ! Dabei besteht er nur aus einer einzigen Datei (plus Config) und kann dadurch praktisch auf jedem Amiga-System bei gleich- zeitig sehr ergonomischer Benutzführung verwendet werden. Fazit: Unbedingt anschauen ! @jolo: Alles ganz falsche Vermutungen ;-) Gruß uho |
|||||
|
uho
Nutzer
12.10.2007, 21:58 Uhr [ - Direktlink - ] |
Thema: Float Exception
Brett: Programmierung @Der_Wanderer: Aber gerne; ist zum Glück nicht zu schwierig: Division durch Null ist halt immer schlecht... int div=dx*dy; - sowohl dx als auch dy beginnen bei 0, womit div natürlich auch 0 ist, was dann zu dem Fehler in besagter Zeile führt. Wundert mich nur, daß das der Compiler überhaupt schluckt; Aztec spuckt selbst, wenn man const int dx=1234, dy=1234; int div=dx*dy; schreibt "initializer is not a constant" aus... Daher hat man dann auch immer viel Extra-Aufwand, wenn man (eigl.) konstante Werte in Strukturen eintragen muß... Gruß uho |
|||||
|
uho
Nutzer
08.10.2007, 20:46 Uhr [ - Direktlink - ] |
Thema: Voranfrage: Interessenten gesucht
Brett: Programmierung Hallo Der_Wanderer, erstmal danke für die ebenso schnelle wie aufschlußreiche Antwort. Nur hier wollte ich nochmal nachhaken: Zitat:Zitat: Naja, so einfach ist es wohl nicht: Die von mir getesteten Lösungen (Höhenprofil und Fraktale durch Aufteilung von Liniensegmenten) erlauben keine Überhänge. Addiert man einfach jeweils zufällige Werte zu x und y, erhält man so etwas wie eine Brownsche Bewegung - also ohne Ziel. Wählt man den x-Wert etwas positiver (um den rechten Rand zu erreichen), hat man immer noch das Problem, daß sich der Polygonzug selbst schneidet -> Füllprobleme. Da gibt's doch sicher noch einen Kniff, oder ? So, muß leider Schluß machen... Gruß uho |
|||||
|
uho
Nutzer
04.10.2007, 21:55 Uhr [ - Direktlink - ] |
Thema: Voranfrage: Interessenten gesucht
Brett: Programmierung @Der_Wanderer, bin leider etwas (naja, ziemlich :-) ) verspätet, da ich einfach keine Zeit fand, einen Beitrag zu schreiben... Trotzdem habe ich diesen Thread mit großem Interesse verfolgt, da ich - wie es der Zufall so will - gerade vor einigen Wochen begonnen habe, ein Projekt, das schon vor ca. 15 Jahren in AmigaBasic realisiert werden sollte, in C fortzusetzen. Und dies hat auch mit Landschaftsgenerierung und fraktalen Pflanzen zu tun. Nun zu meinen Fragen: 1) Irgendwo bin ich mal einem Link zu Deinem Prog gefolgt. Da gab's 'n richtiges Progger-Forum, in dem Du Deinen Worms-Verschnitt (Name vergessen) vorgestellt hast. Cooles Avatar-Bildchen übrigens. Leider hab ich den Link nicht notiert... 2) Die Darstellung der Landschaft bei Deinem Prog finde ich genial - vor allem, da man keinerlei Rasterung sieht. Dies trifft besonders auf die Ober- und Unterseiten zu. Schneidest Du da eine Grafik mit einem Polygonzug aus ? Ein Tip zu Letzterem wäre hilfreich. Wie bekommt man so schöne Überhänge und erreicht dennoch das Ziel (also den rechten Bildschirmrand) ? Bei meinem Projekt richte ich mich bei der Grafik nach der max. sinnvollen Größe einzelner Elemente (z.B. Blätter). Da ich auch Berechnungen mit jedem Element durchführen möchte, versuche ich also die Landschaft aus z.B. 8x8 Pixel großen Blöcken darzustellen - nicht zuletzt, um einen direkten Zusammenhang zwischen graphischer Darstellung und dahinterliegenden Datenfeldern zu ermöglichen. Gut möglich, daß es da noch bessere Ansätze gibt. Ich würde ja ein Beispielbild einstellen, aber soweit ich gehört habe, geht das nicht ohne eigenen Webspace. Ist aber in diesem Fall vielleicht auch besser so, denn es sieht Scheiße aus. Außerdem ist es auch programmiertechnisch sehr unelegant, da man Unmengen Ifs braucht, um - in Abhängigkeit von den Nachbarblöcken - die passende Grafik zu blitten... Wie legst Du fest, wie in Abhängigkeit von der Steigung die Landschaft (Grasnarbe) ändert ? Oder zeigst Du einfach ein fertiges Bild an ? Das wäre aber sehr speicherintensiv und eintönig... 3) Die grundsätzliche Grammatik zur Erzeugung von Pflanzen war mir zwar schon bekannt, dennoch habe ich aus der bisherigen Diskussion viele Anregungen mitnehmen können. Nur für die Zuordnung der 2D-Pflanze zu den entsprechenden Feldindizes der Landschaft habe ich noch keine Idee. Wie kann man z.B. ein einzelnes Blatt eines rekursiv erzeugten Baumes einer x/y-Pos. zuordnen ? Wie löst man Mehrdeutigkeiten durch ineinanderwachsende Äste auf bzw. wie verhindert dies ? Gibt es eine einfache Möglichkeit, einzelne Äste eines Baumes abzuschneiden ? Der eigtl. Wuchs hängt ja nur von der Anzahl der Iterationen und den globalen Parametern (Winkel..., Grammatik) ab. (Für diese Frage bin ich inzwischen auf die Idee gekommen, während der Generierung der Grammatik (oder extakter des Baumes aus derselben) eine lfd. Nr. zu jedem Verzweigungs- beginn abzuspeichern, so daß ich dann die Darstellung unterdrücken bzw. die Zeichenfolge entsprechend kürzen könnte. Gruß uho P.S.: Habe letztens ein ca. 15 Jahre altes Zufallstext-Prog von AmigaBasic nach C umgesetzt. Geschwindigkeitsgewinn: ca 160000 Prozent - natürlich bei identischer Hardware. Geil ! |
|||||
|
uho
Nutzer
19.08.2007, 20:22 Uhr [ - Direktlink - ] |
Thema: Bild größer als Screen
Brett: Programmierung Hallo MaikG, hier mal eine Antwort "auf die Schnelle", da ich noch nichts mit Datatypes programmiert habe: Zitat: Da werden wohl die Daten, die nicht mehr in die Zeile passen, an den Anfang der nächsten geschrieben; diese wird dann entsprechend später mit den zugehörigen Daten gefüllt, so daß sich der Inhalt immer weiter verschiebt. Zitat: Da wird wohl einfach der Grafik-Speicher nicht reichen. Die CyberVisionPPC hat IMHO 8MB, 2635x1846x24/8 = ca 14 MB - also mehr als vorhanden. Multiview scaliert dagegen. Testen kannst Du das auch sehr schön mit dem Bildanzeiger Visage (nebenbei: der ist _viel_ schneller und mächtiger als MV): Bild normal laden -> Bild nicht da Bild mit Parameter "Scale" laden -> Bild da -> im ersten Fall Bild zu groß für GraKa, im zweiten skaliert Gruß uho |
|||||
|
uho
Nutzer
08.08.2007, 21:26 Uhr [ - Direktlink - ] |
Thema: Autoscroll-Screens und mehr
Brett: Programmierung Hallo, hatte leider wieder bischen Zeitnot... @thomas: Zitat: Das ist ein Mißverständnis. Ich habe nie gesagt, daß ich vertikal scollen will. Sieht man auch an meinem Code-Beispiel. Allerdings hatte ich es nicht explizit erwähnt. Die Bildschirmabmessungen sind zwar konstant, die Overscan-Prefs aber nicht. Die Grafik (konstanter Größe) wird in Felder aufgeteilt. Außerdem sollen am unteren Rand auch Gadgets zu sehen sein. Bei variablem Overscan kann man nicht sagen, wie groß der sichtbare Ausschnitt wirklich ist - was ungünstig/fatal für die Darstellung der Grafik bzw. die Nutzbarkeit der Gadgets sein kann. Mein Kompromiß dazu: s.u. @whose: Der Tip mit SA_QUIET ist wirklich genial ! Man kann ein BACKDROP- BORDERLESS-Fenster nutzen und sieht dennoch nichts von Intuition. Funktioniert auch einwandfrei (und spart evtl. paar Taktzyklen). Mir macht allerdings Gedanken, daß SA_Quiet per #define SCREENQUIET ist. Und dieses steht zusammen mit einigen anderen Flags unter der Überschrift "FLAGS SET BY INTUITION" - also eher nicht für User. Ob das noch bei OS 3.2 funktioniert ? >:-) @whose+NoImag: Zitat:Zitat: Zitat: Lest doch bitte wenigstens Eure eigenen Beiträge ! Die Frage war eben bis zu diesem Zeitpunkt noch NICHT beantwortet, da - wie ja NoImag gerade selbst darlegte - OSCAN_TEXT die Vorein- stellung von SA_Overscan ist. Das Weglassen dieses Tags bedeutet also gerade NICHT, daß man keinen Overscan benutzt. Frage war vielmehr, wieso Autoscroll nicht mehr geht und der Mauszeiger verrückt spielt, wenn man Overscan abschaltet (also SA_Overscan, FALSE)... So wie ich das inzwischen sehe, ist "FALSE" einfach ein falscher Parameter und Overscan läßt sich nur indirekt durch Nutzung von SA_DClip abschalten. Siehe dazu auch den Beitrag von Holger. @Holger: Zitat: Ist das ein dokumentiertes Verhalten oder sollte man aus Kombatibilitätsgründen die Fenstergröße doch lieber explizit hinschreiben ? Der letzte Beitrag war übrigens aufschlußreich. Danke. @alle: So wie es mir vorschwebte (eine zentrierter, scrollender Bildaus- schnitt mit exakt 640x256, ringsherum Hintergrundfarbe) ist wohl direkt nicht möglich. Da man mit SA_DCLIP die Darstellung entweder am (meist unsicht- baren) oberen Rand hängen hat oder aber darunterliegende Screens sieht, werde ich wohl Folgendes machen: Ich öffne den Screen mit SA_Text, frage die tatsächliche Größe ab und baue dann meine Darstellung mit z.B. 1200x256 zentriert auf (mit Rändern ringsherum, um die Sichtbarbkeit zu garantieren). Das kostet zwar bischen Chip-Mem (und wohl auch DMA-Zyklen), ist aber ein annehmbarer Kompromiß. Zumindest weiß ich nun, was machbar ist und was nicht und habe sogar einige Extra-Tips erhalten. Danke. Jedenfalls danke für die Mühe ! Nächster Schritt ist dann eine Bitmap zum direkten Reinschreiben. Mal sehen, ob ih das alleine gebacken bekomme. Bei den Vortests ist mir schonmal aufgefallen, daß ein Screen gar keinen eigenen (Bildschirm)Speicher zu haben scheint. Jedenfalls ist der Speicherverbrauch des ersten geöffneten Fensters ähnlich - egal, ob man SIMPLE- oder SMART_REFRESH angibt. Erst beim zweiten Fenster unterscheidet sich der verbrauchte Speicher wie erwartet. Gruß uho P.S.: Einige Passagen haben sich mittlerweile erübrigt, jedoch kann ich jetzt nicht nochmal alles umschreiben, da ich online bin, ein Gewitter aufzieht und ich Euch nicht noch länger warten lassen will. Jedenfalls nochmals danke für die ausführlichen Antworten. Das war diesmal wirklich besser ! |
|||||
|
uho
Nutzer
03.08.2007, 10:45 Uhr [ - Direktlink - ] |
Thema: Autoscroll-Screens und mehr
Brett: Programmierung (sorry, hatte nicht gleich Zeit) Hallo, mittlerweile habe ich einige Tests gemacht und Folgendes herausbekommen: a) Autoscroll OHNE Overscan scheint wirklich nicht zu funzen. Allerdings habe ich dazu keine "offiziellen" Infos. b) Verwendet man Overscan, ist man auf Teufel komm' raus von den User-Prefs abhängig: Niemand hindert einen daran, die OSCAN_TEXT-Einstellung in den unsichtbaren Bereich zu verschieben bzw. auf die Maximalwerte einzustellen. Man kann zwar die Fenstergröße automatisch anpassen, z.B. WA_Top, Screen->BarHeight+Screen->BarVBorder, WA_Height,Screen->Height-Screen->... ...BarHeight-Screen->BarVBorder, Im allgemeinen hat man bei Pixelgrafik aber feste Abmessungen (siehe Wator). Außerdem lassen sich die dahinterstehenden Algorithmen oft nur aufwendig und/oder unter Leistungsverlust variabel gestalten. Der Aufwand steht dabei in keinem Verhältnis zum Nutzen ! c) Wie von Euch vermutet, verwendet ABAckup tatsächlich ein BORDERLESS-Fenster. Dies habe ich mittels RSys feststellen können, da dort neben den Screens auch die Fenster angezeigt werden. Als Flags wurde dort 0x00001900 angezeigt. Das läßt sich zerlegen in: 0x00001000 WFLG_ACTIVATE 0x00000100 WFLG_BACKDROP 0x00000800 WFLG_BORDERLESS So ein Fenster habe ich dann auch geöffnet. Allerdings war bei mir die Titelzeile noch zu sehen. Das lag daran, daß ich WA_Title, " " bei OpenWindowTags() angegeben hatte. Das stammte noch aus Zeiten, als ich OpenWindow() ver- wendet habe - bei der man es nicht weglassen konnte. Bei OpenWindowTags() dagegen gibt man einfach nichts an und die Titelleiste verschwindet auch. Übrigens ist mir aufgefallen, daß BACKDROP-Windows auch hinter der Screen-Leiste verschwinden. Dieser Speicherbereich kann dann sowohl von Intuition als auch von mir beschrieben werden. Führt das nicht zu Komplikationen ? Wird an dieser Stelle das Zeichnen einfach geblockt ? Oder muß ich selber darauf achten, daß das Fenster erst unterhalb der Screenleiste beginnt ? Ein normales Fenster würde die Screenleiste ja einfach überdecken... d) Um die o.g. Nachteile mit variablem Overscan zu vermeiden, kann man stattdessen SA_DClip, dclip_rect, angeben, wobei dclip_rect auf eine struct Rectangle- Struktur zeigen muß, die den den zu scrollenden Bereich - z.B. 640x256 - bestimmt. Großer Nachteil: Oberhalb des Screens, der ja i.A. unter- halb des Overscan-Bereiches beginnt, sieht man nicht die Hintergrund-Farbe, sondern dahinterliegende Screens. Der geöffnete Screen läßt sich nichtmal nachträglich über die ursprüngliche Position schieben ! Läßt man deshalb den Ausschnitt bei Zeile 0 beginnen, liegt er meist im unsichtbaren Bereich. Also auch keine optimale Lösung. So. Lange Rede, langer Sinn :-) Ich habe viel herausgefunden, bin aber nicht wirklich am Ziel. Keine Variante ist optimal: Entweder alles variabel (aber: feste Größe des Bildschirminhaltes) oder Sichtbarkeit mehrerer Screens... Die Antworten von Euch haben mir immerhin den Weg gewiesen. Herausgefunden habe ich letztlich das meiste selbst (und das nur durch Probieren, da in den Büchern stets nur die Verwen- dung der Standard-Parameter beschrieben wird). Keiner konnte mir die Frage beantworten, ob Autoscroll Overscan vorraussetzt. Niemand hat die Möglichkeit von SA_DCLIP erwähnt. Evtl. gibt es sogar noch weitere Variationen, die ich noch nicht herausgefunden habe. Es gibt so viele gute Programme für den Amiga. Aber manchmal frage ich mich wirklich: Wer hat sie geschrieben ? mfg uho |
|||||
|
uho
Nutzer
24.07.2007, 20:22 Uhr [ - Direktlink - ] |
Thema: Autoscroll-Screens und mehr
Brett: Programmierung Zitat: Das OSCAN_TEXT 1:1 die Einstellung im Prefs-Fenster meint, darauf bin ich kurz nach Absenden meines Beitrags auch gekommen - naja  Den o.g. Abschnitt in den Includes hatte ich schon vorher entdeckt. Jedoch erfährt man da eben gerade _keine_ konkrete Pixelzahl (da User-Einstellung). Es ging aber gerade darum, sich von den Overscan-Einstellungen unabhängig zu machen. Also bitte die Fragestellung genauer lesen ! uho |
|||||
|
uho
Nutzer
23.07.2007, 20:05 Uhr [ - Direktlink - ] |
Thema: Autoscroll-Screens und mehr
Brett: Programmierung @Thomas,Holger: Erstmal danke für die Antworten. Allerdings muß ich nochmal nachhaken: > "Ohne Fenster geht eh nichts. ABackup öffnet vermutlich ein > Backdrop-Fenster." Man kann also keine Gadgets direkt an den Screen anhängen ? In der NewScreen-Struktur ist doch Platz für einen Gadget-Zeiger ? Und zu dem Problem "Autoscroll ohne Overscan" habt Ihr Euch leider gar nicht geäußert. Bedingt das Eine das Andere oder mache ich nur bei den Flags was falsch ? OSCAN_TEXT ist wohl der kleinste, aber doch eben ein Overscan. Auch habe ich keine Info gefunden, wieviele Pixel das denn sind. Gruß uho |
|||||
|
uho
Nutzer
22.07.2007, 10:15 Uhr [ - Direktlink - ] |
Thema: Autoscroll-Screens und mehr
Brett: Programmierung Habe letztens mal einen Abend versucht, einen Autoscroll-Screen (ähnlich wie es auch auf der WB möglich ist) zu proggen. Kam leider - auch mangels Literatur, da auswärts - nicht recht zum Zuge. Der Screen soll - Autoscroll haben - kein Overscan - kein Fenster - evtl. Gadgets direkt im Screen - automatisch aktiviert sein Anschauungsbeispiel: ältere Versionen von ABackup Der Screen soll Autoscroll haben, jedoch keinen Overscan, da dieser ja von den Prefs des jeweiligen Users abhängig ist, die Darstellung jedoch immer gleich sein soll. Kein Fenster, da ich mal gelesen habe, daß die Darstellung mit häufigen Systemaufrufen (z.B. Pixel setzen) schneller sein soll, da man sich das ständige Hangeln durch die Windows-Struktur spart (stimmt das ?) und man auch selber durch direktes verändern der Bytes in den Screen schreiben können soll. Außerdem stören für diesen Fall Windows-Elemente nur. Ich benutze OpenScreenTags() mit SA_Type, CUSTOMSCREEN, SA_DisplayID, HIRES_KEY, (also 640x256) SA_WIDTH, 1280 und SA_AUTOSCROLL, TRUE. Funzt aber nicht: Sobald der Mauszeiger an den rechten Rand kommt, verschwindet er, um später am linken Rand wieder aufzutauchen. Dann sind jedoch der aktive (Klick)punkt und die Darstellung des Mauszeigers nicht mehr identisch; man kann nichts mehr gezielt anklicken (Abstand wahrscheinlich 640). Der Screen scrollt gar nicht. Nehme ich noch SA_Overscan, TRUE (oder muß hier ein Wert hin ?) dazu, scrollt der Screen - aber erst nach öffnen eines Fensters (WA_Flags, ACTIVATE) oder Anklicken und natürlich mit Overscan :-(. IMHO gibt es kein Screen-Flag fürs Aktivieren. Bei ABAckup geht das aber. (Test: LAmiga+LMB drücken und Screen runterziehen, loslassen, bei Bewegen der Maus an den unteren Bildschirmrand scrollt der aktive (!) Screen hoch. Geht bei ABackup, in meinem Beispiel aber erst nach Öffnen eines Fensters oder vorherigem Anklicken mit LMB) Vielleicht kann mir ja diesmal jemand helfen. Da ich noch nicht viele Versuche unternommen habe, sollten die Chancen besser als sonst sein ;-) Gruß uho |
|||||
|
uho
Nutzer
18.07.2007, 09:59 Uhr [ - Direktlink - ] |
Thema: Manx Aztec C - Welches war die letzte Version?
Brett: Programmierung Habe Aztec-C V5.2a (anno 1992). Leider ohne Debugger, da damals zu teuer. Selbst so war es mit 290 DM (damals gleichbedeutend mit mehreren Jahren Taschengeld) eine Anschaffung fürs Leben ;-) Nehme es immer noch regelmäßig, habe aber noch einige Fragen, bei denen mir niemand weiterhelfen konnte. Wäre an Erfahrungsaustausch interessiert. Außerdem habe ich auch immer gern Feedback zu meinen beiden im Aminet stehenden Progs: misc/sci/Wator1_27.lha (Räuber-Beute-Simulation) und gfx/misc/HideIt_1.20.lha (Steganographie-Prog). Anregungen immer willkommen. Apropos Selbstgeschriebenens: Da Du ja immer wieder mal Dein Adventure erwähnst: Erzähl' uns doch mehr davon (Thema, 2D/3D ? u.a.m.) ! Gruß uho |
|||||
|
uho
Nutzer
18.07.2007, 09:56 Uhr [ - Direktlink - ] |
Thema: Updates für SAS/C 6.x aber wo?
Brett: Programmierung Hoppla, bin ich der Themen-Zeile verrutscht - sollte eitgl. in den Aztec-Thread. K.A., ob man das selber korrigieren kann... uho |
|||||
|
uho
Nutzer
16.07.2007, 16:36 Uhr [ - Direktlink - ] |
Thema: Updates für SAS/C 6.x aber wo?
Brett: Programmierung @zErec: Habe Aztec-C V5.2a (anno 1992). Leider ohne Debugger, da damals zu teuer. Selbst so war es mit 290 DM (= damals mehreren Jahren Taschengeld) eine Anschaffung fürs Leben ;-) Nehme es immer noch regelmäßig, habe aber noch einige Fragen, bei denen mir niemand weiterhelfen konnte. Wäre an Erfahrungsaustausch interessiert. Außerdem habe ich auch immer gern Feedback zu meinen beiden im Aminet stehenden Progs: misc/sci/Wator1_27.lha (Räuber-Beute-Simulation) und gfx/misc/HideIt_1.20.lha (Steganographie-Prog). Anregungen immer willkommen. Apropos Selbstgeschriebenens: Da Du ja immer wieder mal Dein Adventure erwähnst: Erzähl' uns doch mehr davon (Thema, 2D/3D ? u.a.m.) ! Gruß uho |
|||||
|
||||||
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|