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

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

Erste << 24 25 26 27 28 -29- 30 31 32 33 34 >> Letzte Ergebnisse der Suche: 8130 Treffer (30 pro Seite)
Holger   Nutzer

08.08.2011, 00:43 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Nach dem bisher gelesenen muss man bei SuperBitMap-Fenstern doch immer die BitMap selbst angeben, oder hab ich was übersehen?
Ich dachte, wenn man keine angibt, erstellt das System eine, aber da habe ich mich wohl geirrt.
Zitat:
Von Hand auch bei SmartRefresh? Wird dort nicht auch vom System der "systemeigene Schaden" repariert?
Ja, aber z.B. nicht, wenn das Fenster größer wird. Außerdem ging es ja um den Zusammenhang mit dem Double-Buffering. Smart-Refresh mit einem eigenen Buffer zu kombinieren, wäre Ressourcenverschwendung. Die SuperBitMap als Buffer zu verwenden war eine Idee, aber nach allem, was ich jetzt gelesen und gesehen habe, scheint das doch nicht so brauchbar zu sein. Bleibt nur SimpleRefresh + eigene BitMap.
Zitat:
Heisst das, dass eine BitMap in Fenstergröße reicht und ich dann eine zusätzliche BitMap in Fenstergröße im Speicher halte, in der ich immer das gesamte Bild aufbaue, welches ich dann in einem Blit ins Fenster blitte? Wenn ich das bei nem "normalen" Fenster auch so mache, ist das doch genauso, oder nicht?
Ja, das ist dasselbe. Der wesentliche Unterschied liegt darin, wie das System mit einem Refresh umgeht, vor allem, wenn das Fenster in der Größe geändert werden kann.
Zitat:
Hm, was würde denn passieren, wenn ich dem Fenster einen Zeiger auf eine andere, von mir angelegte BitMap unterjuble?
Das geht nicht. Bitte vor lauter kompliziertem Denken nicht die Grundlagen vergessen: alle Fenster liegen auf einem Screen und benutzen eine gemeinsame BitMap, nämlich die des Screens.
Zitat:
Ja, unter Verwendung der ClipRects! Das hat mich auch gewundert. In meinem hier verlinkten Bsp.-Programm hab ich mal ne Schleife um das Clippen und Blitten gebaut und ein EraseRect auf den ganzen Fensterbereich eingefügt. Das flackert sehr stark. Nach Reduktion des EraseRect auf die Bounds der ClippingRegion ist kein Flackern mehr erkennbar!
Klingt für mich nach einem Fehler. Welche OS-Version?

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

05.08.2011, 17:34 Uhr

[ - Direktlink - ] 		Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4

Zitat:
Original von Maja:
Aber was, wenn der Rechner dann auf den Ein-/Ausschalter nicht mehr reagiert? Es ist schließlich sehr anstrengend, unter den Schreibstisch krabbeln, um den Stecker aus der Steckdose zu ziehen.
Ja, je nachdem, wo der brennende Rechner steht, würde ich auch nicht mehr unter den Schreibtisch krabbeln. Da hilft nur der Weg zum Sicherungskasten, falls der nicht zu weit weg ist.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

05.08.2011, 17:25 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Aber das kann ich doch auch mit nem normalen Fenster ohne SuperBitMap, oder versteh ich da was falsch?
Da musst Du es aber von Hand programmieren. Der in dem Beispiel gezeigte Fall, dass man die SuperBitMap von Hand anlegt, sollte der Sonderfall sein. Was Dir SuperBitMap-Fenster außerdem abnehmen, ist das Nachdenken über systemseitigen Damage, da die entsprechenden Regionen automatisch wiederhergestellt werden. Was ich nicht genau weiß, ist, wie das System die programmseitigen Updates handhabt.
Zitat:
Der "Nachteil" dieser Methode ist dann aber ein zusätzlicher Blit im Vgl. zum Umbiegen von Zeigern (wie von Thore auch vorgeschlagen) oder dem Scrollen im SuperBitMap Fenster.
SuperBitMap Fenster sind keine Screens. Dein Scrollen einer SuperBitMap ist nichts anderes, als ein Blit von der SuperBitMap in die Screen-BitMap.

Wenn Du Fenster verwendest, kannst Du keine Pointer-Updates oder ähnlich gelagerte Buffer-Techniken einsetzen.
Zitat:
Jetzt schon. :D Hatte zuerst die grobe Kelle geschwungen und immer den ganzen Spielbereich gelöscht.
Aber unter Verwendung der ClipRects? Theoretisch sollte die Größe der sowieso nicht geblitteten Bereiche überhaupt keine Rolle spielen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

