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 << 42 43 44 45 46 -47- 48 49 50 51 52 >> Letzte Ergebnisse der Suche: 1858 Treffer (30 pro Seite)
Reth   Nutzer

24.04.2006, 21:04 Uhr

[ - Direktlink - ]
Thema: Back again....
Brett: Amiga, AmigaOS 4

@madmat:

Willkommen im Club!

Ich nutze auch noch einen A4000 mit PPC und hoffe inständig, dass nix kaputt geht. Zudem bin ich noch AOS4 Betatester und von der Geschwindigkeit auf dem A4000 begeistert. Wenn aber mal neue, anspruchsvolle SW kommen sollte reicht der 4000er und seine Grakas auch nicht mehr.

Bzgl. RAM-Module kannst Du auch mal einen Blick in Google und ebay werfen.

Zudem gibt es noch MOS, auch für den A4000, allerdings wie für AOS4 nur mit PPC. Habs mir aber noch nicht angesehen. Ausserdem hat es noch den Pegasos als neue HW, ein in meinen Augen nettes Maschinchen.
Ich hoffe und warte aber immer noch auf AOS4, solang mir 3.9 noch ausreicht und hoffe auf gute, bezahlbare HW, oder darauf, dass doch mal ein Versuch klappt ne Lizenz für den PegII zu bekommen, dann könnte ich (und andere) alles nutzen: AOS4, MOS, LINUX...

Ciao
 
Reth   Nutzer

14.04.2006, 22:29 Uhr

[ - Direktlink - ]
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4

Cool, endlich weissich das!

Danke!

Gibts vielleicht auch ne Lösung für das andere Config-Problem (s. anderer Thread)?
 
Reth   Nutzer

12.04.2006, 19:57 Uhr

[ - Direktlink - ]
Thema: Amiga-Tasten für Hotkeys in GoldED verwenden
Brett: Amiga, AmigaOS 4

Hallo zusammen,

weiss jemand, wie man das in GoldED Studio AIX machen kann?
Hab schon verschiedenes probiert und nichts hat funktioniert.

Die Amigatasten sind bei den Menüs als Symbol dargestellt, alle anderen als Text (also z.B. [ctrl]).

Geht das überhaupt (wäre bisschen Schade und blöd wenn nicht)? Bin nämlich von den Menühotkeys wie Block löschen nicht so angetan!

Danke schon mal
Ciao
 
Reth   Nutzer

07.04.2006, 11:31 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

Da wir eh schon OT sind, fällt mir gleich noch ne Frage in diese Richtung ein?
Wo platziere ich am dümmsten die Warteschleife auf messages?

Wenn ich mir eine Receiverklasse(nhierarchie) baue, welche z.B. auf INTUITION-Messages wartet, könnte ich den Loop z.B. in dieser unterbringen:

Pseudocode:
C++ code:
IntuiMSGReceiver::receive(struct MsgPort *Port)
{
    struct IntuiMessage *msg = (struct IntuiMessage *) GetMsg(Port);
    // reply und verarbeiten
}


Da fallen mir noch spontan 2 Ansätze ein:

1. Eine Abstrakte Receiverklasse mit einer virtuellen Receive-Methode (quasi das Interface).

2. Eine (evtl. virtuelle) Receiverklasse, die den Empfang und den REply der Message schon implementiert hat, abgeleitete Klassen müssen den MessageTyp in Abhängigkeit ihrer Aufgabe (IntuiMessage) noch entsprechen umwandeln.
 
Reth   Nutzer

06.04.2006, 20:39 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

Zitat:
Original von Holger:
Nein, erzeuge einfach exakt so viele Objekte, wie Du es jetzt auch schon tust. Ist jedes tile ein einzelnes Objekt -> ok, dann ist jedes tile auch ein eigenständiger painter. Gibt es kein tile Objekt, sondern ein Background-Objekt, das alle tiles als array o.ä. verwaltet -> ok dann wird dieses Background-Objekt zum painter.


Hm, dann hab ich wohl den Waal. Meine Animationsobjekte haben ihre Position und bekommen von außen ggf. neue Positionen gesetzt, sie alle werden aber in einem anderen Objekt verwaltet, welches über die Änderungen wachen soll und diese zu Bild bringen.

