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 << 19 20 21 22 23 -24- 25 26 27 28 29 Letzte Ergebnisse der Suche: 899 Treffer (30 pro Seite)
DariusBrewka   [Benutzer gesperrt]

05.11.2004, 00:33 Uhr

[ - Direktlink - ]
Thema: wahlbetrug in den usa... traurig
Brett: Get a Life

@ton

naja eine Erkenntniss habe ich gewonnen, dass nichts an Moores Filmen&Co nach Geldgier ausschaut, jedoch das DU unendlich dämlich bist.

Wie auch immer dein einziges Argument ist Moore=$$$$, Bush=LOVE, du bist einfach Disskussionsunwürdig, den disskutiern kannst du nicht.
 
DariusBrewka   [Benutzer gesperrt]

04.11.2004, 00:21 Uhr

[ - Direktlink - ]
Thema: wahlbetrug in den usa... traurig
Brett: Get a Life

@ton

Du solltest den Schwachsinn den du hier schreibst noch einmal lesen bevor du auf den absenden Knopf drückst. Andererseits scheinst du die letzten vier Jahre im Koma gelegen zu haben, viel mitbekommen scheinst du jedenfalls nicht zu haben PUNKT
 
DariusBrewka   [Benutzer gesperrt]

03.11.2004, 11:56 Uhr

[ - Direktlink - ]
Thema: wahlbetrug in den usa... traurig
Brett: Get a Life

Ehrlich, ich verstehe dieses Volk nicht. So **** kann doch keiner sein einen solchen Lügner, Kriegstreiber etc. zu wählen (Wahlbetrug hin oder her). Für mich heißt das nur, das 50% der Amerikaner zum Mond geschossen gehören. Aber wie auch immer, anstatt dass Bush xxx Mrd in den Krieg stopft, sollte er das Geld lieber dafür verwenden eine Glaskuppel über die USA zu bauen, was für die USA den Vorteil hätte nicht mehr so leicht angreifbar zu sein und für den Rest, dass wir uns nicht mit deren CO2 und anderen Dreck herumplagen müssen.

Nuja, mal sehen wieviele Särge noch heimkommen müssen bis die Amerikaner begreifen wie ***** Bush ist.

gruss
 
DariusBrewka   [Benutzer gesperrt]

28.10.2004, 10:42 Uhr

[ - Direktlink - ]
Thema: MUI & Window IDCMPs
Brett: Programmierung

wie malst du denn in das Fenster bisher?

Soweit ich mich zurück erinnere kannst du dir nicht einfach irgendwie den Fensterpointer holen und dann mittels Draw()&CO darin rum malen, sondern musst ein MUI-Object erzeugen und kannst dann mittels einer (Überladenen) MUIM_DRAW Methode darin rummalen, diese wird IMO automatisch bei jedem refresh aufgerufen. Unter anderem auch deshalb, weil MUI das Fenster jederzeit schliessen kann (HIDE&CO).

Habe jetzt leider nicht das MUI Developer archiv zur Hand, aber in den Exampels darun beindet sich ein Beispiel (class3.c oder so) wo dieses genau beschrieben ist.


Mit dem gleichem Ansatz kannst du auch das zweite Problem lösen indem du die Methode MUIM_HandleInput/HandleEvent benutzt, das oben angegebene Beispiel aus dem MUI Archiv benutzt sowohl MUIM_Draw als auch MUIM_HandleInput.

gruss.

Darius

[ Dieser Beitrag wurde von DariusBrewka am 28.10.2004 editiert. ]
 
DariusBrewka   [Benutzer gesperrt]

19.10.2004, 18:57 Uhr

[ - Direktlink - ]
Thema: Bilder Speichern mit Datatypes
Brett: Programmierung

Ich habe das zwar noch nicht untersucht, aber soweit ich weiss sind die Datatypes nur zum laden der Dateien, das speichern geschieht immer im Standardt Amiga Format, d.h. in ILBM. Hoffentlich irre ich mich!
 
DariusBrewka   [Benutzer gesperrt]

30.09.2004, 01:05 Uhr

[ - Direktlink - ]
Thema: MUI Listen???
Brett: Programmierung

