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 3 4 5 6 7 -8- 9 10 11 12 13 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)
Der_Wanderer   Nutzer

05.01.2011, 11:35 Uhr

[ - Direktlink - ]
Thema: teiltransparenz
Brett: Programmierung

@Thore
Wie hast du das denn gemacht?
Anders als ich geschrieben habe? (Read/WritePixelArray) Evtl. kann ich noch was lernen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

04.01.2011, 22:13 Uhr

[ - Direktlink - ]
Thema: teiltransparenz
Brett: Programmierung

@akl
Schreib' ich doch.
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

04.01.2011, 20:41 Uhr

[ - Direktlink - ]
Thema: teiltransparenz
Brett: Programmierung

Du brauchst eine Weiche, ob es ein farb-indizierter Screen ist oder Echtfarben.

Bei Echtfarben liesst du mit ReadPixelArray() den Hintergrund in einen Speicherbereich mit fixem Pixelformat, z.b. ARGB. Dann verrechnest du Pixel für Pixel die Daten und schreibst das mit WritePixelArray zurück.

Bei farb-indizierten Bildschirmen geht das nicht, da man den Pen nicht so enfach ermitteln kann. Das geht zwar auch, ist aber etwas rechenaufwendiger. Wenn man in Betracht zieht, das praktisch alle schnellen Systeme 16 oder 24 bit benutzen, und bei einem farb indizierten Screen eine eher langsame CPU darunter werkelt, kann man sich das sparen und kann nur on/off transparenz machen.

So mache ich das mit den Skins (und allen anderen Grafiken) in NTUI, z.b. hier in der Sprechblase:

Bild: http://www.hd-rec.de/pics/ntui_status16.png

Ein wichtiger Aspekt ist noch die re-draw Stategie, denn man darf nicht wie bei on/off transparent ein Bild zweimal auf den gleichen Fleck zeichnen. Man muss also jedesmal vom Fenster Hintergrund beginnen und alle sich überlappenden Elemente neu zeichnen.
Das kann man später evtl. etwas optimieren, aber so musst du das von gund auf erstmal machen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 04.01.2011 um 20:45 Uhr geändert. ]
 
Der_Wanderer   Nutzer

29.12.2010, 22:09 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

@Holger
Du hast natürlich, wie so oft, Recht, man kann die Pointer auch in der Klasse speichern, wenn man dafür eine Instanz anlegt. Bei vielen und kleinen Objekten ist das wesentlich effizienter, wenn auch etwas aufwendiger.

Bei NTUI habe ich das nicht gemacht, da es wenige Methoden sind und der overhead nicht so gross. Dafür spart man sich den Aufwand, die Klasse zu verwalten, und kann leichter "von aussen" in non-OOP Style Methoden subclassen, ähnlich wie SetFunction() für Libraries.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

23.12.2010, 12:07 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Nein, so macht man das nicht.

Das ist sogar eine ganz schlechte Idee, denn die Funktionen der Ober-Klasse müssen selbstverständlich mit den aktuellen Daten arbeiten.

Merke: Redundanz (z.b. Daten an zwei verschiedenen Stellen speichern) = ganz, ganz schlechte Idee.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

23.12.2010, 11:58 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Ja, natürlich. Man kann nichts subclassen, was man nicht kennt, was wäre sonst der Sinn davon? Dann wären es zwei getrennte Klassen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

23.12.2010, 10:43 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Wieso sollte er das nicht wissen?

Du solltest eher in C denken als in Assembler, das ist eigentlich nicht gut für OOP geeignet. Die Unterklasse erweitert ja einfach nur den Struct. Warum sollte sie nicht auf die geerbten Felder zugreifen können?
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

22.12.2010, 23:00 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Genau. Das macht die XUIA_USER ID.

Ich habe das mal so genannt, "XUI" heisst dein Toolkit, "A" steht für Attribute, und "_USER" ist der Name der ersten freien ID.

Im NTUI ListView widget wäre das also

NTUILVA_USER

NTUI - LivtView - Attribute - User


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

22.12.2010, 22:23 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Natürlich ist der Struct zur Compilezeit bekannt. Sonst wäre es ja kein Struct. Du greifst doch auch auf die Koordinaten irgendwie zu. Genauso kannst du doch auf die Funktion Pointer zugreifen, was hindert dich daran?
Normalerweise mit einem offset, z.b.

