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 << 7 8 9 10 11 -12- 13 14 15 16 17 >> Letzte Ergebnisse der Suche: 1229 Treffer (30 pro Seite)
Der_Wanderer   Nutzer

07.05.2010, 18:15 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Holger

Vollste Zustimmung, hätte das nicht besser sagen können.

Eigentlich müssten sich alle verbleibenden Entwickler erstmal auf eine freie, offene high-level API für AmigaOS stürzen. Wenn das dann in einem Jahr fertig wäre, hätte man eine gute Basis für neue Projekte, nach einem weiteren Jahr hätte sich das mehr als amortisiert und dann *könnte* es aufwärts gehen. Vielleicht. Aber so wie jetzt geht es auf keinen Fall. Mit aufwärts meine ich nicht, dass AmigaOS irgendwann in reichweite von Windows, Mac oder Linux kommt. Aber vielleicht mehr User als jetzt, oder zumindest bessere Software Versorgung als jetzt.

Wie Holger geschrieben hat, verpuffen die meisten Anstrengungen da sie für andere Entwickler wenig Mehrwert bringen und schon hunderte Male implementiert wurden. Das ist so wie zu Fuss um die Welt laufen. Wenn man sich vorher ein Flugzeug baut, dann kostest das zwar erstmal Zeit, aber danach ist man mächtig. Wenn man einfach zu Fuss los läuft, dann ist die zweite Hälfte genauso schwer wie die erste, man hat also nichts gewonnen.
Die Entwicklung einer Library, die lediglich von Bild Fromat A nach B kopiert bringt fast gar nichts.
Es muss ein ganzes System aus Libraries sein, die hirarchisch aufgebaut sind und gegenseitig nutzen ziehen.
So wie eben die Amiblitz3 Runtime. Nur umfassender, sophistikateter und konsistent durchgestyled, sodass jemand der weis, wie man ein Bild lädt, auch sofort weis wie man einen Sound lädt.
Eine gute Basis dafür wäre wohl AROS, das wären die einzigen die sowas "offiziell" machen könnten, und vielleicht würde es dann auf den anderen Platformen akzeptiert.


--
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.05.2010 um 18:34 Uhr geändert. ]
 
Der_Wanderer   Nutzer

07.05.2010, 16:57 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Thore:
OWB, Blender und Timberwolf sind alles Ports von Programmen, die auf Portierung bereits vorbereitet sind und keine Amiga Neuentwicklungen.
Da wäre eine High-Level API sogar eher störend als hilfreich, weil die Programme auch eher auf Low-Level Ebene arbeiten, und intern ihre eigene HighLevel API aufbauen, zwecks Portierbarkeit.
Aber das sind Grosse Projekte, die man alleine auf dem Amiga niemals stemmen könnte. Zumindest eben nicht mit der AmigaOS API.

--
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.05.2010, 15:07 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

... wobei Hollywood ein geschlossenes System ist, soweit ich weis. Das geht für "richtige" Entwicklung natürlich nicht, weil man zu anderen Libs, Sprachen, CPUs etc. im Ernstfall offen sein muss. Ist aber für 100%ige X-Platform Entwicklung wiederum notwenig.

--
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.05.2010, 14:43 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

> AmigaBASIC hat auch einen einfacheren Befehlssatz wie C/C++
Das kann man so nicht sagen.
C/C++ hat ja keinen Befehlssatz in dem Sinne, sondern verwendet (neben der Runtime natürlich) weitere Libraries. AmigaBASIC ist für jegliche Entwicklung, auch nur zum experimentieren, völlig out-dated und unbrauchbar.
Und eine GUI, ein Video Abspielen oder einen Emial Client lässt sich damit kein Stück einfacher machen als mit C++, im Gegenteil, das ist quasi unmöglich.

@Andreas Wolf
Ja, nett. Ich sage ja nicht dass Hollywood schlecht ist. Aber ich kann die Runtime nicht in C++ oder Amiblitz benutzen, das ist das Problem von Hollywood.
Es müsste etwas System näher sein und als Library daher kommen, und müsste noch einge weitere Bereiche abdecken. Z.b. glaube ich nicht, dass man sowas wie HD-Rec, YAM oder ArtEffect damit schreiben könnte.
Aber ich kenne Hollywood nicht so gut, evtl. irre ich mich.

--
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.05.2010, 14:34 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

> Bei mir sind das ca 2 Std am Abend....
Das ist schon so viel wie ich in einer Woche. Aber genau deshalb wäre ja mein Vorschlag einer höheren API gerade so wichtig.

Ich selbst kenne die AmigaOS API sehr gut, und habe logischerweise auch die Developer CD. Ich selbst habe ja so eine API wie ich sie vorschlage schon geschrieben, allerdings nur für Amiblitz3 und nicht allmächtig für alle Bereiche des Programmierens, sondern nur die, die ich selbst berührt habe. Das sind schon eine Menge aber es ist nicht erschöpfend und Aufgrund der langen Entwicklungszeitraum weit weg von Perfektion.

Aber ich bin nun immerhin in der Lage, wenn du mir jetzt sagst: "Programmiere ein Tool, wo ich ein Bild reinladen kann, die Schärfe und Farbraum anpassen, resizen und als JPEG, PNG, BMP oder IFF abspeichern."
Dann kann ich das in 2-3h erledigen, und zwar so dass es unter OS3, OS4 und MOS funtkioniert.
Mit der AmigaOS API direkt brauche ich dafür 20-30h, oder vermutlich noch wesentlich mehr wenn man die Saver und DSP Algorithmen noch entwickeln muss, und dannach auch noch Beta Testen auf den verschiedenen Plattformen.



--
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.05.2010, 13:14 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Ich glaube die "Zufriedenheit" mit der API so wie sie ist kommt daher, dass kaum jemand noch versucht was ernsthaftes damit zu entwickeln.
Den Amiga Proggern geht es wohl eher darum, sich mit dem OS als Selbstzweck zu beschäftigen als mit einer echten, nützlichen Applikation, die entstehen soll.

Es werden eher Mini-Projekte gemacht, die zum Experimentieren oder Lernen dienen, aber nicht als richtige Applikation released werden sollen, wo man auf Stabilität, GUI Richtlinien, Integration ins OS, Kompatibilität mit der Aussenwelt etc. wert legt.

Hollywood hat ja so etwas ähnliches vorgemacht, eine einfache, hoch angesiedelte API vorgegeben. Aber kaum jemand macht was damit. Viel mehr als ein Bildbetrachter oder Tic-Tac-Toe kam dabei ja nicht raus. Ich denke, dass nur ein kleiner Teil der Arbeit, die in Hollywood reingesteckt wurde, auch wieder herauskam. Will sagen, Hollywood wurde auch mehr oder weniger zum Selbstzweck entwickelt.
Die Gefahr sehe ich auch bei so etwas wie A/A++, obwohl es deutlich System-näher konzipiert ist.


--
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

06.05.2010, 21:09 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Thore:

> Allein für Linien zeichnen (Move und Line in eine Funktion) lohnt sichs sicher nicht,

Du hast aber gesehen, dass er in True Color zeichnet? Es ging mir dabei nicht darum, Move und Draw in eine Funktion zu bringen, das kann man von mir aus auch so lassen, obwohl sich dieses Konzept heute eigentlich auch überholt hat. Es ging mir darum, eine Funktion zu machen wie man sie heutzutage gerne haben würde.