soweit ich das verstehe hat der construct hook damit nichts zu tun, bzw. wenn du einen angibst wird dieser bei jedem INSERT aufgerufen und du kannst in diesem dann für jeden Eintrag Speicher usw. belegen, du musst m.w. auch nicht einen StringPoibnter zurückgeben sondern jeden anderen, aber das hilft dir hier auch nicht. In allem musst du wohl jeden Eintrag per INSERT einfügen
 
DariusBrewka   [Benutzer gesperrt]

24.09.2004, 20:46 Uhr

[ - Direktlink - ]
Thema: Homepage Richtlinien?
Brett: Get a Life

Hi Ich bin am überlegen ob ich eine eigene Homepage erstelle soll und nun habe ich eine (oder mehrere) Fragen zu dem was drauf muss.Ich habe gehört, dass ein Impressum rein MUSS wo meine Adresse usw. drin stehen muss, was mich natürlich stört, da ich keine Lust habe das mich jeder x-belibige nerven kann.

Kann man das nicht umgehen? z.B. diese nur auf Anfrage rausgeben und ein Impressum gibt's auch nicht auf jeder seite.

Gibt's da noch mehr Schweinereien?, oder eine Seite wo man alles nachlesen kann?

gruss
 
DariusBrewka   [Benutzer gesperrt]

20.09.2004, 18:01 Uhr

[ - Direktlink - ]
Thema: Direkte Gadgetabfrage unter MUI
Brett: Programmierung

Also, du kannst ganz einfach eine Funktion definieren, welche ein Object zurückgibt.

bsp:
code:
Object *NewButton(xyz) {
 Object *obj;
 obj=Button(xyz);
 if (obj) {
   DoMethod(...);
 }
 return obj;
}


so kannst du direkt bei der definition eine ID angeben und auch das andere was du brauchst. Jedenfalls geht das bei mir und du kannst einfach statt Button() NewButton() in die Definition angeben.

code:
Object *NewButton(...,ID)
 Object *obj;

 obj = SimpleButton(...);
 if (obj) {
   DoMethod(...., app, 2, MUIM_Application_ReturnID, ID);
 }
 return obj;
}
...



Object app* = ApplicationObject,...
 Child, maingrouo = VGroup,
 End,
End;

 if (app) {
    Object *display = HGroup,
                       Child, NewButton(..., BUTTON_ID_0),
                       Child, NewButton(..., BUTTON_ID_1),
                       ...
                      End;
   }
   if (display) DoMethod(maingroup, OM_ADDMEMBER, display); 
 }


allerdings ist es notwendig zuerst ein ApplicationObject zu erstellen und die ganze definition mit den Gadgets usw. später per OM_ADDMEMBER zuzufügen, weil man das appobject bei DoMethod() angeben muss (denke ich).

da meines wissens nach alle Strings die du MUI übergibst kopiert werden, kannst du in der Funktion auch den string (auf den Stack) parsen und per MUIA_ControlChar die Taste zum aktivieren definieren.

vieleicht hilft's dir ja.

[ Dieser Beitrag wurde von DariusBrewka am 20.09.2004 editiert. ]
 
DariusBrewka   [Benutzer gesperrt]

19.09.2004, 00:43 Uhr

[ - Direktlink - ]
Thema: MUI NList+NListree Klasse mit grafiken usw.
Brett: Programmierung

Also ausprobiert habe ich das mit den Images in NList nicht, aber ich vermute mal, dass wenn du ein DisplayHook hast dort für die betreffende Spalte/Zeile die Esc Sequence ESC I[s]einfügen musst, wobei das s aus MUIA_Image_Spec zu entnehmen ist. Beispielweise "5:images:test.png" für externe Bilder.
 
DariusBrewka   [Benutzer gesperrt]

11.09.2004, 12:28 Uhr

[ - Direktlink - ]
Thema: Cliping Fehler
Brett: Programmierung

Vieleicht hast du den falschen RastPort angegeben?, statt MyWindow->RPort Screen->RastPort oder so ähnlich.

Womit zeichnest du?, mit Draw()/Line(), SetPixel().