05.08.2011, 12:12 Uhr

[ - Direktlink - ] 		Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4

Zitat:
Original von Mika:
PS: Wenn der Rechner qualmt ist es zu spät für das ausschalten!
Aber auch kein guter Zeitpunkt, ihn an zu lassen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

05.08.2011, 12:02 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Mein bisheriges Verständnis davon ist, dass dort die BitMap größer sein kann als das Fenster (also ich würde in meinem Fall einfach doppelte Höhe nehmen). Dann wird der sichtbare Teil der BitMap immer im Fenster dargestellt, im restlichen Teil kann man dann die Aktualisierung vorbereiten, anschließend kann man den sichtbaren Teil in einem Rutsch aktualisieren.
Na ja, nach meinem Verständnis wäre das gar nicht nötig, wenn man zuerst alles in die Offscreen-BitMap rendert und diese dann in das Fenster blittet. Übergroße BitMaps brächte man dazu gar nicht.
Zitat:
Ein Update noch in eigener Sache: Habe gestern noch etwas optimiert und so das Flackern wegbekommen (EraseRect wird nun nur noch in den Bounds der ClippingRegion durchgeführt - ...
Ich dachte, das wäre sowieso der Fall?

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

04.08.2011, 13:42 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Meinst Du den Teil hier:...
Nein, ich meinte, schau Dir mal SuperBitMap-Refresh an. Das ist letztendlich ein Art von Double-Buffering, nur weiß ich nicht, ob sie für Deine Zwecke brauchbar ist. (Diese Methode wird halt selten benutzt).
Zitat:
Wie steht es denn mit sowas hier? Ist das denn nicht auch ne systemkonforme Möglichkeit...
Das ist doch exakt die von Thore beschriebene Holzhammer-Methode. Wie gesagt, seit AOS3.0 gibt es bessere Methoden. RethinkDisplay berechnet übrigens die Strukturen aller Screens neu und ist somit nur bedingt als systemkonform zu bezeichnen.
Zitat:
...und geht das genau so mit nem Window auf dem Screen (was ich derzeit benutze, um mit Gadgets, genauer Buttons arbeiten zu können)?
Nein, double-buffering verträgt sich überhaupt nicht mit Fenstern, Gadgets und vielen anderen System-Features.
Zitat:
Für diesen Fall ist wohl SuperBitMapWindow keine schlechte Idee! Muss mir aber erst einmal dieses Beispiel genauer ansehen, und verstehen, wie es genau funktioniert (ne Idee hab ich schon) und welche Teile für mich davon relevant sind!
Ich kann nur noch mal davor warnen, zu sehr an den veralteten RKRM-Beispielen zu kleben. Abgesehen davon, dass sie eben vor AOS3.0 oder teilweise auch vor 2.0 entstanden sind, habe ich erst letztens Beispielprogramme in den Fingern gehabt (im Zusammenhang mit diesem Thread übrigens), die schlichtweg deshalb broken waren, weil sie offenbar aus einer gedruckten Fassung eingescannt wurden und dabei ein paar Zeichen falsch waren oder verloren gingen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

03.08.2011, 01:09 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Da ich meine Schichten von unten nach oben alle neu blitte könnte ich bei einem Hintergrundbild mit Clipping auf das EraseRect verzichten und hätte kein Blinken mehr, denn alle Grafiken im geclippten Bereich werden ja eh neu geblittet!
Wie bereits geschrieben, spielt es doch überhaupt keine Rolle, ob Du ein Hintergrundbild oder einen grauen Bereich blittest. Entweder Du bist schnell genug und der Hintergrund (egal ob Bild oder grau) ist wieder verdeckt, bevor der Benutzer es bemerkt, oder Du bist zu langsam und es flackert. Wenn es flackert hilft nur a) beschleunigen oder b) offscreen BitMap resp. double-buffering.
Zitat:
bzw. gibt es weitere Alternativen (einfachere, oder performantere im Hinblick auf Geschwindigkeit)?
Auch das habe ich bereits geschrieben. Im selben Beitrag.
Zitat:
Original von Thore:
2. Screen-Bitmap tauschen: Du hast 1 Screen und 2 Bitmaps. Du zeichnest auf der "losen" BitMap und hängst sie in den Screen ein. Damit tauschst du immer die Bitmaps aus. Ggf muss der Screen durch ein RethinkDisplay neu gezeichnet werden.
Das ist die Holzhammer-Methode. Dafür gibt es zwei bessere Alternativen. Die systemfreundlichste wäre es, die extra dafür vorgesehenen Funktion der intuition.library namens AllocScreenBuffer, ChangeScreenBuffer und FreeScreenBuffer zu benutzen. Da diese in der Anfangszeit von RTG Probleme auf RTG-Systemen bereiteten, hat es sich zu dieser Zeit eingebürgert, stattdessen einen doppelt hohen Screen zu verwenden und diesen über Änderungen des Offsets in ViewPort->RasInfo gefolgt von ScrollVPort zwischen der oberen und unteren Hälfte umzuschalten. Letzteres ist auch die Methode, die auf Systemen vor AOS3.0 funktioniert.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