Allerdings wollte ich die gesamte Animationshierarchie entkoppelt lassen von zeichenspezifischen Sachen, was sich ja aufhebt, wenn ich einer dieser Klassen das Painter-Interface verpasse.

Zitat:
So soll auch auf dem Window auch nur in Ausnahmefällen ein anderer Painter gesetzt werden. Normalerweise stellst Du ja immer das Gleiche dar, ein Level, eine Statusanzeige, ein paar Konfigurationsmögichkeiten, etc. Nur der Zustand dieser Objekte ändert sich. Und wenn das passiert, wird lediglich dem Fenster mitgeteilt, daß ein Refresh gewünscht ist. Der Painter bleibt derselbe.

Wenn aber z.B. jedes Animationsobjekt einen Painter darstellt ist es doch eher "übel" diesen im Window zu setzen, dann wäre es doch eher angebracht diese alle in den Layoutmanager zu hängen und der ruft dann die paint()-Methoden auf, wenn er ein Update vom Fenster mitgeteilt bekommt?!

Ciao
 
Reth   Nutzer

06.04.2006, 08:13 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

@Holger:

Hm, dann würden bei mir aber für jedes Tile und jedes bewegliche Objekt ein eigener Painter entstehen, wenn ich den Objekten das Painter-Interface zuordne. Ist das nicht ein bisschen viel?

Dachte eher daran, dass ein Painter (oder wie bei mir bisher ein RastPort-Objekt) alles macht, ähnlich dem Graphics-Objekt von Java-Components (das kann man ja auch nicht setzen).

Der Statuspainter würde dann z.B. in meinem Fall ein Array(Liste) aus Strukturen (Objekten) übergeben bekommen mit Texten und Positionen dazu, um die Ressourceninformationen zu schreiben.

Du merkst sicher schon, dass ich mich mit dem Ansatz etwas schwer tue, obwohl er mir gefällt.
 
Reth   Nutzer

05.04.2006, 22:05 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

@Holger:

Jetzt versteh ich schon eher wie Du das mit den Paintern meinst.
Aber wie mach ich dass, wenn ich viele Bilder blitten/drawen will, sollte das doch auch mit einem Refresh gehen.
Sollte es dann einen Painter geben, der z.B. einen Vector mit Bildern entgegennimmt und diese dann blittet?

Oder wie ist das in Deinem Konzept vorgesehen? Jedesmal das Image setzen und requestRefresh rufen kann ich mir nicht vorstellen!
 
Reth   Nutzer

05.04.2006, 20:34 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

Zitat:
Original von Holger:
Ne, ne, is schon so, wie Du denkst. setPainter() macht das, was Du von einer set... Methode erwarten würdest. Ala
code:
windowPainter=p;
requestRefresh();


Gut, dachte schon ich blicks echt nich mehr!
Zitat:
Was willst Du sammeln? Du hast Objekte, die einen Status haben, und wenn der sich ändert mußt Du einen Refresh triggern, z.B. mit einer Methode ala requestRefresh(); auf dem Fenster (die Du natürlich schreiben mußt...), funktional vergleichbar mit repaint() in Java. Optional sollte man auch einen Bereich übergeben können, der dann zur damagedRegion des Layers hinzugefügt werden kann.

Hm, ich seh gerad nur nicht, wo die letztendliche Implementation der Blitroutinen sein soll? Im Painter oder im RastPort, oder delegiert der Painter an den RastPort, wenn er was neu zu zeichnen hat?
Also:
code:
painter.blit(...);
window.requestRefresh();
...
// im Painter
rastPort.blit(...);