Andererseits habe ich mit WinUAE so einige Probleme, dass einiges (aber nur extrem selten dorthin gezeichnet wird, wo es nicht hingehört, was aber bei vielen Applikationen passiert und somit nicht auf meine Kappe geht). Das ist aber nur bei BlockOperationen der Fall.

gruss
 
DariusBrewka   [Benutzer gesperrt]

11.09.2004, 00:00 Uhr

[ - Direktlink - ]
Thema: Fensterinhalt mit Datatypes speichern
Brett: Programmierung

Darum sollte man auch die CGFX... Funktionen zum erhalten der Bitmap spezifischen Daten benutzen und dann kennt man die Speichergrenzen&Co. Vermeiden sollte man es aber trotzdem.
 
DariusBrewka   [Benutzer gesperrt]

10.09.2004, 23:27 Uhr

[ - Direktlink - ]
Thema: Fensterinhalt mit Datatypes speichern
Brett: Programmierung

Es dürfte im allgemeinen kein Problem bereiten direkt auf seine eigene Bitmap zuzugreifen und auch mittels memset() etc. zu löschen usw., jedenfalls wenn man die Speichergrenzen einhält. Mehr als ggf. falsche Pixel bekommt man so nicht, jedenfalls dann wenn die Bitmap nicht shared ist, d.h. zum Screen gehört.
 
DariusBrewka   [Benutzer gesperrt]

10.09.2004, 17:42 Uhr

[ - Direktlink - ]
Thema: Fensterinhalt mit Datatypes speichern
Brett: Programmierung

SetRast() löscht die zu einem RastPort gehörende BitMap, bzw. färbt die ein, wohingegen thomas einfach die RastPort struktur löscht d.h. mit Nullen füllt, könnte man auch mit AllocMem(MEMF_CLERAR...). machen.
 
DariusBrewka   [Benutzer gesperrt]

25.08.2004, 16:50 Uhr

[ - Direktlink - ]
Thema: Commodity Programmierproblem
Brett: Programmierung

müsste das nicht über IECLASS_RAWMOUSE gehen?

code:
CxObj          *CxMouse; 
                     IX             mouseinput = {
                                    IX_VERSION,
                                    IECLASS_RAWMOUSE,
                                    0,
                                    0,
                                    0,
                                    0,
                                    0,
                     };

			   	             SetFilterIX(filter,&mouseinput);
CxMouse = CreateCxObj((LONG) CX_SEND, (LONG) BrokerPort, POPMOUSE_ID);
if (CxMouse) {
 AttachCxObj(broker,filter);
 AttachCxObj(filter,CxMouse);
}


du erhälst aber damit auch Mausbewegungen etc., da müsstest du die Codes usw. überprüfen
 
DariusBrewka   [Benutzer gesperrt]

23.08.2004, 23:41 Uhr

[ - Direktlink - ]
Thema: Bilder im AmigaGuide
Brett: Programmierung

@bubblebobble

Ich weiss nicht ob du in dem zum Guide gehörigen Programm mittels amigaguide.library das guide öffnen musst, wenn nicht würde ich dir persönlich empfehlen das über HTML zu machen. Amigaguide bietet sonst keine Vorteile und einen Browser hat jedermann.
 
DariusBrewka   [Benutzer gesperrt]

10.08.2004, 23:12 Uhr

[ - Direktlink - ]
Thema: Library für MOS erzeugen
Brett: Programmierung

@thomas

Ich denke mal, du hast Recht. Danke
 
DariusBrewka   [Benutzer gesperrt]

10.08.2004, 14:56 Uhr

[ - Direktlink - ]
Thema: Library für MOS erzeugen
Brett: Programmierung

@tokai

Vieleicht hast du Recht, habe gestern nachgefragt, wie schnell das auf MOS mit 68K code geht und es war nicht übermässig lange.

Andererseits hatte ich auch nicht vor die Lib selber an MOS anzupassen, sondern den LIB-Source meinem Programm beizufügen, dass wenn jemand das machen will, es ihm freisteht.

Mein Programm ist jedenfalls inzwischen dafür bereit und benutzt interne Funktionen, falls die lib nicht existiert ansonsten werden die Lib-Funktionen benutzt.