JSR DRAW_METHOD_PTR(a0)

Wobei a0 den Objekt Pointer enthält, und DRAW_METHD_PTR der offset ist.

Die Getters and Setters IDs sind ja keine Methoden IDs.
Wenn der Benutzer eigene Attribute vergeben will, dann machst du das so wie bei Taglists üblich (das ist ja genau das gleiche).
Du definierst

XUIA_USER = ...
und der Benutzer fügt seine IDs ab diesem Wert aufwärts hinzu. Den setzt du hinreichend gross.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

22.12.2010, 21:07 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Der Offset ist zur Compilezeit immer bekannt.
In unserem Beispiel wäre das Objekt Pointer + 12, für alle Objekte von "Sprite" und dessen Unterklassen.

IDs oder ähnliches haben nichts mit OOP zu tun, im Gegenteil. Das wird eher benutzt um OOP nachzuahmen, ist aber keine wirklich gute Idee und sehr limitiert.

Ich benutze sowas nur bei Getters und Setters, da es nicht praktikabel ist für jedes Detail eine Methode zu machen.

Achja, nochwas: niemals den Zugriff auf Structs erlauben ausserhalb des Codes der den Struct definiert.
Sonst ist man Ruckzuck in der Falle, wenn es um Erweiterungen geht (siehe AmigaOS).

Beispiel:
Du speicherst das Layout deiner Widgers mit x/y und width/height.
Nun stellst du fest, dass x1/y1 und x2/y2 intern sehr viel komfortabler ist und möchtest das umstellen. Wenn du nun den Zugriff auf width und height per Struct zugelassen hast, sitzt du in der Falle.
Über Getters und Setters kein Problem, da man es ohne größere Umstände umrechnen kann.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

22.12.2010, 19:09 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Nochmal ein simples Beispiel:

code:
+-----------------------------------------------------------------------------
  | 
  | Struct sprite {                     ; define a general "sprite" structure
  |   x.f:y.f
  |   image.l
  | }
  | 
  | Function sprite::Draw(*this.sprite) {   ; define a general draw method
  |   DrawImage(this\image,this\x,this\y)   ; use fictive function DrawImage()
  | }
  | 
  | Struct sprite->alien {  ; define alien sub class, by inheriting from sprite
  |   energy.f
  | }
  | 
  | Function alien::Hit(*this.alien,energy.f) { ; define a method for the alien
  |   this\energy - energy
  | }
  | 
  | *myAlien.alien = New()              ; create a new alien object
  | 
  | ; call the methods on myAlien object:
  | myAlien\Hit(10)                     ; this works only on aliens!
  | myAlien\Draw()                      ; this is a method inherited from sprite
  | Delete(*myAlien)                    ; delete the alien object
  |
  +-----------------------------------------------------------------------------

Also was haben wir hier?

Es gibt eine Klasse "Sprite", die hat Informationen über die Position x/y und das Bild des Sprites.
Ausserdem gibt es eine Methode "Draw" zum anzeigen des Sprites.

Der eigentlich Struct in Assembler würde so aussehen:
code:
float x
float y
ptr image
ptr Draw()
ptr Delete() ; <= Destructor, haben alle Objekte


Jetzt können wir Subklassen vom Sprite bilden, z.b. für ein Alien Gegner.
Dort kommt noch die Energie dazu und die Methode Hit().

Der Resultierend Struct aus ASM sicht wäre:

code:
ptr Delete() ; <= Destructor, haben alle Objekte
float x
float y
ptr image
ptr Draw()
;------------------- hier kommen Felder von "Alien"
float energy
ptr Hit()


Zur Laufzeit muss das Alien nicht mehr wissen, dass es ein Sprite ist. Auch ein Array von Sprites muss nicht wissen, dass dort Teilweise Aliens drin sind, da ja alles was ein Sprite ausmacht vorhanden ist.
Man ruft einfach Draw auf. Draw könnte z.b. jetzt auch Überladen werden, aber in dem Fall mache ich das aber nicht.
Hit() darf natürlich nur auf einem Alien aufgerufen werden, aber wenn du ein Sprite Struct hast dann kennst du ja Hit auch gar nicht, also kommt du erst gar nicht in die Versuchung.
Das ist schon mehr oder weniger alles über die OOP Magie.