BitMapScale ist auch ein Krampf, weil es Algorithmen-interne Probleme nach außen abwälzt, z.B. den Factor/Denominator Split. Das sollte man auf keinen Fall dem App Programmierer aufdrücken, der ist der letzte der weis wie man das am besten wählen sollte. Der App Programmierer will in der Regel die Zielgröße und optional die Qualität angeben, mehr nicht. Außerdem ist der Befehl nur für Echtzeit Einsatz geeignet, wenn man keine 3D HW hat. Fotos oder GUI Elemente sollte man damit tunlichst nicht skalieren.
Insgesamt sind die meisten der AmigaOS Funktionen extrem schwachbrüstig. Z.b. ReadPixelArray. Wenn die Quell Bitmap nicht Hi oder True Color ist, dann funktioniert es nicht. Wenn man also z.B. einen Screen Grabben will, muss man erstmal Fallunterscheidung machen. Bei 8 oder weniger Bit muss man dann ReadPixelArray8 machen, die Colormap aus dem Screen auslesen und das ganze in das gewünschte Ziel Pixelformat umwandeln.

Das wird dann aus einem einfachen ReadPixelArray schnell mal sowas:
code:
;///////////////////////////////////////////////////////////////////////////////
;/                                                                             /
;/ Syntax:  succ.l = image_CutRP{image.l,*rp.RastPort,@x.l,@y.l,@xs.l,@ys.l:: /
;/ ,@trgb.l,@tolerance.l,@dithermode.l,@colorMap.l}                            /
;/                                                                             /
;/ Description:                                                                /
;/ Creates an image object out of (a part of) the given Rastport.              /
;/ NOTE:  ideal for screen-grabbing.                                           /
;/                                                                             /
;/ Inputs:                                                                     /
;/ - image.l        : image object ID                                              /
;/ - *rp.RastPort   : Rastport where to fetch the data from                    /
;/ - trgb.l         : rgbvalue for the desired transparent color, e.g. $ff0000 f:: /
;/ or red, set it to -1 for no transparency                                    /
;/ - x.l,y.l        : optional: position from where to fetch                       /
;/ - xs.l,ys.l      : optional: width and height of the area to fetch              /
;/ - tolerance.l    : ???                                                      /
;/ - dithermode.l   : ???                                                     /
;/ - colorMap.l     : ???                                                       /
;/                                                                             /
;/ Result:                                                                     /
;/ - succ.l     : True if everything went well, False if it failed             /
;/                                                                             /
;///////////////////////////////////////////////////////////////////////////////
Function.l image_CutRP{image.l,*rp.RastPort,@x.l,@y.l,@xs.l,@ys.l,@trgb.l,@tolerance.l,@dithermode.l,@colorMap.l}
SHARED imagedat(),imageengine:USEPATH imagedat(image)
succ.l = False
If *rp
  If x<0 Then x=0
  If y<0 Then y=0
  If *rpLayer
    If xs<=0 Then xs=*rpLayerWidth  -x
    If ys<=0 Then ys=*rpLayerHeight -y
  Else
    If *rpBitMap
      If xs<=0 Then xs=GetBitMapAttr_(*rpBitMap,#BMA_WIDTH)  -x
      If ys<=0 Then ys=GetBitMapAttr_(*rpBitMap,#BMA_HEIGHT) -y
    End If
  End If

  If image_Create{image,xs,ys}
    d.l=GetBitMapAttr_(*rpBitMap,#BMA_DEPTH)
    If d>8 OR d<=0
      ReadPixelArray_ raw_ptr,0,0,bpr,*rp,x,y,xs,ys,#RECTFMT_ARGB
    Else
      *scr.Screen = Peek.l(Addr Screen (Used Screen))
      If *scr
        scr_depth.l = d ;*scrBitMapDepth
        CopyMem_ *rp,temprp.RastPort,SizeOf.RastPort
        temprpLayer = 0
        xsw.l = (((xs+15) LSR 4) LSL 4)
        temprpBitMap = AllocBitMap_ (xsw,1,8,0,0)
        temprpBitMapBytesPerRow = xsw LSR 3
        penArray8.l = tempbuffer_Get{xsw*ys*1}
        ReadPixelArray8_ *rp,x,y,x+xs-1,y+ys-1,penArray8,temprp
        FreeBitMap_ temprpBitMap

        lut.l = AllocVec_(256*4,#MEMF_CLEAR)

        If colorMap=-1
          For n.l=0 To 1 LSL scr_depth-1
            GetRGB32_ *scrViewPortColorMap,n,1,col.cmapitem
            R.l = colR LSR 24
            G.l = colG LSR 24
            B.l = colB LSR 24
            ARGB.l = (R LSL 16) | (G LSL 8)  | (B)
            Poke.l lut+n*4,ARGB
          Next
        Else
          For pen.l=0 To (1 LSL scr_depth)-1
            *CReg.ColorRegister = colorMap + 3*pen
            Poke.l lut + (pen LSL 2),((*CRegred&$00FF) LSL 16) | ((*CReggreen & $00FF) LSL 8)  | (*CRegblue & $FF)
          Next
        End If
        For y.l = 0 To ys-1
          For x.l = 0 To xs-1
            pen.l = Peek.b(penArray8+y*xsw+x) & $FF
            Poke.l raw_ptr+y*bpr+(x LSL 2),Peek.l(lut+(pen LSL 2))
          Next
        Next
        FreeVec_ lut
      End If
    End If
    If trgb><-1
      image_InitMask{image,trgb,tolerance.l}
    Else
      mask_trgb = -1
    End If
    succ.l = True
  End If
Else
  error{"\__THIS_FUNCTION: Uninitialized rastport!"}
End If
If succ=False Then image_Free{image}
Function Return succ
USELASTPATH
End Function


Absolut hirnrissig, warum jeder App Programmierer das aufs neue implementieren muss, wo jedesmal wieder Fehler gemacht werden können, oder die App ist dann True color only etc.


--
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 06.05.2010 um 21:16 Uhr geändert. ]
 
Der_Wanderer   Nutzer

06.05.2010, 17:16 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Natürlich eine Lib, ich habe ja nie was anderes geschrieben, oder?

Es ist aber durchaus mehr als nur ein Wrapper oder Convinient Stub, und es darf auch nicht auf C/C++ beschränkt sein.

Z.b. würde man Resizing Code für Bilder hinzufügen, der das unabhängig vom verwendeten Datatype macht. Es können auch Loader hinzugefügt werden, die nicht über Datatypes laufen.
Z.b. um Bilder mit Alpha Channel zu laden unter OS3.
Oder um Icons zu laden via icon.library, so, als wären sie ein Bild.

--
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

06.05.2010, 16:47 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Thore:
Du würfelst da ein paar Sachen durcheinander.

Eine Library ist eine Ansammlung von Code, aufgeteilt in nach aussen gelegte Funktionen. Diese Funktionen zusammen betrachtet nennt man API.

Eine solche API wie ich beschrieben habe würde man natürlich in eine oder mehrer Libraries packen. Sie soll den ganzen Low-Level Dreck verstecken, also genau das was du bei der Win API mit "Ex" und hochzählen bemängelst soll es vermeiden, sowas gibts ja in AmigaOS mittlerweile (oder schon seit langem besser gesagt) auch, nur nicht so heftig weil sie einfach nicht so viel Entwicklung erfahren hat.

Beispiel:

Im Prinzip wollen ja alles Amiga Platformen das gleiche.
Z.b. besseren 24bit Support.
Da kam jemand auf die Idee des Penless Mode.
In OS3 gibt's das nicht, und in OS4 und MOS wurde das jeweils unterschiedlich implementiert und in AfA OS ist das ein böser Hack.
Resultat: eine Katastrophe für jeden Entwickler.

Was fehlt ist nun eben eine API die oben drauf kommt, die diese losen Enden wieder zusammenknüpft, sodass ich meine Linie mit

Line rastport,x1,y1,x2,y2,rgbvalue

zeichnen kann. Ganz entspannt, ohne Altlasten, einfach so und ohne 4 Fall Unterscheidungen.

Im Grund wurde aus dieser Idee heraus auch mein A/A++ Projekt geboren.
Nur wird bis zur Fertigstellung (wenn überhaupt) noch einige Zeit ins Land gehen, und ob das Akeptanz findet wage ich zu bezweifeln, wird also wieder nur eine individual Lösung für mich sein.



--
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

06.05.2010, 16:13 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Thore:
> Öhm, wieso?
Weil sonst niemand richtig Software entwicklen kann/will auf dem Amiga.

> Das macht keiner so
Doch, schau mal genauer hin.

Android zum Beispiel. Das ist eigentlich ein Linux, hat aber genau so eine API aufgestülpt bekommen. Du kannst immer noch Linux programmieren, macht aber (fast) keiner. Alle benutzen die Android API, die sich ungefähr auf dem Level bewegt wie ich oben beschrieben habe.

MFCs zum Beispiel. Zugegeben, ein etwas älterer Ansatz, nur 15 Jahre alt statt 25. Es stülpt der Win32 API eine OOP API über. Damit hat man immerhin in etwa einen Code Aufwand von 1:4, d.h. vier Zeilen Win32 macht ein MFC Aufruf (kann man natürlich nicht 1:1 aufrechen, hängt davon ab was man macht).

Die grossen OSe sind natürlich gross genug, dass es nicht nur einen solchen Ansatz gibt. Aber vergleiche mal die Linux Distributionen, das ist jeweils eine solche Idee.

Natürlich gibt es friendliche Co-Existenzen mit 3rd Party Libraries, aber das ist eben was anderes und sollte jeweils nur eine Nische füllen, keine Grundlegenden Aufgaben erledigen. Die Lebensdauer von 3rd Party Libs ist auch meistens sehr begrenzt. Die meisten sind mittlerweile verwaist. Möchte man darauf aufbauen?

Wenn ich jetzt so eine Converter Lib machen würde (wäre kein grosser Act mit Amiblitz), wer würde das benutzen? Keiner vermutlich. Es würden trotzdem alle mit Datatypes rumfrickeln und die gleichen Probleme lösen, die ich schon teuer erkauft gelöst habe.

> Warum nicht einfach eine Lib, die konvertieren kann?
Weil das nur ganz wenige brauchen.
Die Macht kommt erst, wenn verschiedene Themen anfangen zusammenzuarbeiten. Also wenn ich ein GUI Toolkit habe, was die Bilder damit lädt. Wenn ich aus einem Video einen Frame als Image Objekt abholen kann und mit der Library speichern.

Einzelne Libraries bilden nur eine Summe, also der Nutzen steigt additiv. Eine ganze OS API aus einer Hand, die sich untereinander kennen, ergibt das Produkt, also multiplikativ.

Es muss auch als einheitliches SDK kommen. Wenn man sich sein Set an Libs zusammensuchen muss, aus mehr oder weniger vertrauenswürdigen einzel Libs, dann harmoniert das nicht und die reibungsverluste resultieren in schlechter Qualität der Soft oder mehr Aufwand.

--
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 06.05.2010 um 16:16 Uhr geändert. ]
 
Der_Wanderer   Nutzer

06.05.2010, 15:44 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

So eine Lib alleine bringt noch nicht viel.
Das ganze muss eingebettet sein in eine grosse Runtime, die alle Teile des Betriebssystems behandelt.

File Formate konvertieren ist ja eine sehr spezielle Anwendung.

Man bräuchte eine Lib, die Bilder lädt, anzeigt, manipuliert und speichert. Dann kann man auch konvertieren, aber auch alles andere damit tun.
Aber auch das reicht nicht.
Diese Lib muss wiederum vom GUI Toolkit benutzt werden usw.

Deshalb geht das nur, wenn es als Teil des OS angesehen wird.
Wie gesagt, was ich hier gepostet habe ist ja real existierender Code der Amiblitz API. nur ist das auf die kleine, überschaubare Amiblitz Welt begrenzt. Und hätte ich das nicht gemacht, müsste auch in Amiblitz sich jeder noch mti Datatypes rumschlagen und seinen eigenen Saver programmieren.
So eine API ist aber der Schlüssel dazu, robuste und mächtige Apps in vertretbarer Zeit implementieren zu können.
Schau dir z.B. meine Fusszeile an. Alle diese Programme benutzen die gleiche API zum Laden von Sounds (HD-Rec, Sweeper, Samplemanager, ArTKanoid, Asteroids, TKPlayer, etc. etc). Wenn ich jetzt zufällig nicht die gleiche Person wäre, dann hätte ich für alle diese Programme meinen eigenen AHI Code, meine eigenen Lade und Speicher Routinen für Sounds implementieren müssen. Da wäre nicht mal 1/4 der Soft herumgekommen, und es hat über 10 Jahre gedauert bis das ganze auf allen Plattformen robust gelaufen ist.

Also was eigentlich passieren müsste, wenn Amiga+Freunde noch irgendwie Chancen auf Wachstum haben will:
- AROS, MOS, OS4 Leute müssten sich an einen Tisch setzen (ich weiss, schon mal unrealistisch)
- Es müsste eine gemeinsame API entwickelt werden, auf einem Niveau wie oben besprochen. Die kann ja durchaus auf der vorhandenen AmigaOS API fussen.
- Die API muss auf allen Plattformen auf der gleichen Code-Base basieren, sodass alle das gleiche vor sich haben. Z.b. die OS3.x API ist grundsätzlich mal in OS3/4 und MOS enthalten, verhält sich in Details aber doch anders.
- Die API muss Bestandteil des OS sein. Auch für OS3 muss es zugänglich gemacht werden, da hier de facto immer noch ein grosser Teil der Entwicklung passiert.
- Enthalten sein muss Bilder, Sounds, Videos, Musik Streams, Netzwerk+Internet, GUI Toolkit + Builder, File I/O etc., was zu einem OS gehört. Dazu natürlich SDK mit Doku.

Das kann natürlich niemand alleine tun.

--
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

06.05.2010, 14:51 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

> Wenn man von Blitz auf C++ wechselt, hat man sicher diese Ansicht.
Vergiss nicht, dass die moderne Runtime von Blitz von mir ist. Ich habe also die ganze "dirty work" selbst gemacht. So gesehen ist mein Blickwinkel eher der des C Programmierers. Und Leute die meine API ablehnen (gibts auch), die machen in Amiblitz genau das gleiche wie in C, nur etwas anders dekoriert.

Einfach drauf los machen hat keinen Sinn, hat keinen Mehrwert und ist ein Kampf gegen Windmühlen. Das scheinst du nicht zu verstehen. Es kommt auf die Organisation an.

Einfach und mächtig sind auch zwei verschiedene Paar Schuhe.

Eine API kann einfach aber schwach sein. Sie ist idealer weise einfach und mächtig. Sie kann im schlimmsten Fall aber auch schwierig und schwach sein. Oder aber auch schwierig und mächtig.


--
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 06.05.2010 um 14:52 Uhr geändert. ]
 
Der_Wanderer   Nutzer

06.05.2010, 14:32 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Thore:
> Wozu denn auch? Ich find die API einfach zu programmieren.
Da bist du aber ein wenig "Amiga-Blind". Die API ist alles andere als einfach zu programmieren. Du bist nur bereit, im Falle des Amiga beide Augen zuzudrücken und viel mehr Zeit zu investieren um was ans Laufen zu bekommen.

> Wenn es denn noch keine ultra converter lib gibt, wieso entwickelt
> dann nicht jemand diese, dann gäbe es sowas.
Macht ja jeder im Stillen kämmerlein für sich.
In Amiblitz3 gibt's das auch. Es ist aber kein OS Bestandteil und findet damit keine Akzeptanz. Ist auch nur von mir alleine und deshalb nicht so mächtig wie es sein könnte.
Und vor allem dürfte sowas eben nicht nur OS4-only oder MOS-only sein, sondern müsste alle Platformen unterstützen.

> Sooo notwendig wars wohl dann doch nicht
Doch. Schau dir doch nur mal an, wie schwach Amiga Software im Vergleich ist.
Z.B. im Email Programm, wenn jemand im Urlaub 10 JPEG Bilder anhängt von der Digicam (typischer User-Case), die jeweils 2MB haben, und von der Strandbar aus senden will. Es wäre mit so einer API wie in Amiblitz3 kinderleicht, es anzubieten dass beim Senden das on-the-fly in Monitor-freundlicher Auflösung heruntergerechnet wird und als JPEG gepackt. Das wären dann statt 20MB Email nur 2MB Email, das entscheidet zwischen Go oder No-Go. Non-Amiga Emailer bieten sowas. Bei YAM oder SimpleMail? Fehlanzeige.
Dabei wäre das so einfach:

code:
...
img = image_Load{"T:Attachment.jpg"}
image_Resize{img,800,600,IMG_KEEP_ASPECT|IMG_INTERPOLATION_BILINEAR}
image_Save{"T:Attachment_sized.jpg","JPEG",IMG_COMPRESSION_HIGH}
...


Aber mit AmigaOS Board-Mittel steht man da erstmal wie der Ochs vorm Berg und müsste sich erstmal die Finger wund tippen, also macht es keiner.

> Wenn ich "Superfunktionen" will, kann ich mir diese bauen.
Das ist schon die falsche Haltung. Auf dem Amiga vielleicht Superfunktionen, auf anderen OS ist das normal. Und selbser bauen ist immer schlecht, da Fehleranfällig, ungetestet und die Entwicklung wird um ein vielfaches verlangsamt.


--
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 06.05.2010 um 14:34 Uhr geändert. ]
 