03.08.2011, 00:22 Uhr

[ - Direktlink - ] 		Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung

Zitat:
Original von AGSzabo:
Was sind denn "Ken Icons"?
http://aminet.net/package/pix/picon/kens_icons_v4

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

03.08.2011, 00:17 Uhr

[ - Direktlink - ] 		Thema: Amiga 500 Kuriositäten
Brett: Amiga, AmigaOS 4

Lieber spät als nie.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.08.2011, 19:29 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Thore:
Hier musst du abwägen: Mehr Speicherverbrauch und performanter, oder weniger performant und dafür weniger Speicherverbrauch.
Nun ja, es kann immer passieren, dass für einen Refreshvorgang die gesamte BitMap benötigt wird. Ein in dieser Hinsicht schwankender Speicherverbrauch bietet keinen wirklich Vorteil, es sei denn, man will wirklich riskieren, dass mittendrin nicht mehr genug Speicher frei ist. Dann kann man zwar immer noch auf die flackernde Variante zurückfallen, aber ein Spielvergnügen wird das dann nicht. Dann lieber eine konsequente Mindestanforderung definieren, bei der das Spiel dann aber auch wirklich läuft.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.08.2011, 19:08 Uhr

[ - Direktlink - ] 		Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Ich wollte Mason zeigen, wie "schlecht" seine Copy/Move/Paste/Rename Icons sind.
Man erkennt kaum einen Unterschied => ziemlich nutzlos ohne Text. Das hat er aber inzwischen verbessert.
Das ist Dir gelungen. Ist mir nämlich auch ins Auge gesprungen, dachte allerdings, dass da einfach mehrmals dieselbe Aktion als Dummy steht.
Zitat:
Übrigends: Die Icons passen sich an die Höhe der Listenzeile an, nicht umgekehrt.
So sollte es sein. Hatte allerdings die Amiga-Workbench-Icons oder klassische Icon-Sammlungen, wie eben AISS im Hinterkopf.
Zitat:
Ich denke die skalierten Versionen sehen nicht schlechter aus als die original bilder, vergl. die 24px AISS mit meinem 24px skaliertem.
Ja, es ist äußerst selten, das runterskalierte Bilder deutlich schlechter als speziell für die Auflösung designte aussehen. Da müsste sich der Designer schon sehr viel Mühe bei den niedrigen Auflösungen geben, wobei 24px ja noch relativ groß ist.
Zitat:
Original von Der_Wanderer:
2MB ist ja nicht viel. Skins sind was für "High-End" Rechner, z.B. mit 1GB RAM oder so.
Für einen nackigen A1200 würdest du niemals Skins nehmen, das ist zu langsam und zu viel speicher.
Sofern man unter einem Skin grundsätzlich 24/32Bit Grafiken versteht. Effizient kodierte Vektorgrafiken könnten durch ihre Anpassungsfähigkeit auch auf Systemen mit niedriger Auflösung, CLUT und wenig CPU-Kapazität etwas reißen.
Aber wer optimiert heutzutage noch für diese Systeme…
Zitat:
Original von Der_Wanderer:
Spätestens beim Beenden des letzen NTUI Programms (also beim Schließen der ntui.library), sonst hat ja NTUI keine Möglichkeit mehr.
Man muss eine Library nicht beim letzten Schließen freigeben. Exec ruft Expunge automatisch auf, sobald der Speicher benötigt wird. Man kann also durchaus die Library (und auch die Bilder) länger im Speicher halten.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.08.2011, 10:49 Uhr

[ - Direktlink - ] 		Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung

@Der_Wanderer:
PS: Der Screenshot sieht ganz nett aus. Allerdings leidet er an der sehr verbreiteten Krankheit der Rahmen-Inflation. Zur Entschärfung empfiehlt sich, wenigstens den überflüssigen senkrechten Divider in der Mitte zu entfernen und vielleicht den Rahmen der Statuszeile unten zu entfernen und stattdessen eine einfache Trennlinie zwischen Statuszeile und Toolbar einzuführen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.08.2011, 10:46 Uhr

[ - Direktlink - ] 		Thema: OS 4.1 classic
Brett: Amiga, AmigaOS 4

Zitat:
Original von tploetz:
Ich verstehe das nicht, als der Amiga noch offen war, liefen díe
Festplatten, als ich ihn zugeschraubt habe, ging es nicht mehr.
Da musst Du Dir jetzt die Frage stellen, wo drückt das Gehäuse beim zumachen womöglich gegen? Oder klemmt es vielleicht ein lose rumliegendes Kabel ab?

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.08.2011, 10:41 Uhr

[ - Direktlink - ] 		Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung

Zitat:
Original von Der_Wanderer:
Zitat:
Diese spezielle Implementierung muss davon ausgehen, dass alle Elemente dieselbe Höhe haben und eine bestimmte Breite erzwungen wird.
Nein, muss es nicht. Es kann dann nur sein, dass sich eben der Scoller Knob in der Größe leicht verändert beim Scrollen. So ist es bei Android.
Und warum verändert er sich? Weil die Implementierung davon ausgeht, dass alle Elemente gleich hoch sind (was sie offenbar nicht sind). Also kein Widerspruch zu dem von mir gesagten.

Was ich dagegen von sich verändernden Scrollern halte, habe ich bereits gesagt. Ich bezweifle auch einfach mal, dass der Performancegewinn durch diese Technik real ist. Ich habe einfach schon zu viel Programmcode gesehen, der mit exakt dieser Technik exakt null Einsparung erzielt, weil der Overhead der Verwaltung solcher Strukturen höher als die mögliche Einsparung ist.
Zitat:
Man braucht keine Angst zu haben, dass jemand über irgendwelche Objekte iterieren will. Denn wenn das GUI Toolkit richtig implementiert ist, dann darf ja nur der ListView die Unterelemente anfassen, und der weis ja was er tun muss.
Sofern der Entwickler des ListViews wusste, was er tut. Der Adressat meines Beitrags waren nicht die Android Entwickler.
Zitat:
Bei NTUI habe ich das Konzept leider (noch) nicht umgesetzt. Z.b ist es schon erwas nervig bei einem Filemanager, der Echt-Icons anzeigt.
Wenn man einen Folder öffnet mit 10.000 Files, dann dauert das schon mal ne Weile bis was angezeigt wird.
Würde man so einen Adapter nutzen, müssten nur die sichtbaren, sagen wir mal 10-20 Icons geladen werden. Der Rest erst bei Bedarf.
Nur braucht man dazu kein solch komplexes Konzept. Solche Datei-Listen sehen mit unterschiedlichen Höhen sowieso bescheiden aus, weshalb man i.A. das Layout auf eine bestimmte, angenommene Icon-Höhe fixiert und evtl. vorhandene größere Icons bei Bedarf skaliert.

D.h. man braucht die Icons gar nicht, um das Layout zu berechnen. Insofern können die Elemente der Liste die Icons problemlos on-demand laden, ohne dass der ListView spezielle Algorithmen benötigt.

Btw. schon mal bewusst wahrgenommen, was im Windows-Explorer bei hoher Systemlast oder wenig freiem Speicher passiert? Der lädt nämlich Icons auch bei Bedarf, bzw. asynchron ohne das GUI zu blockieren. Und wirft sie auch weg, falls der Speicher für andere Dinge benötigt wird.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