Der Anwender kann nun auch selbst Sprite, oder auch Alien, Subklassen und weitere Felder hinzufügen, weiter Methoden oder auch vorhandene Methoden überladen. Alles, was ein OOP braucht also.

Note:

New = AllocMem + Init
Delete = Deinit + FreeMem

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 22.12.2010 um 19:10 Uhr geändert. ]
 
Der_Wanderer   Nutzer

22.12.2010, 15:12 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Es gibt verschiedene Wege das alles zu realisieren.
Dein Problem ist halt, dass du Assembler verwendest, und daher erstmal den OOP Code von C++ oder einer anderen OOP Sprache nachprogrammieren musst.

Hier ist mein Vorschlag:

1. Methoden haben keine ID. Es sind Funktion Pointer, wie in einer Library. Eine Objekt Instanz kennst seine Funktionen immer.

2. Ein Objekt muss seine Eltern Klasse zur Laufzeit nicht kennen. Es kennt nichts, ausser sich selbst, und das steht zur Kompilezeit immer fest.
Generell stellst du dir das evlt. falsch vor. Eine Klasse gibt es nicht in Form von Daten. Es ist nur eine Definition in Gedanken, die nach dem Kompilieren nicht mehr existiert, genauso wie Structs oder Variablen. Alles sind am Ende nur noch Speicherzugriffe an bestimmte Offsets.
(Debug-Informationen oder Call-by-Name sind hier was anderes, aber das brauchst du erstmal nicht)

3. Vergiss das Wort "Garbadge Collector". Du gibst deine Objekte in gewohnter Manier frei - mit Hilfe der Destructor Funktion (ich sage jetzt absichtlich nicht Methode), die es für jede Klasse gibt.

4. Bei dem Beispiel mit dem ImageButton hat Holger natürlich recht, aber ich wollte es jetzt verkomplizieren, das war ja nur ein Beispiel für Vererbung. Im GUI System solltest du die mölgichst mächtige "Drawables" implementieren, sodass du ohne zutun z.b. Bilder überall einfügen kannst, und das nicht jedesmal individuell implemenieren musst.
z.b. eine "RichText()" Funktion, die auch Bilder im Fliesstext kannt.
AmigaOS kennt z.b.
code:
Text(rp,"Hallo",5)

, und damit Zeichnest du deine Texte für Label Button Karteitreiter etc.
Hast du aber einmal "RichText()" geschrieben, werden auf einmal alle Widgets viel "mächger".
So ein RichText könnte z.b. sowas machen:
code:
RichText("\i'AISS:Exclamation'\bHallo"

was dann Hallo in Bold macht und vorher das AISS Bildchen zeichnet.
Dafür solltest du dann am besten noch so wie in NTUI auto-resizing der Bilder machen, sodass sie Fontgröße bekommen.

Bild: http://www.hd-rec.de/pics/ntui_status20.png


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ Dieser Beitrag wurde von Der_Wanderer am 22.12.2010 um 15:19 Uhr geändert. ]
 
Der_Wanderer   Nutzer

19.12.2010, 21:19 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Richtig. Und wenn du auch dem Benutzer erlaubst, eigene Funktionen reinzuhängen (unter Zugriff auf die Original), dann ist dein System offen und viel mächtiger. Du kannst nämlich nicht alle Wünsche der Programmierer befriedigen. Das ist ein Fass ohne Boden.

Einen Dispatcher im dem Sinn gibt es nicht.
Einen Dispatcher gibt es für Events, die verarbeitet werden. Die treten aber sehr viel seltener auf als Methoden, deshalb ist das wichtig dass die Methoden effizient aufgerufen werden, z.b. wenn eine komplexere GUI resized wird, oder wenn viele Attribute gesetzt werden.

Der Vorteil von Funktion Pointern ist eben die Erweiterbarkeit, und der Aufwand ist O(1), während dein Dispatcher einen Aufwand von O(n) hat.

Wo man eine Art Dispatcher einbauen kann sind die Getters und Setters.