Leider bekomme ich Kurioserweise die lib nicht übersetzt, es ist nämlich so:

Ich benutze wie oben angeführt CLIB-SDI und mit GCC2.95 scheint es da Probleme zu machen, die mir sehr eigenwillig erscheinen. Wenn ich in einer Library Funktion eine Exec Funktion aufrufe, so geht alles gut, wenn ich aber in meiner Library funktion aine Funktion aufrufe, welche eine Exec Funktion aufruft, dann meldet GCC einen Fehler, dass die Library Base meiner Erzeugten Liibrary nicht definiert ist.

Es liegt nicht an meiner Library, sondern ist bei mir auch in der Beispiellib aus CLIB-SDI

beispiel aus der CLIB-SDI Library, welches Funktioniert:

code:
/* this one shows how functions with variable argument lists are handled */
ASM(LONG) LIBex_TestRequest2A(REG(a0, STRPTR title), REG(a1, STRPTR body),
REG(a2, STRPTR gadgets), REG(a3, APTR args), REG(a6, struct ExampleBaseP *ExampleBase))
{
  struct EasyStruct estr;

  estr.es_StructSize   = sizeof(struct EasyStruct);
  estr.es_Flags        = NULL;
  estr.es_Title        = title;
  estr.es_TextFormat   = body;
  estr.es_GadgetFormat = gadgets;

  ++ExampleBase->exb_NumCalls;
  Forbid();
  return EasyRequestArgs(NULL, &estr, NULL, args);
}

das Forbid hat oben keinen Sinn, wude von mir nur Testweise eingefügt um den Fehler zu zeigen.


nun das gleiche Beispiel welches NICHT Funktioniert:

code:
/* this one shows how functions with variable argument lists are handled */

void test() {
  Forbid();
}

ASM(LONG) LIBex_TestRequest2A(REG(a0, STRPTR title), REG(a1, STRPTR body),
REG(a2, STRPTR gadgets), REG(a3, APTR args), REG(a6, struct ExampleBaseP *ExampleBase))
{
  struct EasyStruct estr;

  estr.es_StructSize   = sizeof(struct EasyStruct);
  estr.es_Flags        = NULL;
  estr.es_Title        = title;
  estr.es_TextFormat   = body;
  estr.es_GadgetFormat = gadgets;

  ++ExampleBase->exb_NumCalls;
  test();
  return EasyRequestArgs(NULL, &estr, NULL, args);
}


in diesem Beispiel kommt von gcc dei Meldung

code:
examplefuncs.c: In function 'test':
examplefuncs.c:26: 'ExampleBase' undeclared (first use in this function)
examplefuncs.c:26: (Each undeclared identifier is reported only once
examplefuncs.c:26: for each function it appears in.)
make: *** [examplefuncsgcc.o] Error 1

 
DariusBrewka   [Benutzer gesperrt]

09.08.2004, 19:30 Uhr

[ - Direktlink - ]
Thema: Library für MOS erzeugen
Brett: Programmierung

Nunja, für 68K AOS habe ich ja dann die 68K library, mir ist nur wichtig, dass das ganze dann auf PPC klappt d.h. schnell ist, sonst würde sich der Aufwand ja auch nicht lohnen. Der Rest in meinem Code würde nicht unbedingt vom PPC profitieren, da es eigentlich egal sein sollte, ob ein Fenster nun in 0.1 oder 0.2 Sekunden aufgeht.

Jetzt muss ich nur noch herausfinden wie man eine MOS Library erzeugt ;-) bzw. benutze CLib-SDI müsste wohl damit zu machnen sein.

danke
 
DariusBrewka   [Benutzer gesperrt]

09.08.2004, 15:33 Uhr

[ - Direktlink - ]
Thema: Library für MOS erzeugen
Brett: Programmierung

Hi Ich mal wieder.

Ich habe in meinem Programm einige sehr Rechenintensive Operationen durchzuführen (TrueColor Berechnungen etc.) das geht auf WinUAE auch so schnell genug, aber ich denke, dass es beispielweise auf MorphOS doch nicht so schnell mit Emulieter CPU (trotz JIT) geht und so würde ich gerne diese Teile aus meinem Programm in eine/ein Library/Modul auslagern.