02.08.2011, 10:19 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Wie wäre dann die Offscreen-BitMap-Lösung am geeignetsten? Lege ich die BitMap für jeden Refresh-Vorgang in der gerade benötigten Größe neu an oder halte ich vorsorglich eine BitMap in Spielfeldgröße bereit, erstelle nur den zerstörten Bereich mit Clipping neu und blitte diesen in den sichtbaren Bereich?
Ich gehe mal davon aus, dass eine permanente BitMap in Komplettgröße in den meisten Fällen am effizientesten ist. Vielleicht lohnt es sich an dieser Stelle, sich doch mal das Verhalten der selten genutzen SuperBitmap-Refresh Fenster anzuschauen. Möglicherweise liefern sie schon das gewünschte frei Haus.
Zitat:
Der Vorschlag, den immer verdeckten Bereich nicht zu erasen würde z.T. helfen. Wenn ich um mein Spielfeld irgendwie ne "Hintergrund-" bzw. "Umgebungsgrafik" hinbekäme wäre das Problem komplett gelöst.
Ob der Hintergrund grau oder eine Umgebungsgrafik ist, spielt eigentlich keine Rolle. Der Unterschied wäre ja nur, dass es nicht mehr grau aufblitzt, sondern die Umgebungsgrafik durchblitzt, wenn man die Bereiche nicht trennt.
Zitat:
Frage mich, wie es z.B. bei MegaLoMania gemacht wurde. Dort liegen die Grafiken direkt in ner Datei vor, die werden doch bestimmt auch nur geblittet. Wird dort auch alles immer neu erstellt? Lief ziemlich flüssig aufm A500!
Wie bereits gesagt, alles neu zeichnen plus double-buffering, ohne mit dem System zu interagieren, ist der am häufigsten anzutreffende Algorithmus.

Flüssig ist übrigens eher das Gegenteil von Ruckeln. Ob dabei etwas aufblitzt oder nicht, ist eine andere Frage. Oder ruckelt Deine Grafik?

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

01.08.2011, 20:27 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Thore:
Vermutlich hab ich das in dem Context mit dem Windows BeginRefresh/EndRefresh zusammengeschmissen, wobei es hier so ist, daß die sichtbare Änderung erst beim EndRefresh dargestellt wird?
Nein, Zeichenoperationen gehen trotzdem direkt und sofort in die Zielbitmap, es wird lediglich geclippt. Das mag vielleicht im Falle von SuperBitmap-Fenstern anders sein, aber von denen war hier nicht die Rede.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

01.08.2011, 18:31 Uhr

[ - Direktlink - ] 		Thema: Anfänger: DOS-Programm auf den Classic portieren
Brett: Programmierung

Routinen zum Lesen und Schreiben von Dateiformaten bezügl. der Endianess zu fixen, setzt schon sehr viel Detailwissen zum Dateiformat und der Routinen voraus. Das wird alles andere als eine schnelle Portierung.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

01.08.2011, 18:24 Uhr

[ - Direktlink - ] 		Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung

Zitat:
Original von AGSzabo:
die listview kann dynamisch neue zeilen zur laufzeit aufnehmen. was sollte denn _nicht_ statisch sein so wie bei android?
Die beschriebene Technik zielt auf folgendes ab: Statt von vornherein 3000 Objekte für 3000 Listenelemente zu haben, hast Du evtl. nur ein großen Plain-Text Objekt, von dem Du aber schon weißt, dass es 3000 Zeilen besitzt. Der List-View würde so implementiert sein, dass er ausschließlich für sichtbare Elemente ein Objekt anlegt. Diese Objekte würden dann on-the-fly auf dem Plain-Text generiert werden.

Um daraus einen Nutzen zu ziehen, muss der Code aber einige Anforderungen erfüllen. So darf z.B. niemand auf die Idee kommen, durch die Liste zu gehen und für sämtliche Elemente das Layout berechnen zu wollen. Diese spezielle Implementierung muss davon ausgehen, dass alle Elemente dieselbe Höhe haben und eine bestimmte Breite erzwungen wird.

Das entbindet Dich dann aber auch nicht davon, Pixelpositionen in 32 Bit zu berechnen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

01.08.2011, 18:14 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Thore:
Also EndRefresh(MyClip, FALSE);
Damit ist die Zeichnung noch nicht fertig, und erst bei EndRefresh(MyClip, TRUE); wird sie angezeigt.
Ich glaube, Du hast eine völlig falsche Vorstellung davon, was BeginRefresh und EndRefresh machen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

01.08.2011, 18:12 Uhr

[ - Direktlink - ] 		Thema: Neue Frage zu Überdeckungen
Brett: Programmierung

Zitat:
Original von Reth:
Einen Nachteil hat die Lösung allerdings! Durch das EraseRect flimmerts, da dabei jedesmal der graue Hintergrund des Fensters/Screens durchscheint.
Erst einmal eine Verständnisfrage: der graue Hintergrund flimmert nur innerhalb des durch die ClipRects festgelegten Bereiches, oder?
Zitat:
Was kann ich gegen diesen Nachteil noch unternehmen? Offscreen-BitMap nehmen oder Doublebuffering (was ich noch nicht so durchdrungen habe) oder gibt es noch einen einfacheren "Kniff"?
Wenn Du obige Frage mit ja beantwortet hast, kannst Du versuchen, die die Zeit zwischen den Zeichenvorgängen zu verringern, d.h. den gesamten Prozess zu beschleunigen, oder Du brauchst eine Offscreen-BitMap. Natürlich kann man auch das EraseRect so begrenzen, dass Bereiche, die definitiv immer vom Spielfeld verdeckt sind, nicht extra gelöscht werden. Das reduziert mögliches Flimmern, löst das Problem aber nicht grundsätzlich.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