Also

GetAttr(widget, attr, value);
value = GetAttr(widget, attr);

Da man nicht unbedingt für jedes spezielle Attribut eine eigene Funktion braucht. Ich würde die Funktionen eher gering halten, und
Widgets nur über Get/SetAttr verändern. Dann ist alles zentral unter Kontrolle.
Man kann dann eine "ConvinientStubbs" Biliothek machen, wo dann sowas gewrapped wird:

SetTextForStringGadget(StringButton* btn, char *text) {
btn->SetAttr(btn, STRINGA_TEXT, text);
}

Aber das sollte man seperat halten. Es sollte klar sein, was eine reine Convinient Stubb ist und was eine echte Funktion ist.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 19.12.2010 um 21:31 Uhr geändert. ]
 
Der_Wanderer   Nutzer

19.12.2010, 21:05 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

@AGSzabo
Das was du machst ist nur ansatzweise objektorientiert.

So eine switch-Kaskade ist ineffizient (gutes Beispiel, dass Assembler nicht durch seine bloße Verwendung zu schnellerem Code führt).

Das Problem dabei ist, dass alles statisch ist, d.h. alle Subklassen müssen zur Compilezeit bekannt sein.

Das macht es aber unmöglich, dein GUI system durch 3rd Party widgets zu erweitern, oder dass der Programmierer eine Variente mittels subclassing erstellen kann, z.b. einen speziellen Scroller der Suchtreffer farblich anzeigt.

Deshalb benötigst du Function-Pointer.

Also z.b. nochmal zum Button:

code:
struct Button {
  int x,y;
  int width, height;
  int borderstyle;
  Hook *Draw;
  Hook *SetSize;
}

Button* Button_Create() {
  btn = malloc();
  btn->x = 0,0;
  btn->Width = 100,20;
  btn->BorderStyle = 1;
  btn->Draw = &Button_Draw();
  btn->SetSize = &Button_SetSize();
  return btn;
}

void Button_Draw(Button *btn, RastPort *rp);
void Button_SetSize(Button *btn, int Width, int Height);


Eigentlich muss die Button Struct so aussehen.
Wenn ich nun den Image Button subclasse, dann kommt folgendes dazu:

code:
struct ImageButton {
  struct Button btn;
  Bitmap *bmap;
  Hook *SetBitmap;
}

ImageButton* ImageButton_Create() {
  btn = Button_Create();
  btn->bmap = ...
  btn->SetBitmap = &ImageButton_SetBitmap();
  btn->btn.Draw  = &ImageButton_Draw();

}

void ImageButton_Draw(ImageButton *btn, RastPort *rp) {
  Button_Draw(btn, rp);
  BltBmapRastPort(rp,btn->Bitmap);
}

void ImageButton_SetBitmap(*imageButton *btn, char* filename) {
  ...
}


Also, was ist hier passiert:

Button ist bereits ein eigentständiges Widget.
Dann kommt der ImageButton, dessen erster Teil der Struct dem Button entspricht. Somit kann man alle Operationen durchführen, die der Button schon kann, ohne dass man was doppelt implementieren muss.
Z.b. mit SetSize die Dimensionen setzen.
Dann bekommst der ImageButton aber nach das Feld "Bitmap", um das Bild zu speichern, und einen eigenen Konstruktor, der das initialisiert. (der Vollständigkeit halber benötigt man natürlich auch noch einen Destruktor).
Dann gibt es eine neue Methode "SetBitmap", die nur die Subklasse beherrscht. Auf einem Button Objekt kann man die nicht aufrufen.

Dann gibt es noch Draw, was Überladen wird mit einer modifizierten Zeichenroutine, die das Bild zusätzlich malt.

Das tolle am Überladen ist nun, dass man z.b. eine Liste von Buttons haben kann, wobei man nicht wissen muss welche Subklasse das nun genau ist. Man kann alle durchgehen und "btn->Draw" aufrufen, und alle malen sich korrekt.

Meiner Erfahrung nach mit NTUI würde ich nicht tiefer Subklassen als 3 Stufen.

Also z.b. du hast die Oberklasse "Widget".
Da sind solche Sachen drin wie x/y, width/height, borderstyle, visibility, bgColor, fgColor, Font, ID und die Methoden "Draw", "CalculateMinSize", "Layout", "DispatchEvent", "Free".