Der_Wanderer   Nutzer

06.05.2010, 13:06 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Thore:

Du widersprichst dir irgendwie selbst:

> GIF, BMP, PNG und ILBM sind nicht weiter schwierig zu implementieren
> Interessant wäre eine Lib, die die Konvertierung von verschiedenen Formaten unterstürzt...

> Ich hab mal in BASIC Routinen (Laden + Speichern) für BMP, GIF und IFF(ILBM und ACBM) gemacht,
Und genau das ist ja das Problem. Warum hast du das gemacht? Weil AmigaOS dir das nicht bietet.
Also anstatt einmal das gescheit im OS zu haben, gibt es sicherlich hunderte von solchen Implementationen. Das ist quasi kollektive Zeitverschwendung, obwohl ja gerade auf dem Amiga Entwickler-Zeit absolute Mangelware ist. Und das Resultat ist schlechtere Qualität der Software, weil nicht jeder gleich gut Programmieren kann und nicht jeder alle Features der Formate implementiert hat, und verletzt gleichzeitig heftigst Linus' Law.

Ich arbeite auch beruflich unter Windows. Die Win32 API ist in eingen Aspekten besser als die von AmigaOS, aber nicht viel, und in einigen auch schlechter. Sie hat auch das gleiche Problem, vor über 20 Jahren erdacht zu sein und heutige Probleme nicht richtig zu reflektieren.
Aber die benutzt heute fast keiner mehr direkt. Jeder, der einen gewissen Output leisten muss, der benutzt was anderes, z.B. MFCs, die auch schon etwas angegraut sind, oder COM oder was ganz anderes.
Windows ist ja so riessig, da gibt es viele APIs.