29.07.2011, 18:31 Uhr

[ - Direktlink - ] 		Thema: Die Lügenbande, Teil zwo ! ;-)
Brett: Get a Life

Zitat:
Original von _PAB_:
Gedanken sind nicht nur das Produkt chemischer (oder allgemeiner: neurologischer) Vorgänge, es gibt auch einen nicht zu unterschätzenden Anteil Zufall darin, denn wir haben es auch mit Quantenphysik zu tun.
Auf so etwas makroskopisches wie das Gehirn haben zufällige Quanteneffekte keinerlei Einfluss.
Zitat:
Wäre das nicht so, wäre unser gesamtes Gehirn "berechenbar" (=deterministisch), was meiner Vorstellung von Leben widerspricht.
Die Physik funktioniert nicht, um Dir zu gefallen. Ob Du deterministisch denkst oder nicht, merkst Du selbst gar nicht. Wobei Du ja, selbst wenn die Prozesse nichtdeterministisch wären, Zeit Deines Lebens damit beschäftigt bist, Deine Gedanken in eine deterministische Form zu bringen.

--
Good coders do not comment. What was hard to write should be hard to read too.
 
Holger   Nutzer

29.07.2011, 15:03 Uhr

[ - Direktlink - ] 		Thema: UAE zu langsam oder Programmierfehler?
Brett: Programmierung

Zitat:
Original von AGSzabo:
Sie sind jetzt mal 19 pixel hoch. Das mal 3000 sind $dea8. Das liegt mit vorzeichen (bei grafikoperationen wichtig) außerhalb der $7fff, funktioniert also nicht. Oder was hast du gemeint?
Dein Scroller hat laut Deiner Aussage einen Range von 0-0xffff, also ohne Vorzeichen. Dass Du auch für Deine Gadget Koordinaten 16Bit-Zahlen benutzt, wusste ich nicht.

