|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Suche | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
||||||
|
akl
Nutzer
05.01.2011, 13:59 Uhr [ - Direktlink - ] |
Thema: negativer addresszeiger?
Brett: Programmierung @Holger: Haarespalten würde ich das nicht nennen. Der LowMemory-Mechanismus greift noch innerhalb von AllocMem - und zwar wird von dort aus aufgeräumt, nachdem es eigentlich bereits fehlgeschlagen war. Der Unterschied kann dementsprechend gewaltig sein, und deutlich größer als das, was zufällig wieder freiwerden würde. Leider war das in vielen AOS-Versionen nie richtig implementiert. |
|||||
|
akl
Nutzer
05.01.2011, 11:06 Uhr [ - Direktlink - ] |
Thema: negativer addresszeiger?
Brett: Programmierung @Thore: >Was Du brauchst ist ein doppelter Rückgabewert. Logisch. Allerdings setzt das voraus, dass man seine Anforderungen sorgfältig definiert. Also entweder tristate_pointer = MyAllocVecDirectDropIn(size, flags) oder eben pointer = MyAllocVecSimilarReplacement(size, flags, &status); Aber man kann natürlich auch erstmal lang und breit mit anderen (also uns) darüber diskutieren ;-) nur um dann die Anforderungen zu ändern... |
|||||
|
akl
Nutzer
05.01.2011, 11:04 Uhr [ - Direktlink - ] |
Thema: negativer addresszeiger?
Brett: Programmierung @tboeckel: >Unter AmigaOS4 kann man selbst bei angezeigten Null freien Bytes immer >noch erfolgreich Speicher allokieren, weil es da einen Pager gibt, der >genau das ermöglicht Es braucht nichtmal einen Pager, sondern lediglich einen funktionierenden LowMemory-Mechanismus (vgl. "avail flush") |
|||||
|
akl
Nutzer
04.01.2011, 21:17 Uhr [ - Direktlink - ] |
Thema: teiltransparenz
Brett: Programmierung @Der_Wanderer: Alpha-Effekte auf 8 Bit-Screens halte ich generell nicht für eine so besonders gute Idee, weil man für jede berechnete Transparenz eigentlich einen eigenen Pen allozieren müsste - wenn sich also 16 Pixel unterschiedlicher Farbe mit 16 anderen Pixeln unterschiedlicher Farbe überlagern, braucht man unter Umständen nochmal 16 Pens für die Transparenz... Wenn's eine Arbeitsoberfläche ist und der vorherrschende Farbton einfarbig ist (Grau-/Blau-/Grüntöne oder ähnlich) dann sieht's vielleicht dennoch einigermaßen aus... Wär's nicht sinnvoller, auf halbgare Transparenz bei 8 Bit besser ganz zu verzichten?! [ Dieser Beitrag wurde von akl am 04.01.2011 um 21:17 Uhr geändert. ] |
|||||
|
akl
Nutzer
04.01.2011, 18:03 Uhr [ - Direktlink - ] |
Thema: teiltransparenz
Brett: Programmierung @AGSzabo: Steht eigentlich alles hier: http://de.wikipedia.org/wiki/Alpha_Blending Die entscheidende Formel ist: pixel = alpha * x + (1 - alpha) * y Dass alpha nicht zwischen 0..1 liegt, sondern zwischen 0..255 - und dass x,y jeweils ebenfalls innerhalb 0..255 für R,G,B getrennt vorliegen, sollte klar sein. Deshalb muss auch pixel nochmal durch 255 geteilt werden und sichergestellt sein, dass das Ergebnis immer zwischen 0..255 liegt... Eine optimierte Berechnung dafür bekommst Du sicher selbst hin, und ggf. einen Lookup-Table um die Multiplikationen einzusparen... Viel Spass :-) [ Dieser Beitrag wurde von akl am 04.01.2011 um 18:06 Uhr geändert. ] |
|||||
|
akl
Nutzer
01.01.2011, 17:39 Uhr [ - Direktlink - ] |
Thema: negativer addresszeiger?
Brett: Programmierung @AGSzabo: Da beim Zweierkomplement glücklicherweise -1 mit 0xFFFFFFFF belegt ist und man rückwärts zählt (-2 ist 0xFFFFFFFE) kann man diese Werte vom Ende des Adressraums ziemlich entspannt als Fehlerwerte verwenden. Das wird auch an einigen Stellen im AmigaOS so gemacht (siehe z.B. Graphics/Layers/Intuition-Taglisten). Das geht prinzipiell so lange, wie der allozierte Speicher (immer) größer ist, als das, was am Ende des Adressraums theoretisch an effektiv physikalisch verfügbarem RAM noch kommt. Im dem Zusammenhang: Speicher, der von AllocVec zurückgegeben wird, ist grundsätzlich immer (mindestens) langwort-ausgerichtet. Selbst wenn also im Bereich am Ende des Adreßraumes nicht sowieso ROM oder andere Nicht-RAM-Adressen liegen würden, würde bei AllocVec() grundsätzlich keine Adresse größer als 0xFFFFFFFC sein können. Bis -4 hast Du also (mindestens) Luft ;-) |
|||||
|
akl
Nutzer
28.08.2010, 09:09 Uhr [ - Direktlink - ] |
Thema: Welche Programmiersprache
Brett: Programmierung @jochen22: Das sind ja gleich drei Wünsche auf einmal, das geht nun wirklich nicht... (*) (*) jedenfalls nicht diese, unter AOS |
|||||
|
akl
Nutzer
19.08.2010, 09:45 Uhr [ - Direktlink - ] |
Thema: html: elementhöhe in prozent
Brett: Programmierung @AGSzabo: http://de.selfhtml.org/html/frames/eingebettete.htm |
|||||
|
akl
Nutzer
10.08.2010, 14:11 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 @Thore: >Und das war ja auch die Aussage, daß er dann sauberer arbeiten muss, >um Fehler von vornherein auszuschließen. Das muss man unter .NET oder Linux auch... Die Frage ist die nach dem Qualitätsanspruch bzw. der Professionalität. >Aminet-Programme von Hobbyprogrammierern als Messlatte zu verwenden >ist ein interessantes Thema.... Messlatte ist doch letztlich die Systemstabilität, oder? Wenn ich AmigaOS als Maßstab gegenüber Windows nehme, muss das de-facto das Verhalten des Durchschnitts der Programme sein, die ein typischer Anwender nutzt - da die Programme kein Qualitätssiegel tragen, gilt im Zweifel der Worst Case (alles Hobbyprogrammierer). >aber vielleicht habt ihr auch nur nicht verstanden was ich aussagen >wollte. Durchaus - ich sehe das allerdings (inzwischen?) etwas differenzierter. >Ich sagte auch nicht daß er es macht, ich sagte daß er es muss wenn er >ein stabiles Programm will. Die Frage ist doch, welche Techniken und Methoden man dazu einsetzt. >da macht mal einmal die Anmerkung, Programmierer ohne systemseitige >Sicherheit müssen für bugfreie Software sauber programmieren, und >schon ists wieder nicht recht... Du hast vielleicht einen meiner Einwände ebenfalls überlesen: ich denke, Programmierung für ein System wie AOS sensibilisiert für die Problematik und erleichtert das Erlernen entsprechender Techniken. Wer unter AOS gut programmiert, kann z.B. auch gut für eine Spielekonsole oder ein Handy entwickeln - vielleicht schreibt er auch tendenziell bessere Windows-Software, aber da wäre ich vorsichtig. Wer unter AOS schlecht programmiert, macht es unter Windows vielleicht sogar besser. Ich würde sogar behaupten, manche Bugs lassen sich dort einfacher finden. >Laut eurer Meinung dürften sie sogar diesen messy code machen.. aber >dann beschwert euch nicht wenn es auf ner anderen Maschine crasht. Das ist jetzt etwas viel hineininterpretiert... |
|||||
|
akl
Nutzer
10.08.2010, 09:46 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 @Thore: >Und du wirst dich wundern, aber die meisten Amiga-Programme sind >perfekter ausprogrammiert als so manches Win-Programm. Denn ohne >Speicherschutz muss man von sich aus schon sauberer arbeiten. Naja... unter .NET z.B. knallt es so schnell, da besteht die Schwierigkeit weniger darin, den Knall zu hören (= Speicherschutz schlägt) an, als die Richtung festzustellen, aus der er kam (= den Fehler zu finden). Bei letzterem helfen bestimmte mit AOS unter relativ primitiven Bedingungen erlernte Techniken ganz gut weiter - der typische .NET Programmierer wird vielleicht den Fehler einfach ignorieren, wenn er nur jedes 10. Mal auftritt, nicht leicht zu reproduzieren ist und weil der Speicherschutz so gut ist... (*) Aber genausogut ist das andere Argument richtig, dass unter AOS der Durchschnittsprogrammierer weniger sauber arbeitet - da es meistens trotz der Bugs nicht sofort zum Absturz kommt. (*) Wobei innerhalb einer .NET Laufzeitumgebung (genauso wie innerhalb einer Java VM) sich letztlich doch wieder alle Threads den gleichen Adressraum und den gleichen Heap teilen - im Zeitalter von Multithreading und Multicore-CPUs verlagert das letztlich lediglich die bereits von der OS-Ebene bekannten Probleme auf die Applikationsebene. D.h. das OS an sich ist stabiler, dafür stürzen die Anwendungen umso freudiger ab... Unter .NET ist man daher z.B. fast geradezu dazu genötigt, sich ein MungWall selbst zusammenzubauen... |
|||||
|
akl
Nutzer
09.08.2010, 11:31 Uhr [ - Direktlink - ] |
Thema: MuForce und einige Programme
Brett: Amiga, AmigaOS 4 @Ralf27: zu 3: - angenommen, die geschriebenen Daten sind länger als 4 Byte, was passiert wohl mit den Daten an Adresse 4? - angenommen, die hingeschriebenen Daten werden später von einem anderen Programm gelesen und als Zeiger interpretiert, was passiert wohl mit dem Speicher an der entsprechenden Stelle, irgendwo im System? - angenommen, Adresse 0 wird als Stringzeiger verwendet, und es kommt sehr lange kein NUL-Byte im Speicher... - etc, |
|||||
|
akl
Nutzer
17.07.2010, 12:02 Uhr [ - Direktlink - ] |
Thema: Sch... PPC hat den Geist aufgegeben :-(
Brett: Amiga, AmigaOS 4 @AmigaHarry: Oder ganz im Gegenteil PowerUP. |
|||||
|
akl
Nutzer
16.07.2010, 12:29 Uhr [ - Direktlink - ] |
Thema: Sch... PPC hat den Geist aufgegeben :-(
Brett: Amiga, AmigaOS 4 @AmigaHarry: Ich weiss nicht, wie damals bei WarpUP intern das Cache-Handling gelöst wurde, aber bei PowerUP musste man es zu Fuß machen, um auf der sicheren Seite zu sein, was den Datenaustausch zwischen 68k- und PPC-Seite anging. Wenn da also irgendetwas nicht sauber gelöst gewesen sein sollte, dann tritt es am ehesten auf, wenn die PPC-Seite plötzlich langsamer und die 68k-Seite (relativ) schneller wird - denn die PPC-Caches leeren sich ebenfalls langsamer und der 68k kommt schneller an falsche Daten. Vereinfacht. |
|||||
|
akl
Nutzer
15.07.2010, 20:30 Uhr [ - Direktlink - ] |
Thema: Sch... PPC hat den Geist aufgegeben :-(
Brett: Amiga, AmigaOS 4 @AmigaHarry: >Das habe ich auch nie behauptet....... Warum ist dann das stufenweise Runterschrauben der Taktung eine Erklärung für das folgende? >>Zuerst merkwürdige Abstürze und nun geht der PPC überhaupt nicht mehr ! Entweder wäre - der PPC nur langsamer, aber ok; dann liegt das Problem in der Software, die sich auf das Nicht-Auftreten von irgendwelchen Race Conditions verlässt - oder der PPC wäre gleich schnell, aber rechnet fehlerhaft - oder der PPC wäre langsamer und rechnet fehlerhaft (hoffnungslos) [ Dieser Beitrag wurde von akl am 15.07.2010 um 20:31 Uhr geändert. ] [ Dieser Beitrag wurde von akl am 15.07.2010 um 20:33 Uhr geändert. ] |
|||||
|
akl
Nutzer
14.07.2010, 19:49 Uhr [ - Direktlink - ] |
Thema: Sch... PPC hat den Geist aufgegeben :-(
Brett: Amiga, AmigaOS 4 @AmigaHarry: (Fehlerfreie) Software stürzt nicht ab, nur weil eine CPU langsamer läuft. Also entweder/oder. |
|||||
|
akl
Nutzer
09.07.2010, 19:23 Uhr [ - Direktlink - ] |
Thema: S: EGS Treiber für Retina
Brett: Amiga, AmigaOS 4 @rbn: EGS war zu nichts kompatibel, schon gar nicht zu Intuition. Deshalb hat sich natürlich CyberGfx/Picasso96 durchgesetzt. |
|||||
|
akl
Nutzer
09.06.2010, 13:26 Uhr [ - Direktlink - ] |
Thema: Cast auf PLANEPTR funktioniert nicht
Brett: Programmierung @Reth: >Das mit dem & vor lake_data lasse ich im Code nun auch mal weg. Hab >mich nur gewundert, wieso die Grafiken dennoch einwandfrei angezeigt >wurden! Bei einem statischen Array der Art "char name[]" hast Du einfach Glück gehabt, weil alle drei Wege zum gleichen Ziel führen: name &name &name[0] Wäre es dagegen ein dynamisches Array vom Typ "char *name" gewesen, wärst Du mit &name so auf die Nase gefallen, wie es einer der Vorredner beschrieben hat. Ich würde mir Schreibweise Nummer 3 angewöhnen, weil sie einheitlich ist und Fehler besser auffallen. [ Dieser Beitrag wurde von akl am 09.06.2010 um 13:28 Uhr geändert. ] |
|||||
|
akl
Nutzer
09.06.2010, 12:54 Uhr [ - Direktlink - ] |
Thema: Cast auf PLANEPTR funktioniert nicht
Brett: Programmierung @Reth: >std::cout << "Lake_Data: " << ((PLANEPTR)(&lake_data)) << std::endl; Was erwartest Du denn zu sehen? Wie wäre es mit: std::cout << "Pointer als Hexwert: " << std::hex << ((unsigned long) &lake_data[0]) << std::endl; oder std::cout << "Pointer als Dezimalwert: " << std::dec << ((unsigned long) &lake_data[0]) << std::endl; Du kannst nicht voraussetzen, dass der C++ Compiler erahnt, wohin er den Pointer konvertieren soll. Wenn ich C-Compiler wäre, würde ich ihn nach (char *) konvertieren, womöglich(!) im ersten Byte ein NUL (0x00) finden und nichts ausgeben... ;-) Das ist übrigens der Vorteil von printf(), dass man dahingehend diszipliniert sein und klare Angaben machen muss... [ Dieser Beitrag wurde von akl am 09.06.2010 um 12:55 Uhr geändert. ] |
|||||
|
akl
Nutzer
07.06.2010, 13:43 Uhr [ - Direktlink - ] |
Thema: spezielle Stormwizard Fragen (unter AmiBlitz)
Brett: Programmierung @ZeroG: ...und ich dachte, Reactor wäre für Reaction (Ex-ClassAct...) http://www.virtualdimension.de/amigafever/archiv/99-05/haage.html [ Dieser Beitrag wurde von akl am 07.06.2010 um 13:43 Uhr geändert. ] |
|||||
|
akl
Nutzer
28.04.2010, 16:40 Uhr [ - Direktlink - ] |
Thema: C oder C++?
Brett: Programmierung @Holger: >Die C-Funktionen sind grundsätzlich nicht für den Einsatz in einer >Amiga-Bibliothek geeignet Das hängt davon ab, welchen Compiler mit welcher C-Laufzeitumgebung man nutzt, welche Funktionen man davon nutzt und ob und wie man sicherstellt, dass der Code "threadsafe" bleibt. So verallgemeinert ist die Aussage nicht richtig. |
|||||
|
akl
Nutzer
11.04.2010, 23:04 Uhr [ - Direktlink - ] |
Thema: Algo zum Kreiszeichnen
Brett: Programmierung @Ralf27: WritePixel_ rp,x+xh,y+yh WritePixel_ rp,x+yh,y+xh WritePixel_ rp,x+yh,y-xh WritePixel_ rp,x+xh,y-yh WritePixel_ rp,x-xh,y-yh WritePixel_ rp,x-yh,y-xh WritePixel_ rp,x-yh,y+xh WritePixel_ rp,x-xh,y+yh ^ Ich würde mal mit WriteLine() vergleichen, auch wenn die Linie nur einen (oder ggf. optimiert: wenige) Pixel lang ist... |
|||||
|
akl
Nutzer
10.03.2010, 07:07 Uhr [ - Direktlink - ] |
Thema: PC emulieren am Amiga ohne EMU-Hardware
Brett: Amiga, AmigaOS 4 @Maja: >Der Amiga "lebt" nun schon seit 12 Jahren auf PPC weiter. Das tut er irgendwie und irgendwo, aber jedenfalls nicht "neben dem PC"... Für die eigentliche Fragestellung würde ich VMware vorschlagen, und zwar ggf. jeweils ein eigenes, selbststartendes Image pro Spiel oder Anwendung... |
|||||
|
akl
Nutzer
23.02.2010, 13:43 Uhr [ - Direktlink - ] |
Thema: Euro Zeichen bei FinalWriter
Brett: Amiga, AmigaOS 4 @ZeroG: Geschichte: http://www.truetype-typography.com/articles/ttvst1.htm |
|||||
|
akl
Nutzer
29.01.2010, 15:08 Uhr [ - Direktlink - ] |
Thema: RastPort und Multithreading
Brett: Programmierung @whose: Sicher ;-) |
|||||
|
akl
Nutzer
29.01.2010, 14:35 Uhr [ - Direktlink - ] |
Thema: RastPort und Multithreading
Brett: Programmierung @whose: Ich weiss ja nicht, wer sich aktuell als wxWidget-Fan hervortut... Vor einigen Jahren habe ich für diesen Ansatz mal plädiert, weil auf die Art neue Applikationen bzw. GUIs leicht von Anfang an hätten portabel programmiert werden können. Davon bin ich inzwischen abgekommen, weil a) das niemanden wirklich interessiert (wer Amiga-Software schreibt, dem ist das heute wie gestern offensichtlich schnuppe, Ausnahmen wie Hollywood bestätigen die Regel) und b) wxWidgets teilweise echte Limitierungen hatte sowie c) unter Verwendung mittelmäßiger Shareware-CASE-Tools immer noch sehr viel Handarbeit zu leisten war was d) mich dazu bewogen hat, lieber gleich RAD via Visual Studio vorzuziehen und dabei e) Applikation und GUI sauber zu trennen, was f) wieder alles auf die Frage des Programmierstils reduziert und g) dann auch den Kreis zu a) gleich wieder schließt... Oder kurz: wxWidgets ist für portable GUIs. Das eigentliche Ziel weitestgehender portabler Anwendungen kann man auch anders erreichen. Unter dem Aspekt der Portierung bereits portabler Anwendungen kann man das anders sehen, aber wxWidgets spielt auch hier keine wirkliche Rolle... Im Übrigen kann man soviele GUI-Toolkits bauen wie man will - wenn aber neue Entwickler keinen aktuellen Standard inkl. GUI-Builder (IDE mit RAD) und zugehörigen Styleguide vorfinden oder dem Anwender sich jedes Toolkit im Look & Feel anders präsentiert - dann hat die OS Plattform ein echtes Problem. (Nein, Office 2007 ist eine andere Kategorie...) |
|||||
|
akl
Nutzer
27.01.2010, 19:00 Uhr [ - Direktlink - ] |
Thema: RastPort und Multithreading
Brett: Programmierung @Der_Wanderer: Sorry, nochmal einen Schritt zurück: was ist eigentlich mit rp->RP_User? Habe gerade kein Autodoc zur Hand, aber... es sieht stark nach einem benutzerdefinierbaren Pointer aus. Was den Aufrufer angeht, kann man daraus ggf. mit etwas Aufwand auch den Kontext ableiten, solange nicht derselbe Rastport nicht nur in mehreren Threads sondern auch in mehreren Engines verwendet wirds. Aber wie gesagt... hier eher nicht. [ Dieser Beitrag wurde von akl am 27.01.2010 um 19:01 Uhr geändert. ] |
|||||
|
akl
Nutzer
27.01.2010, 18:15 Uhr [ - Direktlink - ] |
Thema: RastPort und Multithreading
Brett: Programmierung @Der_Wanderer: Wenn's im Einzelfall eventuell nur darum geht, den Aufrufer zu identifizieren, wäre auch denkbar, jedem Task seine eigene Library-Base zu geben... hier aber eher nicht. |
|||||
|
akl
Nutzer
27.01.2010, 18:10 Uhr [ - Direktlink - ] |
Thema: RastPort und Multithreading
Brett: Programmierung @Der_Wanderer: Das ist der Punkt. Du musst einen Kontext definieren und durch die API durchschleifen. |
|||||
|
akl
Nutzer
27.01.2010, 16:20 Uhr [ - Direktlink - ] |
Thema: RastPort und Multithreading
Brett: Programmierung @Der_Wanderer: Was spricht gegen - ObtainWindow(ntui_context, &window) - ObtainRastPort(ntui_context, window, &rastport) - werkel() - 2x Release... |
|||||
|
akl
Nutzer
25.01.2010, 21:50 Uhr [ - Direktlink - ] |
Thema: Picture Manager und OS4??
Brett: Amiga, AmigaOS 4 @tploetz: Der Ort, wo VMEM: hinzeigt, sollte irgendwo liegen, wo genug Platz frei ist. Ansonsten kann es sein, dass PMPro auch noch ein eigenes Temp-Verzeichnis benötigt, erinnere mich nicht genau, wo das liegt. |
|||||
|
||||||
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|