Im Vergleich hat der Amiga aber nur eine Low Level API, also quasi nur die Win32. Es wurde nicht wirklich ein neuer Layer draufgesetzt, das macht dann immer jede Programmiersprache oder jeder Programmierer von Grund auf neu. Und das verbrennt massig wertvolle Entwicklerzeit.
Da können auch Addons wie MUI oder Reaction nicht viel ausrichten.

--
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 06.05.2010 um 13:11 Uhr geändert. ]

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

06.05.2010, 11:48 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@whose
Das ist wirklich nur der Schlüssel Aufruf. (und hat schon wesentlich mehr Parameter wo man nicht intuitiv weis was sie machen).
Du siehst das gnaze etwas verklärt denke ich. Jemand der AmigaOS nicht kennt würde nur den Kopf schütteln und mit sowas niemals anfangen was zu entwickeln, also nicht im Jahre 2010. Heute sind die Anforderungen viel höher an eine App. Man will sich heute auch nicht mehr mit sowas aufhalten. Das Hauptaugenmerk sollte die eigentliche Funktionalität der App sein, nicht das Bezwingen der OS API um ein Bild zu laden.

Schau mal die Funktion in Amiblitz, um IFF-ILBM zu speichern. Da ist natprlich noch ein bisschen Code drin, den man weglassen könnte, aber vieles ist auch notwendig.
Andere Formate habe selbst ICH nicht hinbekommen, nach stundenlangen Bemühungen. Wenn ich das nicht hinbekomme, heisst das nicht dass es nicht geht, aber das heisst dass es fast NIEMAND hinbekommt.
Und sowas wie "SaveImage(image,file)" bekommt JEDER hin, der es schafft einen Texteditor aufzumachen.

Dazu kommt, dass das Speichern via DT wertlos ist, da es fast kein DT unterstützt. Wenn du z.B. ein Paint Program schreibst, und speichern via DT machst, dann funktioniert das in der Praxis einfach nicht und du wirst nur Beschwerden bekommen, warum geht PNG speichern nicht? warum geht JPEG speichern nicht? etc.
Du kannst dann natürlich wieder auf die DT zeigen, aber wen interessiet das? Deine App kann nicht speichern, Punkt.

In Amiblitz kann man IFF-ILBM, PNG, JPEG, BMP und AB3I (Haus eigenes Format) speichern. Das sind aber alles Hand-implementierte Saver (bis auf JPEG, das nutzt die jpeg.library, die bei einem richtigen DT Konzept gar nicht nötig wäre). Und das ist natürlich schlecht, dass sie von Hand implementiert sind, weil sie dann nicht so mächtig sind.

Aber es erlaubt die AB3 API

image_Save{"dh0:image.png","PNG"}

ohne wenn und aber.