Jetzt wird es für Dich wirklich mal Zeit, über Deine Konzepte nachzudenken.

  • Vielleicht 32 Bit Koordinaten?
  • Oder nicht mehr alle Objekte beim Scrollen transformieren? (Dann wären alle Koordinaten positiv und nur der ListView müsste 32Bit vorzeichenbehaftet rechnen)
  • Ist es überhaupt noch sinnvoll, bei tausenden Elementen, die nur aus Text bestehen, auch tausend Gadgets anzulegen?
  • Oder…

    --
    Good coders do not comment. What was hard to write should be hard to read too.
    •  
    Holger   Nutzer

    29.07.2011, 12:10 Uhr

    [ - Direktlink - ]     		Thema: OS 4.1 classic
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von wawa:
    ich würde das nicht eine entscheidung nennen. man verlernt sachen die man nicht gebraucht. ich wwar mal in gymnasiom nicht schlecht in mathe, heut weiss ich nicht mehr wie man ne quadratische gleichung löst.
    Trotzdem gibt es niemanden, der Dich daran hindert, hier und heute das vergessene (oder auch das nie erlernte) zu erlernen. Es gibt genügend Möglichkeiten.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    29.07.2011, 11:54 Uhr

    [ - Direktlink - ]     		Thema: UAE zu langsam oder Programmierfehler?
    Brett: Programmierung

    Zitat:
    Original von AGSzabo:
    Allerdings scheint es ab einer gewissen Zahl von Zeilen einen grafischen Überlauf zu geben, ich meine die Koordinaten werden wieder negativ oder positiv oder so. ...
    ps: es könnte evtl auch der scroller sein, der bei zu großen zahlen nicht mehr richtig funktioniert?
    Das musst Du doch wissen.

    Also selbst mit Deinem Gewürge mit 0xffff als Maximum, sprich 16Bit-Arithmetik wären bei 16 Pixel hohen Zeilen 4096 Elemente ohne Probleme möglich, bzw. bei 20 Pixel pro Element immer noch deutlich über 3000.

    Wenn Du bei weniger Elementen Probleme hast, hast Du irgendwo Mist gebaut. Wenn Dir dagegen diese maximale Anzahl Elemente nicht reicht, musst Du ordentliche 32 Bit-Arithmetik verwenden (bzw. deren Bugs beheben, falls Du schon in 32 Bit gerechnet hast).

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    28.07.2011, 17:42 Uhr

    [ - Direktlink - ]     		Thema: Anfänger: DOS-Programm auf den Classic portieren
    Brett: Programmierung

    @Dr_Chaotica:
    Halte Dich lieber an das von thomas geschriebene:

    vc programm.c -o programm

    Wenn Du es brauchst, dann gib -c99 an und in Hinblick auf die Fehlermeldung wäre -lm zu empfehlen. Aber den Rest, den solltest Du nicht brauchen, sonst wäre das ein Zeichen für eine fehlerhafte Compiler-Installation (und das sollte man immer als erstes beheben).

    Also:
    vc -c99 programm.c -lm -o programm
    sollte es eigentlich tun.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    27.07.2011, 11:43 Uhr

    [ - Direktlink - ]     		Thema: UAE zu langsam oder Programmierfehler?
    Brett: Programmierung

    Zitat:
    Original von Der_Wanderer:
    Noch schlimmer, es verhindert möglicherweise die Implementation eines effizienten Algorithmus, weil es zu kompliziert ist, und statt dessen wird der naive Algorithmus (meistens "Brute-Force") gewählt.
    Genau das meinte ich mit: „es verführt zu ineffizientem Code“. Der wird einerseits geschrieben, weil der effiziente mit Assembler schwieriger zu machen ist oder nicht mit der damit verbundenen Denkweise zusammenpasst, andererseits ist ein ineffizienter Assemblercode oftmals bis zu einem gewissen Grad trotzdem noch schnell genug, um dann gerne in Situationen, die der Programmierer nicht getestet hat, einzubrechen.
    Zitat:
    Original von AGSzabo:
    Optimierungsklausel? Ganz allgemeine Lösungen zu verwenden machte bisher das coden leicht. Aber dank eurer Tips kann ich jetzt den code diese Sonderfälle berücksichtigen lassen, ich finde bestimmt eine Lösung.
    Mir scheint, Du verwechselst gerade das Allgemeine mit dem Besonderen.

    Der allgemeine Fall lautet: Größe hat sich geändert ⇒ Layout muss neuberechnet werden.

    Das Besondere ist Deine Implementierung, die etwas tut, ohne dass es einen Grund dafür gibt.

    Defragmentiert Dein Programm auch beim Start die Festplatte? Oder ist es da doch naheliegend, Dinge nur dann zu tun, wenn es auch einen Grund dafür gibt?

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    27.07.2011, 11:36 Uhr

    [ - Direktlink - ]     		Thema: UAE zu langsam oder Programmierfehler?
    Brett: Programmierung

    Zitat:
    Original von Der_Wanderer:
    Bei NTUI ändert sich beim Scrollen nichts, ausser dem Offset (1 Integerwert). Der Rest ist immer gleich, also das Zeichnen des Listviews.
    So sollte es sein.
    Zitat:
    b) falls die unterschiedlich sein sollen, dann kannst du beim Scroller trotzdem annehmen, sie wären gleich hoch, allerdings änderst du die Visible Größe, je nachdem wie hoch die sichtbaren Elemente dann tatsächlich sind (nur die hand-voll sichtbaren!).
    http://de.wikipedia.org/wiki/Interpolationssuche

    Richtig auf das konkrete Problem zugeschnitten implementiert, wirst Du keinerlei Performance-Unterschied zu Elementen fester Größe feststellen.

    Ein Scroller, der seine Knob-Größe während des scrollens verändert, ist für mich ein Armutszeugnis. Egal, welche große Firma das so macht…
    Zitat:
    Der Inhalt muss relativ zum ListView layouted werden, und beim Zeichen wird immer der Offset des ListView-Inhalts addiert. Hat dann zwar leichte Mehrkosten beim Zeichen, aber keinerlei Kosten für das Scrollen.
    Man sollte generell die Koordinaten der Kinder relativ zum Elternelement halten. Die Mehrkosten sind praktisch nicht existent: alle Zeichenoperationen eines Gadgets sind eh in der Anwendung relativ zu ihrer eigenen Position implementiert, die wiederum vom OS relativ zum Fenster ausgeführt wird. Die Relation zwischen Kind und Elternelement wird dagegen vor dem Beginn des Zeichnen vorberechnet und hat auf die Zeichenoperationen gar keinen Einfluss.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    27.07.2011, 11:10 Uhr

    [ - Direktlink - ]     		Thema: OS 4.1 classic
    Brett: Amiga, AmigaOS 4

    Zitat:
    Original von antiByte:
    Es scheint hier nur sehr wenige zu geben die sich noch mit dem Amiga beschäftigen. ;)
    Solange Du es genausowenig schaffst, seine Probleme zu lösen, solltest Du das Maul nicht so weit aufreißen.

    Selbstverständlich gibt es hier Classic-User. Aber der Anteil derer, die dafür auch noch AOS4 gekauft haben, dürfte wesentlich geringer sein. Und unter denen dann auch noch jemanden zu finden, der Lust hat, andererleute selbstgemachte Probleme zu beheben, ist wahrscheinlich aussichtslos.

    Du gehörst ja offensichtlich auch nicht dazu.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    27.07.2011, 10:43 Uhr

    [ - Direktlink - ]     		Thema: UAE zu langsam oder Programmierfehler?
    Brett: Programmierung

    Zitat:
    Original von AGSzabo:
    wenn ich die view scrolle, müssen alle x und y coordinaten der childs angepasst werden.
    Das ist zwar ineffizient, dürfte aber kaum zum Problem werden.
    Zitat:
    dazu mache ich das ganze setlayout für den inhalt der view nochmal, also auch höhen und breiten.
    Das ist schon ein anderes Kaliber. Gibt es denn irgendeinen sinnvollen Grund, warum Du das Layout neuberechnest, obwohl definitiv kein Objekt seine Größe geändert hat?
    Zitat:
    Original von Der_Wanderer:
    … 68K Assmelber schützt vor ineffizientem Code nicht ;-)
    Viel mehr noch, es verführt zu ineffizientem Code.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
    Holger   Nutzer

    26.07.2011, 16:53 Uhr

    [ - Direktlink - ]     		Thema: Jetzt nochmal das Notify
    Brett: Programmierung

    Zitat:
    Original von Der_Wanderer:
    Ja, als Aktion sollte man das Ganze verstehen, d.h. zur Aktion gehört auch der App Code, richtig?
    Typischerweise, ja. Wenn man objekt-orientiert programmiert, hat ein Aktion-Objekt eine Methode, die diejenige ist, die vom Dispatcher beim Empfang eines Action-Events auch aufgerufen wird. Das Action-Event ist bereits ein abstrakter Ereignistyp, nicht mehr das auslösende Maus- oder Tastatur-Event.

    Zitat:
    Mit deiner Kritik, dass die XML z.b. keine Default Werte oder Wertebereiche setzen darf, bin ich nicht einverstanden. Alle GUI Toolkits die ich kenne machen das so. Man kann sie natürlich programmatisch auch setzen, muss man aber eben nicht.
    „Das machen alle so“ ist keine sinnvolle Begründung. Es ist nunmal so, dass die Anwendungslogik die gültigen Werte vorgibt. Wenn der Amiga nunmal nur einen Lautstärke-Bereich von 0 bis 63 besitzt, ergibt es einfach keinen Sinn, dass der GUI-Designer etwas anderes festlegen kann.

    Und wenn das Programm AHI unterstützt und sich deshalb der erlaubte Range ändert, soll die Anwendung eine spezielle GUI-XML bekommen müssen? Bzw. muss man dann zwischen zwei unterschiedlichen GUIs wechseln, je nachdem, ob man jetzt AHI oder Paula benutzt?
    Zitat:
    Welche Object IDs es gibt, und welche Notify an die App es gibt, definieren letztendlich beide, die App und das XML. Beides muss logischerweise matchen. In integrierten Umgebungen erstellt daher der GUI Builder ein automatisches Include mit den #defines, die man im Programmcode benutzt.
    Das geht alles von einem Workflow aus, bei dem der GUI-Designer letztendlich der Programmierer ist, bzw. eng an dessen Entwicklungszyklus gebunden ist.

    Nur brauche ich dann kein XML. Dann kann ich das Ergebnis gleich direkt in das Programm kompilieren.

    Der Vorteil einer XML-GUI ist aber eigentlich, dass man sie austauschen kann, ohne die Anwendung neu übersetzen zu müssen. Und dann ist eigentlich klar, wer den Rahmen vorgibt. Nämlich derjenige, der sich nicht ändern kann. Die kompilierte Anwendung.

    --
    Good coders do not comment. What was hard to write should be hard to read too.
     
     
    Erste << 24 25 26 27 28 -29- 30 31 32 33 34 >> Letzte Ergebnisse der Suche: 8130 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.
    .