Eben alles, was alle Widgets gemeinsam haben, evtl. ein bisschen mehr.
Dann gibt es die Unterklassen, die die einzelnen Widget Typen implementieren, also Button, String, Cycle, ListView, Scroller, Slider, etc.
Darunter gibt es dann, sofern nötig, nochmal Unterklassen wie z.b.
Widget->String->NumString
Widget->String->MultiLine
Widget->Button->ImageButton
Widget->Button->Toggle
Widget->Button->Textbutton
Widget->Button->CheckBox

etc. etc.

Mehr Tiefen kann ich nicht empfehlen, dann wird es unübersichtlich.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 19.12.2010 um 21:09 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 19.12.2010 um 21:16 Uhr geändert. ]
 
Der_Wanderer   Nutzer

19.12.2010, 20:53 Uhr

[ - Direktlink - ]
Thema: USB-Midi
Brett: MorphOS

Ja, USB Interfaces bieten oft mehr als einen Port, aufgrund der Speed von USB. Dann müssten aber auch 16 Anschlüsse auf der anderen Seite sein, sonst macht das ganze ja keinen Sinn.
Oder verwechselst du die Ports mit Kanälen?

HD-Rec unterstützt momentan 8 Ports, die jeweils 16 Kanäle haben können.
Jeder Port muss einem CAMD Cluster zugewiesen werden.

Die 68K zlib wird benötigt, weil die MOS Version fehlerhaft ist. Auch HD-Rec benötigt die zlib.

Folgendes kann eine Quelle für die Crashes sein:

1. Der CAMD Treiber von Poseidon

2. camd.library

3. Der AHI Treiber

4. zlib.library

Bei camd.library muss es unbedingt das Replacement sein, nicht die original von Commodore.
Der AHI Treiber muss fit sein, denn so ziemlich jedes Feature von AHI wird ausgenutzt. Wenn AHIRecord aufnimmt, heisst das noch lange nicht dass der Treiber alle AHI funktionen ausimplementiert hat.
Evtl. schalte mal AHI ab.
Die zlib muss die 68K sein, die PPC Ports crashen alle, auch OS4 soweit ich weis.

Gaaaanz am Ende der Kette kommt irgendwann HD-Rec. Ich glaube nicht dass es crashed, da es schon erfolgreich auf MOS und OS4 gelaufen ist.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

18.12.2010, 21:34 Uhr

[ - Direktlink - ]
Thema: wie programmiert man "vererbung"
Brett: Programmierung

Vielleicht hilft dir das hier weiter:

http://hd-rec.de/A/inherit.html

oder schau dir den Source von NTUI an ;-)

Ansonsten:

Du machst eine generelle Klasse "Button".

Die hat die Felder und die Funktion


code:
struct Button {
  int x,y;
  int width, height;
  int borderstyle;
}

void Button_Draw(Button *btn, RastPort *rp);
void Button_SetSize(Button *btn, int Width, int Height);


Draw zeichnet, was bei allen Buttons gleich ist, z.b. die Border und den Hintergrund.

Jetzt machst du eine Subklasse "ImageButton", die bekommt zusätzlich das Feld "Bitmap" und muss die Funktion Draw ersetzen bzw. ergänzen:

code:
struct ImageButton {
  struct Button;
  Bitmap *bmap;
}

void ImageButton_Draw(*ImageButton *btn, RastPort *rp) {
  Button_Draw(btn, rp);
  BltBmapRastPort(rp,btn->Bitmap);
}


Die Funktion Draw wurde also überladen. Die Funktion SetSize muss nicht überschrieben werden, wurde also geerbt, genauso wie die Felder vom Button.

Wenn man keine Sprache hat, die OOP unterstützt, muss man dafür Funktionpointer nehmen, sonst ist kein überladen möglich.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

18.12.2010, 20:37 Uhr

[ - Direktlink - ]
Thema: USB-Midi
Brett: MorphOS

ich werde mal ein aktuelles Release zusammenschnüren.
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

18.12.2010, 18:55 Uhr

[ - Direktlink - ]
Thema: USB-Midi
Brett: MorphOS