code:
;///////////////////////////////////////////////////////////////////////////////
;/                                                                             /
;/ Syntax:  result.l = image_WriteDT{fid.l,image.l}                           /
;/                                                                             /
;/ Description:                                                                /
;/ * private *                                                                 /
;/ Write a picture as 24Bit IFF-ILBM via datatypes.                            /
;/                                                                             /
;/ Inputs:                                                                     /
;/ - image.l     : image object ID                                             /
;/ - fid.l       : file object ID                                              /
;/                                                                             /
;/ Result:                                                                     /
;/ - result.l    : -1 if everything went well, 0 otherwise                     /
;/                                                                             /
;/ Bugs: does not work on AfA4.2 and lower                                     /
;/                                                                             /
;///////////////////////////////////////////////////////////////////////////////
Function.l image_WriteDT{fid.l,image.l}
SHARED imagedat()
DEFTYPE.dtWrite DTMW
DEFTYPE.pdtBlitPixelArray DTMB
succ.l=False
If ARGBbitmap_ptr
  *newbm.BitMap = AllocBitMap_(img_width,img_height,24,#BMF_MINPLANES|#BMF_SPECIALFMT|(#PIXFMT_RGB24 LSL #BMB_PIXFMT_SHIFTUP) ,0)
  If *newbm=0 Then error{"\__THIS_FUNCTION: Unable to allocate 24bit Bitmap!"} : Function Return False

  DEFTYPE.RastPort rp
  InitRastPort_ rp
  rpBitMap = *newbm
  ClipBlit_ rastport_ptr,0,0,rp,0,0,img_width,img_height,$c0


  basename.s = "iff"          ;          #DTA_BaseName    ,&basename,@@
  tag5.tag5ti_Tag  = #DTA_SourceType,#DTST_RAM,#DTA_GroupID,#GID_PICTURE,#PDTA_DestMode,#PMODE_V43,#PDTA_BitMap,*newbm,#TAG_DONE,0
  *DTPic._Object = NewDTObjectA_ (0,tag5)

  If *DTPic
    tag5.tag5ti_Tag = #PDTA_BitMapHeader,&*bmhd.BitMapHeader,#TAG_DONE,0
    GetDTAttrsA_ *DTPic,tag5
    If *bmhd
      *bmhdbmh_Width      = img_width
      *bmhdbmh_Height     = img_height
      *bmhdbmh_Depth      = 24
      *bmhdbmh_XAspect    = 22
      *bmhdbmh_YAspect    = 22
      *bmhdbmh_PageWidth  = 1600
      If (*bmhdbmh_Width<=1280) Then *bmhdbmh_PageWidth=1280
      If (*bmhdbmh_Width<=1024) Then *bmhdbmh_PageWidth=1024
      If (*bmhdbmh_Width<= 800) Then *bmhdbmh_PageWidth= 800
      If (*bmhdbmh_Width<= 640) Then *bmhdbmh_PageWidth= 640
      If (*bmhdbmh_Width<= 320) Then *bmhdbmh_PageWidth= 320
      *bmhdbmh_PageHeight = *bmhdbmh_PageWidth * 3 / 4
    Else
       error{"\__THIS_FUNCTION: Unable to get bitmap header!"}
    End If

    ;fh.l = Open_ (&filename.s,#MODE_NEWFILE)
    fh.l = file_GetFH{fid}
    If fh
      DTMWMethodID            = #DTM_WRITE
      DTMWdtw_GInfo           = 0
      DTMWdtw_FileHandle      = fh
      DTMWdtw_Mode            = #DTWM_IFF
      DTMWdtw_AttrList        = 0
      succ = DoDTMethodA_(*DTPic,0,0,DTMW)
      ;succ = DoMethodA(*DTPic,DTMW)
     ; Close_ fh
      If succ=False
        error{"\__THIS_FUNCTION: Unable to write image via "+basename+" datatype!"}
      EndIf
    EndIf

    DisposeDTObject_ *DTPic
  Else
    error{"\__THIS_FUNCTION: Unable to create datatype object out of the bitmap!"}
    FreeBitMap_ *newbm
  EndIf
Else
  error{"\__THIS_FUNCTION: No bitmap!"}
End If
Function Return succ
End Function



--
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 06.05.2010 um 11:52 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 06.05.2010 um 11:56 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 06.05.2010 um 12:05 Uhr geändert. ]
 
Der_Wanderer   Nutzer

05.05.2010, 21:51 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@whose
Der Beispiel Code lädt ein Bild via Datatype (als ARGB Bitmap) in den Speicher, skaliert das Bild und speichert es. Und zwar so, dass es unter OS3.x, OS4, MOS und AfA (und somit AROS?) funktioniert.

Von auf den Schirm bringen habe ich nichts gesagt. Das ist eine andere Funktion, die nichts mehr mit Datatypes zu tun hat.

Ich würde gerne mal dein Code sehen, der das per DT in einigen wenigen Zeilen macht. Das fängt schon beim skalieren an. Da das in jedem Datatype extra implementiert ist, hast du keinerlei Garantie über die Skalierungsqualität. Speichern habe ich bei DT noch nie gesehen, ausser ILBM über die datatype.library selbst, und sogar dass funktioniert nicht überall, z.b. nicht unter AROS. Ist auch ziemlich nutzlos, weil IFF-ILBM niemanden mehr interessiert.

Datatypes können Bilder auch direkt darstellen, ist meiner Meinung nach aber (ausser vielleicht für einen reinen Bildbetrachter) völlig überflüssig.
Überhaupt ist das Konzept der DT zwar gut, aber die API ist total verkorkst und es ist nicht konsequent durchgezogen, z.b. das Sound Datatypes ist völliger Krampf.

Wenn ich ein Bild laden will, dann erwarte ich eine Funktion wie

LoadImage(...).

Wenn ich es speichern will

SaveImage(...)

Wenn ich es blitten will,

BlitImage(...)

...oder eben die OOP Pendants.
Ich möchte mich nicht mit zig Tags und Flags rumschlagen müssen, oder ob es nun OS3/4 oder MOS ist, ob es nun 256 Farben oder 24bit ist.

Die API sollte natürlich erlauben, tiefer eingreifen zu können, z.B.

RemapImage(...,ColorMap)
GetRawPtr(...)
SetDithermode(...)
SetTransparency(...)
SetBlitArea(...)
...
LoadImage sollte natürlich auch weitere, optionale Parameter haben wie z.B. ImageNumber, Thumbnail etc.

aber nicht im simplen Fall der in 90% der Fälle ausreicht.
Ein Bild so zu laden via DT, dass es überall funzt, ist ein kleines Kunstück, und dauert z.B. auf Android 2min ohne das IDE zu verlassen, selbst wenn man ein totaler Noob ist, und auf dem Amiga viele Stunden und Reboots.

Wenn deine App nicht funktioniert, ist das immer erstmal dein Problem. Da nützt es nichts, auf bestimme Datatypes zu verweisen.

Also ich fasse nochmal zusammen:

Um auf dem Amiga in heutzutage üblichen Geschwindigkeit entwickeln zu können, wäre eine Amiga-Like Platform übergreifende API, ein dazugeöriges IDE und SDK sehr wichtig. (sowas wie MFC, nur moderner).
Das kann aber niemand alleine machen, nichtmal wegen der Zeit, sondern wegen der Akzeptanz. Das müsste quasi "von oben" kommen und Teil aller beteiligten OSe sein.

Unter Amiblitz3 habe ich mir in etwa sowas zusammen programmiert, das hat über 10 Jahre gedauert, und ist wegen der zeitlichen Ausdehnung nicht so durchgestyled wie ich es mit wünschen würde. Aber das ist 68k, kein C und findet damit logischerweise kaum Akzeptanz.

--
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 05.05.2010 um 21:54 Uhr geändert. ]
 
Der_Wanderer   Nutzer

05.05.2010, 16:44 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@whose:

Zitat:
hm? Im Groben funktionierts via Datatype mit ziemlich genau so viel Code und mit ungefähr der gleichen Menge an Tags.
Hüstel.
Das hier ist der Code, den u.A. image_Load ausführt, wenn es sich um ein Datatype ladbares Format handelt.
Das würde ich nicht als "ziemlich genauso viel Code" bezeichnen.
Und das ist noch lange nicht alles, es muss ja noch das CImage Objekt angelegt werden mit weiteren Informationen zum blitten etc.
Der Code lädt "nur" ein Bild in eine Bitmap.
Der Code ist u.A. so lange, weil man OS3, OS4 und MOS unter einen Hut bekommen muss.