NUn meine Frage, wenn ich diese Lib für MOS übersetze(n lasse), wie sieht das dann mit der Kompatiblität zu den 68K libs aus, mein Programm kann weiterhin nur 68K. Anders ausgedrückt bringt das was an Speed (denke mal es wird PPC Code erzeugt) und läuft mein programm weiterhin?

Ich kenne mich mit MOS nicht aus und weiss nicht wie man das von der Registerbergabe von 68K auf PPC macht oder besser wie MOS das macht damit es läuft.

danke

Darius
 
DariusBrewka   [Benutzer gesperrt]

09.08.2004, 10:42 Uhr

[ - Direktlink - ]
Thema: FFS int und OS1.3
Brett: Amiga, AmigaOS 4

Ich glaube schon das es schon mit 1.3 FFS gab aber nicht im ROM, sodass man nicht von z.B. Diskette Booten konnte,auf die Platte hatte man das FS aber installieren können, da OS1.3 erstmals auch von HD booten konnte.

Es mag aber sein, dasses FFS int erst mit 2.x gab
 
DariusBrewka   [Benutzer gesperrt]

08.08.2004, 14:56 Uhr

[ - Direktlink - ]
Thema: Neues MOS Problem
Brett: Programmierung

Ist inzwischen behoben, lag daran dass sich MatchFirst/Next/End() auf MOS scheinbar ein wenig anders als auf AOS verhalten.

Man kann soweit ich weiss nicht einfach ein Verzeichnis angeben, welches untersucht werden soll, also mit CurrentDir() ändern, da ich aber während der Untersuchung lokale Daten aus dem letzten lokalen Verzeichnis laden muss, habe ich kurz nach MatchFirst() dieses wieder zurückgesetzt und das hat auf AOS immer funktioniert, da ich dachte MatchFirst() speichert dieses zwischen. dadurch ist auf MOS aber einiges durcheinander geratenso dass ich das CurrentDir(dir vor MatchFirst()) jetzt hinter MatchEnd() gesetzt habe.

Leider muss ich jetzt nach jedem MatchNext() zwei mal CurrentDir() aufrufen.

Nunja, hauptsache es funktioniert jetzt.

gruss

[ Dieser Beitrag wurde von DariusBrewka am 08.08.2004 editiert. ]
 
DariusBrewka   [Benutzer gesperrt]

06.08.2004, 11:44 Uhr

[ - Direktlink - ]
Thema: GCC 2.95.3 und float
Brett: Programmierung

@gni

du hast wohl Recht ist aber schon einige Jahre her wo ich das Zeug installieren müsste. War für mich aber eine schlussforderung, da er ja keine -68881 Option angegeben hatte.
 
DariusBrewka   [Benutzer gesperrt]

05.08.2004, 18:28 Uhr

[ - Direktlink - ]
Thema: GCC 2.95.3 und float
Brett: Programmierung

@thomas

Habe bei mir auch -lm und wenn ich hier bei WinUAE auf 020 noFPU stelle schmiert das nicht ab. Soweit ich sehe heissen alle Libs libm in dem lib Verzeichnis befinden sich aber Unterverzeichnise für FPU etc. d.h. man mus die wohl eher rüberkopieren.

Gruss

Darius
 
DariusBrewka   [Benutzer gesperrt]

02.08.2004, 15:48 Uhr

[ - Direktlink - ]
Thema: Neues MOS Problem
Brett: Programmierung

Zitat:
Ich finde deine Einstellung irgendwie ein bißchen komisch. Warum investierst du drei bis vier Stunden täglich, wenn es dir keinen Spaß

Ich weiss nicht, ob ich etwas von keinen Spass geschrieben habe. Fakt ist wenn du etwas an Personen schickst, weil du eigentlich mit deinem Programm überfällig bist UND extra schreibst dass das Wichtig ist, würdest auch du Sauer werden, wenn du nach 3 Wochen noch keine Antwort erhälst. Wie gesagt man braucht nur das Icon anklicken und Fertig ist oder auch nicht. Warum es auf MOS so viele Komplikationen gibt weiss ich nicht, ich jedenfalls sehe bei mir kein gravierenden Fehler.