Du hast die falsche MIDI Thread executable, die ist für den Classic.
Es gibt auch eine für das timer.device, was man unter MOS und OS4 braucht. Wenn man "Version ..." macht, steht welche Version das ist.
Die Exectuables liegen under "Bin/". Eigentlich sollte aber das Starten des richtigen Icons (HD-Rec_MOS) die richtigen Exectuables auswählen.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

18.12.2010, 16:06 Uhr

[ - Direktlink - ]
Thema: USB-Midi
Brett: MorphOS

d.h., Poseidon nennt seine MIDI Ports "MIDI1x1.in.0" etc.?

Ich nehme mal an der Timeout kommt nur, wenn Poseidon läuft.
Vermutlich dauert es zu lange das MIDI zu initialisieren?

Ich packe mal ein kleines Tool zusammen, was die aktiven CAMD Cluster auflistet.
Da kannst du auch sehen, ob es signifikant lange hängt.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

18.12.2010, 15:11 Uhr

[ - Direktlink - ]
Thema: USB-Midi
Brett: MorphOS

Weist du denn, wie das CAMD Cluster heisst, was Poseidon erzeugt?

Das musst du in den Prefs unter MIDI einem der 8 HD-Rec Ports zuweisen.
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

12.12.2010, 18:37 Uhr

[ - Direktlink - ]
Thema: 68K Assembler
Brett: Programmierung

Für Anfänger wäre evtl. auch Amiblitz3 zu empfehlen.
Dort gibt es eine grafische IDE, einen Source Level Debugger, auch unter WinuAE kann man Memory Hits anzeigen lassen etc.
Und wenn man zu faul ist, kann AB3 das "drumherum" machen und man konzentiert sich auf seine Routine.

Beispiel:

code:
MOVE.l #3,D0
MOVE.l #7,D1
ADD.l D1,D0

MOVE.l D0,result.l@(A5)

NPrint "Ergebnis: ",result
End


Das Prog würde 3+7=10 ausrechnen, in die Basic Variable result schreiben und auf der Console ausgeben.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

07.11.2010, 16:26 Uhr

[ - Direktlink - ]
Thema: 24bit Audio
Brett: Amiga, AmigaOS 4

HD-Rec kann im Mixdown bis zu 32bit (wav, aiff), allerdings nur in 16bit aufnehmen und wiedergeben. (es gehen auch mehr als 96kHz, btw.)

Das liegt daran, dass mir bisher kein 24bit Treiber in die Finger gekommen ist.

Wenn Dr Chaoticas Soundkarte 24bit aufnehmen/abspielen kann, könnte ich das einbauen wenn er bereit ist das zu testen. Ob das Sinn macht, ist eine andere Frage. Ich habe noch keine Soundkarte gesehen, die 24bit vom SNR her auch nur annähernd ausnutzen würde, bis auf sehr teure (>>500EUR), und die Aufnahme Quelle muss natürlich auch entsprechende SNR liefern, was z.b. ein Microphone prinziell nicht tut.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ Dieser Beitrag wurde von Der_Wanderer am 07.11.2010 um 16:32 Uhr geändert. ]
 
Der_Wanderer   Nutzer

24.08.2010, 20:50 Uhr

[ - Direktlink - ]
Thema: RGB16 lesen
Brett: Programmierung

Wo hast du denn die RGB16 Bilder her?
Gibt es zu dem Format eine Dokumentation?

Du solltest herausfinden, wie die Bits aufgeteilt sind.
Ich vermute, dass es 5+5+5 ist, nicht 5+6+5. Aber das kann man natürlich nicht wissen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 24.08.2010 um 20:51 Uhr geändert. ]
 
Der_Wanderer   Nutzer

09.08.2010, 13:55 Uhr

[ - Direktlink - ]
Thema: Betatester für neue iBatch Bildstabelverarbeitung gesucht !
Brett: Amiga, AmigaOS 4

http://stormwizard.amiforce.de/

Da sollte mal ein bisschen aufgeräumt werden, das stimmt.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

02.08.2010, 21:06 Uhr

[ - Direktlink - ]
Thema: Betatester für neue iBatch Bildstabelverarbeitung gesucht !
Brett: Amiga, AmigaOS 4