code:
Function.l image_LoadViaDT{image.l,filename.s,imgnum.l}
DEFTYPE.BitMapHeader *bmhdp
DEFTYPE.BitMap *bmap
DEFTYPE.pdtBlitPixelArray DTM
succ.l = False
If imgnum<0 Then imgnum=0
tag5.tag5ti_Tag = #PDTA_DestMode, #PMODE_V43, #DTA_SourceType, #DTST_FILE, #DTA_GroupID, #GID_PICTURE, #PDTA_Remap, False,#PDTA_WhichPicture,imgnum,#TAG_DONE,0
*DTPic._Object = NewDTObjectA_ (&filename.s,tag5)
If *DTPic
  tag5.tag5ti_Tag = #PDTA_BitMapHeader,&*bmhdp,#TAG_DONE,0
  GetDTAttrsA_ *DTPic,tag5
  If image_Create{image,*bmhdpbmh_Width,*bmhdpbmh_Height}
    If image_Lock{image}

      ; try to get as ARGB immediately, good datatpyes support this, but not all!
      ;If *bmhdpbmh_Depth>8 ; dont even try if depth <=8
        DTMMethodID            = #PDTM_READPIXELARRAY
        DTMpbpa_PixelData      = raw_ptr          ; /* The pixel data to transfer to/from */
        DTMpbpa_PixelFormat    = #PBPAFMT_ARGB     ; /* Format of the pixel data (see "Pixel Formats" below) */
        DTMpbpa_PixelArrayMod  = bpr              ; /* Number of bytes per row */
        DTMpbpa_Left           = 0                 ; /* Left edge of the rectangle to transfer pixels to/from */
        DTMpbpa_Top            = 0                 ; /* Top edge of the rectangle to transfer pixels to/from */
        DTMpbpa_Width          = *bmhdpbmh_Width  ; /* Width of the rectangle to transfer pixels to/from */
        DTMpbpa_Height         = *bmhdpbmh_Height
        If DoMethodA (*DTPic,&DTM) Then succ = True
      ;End If

      ; ok, try to read out the bitmap if ARGB failed...
      If succ=False
        tag5.tag5ti_Tag = #PDTA_ColorRegisters,&colorMap.l,#TAG_DONE,0
        If GetDTAttrsA_ (*DTPic,tag5)
          tag5.tag5ti_Tag = #PDTA_BitMap,&*bmap,#TAG_DONE,0
          If GetDTAttrsA_ (*DTPic,tag5)
            *layerinfo.Layer_Info = NewLayerInfo_
            If *layerinfo
              *layer.Layer = CreateUpfrontHookLayer_ (*layerinfo,*bmap,0,0,*bmhdpbmh_Width-1,*bmhdpbmh_Height-1,0,#LAYERS_NOBACKFILL,0)
              If *layer
                *rp.RastPort = *layerrp
                If *rp
                  image_Unlock{image}
                  succ = image_CutRP{image,*rp,0,0,*bmhdpbmh_Width,*bmhdpbmh_Height,-1,-1,-1,colorMap}
                  If succ Then image_Lock{image}
                End If
                DeleteLayer_ 0,*layer
              End If
              DisposeLayerInfo_ *layerinfo
            End If
          End If
        End If
      End If

      ; Try READPIXELARRAY LUT8, if we couldn't catch the bitmap (outch!)
      If succ=False
        penArray8.l = AllocVec_(*bmhdpbmh_Height * *bmhdpbmh_Width,#MEMF_ANY)
        lut.l       = AllocVec_(256*4,#MEMF_CLEAR)
        If penArray8><0 AND lut><0
          DTMMethodID            = #PDTM_READPIXELARRAY
          DTMpbpa_PixelData      = penArray8         ; /* The pixel data to transfer to/from */
          DTMpbpa_PixelFormat    = #PBPAFMT_LUT8     ; /* Format of the pixel data (see "Pixel Formats" below) */
          DTMpbpa_PixelArrayMod  = *bmhdpbmh_Width  ; /* Number of bytes per row */
          DTMpbpa_Left           = 0                 ; /* Left edge of the rectangle to transfer pixels to/from */
          DTMpbpa_Top            = 0                 ; /* Top edge of the rectangle to transfer pixels to/from */
          DTMpbpa_Width          = *bmhdpbmh_Width  ; /* Width of the rectangle to transfer pixels to/from */
          DTMpbpa_Height         = *bmhdpbmh_Height
          If DoMethodA (*DTPic,&DTM)
            tag5.tag5ti_Tag = #PDTA_ColorRegisters,&colMap.l,#TAG_DONE,0
            If GetDTAttrsA_ (*DTPic,tag5)
              For pen.l=0 To (1 LSL *bmhdpbmh_Depth)-1
                *CReg.ColorRegister = colMap + 3*pen
                Poke.l lut + (pen LSL 2),((*CRegred&$00FF) LSL 16) | ((*CReggreen & $00FF) LSL 8)  | (*CRegblue & $FF)
              Next
              For y.l = 0 To *bmhdpbmh_Height -1
                For x.l = 0 To *bmhdpbmh_Width -1
                  pen.l = Peek.b(penArray8+y**bmhdpbmh_Width+x) & $FF
                  Poke.l raw_ptr+y*bpr+(x LSL 2),(Peek.l(lut+(pen LSL 2)) );& $FEFEFEFE) LSR 1
                Next
              Next
              succ.l = True
            End If
          End If
          If penArray8 Then FreeVec_ penArray8 : penArray8 = 0
          If lut       Then FreeVec_ lut       : lut       = 0
        End If
      End If
      image_Unlock{image}
    End If
    If succ=False Then image_Free{image}
  End If
  DisposeDTObject_ (*DTPic)
End If
Function Return succ
End Function

--
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

05.05.2010, 12:08 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Man bräuchte eigentlich eine moderne API, die auf allen Systemen in gleicher Version verfügbar ist.
Z.B. sowas
code:
Import Amiga.CImage

CImage img = new CImage("DH0:myImage.jpg")
img.Resize(800,600,CIMAGE_INTERPOLATION_CUBIC);
img.Save("DH0:myImage_in800x600.png","PNG");

Das entspricht so in etwa der API von Amiblitz3 und was in in A/A++ vorhabe, wenn ich das jemals realisiere.

Alles andere ist viel zu kompliziert, mit Datatypes, richtige Tags setzen etc. Und das speichern geht schonmal gar nicht.
Im gleichen Stil wäre dann
code:
Import Amiga.CSound

CSound snd = new CSound("DH0:mySound.wav")
snd.Play();
snd.Save("DH0:mySound.mp3","MP3")


oder

code:
Import Amiga.CAudioStream

CAudioStream music = new CAudioStream("DH0:myMusic.mod")
while (music.Available()>0) {
  music.PlayBuffer()
}


Das Problem ist halt nur, dass jedes System das versucht, aber nicht mit den anderen kooperiert. Deshalb bleibt der Amiga auf 3.x stehen, und ein neues Projekt in C anzufangen ist gleich eine Mammutaufgabe mit viel Trial and Error.
In Eclipse+Java funktioniert der Code meistens fast auf Anhieb. Unter C auf dem Amiga braucht man zig Compiler Läufe bis dann alles klappt. Und wenns dann auch noch zur Laufzeit funktioniert, fliegt es einem mit hoher Wahrscheinlichkeit um die Ohren wenn jemand das auf einer anderen Plattform ausprobiert. Das liegt nicht an C, sondern am schwachen IDE, was einem nicht zur Tip-Zeit auf Fehler hinweist, an einem schwachen SDK was nur eine Plattform berücksichtigt und an einer schwachen API die einem für (aus heutiger sicht) triviale Sachen wie ein Bild laden viel zu viel OS Internas vor den Latz knallt wo man massig Fehler machen kann (auch als erfahrener Progger) und ein vielfaches mehr Code braucht als man heutzutage erwarten würde.

Und wie gesagt, das kann man nicht durch Enthusiasmus ausgleichen. Und gerade wenn Entwickler Man-Power knapp ist, muss man sich auf eine gutes IDE+SDK+API gespannt konzentrieren, das passiert aber nicht, sondern alle backen ihre eigenen, kleinen Brötchen.

Aber ich schweife langsam vom Thema ab, das wäre ein anderer Thread...




--
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 05.05.2010 um 12:13 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 05.05.2010 um 12:17 Uhr geändert. ]
 
Der_Wanderer   Nutzer

05.05.2010, 10:04 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Mit mächtig meine ich z.B. folgendes:

Meine App verwendet einen HTML View für die Ausgabe von Informationen, man stelle sich z.B. den Chatlog von Skype vor.
In HTML hat man da fluchs ein schönes Layout mit kleinen Bildern etc. gemacht, man kann auf Online Hilfe linken, einen "Drucken" Button anbieten, Tutorial Videos einbetten etc., eben alles was im Browser so möglich ist, mit sehr wenig Aufwand und ohne sich gross durch Docu zu wälzen (wenn man HTML kann).
Ein Tutorial Video einbetten hat mich auf einem Handy(?) nicht mal 5min gekostet, und ich bin auf der Platform quasi ein Noob im Vergleich zum Amiga.

Jetzt stelle ich mir das als Amiga Port vor.
HTML View? Hm, vielleicht rudimentär mit MUI. Wie sieht es mit Drucken oder eingebetteten Videos aus? Link auf die Homepage der Software? Geht nicht. (Ja, es gibt OpenURL, aber dann geht ein extra Browser auf (dauert....) und stellt dann sie Seite soweiso nicht richtig dar.)

Oder z.B. mein TKPlayer. Die einzige Lib für MODs die ich gefunden habe ist die ptplay.library. Die kann aber nur die Ur-MODs und Protracker.
Würde mich interessieren von welcher MOD Lib du oben sprichst.
Die Lib muss einen Audio Stream berechnen, keine Custom Chips benutzen. Sonst kann ich es nicht in die Amiblitz API als Audio Format integrieren analog zu mp3 oder wav.

Also setze ich mich hin und progge einen Decoder für alle möglichen Formate, da bin ich 2 Jahre mit ausgelastet. In der Zeit käme dann nix anderes von mir. Unter Windows nehme ich MikMOD, und schon kann ich massig MOD Formate abspielen.

Und das eine ich damit, dass man das mit Amiga-Fan-sein nicht ausgleichen kann. Was mein Kollege auf dem iPhone in 5min macht würde mich auf dem Amiga ein halbes Jahr und sehr viel mehr graue Haare kosten.

Dieses "mächtige" Programmieren geht aber nur, wenn es, wie schon gesagt, ein gutes IDE, SDK (Docu) und die entsprechenden APIs gibt.
Mit der Amiblitz API habe ich mich versucht da heranzuarbeiten, es ist auch sehr viel möglich, aber alles innerhalb der Grenzen von AmigaOS und was dort verfügbar ist. Z.b. das Thema Video Codecs habe ich noch nicht angefasst,obwohl ich z.B. in HD-Rec gerne neben MIDI und Audio auch Video Tracks einbauen würde, ich wüsste aber nicht wirklich wie, wenn nicht selbst die Codecs schreiben, so wie ich es für einige Audio und Bild Formate gemacht habe. Aber für Video ist das eben zu aufwendig, vor allem wenn es nicht nur MPEG-1 sein soll.

--
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 05.05.2010 um 10:09 Uhr geändert. ]

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