Zitat:
macht ? Es zwingt dich doch keiner. Warum versuchst du MorphOS zu unterstützen, wenn du kein Feedback dazu bekommst ? Es zwingt dich doch keiner. Warum beschwerst du dich ? Du machst es doch freiwillig,

es gibt halt aber noch Menschen, die mir auch auf MOS Feedback geben, Leider kann man aber mit einem/zwei Tester/n manche Sachen nicht beurteilen, ob das nun Persönliches Pech, oder etwas MOS typisches ist.

Zitat:
es zwingt dich doch keiner. Für eine als Hobby programmierte Freeware ist es doch kein Problem, wenn mal drei Wochen oder Monate nichts daran gemacht wird. Oder wenn es auf MorphOS nicht läuft. Man kann

über ein Jahr, und wenn ich angebe dass ich eine neue in ein Paar wochen veröffentlichen will, so finde ich das schon schlimm, wenn ich erstmal Wochen/Monate-lang auf Antwoten warten muss.

Leider gibt es von OS Installation zu OS Installation auch Unterschiede und ich kann einige Bugs nicht selber reproduzieren, d.h. ich muss mich auf BetaTester verlassen!, wenn ich aber Vorschläge unterbreite oder Bugfixes anbiete, so will ich doch wissen ob's gklappt hat oder? schliesslich ist es so, das diese Leute das Pogramm benutzen wollten.

Zitat:
das ganze auch viel ruhiger angehen, ohne fremde Systemprogrammierer zu beschimpfen (siehe MorphOS Versionsnummern).

wo habe ich das?, bzw. wenn ich gesagt bekomme " andere AOS Programme machen auf MOS aber keine Probleme " , fragt man sich schon woran dieses liegt. Auf AOS 68k unterscheidet man soche Sachen an den Versionsnummern und wenn es auf MOS damit nicht geht, kann ich nichts dafür, deshalb ist mein Programm noch lange nicht Buggy!

Inzwischen testet mein Prog auf MOS und wenn dann workbench.lib V41 existiert wird trotzdem nur von V39 ausgegangen, leider ist selbst dieses bei manchen MOS Funktionen Sinnlos!, da diese einfach nicht vorhanden zu sein scheinen. Natürlich hast du aber Recht dass man die MOS Developer nicht deswegen beschimpfen soll (was ich auch nicht tat).

Zitat:
Und wenn du Rückfragen an deine Tester stellst, dann solltest du die Antworten auch hier dazuschreiben (z.B. welches Assign denn nun gefragt wurde). Sonst darfst du dich nicht beschweren, daß du beschuldigt wirst, Anfragen ungefiltert weiterzugeben.

Ich denke mal, wenn es irgend welche Informationen darüber geben würde ich das garantiert auch angeben und würde selber auch Lösungen haben. Sprich es kommen Assign Requester ohne Information, nächstes mal werde ich das natürlich nicht vergessen!

Jetzt ist aber Schluss mit dem persönlichen Zeug, ich gebe hier keine Ungefilterten Anfragen weiter und habe erst mehrere Tage selber nach dem Problem gesucht.
 
DariusBrewka   [Benutzer gesperrt]

02.08.2004, 11:02 Uhr

[ - Direktlink - ]
Thema: Neues MOS Problem
Brett: Programmierung

Nachtrag:

Im "amiga-news.de/forum/Morphos&Andere System" habe ich hier einen Aufruf gestartet damit Leute mein Programm auf MOS testen.

Geantwortet haben auch einige (6 Personen), vor ca. 3 Wochen habe ich denen Vesionen zum Testen geschickt, drei dieser Personen hielten es bilang nicht für nötig auch nur eine Zeile zu schrieben, ob's läuft oder nicht. Da das Programm auch ohne Installation läuft finde ich das traurig. Von den MOSlern, auf deren Antwort ich seit 2 bzw. 4 Monate warte ganz zu schweigen.
 
DariusBrewka   [Benutzer gesperrt]

01.08.2004, 23:50 Uhr

[ - Direktlink - ]
Thema: Neues MOS Problem
Brett: Programmierung

@thomas