?(
 
Reth   Nutzer

05.04.2006, 20:26 Uhr

[ - Direktlink - ]
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4

Zitat:
Original von Holger:

Hmm, ich versuche ja auch immer offen gegenüber allem zu sein, und GoldEd scheint wirklich sehr viele Features zu haben.
Aber allein das Positionieren des Cursors nach einer Einfügeoperation ist für mich ein Ausschlußkriterium. So könnte ich nie arbeiten, und wenn keiner eine Konfigurationsmöglichkeit kennt...
Und daß ist ja nicht die einzige Eigenheit, bei der GoldEd polarisierend auf die User wirkt.


Naja muss zugeben, dass ich noch nicht mit den internen Befehlen programmiert habe. Dort könnte man CTRL-V neu belegen und aus dem Menü entfernen. Dann gibt man der Tastenkombination einfach die benötigte Befehlsreihenfolge, so dass der Cursor nach dem Einfügen hinter dem Eingefügten steht (nur Theorie, noch nicht ausprobiert).
Allerdings sollte sowas natürlich einfach konfigurierbar sein!
 
Reth   Nutzer

05.04.2006, 20:22 Uhr

[ - Direktlink - ]
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4

Zitat:
Original von schluckebier:

Z.B. kommt oben direkt unterhalb der Symbole immer ein weißes Feld, in dem der Dateiname steht. Finde ich vollkommen unnütz, da der Dateiname ohnehin im Fensterrahmen steht (und Platzverschwendung ist es obendrein, weil in dieser Zeile sonst nichts steht), bekomme ich aber ums Verrecken nicht weg. Sollte also jemand einen Tipp haben... Falls ich's nicht hinbekomme, muss das Backup von GoldEd 6 halt wieder her. :o)


Wenn es das ist, was ich denke, dann ist das die Zeile mit den Tabs der geöffneten Dateien! Ein äußerst gutes und nützliches Feature.
Sobald mehrere Dateien geöffnet sind, stehen die Dateinamen in den Tabs oben und man kann auf einen Klick darauf zwischen den geöffneten Dateien hin- und herschalten. Suuupergut.
Dazu rechts noch die Projektleiste mit den Sourcen, Headern und makefile - erste Sahne!!!

Hoffe, ich konnte helfen, ansonsten bringen evtl. Screenshots mehr, zur Not an meine Mailadresse (dann haben die anderen halt nicht ganz soviel davon).

Aber die Konfig ist zum Teil echt schwer zu verstehen.
Z.B. alles was ich im Kontextmenü des Makefiles einstelle (Farbcodes etc.) bezieht sich auf .h und .cc Dateien. Deren Kontextmenüs sind dagegen recht leer.

Hab mir aber schon mit den internen Befehlen ne Faltroutine für markierte Blöcke programmiert (auf- und zuklappen, nur Eingabe der Beschreibung fehlt noch), dazu noch ne Routine die mit CTRL-7 die aktuelle Zeile aus- bzw. einkommentiert.

Da geht noch viel mehr, und dann gibts ja noch Arrexx. Ist halt alles sehr aufwendig.
 
Reth   Nutzer

05.04.2006, 12:49 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

Hi Holger,

Zitat:
Original von Holger:
Zeichenoperationen sind an sich nicht kritisch. Aber RastPort wie Graphics besitzen einen Zustand wie aktuelle Zeichenfarbe, Zeichenmodus, Line Pattern, etc.
Man sollte sicherstellen, daß zu Beginn eines Refreshs ein definierter Ausgangszustand herrscht. Das kann man erreichen, in dem man immer eine Kopie resp. neuen RastPort herausgibt oder alle Attribute zurücksetzt.

...

Deshalb ist eine getRastPort-Methode auf einem Fenster nicht sinnvoll. Dem Fenster sollte die fürs Zeichnen zuständige Instanz bekannt sein, an die es den Refresh delegieren kann.

Vereinfacht so:
C++ code:
class Painter
{
  virtual void paint(RastPortObj& rp);
}

class Window
{
  //... bißchen was weggelassen ;)
  public:
    setPainter(Painter& p);
  protected:
    void refresh();
}

Window::refresh()
{
  windowPainter.paint(new RastPortObj(intuiWindow->RastPort));
}



Komme bei dem Bsp. nicht ganz mit.
Wird da bei setPainter() im Window der internen Variable windowPainter die Referenz auf p zugewiesen, oder sind das 2 unterschiedliche Painterobjekte, die da im Spiel sind? In letzterem Fall komm ich gleich gar nicht mehr mit.

Wie kommt man denn in obigem Bsp. an Blitfunktionen und so Sachen wie Vordergrund-/Hintergrundstift setzen dran?
Momentan sind das Methoden meiner RastPortklasse, die public sind, da man ja die Darstellung beeinflussen will.
Wird im Painterobjekt gesammelt, so lange, bis paint() gerufen wird?

Vielleicht kannst Du mir hier kurz auf die Sprünge helfen?!

Ciao
 
Reth   Nutzer

05.04.2006, 09:34 Uhr

[ - Direktlink - ]
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4

Geht das wirklich nicht, oder weiss es keiner?

Gibt es zu GoldED eigentlich irgendwo ne Doku oder Benutzerhinweise zur Konfiguration? Die ist nämlich m.M. nach nicht in allen Punkten intuitiv, sprich man weiss nicht ob versch. Dinge einfach nicht gehen, oder man sie nur noch nicht gefunden hat.
 
Reth   Nutzer

05.04.2006, 09:23 Uhr

[ - Direktlink - ]
Thema: C++ Compiler
Brett: Programmierung

@Honitos:

Also ich kann da eigentlich nur GoldED Studio (nunmehr Cubic IDE) empfehlen. Es ist zwar nicht klein (GCC), aber schnell installiert und funktioniert "out of the box". Zudem bekommst Du viele schöne weitere Dinge mitinstalliert, wenn gewünscht.
 
Reth   Nutzer

04.04.2006, 14:54 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

@Solar:

Hi nochmal,

genau diese Dinge bietet die RastPort-Klasse, nicht die Windowklasse, denn die genannten Operationen laufen auf einem RastPort und dieser ist unabhängig von einem Fenster (kann auch von einem Screen kommen, oder für sich existieren).

Ist so ähnlich wie die Graphics-Klasse in Java.

Es wird immer in einen RastPort gezeichnet, nicht in ein Fenster und nicht in einen Screen.
Daher hat die Fensterklasse ein RastPort-Member. Dieses kann man sich besorgen, um dann die Zeichenoperationen darauf auszuführen.

Wenn man will kann man auch ein eigenes RastPort-Objekt anlegen und darin herumzeichnen.
Was man bei meiner Konstruktion allerdings (bisher) nicht kann (und auch erstmal nicht können soll), ist einem Fenster einen neuen RastPort zu setzen.
 
Reth   Nutzer

04.04.2006, 09:58 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

@Holger:

Die Frage ist, ob das hier wirklich hilft?
Das RastPort-Objekt ist um den Zeiger auf eine existierende RastPort-Struktur aufgebaut.
Bei einer Kopie kann ich zwar den Zeiger auf diese RastPort-Struktur kopieren, aber das ändert ja nichts, die Zugriffsmöglichkeiten bleiben ja die gleichen (abgesehen von evtl. vorhandenen anderen Membern der RastPortklasse)! Die dahinterliegende RastPort-Struktur bleibt dieselbe (muss sie ja, da sie ja z.B. zu einem Fenster oder Screen gehören kann, in dem ich meine Sachen angezeigt haben will).

Oder soll die RastPort-Struktur auch kopiert werden und jedesmal wenn eine Operation darauf ausgeführt wird der RastPort im Fenster, Screen etc. ausgetauscht werden?
 
Reth   Nutzer

04.04.2006, 09:21 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

@Solar:

Versteh ich, aber das hier genannte Problem ist ja nicht GUI-spezifisch.

Ist halt nur zufällig so, dass ich bei der GUI-Programmierung drauf gestoßen bin.
 
Reth   Nutzer

04.04.2006, 08:45 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

@Solar:

Bin in C++ ziemlich blutiger Anfänger (obwohl das ja eine Designfrage ist und daher eigentlich von der Prog.-Sprache unabhängig).

Aber wie würdest Du/"man" das dann designen?

Im konkreten Fall hab ich eine Window-Klasse, die eine nicht konstante Referenz auf ihr RastPort-Objekt zurückgibt, damit man darin Operationen fahren kann.
Wenn ich die Referenz konstant mache, muss ich alle Public-Methoden der RastPortklasse ebenfalls konstant machen, damit darauf von außen zugegriffen werden kann.
Bin mir nicht sicher, ob das geht, da die RastPortklasse einen Zeiger auf ne RastPort-Struktur kapselt und darauf z.B. Blitoperationen macht und sich dabei ja die RastPort-Struktur ändert (allerdings nicht der Zeiger darauf, mit dem ja gearbeitet wird - geb ich zu).

Wie erstellt man da ein Design, dass mit konstanten Referenzen arbeiten kann bzw. wie stellt man dann das Design um?

?( ?( ?(
 
Reth   Nutzer

03.04.2006, 22:03 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

Es lag wohl an der Art der Implementierung von B, die auf Header und Source verteilt war und bei make nicht zusätzlich angegeben wurde.

Habe das nun geändert und es sieht besser aus, habe aber noch kein endgültiges Ergebnis!

Jop, das wars wohl!

[ Dieser Beitrag wurde von Reth am 03.04.2006 um 22:47 Uhr geändert. ]
 
Reth   Nutzer

03.04.2006, 21:06 Uhr

[ - Direktlink - ]
Thema: G++ ld undefined Reference
Brett: Programmierung

Hallo zusammen,

versteh gerad nicht was da los ist.
Ich hab ne Klasse B, von der inner anderen Klasse A ne Klassenvariable angelegt wird.
Diese Klasse A kann eine Referenz auf die Klassenvariable zurückgeben.
Ein Objekt der Klasse A wird per Referenz an eine Klasse C übergeben, dort wird dann von A per Methodenaufruf die Refernz auf B geholt und ne Methode von B gerufen.
Die Klassen wurden prima compiliert und gelinkt, so lange ich in C nicht den Methodenaufruf von B implementiert hatte (über die Referenz von A). Die Klassen und Methoden waren alle schon da es wurde alles compiliert und gelinkt. Nun nachdem ich den Methodenaufruf doBStuff() in C implementiert hatte meldet der Linker beim letztendlichen Linken des Executables "Undefined Reference to B::getBStuff()" in C.

Muss ich in C die Klasse B auch noch inkludieren? Wenn ja, wieso?

Sorry, bekomme keine Leerzeichen in den Code, bei der Eingabe sind sie jedenfalls da.


//Klasse A
#include "B"

class A
{
privat:
B b;

public:
B& getB() { return b; }
}

...
// Klasse C
#include A

class C
{
public:
void do(A& a)
{
a.getB().doBStuff();
}
}


Danke schon mal!

Ciao
 
Reth   Nutzer

23.03.2006, 22:15 Uhr

[ - Direktlink - ]
Thema: YAM und Komprimierung
Brett: Amiga, AmigaOS 4

Sorry, wenn ich hier nicht ganz klar rüberkam:

Ich meine die Postfachkomprimierung!
 
Reth   Nutzer

22.03.2006, 20:38 Uhr

[ - Direktlink - ]
Thema: YAM und Komprimierung
Brett: Amiga, AmigaOS 4

Hallo zusammen,

ich habe noch eine Frage zu diesem Thema. Aus anderen Threads weiss ich, dass man das XPK Paket installieren muss, damit man in YAM Komprimierung verwenden kann.

Nun ist bei mir nur die xpkmaster.library und im Unterordner die shrink.library installiert und ich befürchte, dass ich nach Installation des XPK PAketes ausm Aminet mein System evtl. dahingehend beeinflusse, dass andere Anwendungen nicht mehr laufen.

Reicht es auch, die entsprechenden Unter-Libs zu kopieren?

Gibt es auch ein PPC-Version (nicht AOS4), um den PPC zum De-/Komprimieren zu nutzen?

Danke schon mal!

Ciao
 
Reth   Nutzer

21.03.2006, 14:51 Uhr

[ - Direktlink - ]
Thema: GoldED Konfiguration
Brett: Amiga, AmigaOS 4

Hallo,

vielleicht wurden die Fragen ja schon mal beantwortet, dann verweist mich doch bitte an die entsprechenden Stellen!

Wie kann ich denn GoldED so konfigurieren, dass der Cursor nach dem Einfügen aus dem ClipBoard hinter dem Eingefügten steht anstatt davor?

Danke schon mal!

Ciao
 
Reth   Nutzer

21.03.2006, 11:40 Uhr

[ - Direktlink - ]
Thema: Erneute Umfrage zu AOS4 auf PegII
Brett: Amiga, AmigaOS 4

Zitat:
Original von _PAB_:
@rbn:
Und das, was Genesi mit den MorphOS-Entwicklern macht - ist das etwa richtig und unterstützenswert ?
http://morphos.net/


Das ist ja eigentlich nicht das Thema. Aber was AInc mit den Usern macht ist m.M. noch viel übler. Verhindern, dass AOS4 veröffentlicht wird, indem man keine neue Hardware zulässt und das Ganze totsitzen will!

Das mit Genesi und den Entwicklern ist eigentlich eine interne Angelegenheit. Auf MOS/Pegasos Seite gibts aber alles: Ein OS und eine vernünftige Hardware!

Und auf AmigaOS Seite? Wo kann ich denn nen AOS-Rechner kaufen und woher bekomme ich AOS4 (na gut bin Classic Betatester, drum komm ich jetzt schon in den Genuss und finds daher nur umso mehr schade, dass es hier nicht weiter geht!)?
 
Reth   Nutzer

20.03.2006, 16:10 Uhr

[ - Direktlink - ]
Thema: Erneute Umfrage zu AOS4 auf PegII
Brett: Amiga, AmigaOS 4

Sorry, spenden ist hier wirklich falsch übersetzt, hab ich eigentlich nicht gemeint.

Aber es stimmt auch, dass es schon andere und bessere Angebote gab und ich bin mir auch ziemlich sicher, dass AInc das Ganze auch ablehnen wird, werd das noch ergänzen.
 
Reth   Nutzer

20.03.2006, 15:23 Uhr

[ - Direktlink - ]
Thema: Erneute Umfrage zu AOS4 auf PegII
Brett: Amiga, AmigaOS 4

Hi allerseits,

auf amigaworld.net läuft mal wieder eine Umfrage bzgl. einer Portierung von AOS4 auf den PegII.

Der Initiator würde EUR 20.000,- spenden, wenn sich mind. 250 Befürworter finden. Er favorisiert dann einen Einzellizenzpreis von EUR 110,-; EUR 80,- für seine Investition und EUR 30,- für die Nichtsdafürtuer von AInc, die das Ganze sicher wieder ablehnen oder ignorieren werden.

Also, alle die dagegen oder dafür sind: Auf auf zum Voten!

[ Dieser Beitrag wurde von Reth am 20.03.2006 um 16:10 Uhr geändert. ]
 
Reth   Nutzer

18.03.2006, 23:37 Uhr

[ - Direktlink - ]
Thema: Messagehandling - Eure Meinung
Brett: Programmierung

Hm, das Ganze geht eigentlich schon Richtung MVC.
Du kanns bei jedem Fenster bzw. jedem Gadget etc. Receiverobjekte registrieren, die bei bestimmten Aktionen informiert werden sollen. Es ist egal, wie viele Fenster Du geöffnet hast, da die Methoden in der Fenster- bzw. Gadgetklasse usw. definiert sind die auszuführende Logik wird in den Receiverklassen implementiert, die damit zu Controllern werden. Es ist auch kein Problem, ein Controllerobjekt bei mehreren Fenster- oder Gadgetobjekten etc. zu registrieren, wenn man das unbedingt will.

Den Code kann ich für jede Anwendung wieder verwenden, in denen ich Fenster und Gadgets verwende. Ich muss nur einmal Code schreiben, der die Intuition Messages "dekodiert" und an die Receiver verteilt.
 
Reth   Nutzer

17.03.2006, 20:50 Uhr

[ - Direktlink - ]
Thema: Messagehandling - Eure Meinung
Brett: Programmierung

Hi nochmal,

da der letzte Thread so gut lief hier gleich noch einer!
Da ich aus der Java-Ecke komme und mich gerade an C++ versuche, habe ich mir für die Message-Bearbeitung von Intuition folgendes gedacht:

Ich kupfere die Java-Methodik ein bisschen ab, da ich aber auch recht faul bin, dachte ich ich belass das Ganze erst mal beim Window, ohne Delegation.

Im Klartext ich mach an der Fensterklasse eine bis mehrere Methoden zur Registrierung von Receiverobjekten je nach Art der zu empfangenden Message.

Wenn das einigermaßen läuft, dachte ich später daran, die Delegation nachzubauen und die entsprechenden Messages an die Komponenten des Fensters (Gadgets etc.) weiterzuleiten.

Was meint ihr denn so dazu? Ist mal ein erster Ansatz.

Ciao
 
Reth   Nutzer

14.03.2006, 21:21 Uhr

[ - Direktlink - ]
Thema: Koordinatentransformation, Überdeckung
Brett: Programmierung

Zitat:
Original von bubblebobble:

Aber du siehtst jetzt, warum man dazu eigentlich ein paar Grafiken braucht, das wird schnell zu kompliziert in Worte zu fassen, obwohl es eigentlich einfach ist.


Allerdings! Ich wüsste gern mehr darüber, wie Du die einzelnen Sachen umgesetzt hast (z.B. das mit den Blitroutinen Block, Bit Maske, Alpha, Transparent, Add, Sub; oder das mit den "Rampen" bzw. Textureberechnungen für die Steigungen!

Hoffentlich findest Du mal die Zeit ein paar Erläuterungen hier und da festzuhalten!

Ciao
 
Reth   Nutzer

14.03.2006, 15:41 Uhr

[ - Direktlink - ]
Thema: Koordinatentransformation, Überdeckung
Brett: Programmierung

Zitat:
Original von bubblebobble:
Ja, davon gibts noch mehr, aber nichts released und noch nichts programmiert. Nur Studien bis jetzt.


Schade! Wollte mal den Unterschied zwischen gepixelt und gezeichnet begutachten.

Zitat:
Ja, Objekte die sich bewegen muss man "umhängen" im Array, aber egal ob das direkt auf dem Tile array ist oder dem "imaginären", rechteckigen Array. Allerdings kann dann ein Objekt auch in mehreren Arrays sein. Aber ich denke der Overhead lohnt sich. Wieviele sich bewegende Objekte planst du denn? Ich meine nicht feststehende Anims, wie z.B. eine wehende Fahne, weil da kann man einfach die Maximum Größe aller AnimFrames angeben und fix lassen.

Dann muss man aber die Objektarten unterscheiden statisch vs beweglich, damit man bei den statischen Objekten immer den größten Frame als Umriß hernehmen kann (sowas hatte ich in meiner 1. Version schon zum Hintergrund retten).
Wenn man unterscheidet in statische vs. bewegliche Objekte, dann werdens bei mir wohl in einer ersten Version ca. 10 bewegliche Objekte. Wenn man nur in statische vs. veränderliche Objekte unterscheidet, kann sich das Ganze dann auf ca. 30-50 aufschaukeln.

Zitat:
Speichern würde ich das ganze in einem dynamischen, eindimensionalen Array pro Rechteck Feld. Das ist also ein Array, was dynamisch erweitert wird, falls es zu klein ist.

Das ist der Vorteil der STL Container, die sind schon dynamish. Die Vectors und Maps, von denen ich sprach passen sich in der Größe an.

Zitat:
Es wird also nicht zwischen Boden-Tile, stehenden Objekten und beweglichen Objekten unterschieden. Alle sind in der gleichen Struktue gespeichert. Wenn sich ein Objekt bewegt, wird diese eben manipuliert.

Ist das eine Frage, oder machst Du das so bei Dir?

Zitat:
Die Überdeckung ist eigentlich ganze einfach.Grob wird nach ISO Tiles sortiert, also Objekte auf einem ISO Tile weiter vorne sind auch immer im Bild weiter vorne. Objekten innerhalb eines Tiles gehen dann nach Hotspot. Dadruch kann man z'.B. immer och Zäune entlange der Tilegrenzen machen, wo man einmal davor und einmal dahinter stehen kann. Nur mit Hotspot geht das nicht, das funktioniert nur bei punktuellen Objekten wie Bäumen, Figuren etc.

Für Dein "sind weiter vorn" ohne HotSpot brauchst Du doch aber ne z-Information, oder nicht?

Zitat:
Bei meiner Methode gibt es aber noch den vorteil, das Tiles höher sein können als andere, ohne mehraufwand. Dadruch lassen sich z.B. sehr hohe Berge machen, sodass die Boden Tiles eigentlich mehrere Tile Ebenen höher liegen (optisch). Gespeichert sind sie aber schon brav auf ihrem Platz im Tile Netz.

Wie unterscheidet sich das dann im Handling der Tiles, wenn diese unterschiedliche Höhen haben (in der Optik isses ja klar)?

Danke nochmals!

Ciao
 
Reth   Nutzer

14.03.2006, 10:23 Uhr

[ - Direktlink - ]
Thema: Koordinatentransformation, Überdeckung
Brett: Programmierung

Zitat:
Original von bubblebobble:
@Reth
Ja, der Screenshot ist von meinem Spiel. Die Figur ist allerdings aus einer (sehr viel) älteren Version, als die Landschaft noch gepixelt war. Jetzt ist sie richtig gezeichnet, was mir besser gefällt, obwohl gepixelt auch seinen Charme hat, aber eben old-school aussieht.


Lecker, gibts noch mehr davon zu sehen oder testen? Ist das schon "released" oder noch in Entwicklung?

Zitat:
Kurz gesagt: Man baut die Landschaft in Tiles auf, so wie gehabt. Allerdings nimmt man nicht das Tile Array, um herauszufinden welches Object neu gezeichnet werden muss, sondern ein nochmals imaginär darüberliegendes Array, was dann auch Rechteckig sein kann. Das Array enthält dann für alle Raster-Rechtecke die Information, welches Objekt darinliegt. Das kann man in aller Ruhe berechnen, bevor das Spiel los geht. Objekte die sich bewegen müssen natürlich geupdated werden, aber das kostet kaum Zeit, das sind ein paar Bytes verschieden.
Muss ich einen Bereich neu zeichnen (es wird grundsätzlich immer alles neu gezeichnet), lege ich ein ClipRect um diesen Bereich, schaue in welche Rechtecke des Raster-Arrays die Refresh-Region hineinragen, und erhalte sofort alle Objekte, die ich dann stumpfsinnig blitte. Das ist alles.

Vorteil: Schnelles auffinden aller Bilder, die neu geblittet werden müssen, und Objekte können beliebig gross/hoch sein. Auch kann man Hügel machen, sodass Tiles "angehoben" werden. Der Refresh engine ist das völlig egal woher die Bildchen kommen, weil sie nur in das Raster-Array schaut.


Danke für Deine Beschreibung. Gute Idee mit dem imaginären Raster!
So ähnlich hab ich mir das für mich auch überlegt. Aber Du musst immer pro Durchgang alle Objekte prüfen und in Deinem drüberliegenden Array ggf. umhängen (denke mal, es ist ein Array von Zeigern und an jeder x,y-Position liegt ne aufsteigend sortierte Liste mit Zeigern auf die zu blittenden Objekte, oder?). Bin mal gespannt, wie schnell das bei mir wird.

Ich mach folgendes: Dank C++ und der STL nehme ich einen Vector, in dem liegen alle grafischen Objekte (Zeiger). Dazu nehme ich noch 2 3-dimensionale Maps, die 1. (x,y,z) bildet alle sichtbaren grafischen Objekte auf die Postionen der Hintergrundtiles (x,y) ab. An diesen Postionen liegt dann ne Map von Zeigern, der grafischen Objekte, die über dem Tile liegen (ein Objekt kann ja über mehreren Tiles liegen). Da Maps sortiert sind, werden die Zeiger mit ihrer Tiefeninformation als Schlüssel abgelegt, damit hab ich automatisch alle Objekte in der richtigen aufsteigenden Blitreihenfolge.

Die 2. Map (z,x,y) enthält dann alle neu zu zeichnenden Objekte pro Durchgang, diesmal kommt an erster Stelle die Tiefeninfo und dann die genaue x,y-Position der zu blittenden Objekte. Dadurch wird dann Schicht für Schicht übereinander geblittet.

Aufwändig wird wohl die Bestimmung, welche Tiles von einem Objekt überdeckt werden (dazu muss ich x,y-Position und Höhe, Breite des Objektes berücksichtigen, innerhalb dieser Bereiche [x, x+Breite] [y, y+Höhre] wird dann geschaut, über welchen Tiles das Objekt liegt und der Zeiger eingetragen dazu muss dann immer noch das max. ClipRect berechnet werden).

Das müsste eigentlich klappen, hoffe ich!

Ciao
René
 
 
Erste << 42 43 44 45 46 -47- 48 49 50 51 52 >> Letzte Ergebnisse der Suche: 1858 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.
.