05.05.2010, 00:12 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

> Frieden?

Wir streiten doch gar nicht. Ich glaube jeder hat pro und kontra nun mitbekommen.

Mir war nur nicht ganz klar, dass selbst in C es recht schwer ist eine etwas komplexere Library zu erstellen, vor allem wenn es sich um nicht-notwendigerweise-auf-den-Amiga-maßgeschneiderten Code handelt.

Ich bin in letzer Zeit beruflich mit einigen Plattformen in Berührung gekommen. Da merkt man deutlich, wenn man mal die Ideologie beiseite lässt, dass der Komfort und Qualität von IDE, SDK und der API der Schlüssel sind ob eine Plattform gute Software bekommt oder nicht.
Die Bereitschaft der Amigafans, mehr Zeit zu investieren für das Gleiche was auf anderen Plattformen viel einfacher ist kann das nicht ausgleichen.
Z.b. habe ich verzweifelt nach einer Video Codec Library gesucht, nach einer MOD player library oder einer mp3 Encoder Library. Unter Windows ist das alles in 5min erledigt, FFMPEG als DLL, MikMOD als DLL oder LAME als DLL. Gibts alles. So kann man sehr schnell tolle Multimedia Apps zusammenstellen. Angesichts diesem Überflusses bin ich sogar oft sehr enttäuscht, wie "schwach" viele Windows Soft doch ist.
Auf dem Amiga gibt es von den o.g. Dingen zwar Commando Zeilen Ports, aber keine Libraries. Um da das gleiche zu erreichen muss man quasi alles selbst machen, vom Video Encoder bis zum MOD player. Das ist 1000x so viel Code und Arbeit, und das Ergebnis sehr viel schwächer.
Zumindest ist das so, wenn man keine Statischen Linker Libs hat und oder verwenden kann.

Lohnt es sich also, ein paar Bytes und CPU Cylces zu sparen, wenn dadurch das Erstellen mächtiger Software fast unmöglich wird?

Human Brain Cycles sind heute sehr viel teurer als CPU Cycles.


--
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.05.2010, 15:09 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Eine GUI Applikation unter Windows kann auch ausgaben mittels printf machen. Man sieht sie nur nicht, weil keine Console aufgeht.
Aber man kann sie in eine File pipen.
Also als No-Go würde ich das nicht bezeichnen.

Das Argument mit der Effizienz kann ich auch nicht gelten lassen.
Wie Holger gesagt hat, die Klartext Funktionen müssen nur einmal beim Programm start in Jump Offsets aufgelöst werden. Das ist selbst auf einem A500 ein vertretbarer und kaum spürbarer Aufwand.

Wenn ich das richtig sehe ist der große Unterschied, dass DLLs jedesmal beim öffnen ihren eigenen Kontext erzeugen, während Amiga Shared Libraries nur einmal gestartet werden, und dann von mehreren Prozessen verwendet werden können. Das bringt natürlich einige Probleme mit sich, z.B. man kann bei printf nicht sofort sagen, was der richtige File Handle für den Output wäre.
Wenn man die vor und Nachteile abwiegt, ist die Amiga Shared Library etwas leichtgewichtiger als die DLL, aber viel schwerer vom Entwickler korrekt zu implementieren. Und eine Library, die 2ms länger braucht zum starten ist besser als keine Library. Dafür würde man sich heute wohl kaum mehr entscheiden.

Zu Amiblitz:

Floats werden entweder direkt inline per Softfloat berechnet oder per FPU Instruction. Da findet kein Funktionsaufruf oder ähnliches statt.

Bei einer Shared Library wird der Basic Kontext beim init Code der Library erzeugt. So hat jede Library ihren eigenen Basic Context, nicht aber jeder Nutzer einer Library.

Ob eine Funktion re-entrant ist oder nicht, hängt wie in jeder anderen Sprache davon ab was man da drin so tut. Wenn man gemeinsame Resourcen nutzt, muss man den Funktionsaufruf per Semaphore thread safe machen. Dafür gibt es Macros (lib_Lock und lib_Unlock). Ob das ok ist oder nicht hängt ganz von der Funktion/Aufgabe ab.

Consolen Output ist möglich, wenn man sich den File Handle der Console bei jedem Aufruf vom aufrufenden Thread besorgt. Global darf man den natürlich nicht speichern.


--
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.05.2010 um 15:11 Uhr geändert. ]
 
Der_Wanderer   Nutzer

03.05.2010, 12:12 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Ich wusste schon dass floats Probleme machen können, deshalb habe ich fast alles mittels Integern implementiert, zumindest in den Schnittstellen.

Intern verwende ich hier und da Floats, z.b. um ein Hamming Fenster zu berechnen etc.

Verstehe ich aber nicht ganz, in Amiblitz kann ich doch auch Floats in Shared Libs benutzen.

Meine Situation sieht momentan so aus:

1. Die TTS (Sprachsynthese) Engine ist in Amiblitz3 implementiert und funktioniert auch gut.

2. Ich möchte die Engine unter Windows/Linux/MacOS/iPhone/Android/... nutzen, das hat die höchste Priorität für mich, nicht die Amiga Version (man muss ja von irgendwas leben...).
Auf dem Amiga habe ich das nur entwickelt weil es viel schneller geht in Amiblitz als in C, und ich dort die nötigen Bibliotheken bereits hatte.
Für die non-Amiga Plattformen (und auch AROS) bräuchte ich das ganze nun in C, weil es der kleinste gemeinsame Nenner ist.
Wäre aber schade, wenn ich diesen C Code nicht unter AmigaOS wieder verwenden könnte. Wäre ja schon grotesk, unter AmigaOS entwickelt aber dort als einzige Plattform nicht veröffentlicht...