Entschuldignug, wenn ich etwas Frage und dieses wie schon gesagt nur auf MOS Probleme bereitet, wie so vieles andere auch,so muss es sich meiner Meinung nach um ein Grundsätzliches Problem handeln. wenn ich wie im letzen meiner Threads gesagt, mit einigen Funktionen unter MOS kein Erfolg habe, welcher aber in den Includes & Autodocs angeführt werden, dass sie existieren (d.h. die Funktionen existieren), so muss ich nicht von den Usern wissen, ob diese auch wirklich existieren.

Natürlich habe ich nachgefragt und auch spezielle Versionen erstellt, welche entweder das Problem zu umgehen versuchen oder zumindestens Ausgabn machen, nur irgendwann hat man es satt täglich unzählige Versionen zu verschicken die nichts bringen, da fragt man einfach ob jemand dieses Problem kennt. Schliesslich funktioniert auf 68k AOS Alles ohne diese Macken. Wenn MOS 100% Amiga Compatibel sein will, dann darf es keine Libs mit Versionsnummern V50 geben, die aber nur V40 unterstützen. Ich muss mir nicht deswegen anhören das mein Programm nicht mit MOS läuft.

Ich sitze jetzt einige Jahre an meinem Programm und verlange nichts dafür und JA es gibt einige die das benutzen, sprich also nicht von Bodenloser Faulheit, ich kann diese Zeit weit Sinnvoller nutzen, als mich 3-4 Stunden täglich vor den Rechner zu setzen um 0Euro Software zu erstellen.
 
DariusBrewka   [Benutzer gesperrt]

01.08.2004, 17:38 Uhr

[ - Direktlink - ]
Thema: Neues MOS Problem
Brett: Programmierung

@Holger

Kann ich nicht sagen, da ich das selber unter MOS nicht testen kann. Aber ich habe mir so etwas ähnliches auch gedacht, z.B. musste man doch für die AK Datatypes irgendein Temporary Verzeichnis angeben oder?.

Werde mal bei denen anfragen, welche das Problem haben, vieleicht läuft's ja mit anderen DataTypes

Ansonsten, ich kann nur das wiedergeben, was ich gesagt bekomme.

Was ich aber tue ist, zuerst das aktuelle Verzeichnis setzen, was in der Startup Messag angegeben ist wenn jedoch die benötigten Programm Daten woanders installiert sind, kann man das über ToolTypes setzen, d.h. existiert dieses TT, so wird jetzt das Current-Dir geändert.
Dann wird das Prefs-File geöffnet (relative Pfad angabe) und Zeile für Zeile eingelesen (mittels dos Aufrufen), dort kommt es nun vor, das Images angegeben sind, welche zu laden sind. Auserdem werden auch Icons einglesen. Bei den Icons kommen keine Probleme (alle mit relativen Pfad), bei den Images kommt der Requester (Images auch mit relativen Pfad). Wird bei den Images der Pfad Absolut angegeben, so können auch nicht mehr die Icons geladen werden.

[ Dieser Beitrag wurde von DariusBrewka am 01.08.2004 editiert. ]
 
DariusBrewka   [Benutzer gesperrt]

01.08.2004, 00:34 Uhr

[ - Direktlink - ]
Thema: Neues MOS Problem
Brett: Programmierung

Hi Ich habe wieder ein MOS Problem, und leider finde ich keine Lösung, bzw. warum dieses auftritt, bzw vorher habe ich das über guigfx gemacht wo auch der gleiche Fehler auftrat.

code:
struct NewImage *GetImageFromFile(char *name) {
	struct	BitMapHeader		*bmhd;
	struct	NewImage		*ni;
	struct	pdtBlitPixelArray	pa;
		Object			*pic;
		UWORD			w, h;

	ni = NULL;
	pic = NewDTObject(name,
		DTA_SourceType,	  DTST_FILE,
		DTA_GroupID,		GID_PICTURE,
		PDTA_Remap,		FALSE,
		PDTA_DestMode,	PMODE_V43,
		TAG_DONE);
					