@gerograph
Evtl. hast du den Debugger an?

Ich kann 640x480 Bilder hunderte male in der Sekunde rotieren (WinUAE).

Wenns es trotzdem langsam ist, kann ich mal gucken ob man die Routine optimieren kann. sowas sollte ohne wirkliche Verzögerung möglich sein.
(Auf einem Thumbnail).

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

02.08.2010, 17:51 Uhr

[ - Direktlink - ]
Thema: Betatester für neue iBatch Bildstabelverarbeitung gesucht !
Brett: Amiga, AmigaOS 4

Anregung:
Drehe doch die Bilder bitte sofort in der Thumbnail ansicht.
Das mit dem Toggle Button ist sehr unintuitiv, und man weis nie ob man nun richtig dreht.

Drehen geht ganz schnell mit

image_ext.include/image_Rotate{srcimage,winkel,@destimage}

Winkel in Grad.
Da gäbe es noch einige nette Funktionen, z.b. Spiegeln, Schärfe, Kontrast oder Gamma.
--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
Der_Wanderer   Nutzer

29.07.2010, 11:31 Uhr

[ - Direktlink - ]
Thema: USB Soundkarte
Brett: Andere Systeme

Nein, die Lexicon kannst du nur als Standard Karte benutzen, d.h. 2 Kanäle gleichzeitig. Die kann man umschalten, aber alle 4 kann man nicht gleichzeitig aufnehmen. Das Unterstützt leider weder AHI noch das Standard USB Audio Protokoll.

Die übrigend Features sind Windows Software, das mit dem Hall etc. ist etwas irreführend.
Der "Soundkarte" liegt noch Cubase mit dem Lexicon Reverb Plugin bei. Mit der Soundkarte hat das aber rein gar nichts zu tun, das sind nur Windows-Goodies damit man in der Werbung mehr zu schreiben hat.
D.h das kannst du also unter dem Amiga auch nicht nutzen, egal welche Software.
D.h. eas du bekomsmt ist lediglich eine Standard Soundkarte, dafür aber mit sehr hoher Qualität und jeder Menge Anschlüsse und gutem Vorverstärker, was durchaus den Preis rechtfertigt.

Mit der anderenLösung fährst du aber auch nicht teurer:

iMic 30EUR
UltraGain 90EUR
X58T Micro 80EUR
------------------
Gesamt 200 EUR

oder

Lexicon 150EUR
X58T Micro 80EUR
------------------
Gesamt 230 EUR

Ich nehme mal an, du möchstest auch ein Micro, hängt halt alles davon ab was du am Ende aufnehmen willst. An den UltraGain kann man auch eine E-Gitarre hängen, und es etwas runterregeln für die Soundkarte.
Es ist nicht nur ein Mic Vorverstärker, eher generell ein Level-Anpasser.

P.S.:
HD-Rec hat auch einen Hall, der genauso gut ist wie der Lexicon Hall. Der Lexicon Hall ist legendär und hat einen sehr guten Ruf, allerdings ist das 30 Jahre her. Heute ist das nichts besonderes mehr.
HD-Rec gibts allerdings leider nicht für AROS, d.h. da bist du auf WinUAE/Amithlon angewiesen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 29.07.2010 um 11:34 Uhr geändert. ]
 
Der_Wanderer   Nutzer

28.07.2010, 22:10 Uhr

[ - Direktlink - ]
Thema: USB Soundkarte
Brett: Andere Systeme

So wie ich das lese, gehen Standard USB Soundkarten.

Dann würde ich dir die iMic empfehlen:

http://www.griffintechnology.com/products/imic

Gute Aufnahme Qualität, kompakt (bringt durch das kurze Kabel aber nicht so viel Zug auf den USB Port, wenn man z.B. was "dickes" dranhängt wie ein richtigen 6.5mm Kopfhörer oder eine Gitarre) und nutzt Standard USB Treiber. Hat keinen Schnickschnack, Mic/Line wird manuell eingestellt (ja, das ist ein Vorteil, weil die Automatic oft versagt) und nimmt auch stereo auf, ich denke auch das Mic (das machen die meisten nämlich nicht, weil man dann 2 Mic Verstärtker bräcuhte).