Mein Plan bisher:

Alles nach plain-C portieren.
Unter Windows eine DLL, under Linux eine .so, unter Amiga eine Shared Library.

Evtl. gibt aber auch bessere Lösungen?

--
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.05.2010, 13:47 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Danke für die vielen Hinweise.

Alles hat natürlich seine Gründe.

Was bleibt ist aber, Windows DLL luppt, AmigaOS luppt nicht.

Die C Runtime zu benutzen sollte ja gerade dahin führen, dass der Code portabel ist. Ist mir schon klar dass ich es machen könnte direkt mit AmigaOS, nur ist das eine Zeit frage, wieviel man in die AmigaOS version stecken kann.

Eine Shared library will ich aus verschiedenen Gründen machen.

1. Ich will dass es unter allen Sprachen nutzbar ist, auch Amiblitz.

2. Es geht um Sprachsynthese, wo es gemeinsame Resourcen gibt, z.B. die Lexica und die Stimmen. Wenn ich da ein Update mache, ist das sehr schnell nicht mehr kompatibel. Wenn es eine statische Lib ist, wären die Nutzer der Sprachsynthese zu einem update gezwungen.
Stell euch vor, bei einem AHI update müssten alle Programme re-compiliert werden, die AHI benutzen, oder sie würden nicht mehr funktionieren. Das wäre No-Go.



--
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

30.04.2010, 21:11 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Ok, also ich fasse zusammen:

Plain C verwenden, ohne jegliche Runtime. Also absolute Askese, das habe ich befürchtet.

Das lädt nicht gerade zum Entwickeln für den Amiga ein. Ich verstehe eigentlich gar nicht warum, steckt doch hinter einem fopen() letztendlich ein Open() der dos.library, was re-entrant ist. Irgendwo beim "einpacken" hat da doch jemand Bockmist gebaut.

Dann werde ich wohl erstmal eine ~Amiga Version portieren.
--
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

30.04.2010, 17:10 Uhr

[ - Direktlink - ]
Thema: exotische soundformate unter os4 abspielen?
Brett: Amiga, AmigaOS 4

Fast alle 68k Player spielen direkt über Paula Chip, weil

1. MODs dafür designed wurden

2. Viele Formate nur für ein Spiel oder Demo entwicklet wurden und zum abspielen oft original Code gerippt wurde und als Player integriert

3. Niemand nicht die Mühe gemacht hat, das als Audio Stream zu rendern, weil das komplizierter ist als die Daten direkt auf die Paula zu schmeissen.


--
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.04.2010, 22:04 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Hm, das wird komplizierter als ich dachte. Soll ich nun doch besser C nehmen?

Also wenn ich mich zusammenreise, dann komme ich mit

fopen()
fread()
fwrite()
fseek()
ftell()
fclose()
malloc()
free()

aus. Wobei Konsole Output schon hilfreich wäre, also printf().

Alles andere ist rein algorithmisch und kann re-entrant oder zumindest thread-safe implementiert werden.
Wenn das nicht geht, wird es schwierig.
Wenn ich für diese Funktionen AmigaOS API nehmen würde, dann sollte es doch eigentlich funktionieren, oder nicht?

Also

Open()
Read()
Write()
Seek()
Close()
Allocmem()/Allocvec()
Freemem()/Freevec()

Was hat man denn in der C Runtime "verbrochen", dass es nicht mehr thread-safe ist?
Bei printf() kann ich das noch verstehen, denn da müsste man sich erst den Handle auf den stdout holen. Aber die anderen Sachen sollten doch funktionieren, oder übersehe ich da etwas?



--
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.04.2010 um 22:06 Uhr geändert. ]

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

29.04.2010, 17:04 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Also, darf ich nun "sprintf" oder "fopen" in einer Shared Lib benutzen oder nicht?
Sieht so aus, als bräuchte ich dafür eine spezielle Runtime Linkerlib.

Nachtrag:
Unter Windows und Linux scheint das kein Problem zu sein. Haben dort die DLLs/SOs für jede offene Instanz eigene Addressräume, und die Funktionen müssen deshalb nicht thread-safe sein? Oder ist die Amiga Implementation der C-Runtime einfach crappy?

--
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.04.2010 um 17:45 Uhr geändert. ]

[ Dieser Beitrag wurde von Der_Wanderer am 29.04.2010 um 17:46 Uhr geändert. ]
 
Der_Wanderer   Nutzer

28.04.2010, 15:58 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

@Holger:
> Wenn das alleine ausgereicht hatte, hattest Du nur verdammt viel Glück
nein, hats ja nicht. Deshalb musst ich alles über AmigaOS API machen. (file I/O etc.)

> Wenn es eine Amiga-Bibliothek werden soll, wirst Du nicht um Amiga-spezifischen Code herumkommen.
Ist mir klar. Es macht aber einen unterschied, ob ich nur ein Frontend für die Library davor setzen kann sowas wie "amigalib_main.cpp" oder ob ich meinen kompletten Code kontaminieren muss.

Immerhin habe ich den Filezugriff in ein Modul verbannt, sodass ich nur dort #ifdef AMGIA machen müsste. Aber schön ist das ganze natürlich nicht.

@whose
> So triviale Sachen gehen ohne Probleme,
Also laut Holger geht das dann wohl doch nicht ohne Probleme?

--
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

28.04.2010, 15:35 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

Ich kann mich erinnern, als ich mal eine Library compiliert habe, dass es Probleme mit fopen, printf etc. gab, irgendwas mit libnix in der Commandozeile war notwendig. Ist aber lange her, letztendlich hatte ich alles über AmigaOS API gemacht, aber das will ich eigentlich vermeiden.

Ich habe nun erstmal alles als C++ angelegt. ich hoffe das rächt sich nicht irgendwann...

--
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

28.04.2010, 14:00 Uhr

[ - Direktlink - ]
Thema: C oder C++?
Brett: Programmierung

In dem Code sind erstmal keinerlei OS Abhängigkeiten drin.
Das einzige was ich brauche ist Datei I/O und Speicher allocieren.

Normalerweise verwende ich dafür fopen/fclose etc. und malloc.
Mit #ifdef WIN32 oder #ifdef AMIGA will ich sparsam sein, am besten gar nicht.

Ich verwende auch keinerlei Libraries oder andere externe Anhängigkeiten, wie STL. Wie schon erwähnt, kommt der Code von Amiblitz. Das entspricht eher C. Nur die Strings machen mir etwas Kopfschmerzen. Dafür habe ich eine kleine String Include geschrieben, die aber C++ feature nutzt, wie z.B. Refernzübergabe dass man nicht mit Pointer arbeiten muss.

z.B.
code:
/* free a string */
void str_free(str &string) {
  if (string) {
    free(strH(string));
    string=NULL;
  }
}


Geht das unter Amiga ohne Probleme? Ich möchte auch keine rießen Makefile Orgien, damit kenne ich mich gar nicht aus. Unter Windows benutze ich Visual Studio, da wird man von sowas gottseidank verschont.

Am Ende soll das auf dem Amiga eine Shared Library werden. Unter Windows eine DLL.

GCC habe ich gcc version 2.95.3.

Wenn ich C++ nehme, dann sollte ich am besten alle source files C++ machen und nicht mischen, oder? Unter VS ist das kein Problem, aber "per Hand" wäre das wohl komplizierter zu linken(?).




--
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.04.2010 um 14:04 Uhr geändert. ]
 
 
Erste << 7 8 9 10 11 -12- 13 14 15 16 17 >> 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.
.