	if (pic) {
		get(pic, PDTA_BitMapHeader, &bmhd);
		if(bmhd) {
			w = bmhd->bmh_Width;
			h = bmhd->bmh_Height;
			ni = NewImageContainer(w, h);
			if (ni) {
				pa.MethodID = PDTM_READPIXELARRAY;
				pa.pbpa_PixelData = (APTR) ni->data;
				pa.pbpa_PixelFormat = PBPAFMT_ARGB;
				pa.pbpa_PixelArrayMod = w*4;
				pa.pbpa_Left = 0;
				pa.pbpa_Top = 0;
				pa.pbpa_Width = w;
				pa.pbpa_Height = h;
				DoMethodA(pic, (Msg) &pa);
			}
		}
		DisposeDTObject(pic);
	}
 	return ni;
}


Aus 68K läuft alles gut, die Funktion soll ein Bild laden und daraus ein ARGB Puffer erzeugen. NewImageContainer belegt Speicher etc..

Der Fehler ist, das unter MOS beim ersten aufruf dieser Funktion immer ein Assign Requester kommt! und ich weiss nicht warum.

Ich habe zuvor mittels CurrentDir() das Verzeichnis geändert und alles wird korrekt geladen (Texte, Icons etc.), nur wenn Bilder über die Datatypes geladen werden sollen, dann kommt auf MOS dieser Requester.

Wie gesagt kam das auch unter guigfx, aber das lädt ja auch über die Datatypes.

gruss

[ Dieser Beitrag wurde von DariusBrewka am 01.08.2004 editiert. ]

[ Dieser Beitrag wurde von DariusBrewka am 01.08.2004 editiert. ]
 
DariusBrewka   [Benutzer gesperrt]

23.07.2004, 23:39 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

Natürlich ist da Alpha=NULL, da die Amiga Datatypes es trotz anderslautender Angabe nicht laden. Das Bild was geladen wird hat einen AlphaChannel, hatte schon damals das Problem, es wird maximal eine 1 Plane Maske unterstützt mehr nicht (wenn überhaupt).

Das ist wie beim cxg/p96 System, Funktionen kennen das RGBA Format, das A wird aber vollkommen ignoriert, ebenso sind die AlphaWerte in der guigfx.library nutzlos, da ich damit noch nie Bilder mit Alpha mischen konnte. Aus diesem Grund die DrawARGBImage() Funktion, die Source & Dest über Alpha per Hand mischt.

Aber ich kann,auch wenn Alpha geladen wrd, nichts damit anfangen, da ja NewDTObject() Icons sowieso nicht lädt und dann würden mir ja auch noch die ToolTypes fehlen. Ich muss alles auf MOS über die scalos API machen was auch geht, nur auf MOS halt nicht! bzw. unter der Scalos (iconobject API) wird das icon zwar geladen und auch der Alpha Kanal stimmt, nur bekomme ich selbst keine Bilddaten! Heisst ich bekomme Schwarze Bilder mit den richtigen Umrissen!

gruss
 
DariusBrewka   [Benutzer gesperrt]

23.07.2004, 17:37 Uhr

[ - Direktlink - ]
Thema: Ein Paar MOS Fragen
Brett: Programmierung

Irgendwie habe ich schon gewusst das dieses kommt ;-), aber egal auch wenn die Kanäle vertauscht sind müsste irgendwas kommen. DrawAlphaRGBToRP() zeichnet nur, wenn die Kanäle vertauscht sind, dann aber nur in Falschfarben, bei Kanälen in der richtigen Reihenfolge nicht, da dort der Alphakanal NULL ist.

Leider habe ich in meinen Programm aus früheren Zeiten teilweise auch eine andere Reihenfolge der Kanäle, mit welcher WritePixelArray() nichts anfangen kann und somit sieht's manchmal komisch aus. D.h. für
DrawAlphaRGB...() brauche ich ein anderes Pixelformat als für DrawRGB...(). Ist im Code nicht geändert worden.
Mit WritePixelArray() funktioniert das ganze (wenn auch Falsch, wenn ich das Falsche Pixelformat setze.), da hier seitens cgx.lib der Alpha ignoriert wird.
 
 
Erste << 19 20 21 22 23 -24- 25 26 27 28 29 Letzte Ergebnisse der Suche: 899 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.
.