Kostet aber +/-35 Euschies, weis nicht ob das unter die Definition "günstig" fällt.
Sie ist aber deutlich besser als die meisten 10-20EUR Karten und immer noch billiger und handlicher als eine "richtige" Homerecording Karten, die oft nur eingeschränkt über den Standard Treiber gehen.

Wenns ein bisserl mehr sein darf, damit habe ich auch gute Erfahrung gemacht:

http://www.musikland-online.de/index.php?detail=lelau893808

Per Standard Treiber gehen aber nur 2 Eingänge, das ganze ist nicht so schön mobil und in die Laptop Tasche steckbar. Dafür ist der Mic Verstärker recht gut, die Qualität ist 1a. Und es gibt jede Menge Anschlüsse, die man getrennt regeln kann.

Und zu guter letzt, wenn du viel mit dem Micro aufnimmst, und die Vorverstärkung nicht der Soundkarte überlassen willst, dann lohnt sich auf alle fällt das hier:

http://www.behringer.com/EN/Products/MIC2200.aspx

Den (ein Vorgänger Modell) nutze ich mit der iMic, dann ist die Qualität hervorragend. Besser als so manches teure Studio Mischpult noch vor ein paar Jahren.

Falls dir noch ein gutes und erschwingliches Mic fehlt:

http://www.beyerdynamic.de/shop/mp/microphones/vocals-and-instruments/stage-vocals/wired-microphones/tg-x-58.html
esser als so manches gross Membran Studio Mic.


Ich war skeptisch, klingt aber wirklich sehr gut, besser als so manches kondensator grossmembran Studio mikrophon.

Ich selbst benutze

BeyerDynamic TX58 => Behringer UltraGain => iMic

für Sprach/Gesangsaufnahmen und bin sehr zufrieden.


--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 28.07.2010 um 22:29 Uhr geändert. ]
 
Der_Wanderer   Nutzer

20.07.2010, 21:52 Uhr

[ - Direktlink - ]
Thema: HDREC
Brett: Amiga, AmigaOS 4

Wenn es im I/O Control ankommt, dann kann HD-Rec es auch aufnehmen. Auch Effekte könntest du im Mixer drauflegen.
Die Aufnahme steht im I/O Control vermutlich lediglich auf "MIDI" statt auf "Audio". HD-Rec kann ja beides.

Das Sample wird angelegt, sobald du anfängst aufzunehmen, da musst du nichts extra für tun. In bestehende Sample "hinein" aufnehmen geht nicht (punch-in). Das ist bei der heutigen Speicherkapazität auch nicht mehr notwendig. Sowas hat man früher gemacht, als man z.b. nur feste 8 Spuren hatte. In HD-Rec nimmst du einfach alle Takes auf, jedes bekommt eine neue Spure. Später sortierst du dir dann die Abschnitte raus, die gut waren, z.b. mit dem Zerschneide Tool und wirft den Verschnitt weg.

Nicht vergessen, am besten die neuen Aufnahmen erstmal muten, sonst dudeln die immer alle mit.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 20.07.2010 um 21:55 Uhr geändert. ]
 
Der_Wanderer   Nutzer

20.07.2010, 20:33 Uhr

[ - Direktlink - ]
Thema: HDREC
Brett: Amiga, AmigaOS 4


Die Soundkarte muss Full-Duplex sein, sonst geht es nicht.
Alle einigermassen up-to-date Soundkarten sind Full-Duplex, also z.b. Soundblaster Live etc.

Kannst du mit irgendeinem Programm unter WinUAE aufnehmen?
(z.b. AHIRecord?)

Was zeigt HD-Rec im Prefs/Audio Dialog an? Kann man da den Aufnahme Kanal auf "Default" stellen, oder steht da nur "none" oder sogar "n/a" ?
Unter WinUAE heisst der KAnal immer "Default", d.h. es wird das Device benutzt was unter Windows als default Aufnahmegerät eingestellt ist.
Der AHI Treiber lässt leider nicht zu, das zur WinUAE laufzeit zu wählen.

--
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de

 
 
Erste 3 4 5 6 7 -8- 9 10 11 12 13 >> Letzte Ergebnisse der Suche: 1229 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.
.