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

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

1 2 3 4 -5- 6 7 8 9 10 >> Letzte Ergebnisse der Suche: 707 Treffer (30 pro Seite)
bubblebobble   Nutzer

03.09.2006, 13:45 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Speichere es doch einfach im Bowser ;-)

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

03.09.2006, 11:34 Uhr

[ - Direktlink - ] 		Thema: Tonerkennung
Brett: Programmierung

@MaikG

125

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

03.09.2006, 09:49 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Das ARGB Array lese ich natürlich aus, ist aber auch vergewaltigt.

Beispiel:
Das ist das eigentliche Bild:
Bild: http://www.hd-rec.de/pics/Wanderer_NoAlpha.png

Auf das Bild lege ich jetzt diese Alphamaske:
Bild: http://www.hd-rec.de/pics/Wanderer_AlphaMask.png

Das Ergebis, wenn ich mit akpng Datatype lese, sieht so aus:
(keine Garantie wie das jetzt in eurem Browser aussieht.
Schaut es aber mal mit akpng Datatype an, dann ist der
Hintergrund komplett schwarz (im MS Explorer übrigends auch).
Auch in dem ARGB Array ist das so.
Bild: http://www.hd-rec.de/pics/Wanderer_WithAlpha.png

Für ein Zeichenprogramm ist das natürlich nicht akzeptabel.
Zum Beweis dass das Bild eigentlich noch alle Daten enthält,
könnt ihr das Bild auch mal z.B. in Arteffects reinladen,
dann seht ihr dass der Hintergrund noch da ist.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 03.09.2006 um 09:50 Uhr geändert. ]
 
bubblebobble   Nutzer

01.09.2006, 18:49 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

@Holger
> Eben noch hast Du geschrieben, dass Deine Shadow-BitMap im
> Screenformat vorliegt, was ja auch logisch ist, wenn Du sie
> möglichst schnell auf den richtigen Screen blitten willst.
> Jetzt bekommst Du die Möglichkeit, mit den OS-Zeichenfunktionen
> drauf rumzumalen, aber jetzt bist Du schon wieder nicht zufrieden.
In die Shadow Bitmap kann ich natürlich hineinmalen, aber das bringt mir ja nichts. Die Shadowbitmap hat ein beliebiges Pixelformat, und reduziert u.U. die Qualität des Bildes (16bit, Farb-Indiziert). Und zum Speichern in 24bit müssste ich wieder zurückmappen.
Deshalb halte ich mir ja ein Full-Blown ARGB Abbild. Und darauf muss ich zeichnen können.

> Es gibt keine ideale Lösung. Schon gar nicht, wenn man die
> Problemstellung alle Nase lang umdefiniert.
Mein Ziel war immer das gleiche. Nur habe ich während des Threads unterschiedliche Ideen entwickelt, wie man es lösen kann, und am Anfang nur ein Teilproblem geschildert.

> Tja, bringt Dir halt nix, weil dann ja sowieso keine OS-Funktionen funktionieren
Nicht ganz. BltBmapRasport oder FillPixelArray z.B. funktioniert. Aber du hast recht wirklich lohnen tut sich das nicht. Evtl. bleib ich eben doch bei meinem PixelArray, dann spare ich mir den Remapping Code und kann das via guigfx machen, wobei es mir schon gefallen würde guigfx los zu werden.





--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

01.09.2006, 17:11 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Ich will keinen Screen initialisieren, weil ich dessen Pixelformat nicht kontrollieren kann.

Ich lasse mich gerne belehren, ich bin kein Wissensverweigerer.

Was denkt ihr denn, was ist die ideale Lösung ?

Mein Problem:

Ich schreibe sowas wie eine Image-Klasse (in AB2).
Ich möchte, dass der Progger damit Bilder laden, manipulieren, anzeigen und speichern kann, ohne sich einen Kopf über Pixelfromate zu machen. Dabei gibt es noch eine ganze Reihe von Blitmodi, z.B. für Spiele, aber auch zur Bildmanipulation, wie additiv, multiplikativ, mit Alpha Kanal, transparent, rotiert, textured etc. (die müssen allerdings nur auf True/Hi color funktionieren)

Also etwa so:

image_load{id,"Work:mypic.png"}
image_blit{id,40,40,rastport}
image_save{id,"Work:mypic.jpg"}

Und jetzt neu, wenn ich den Images einen Rastport verpasse:
rastport = image_get_rastport{id}
Move_ rastport,x1,y1
Draw_ rastport,x2,y2

...damit ich auch die Bilder mit Standard Routinen (oder auch den Blitmodi der eigenen Image Kalsse) bearbeiten kann.

Das Konzept mit der Shadow Bitmap ist erforderlich, weil ich meine Bilder ja nicht trashen will, nur weil ich sie auf einem 8-Farb Screen anzeigen lassen will, und auf der anderen Seite nicht bei jedem Refresh neu remappen will.

Das habe ich ja auch schon alles implementiert.

Schwierig wird es eben, wenn ich einen Rastport auf meine ARGB Bitmap legen will. Denn dann muss es eine OS Bitmap sein und kein Pixelarray.

Bei den Bitmaps muss ich sicher stellen dass:
1. keine Information verloren geht, ich brauche also immer 32bit
2. das Pixelformat ARGB ist, damit ich eigene Funktionen dafür implementieren kann, die das OS eben nicht bietet. (und nie bieten wird).




--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

01.09.2006, 16:44 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

@gni

Weil ich
1. nicht sicher stellen kann, dass ihn auch alle brav installieren.
(vor allem die OS4 user würden sich gegen ein 68k datatype wehren!)

2. Zum Datatype auch noch der remapping code gehört, und der ist ja auch nicht ohne.

3. Nur 32bit pngs (ARGB) über meinen Loader lade, alle anderen png Formate (also ohne Alpahchannel) lade ich via Datatype.

4. Ich auch einen png Saver haben will, und dann ist es nur noch ein kleiner Schritt zu einem Loader.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

01.09.2006, 14:20 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Wieso denn von hinten durch die Brust ins Auge?

Ich arbeite ausschliesslich auf ARGB Bitmaps, und wenn sie dargestellt werden sollen, erstelle ich eine Shadow Bitmap im Screenformat für schnelles, hardwarebeschleunigtes Blitten. Das ist doch simple, oder nicht ?

AsteroidsTR funtkioniert so. Und das ist schnell und kompatibel auf allen Systemen.
Zum blossen Anzeigen wird die ARGB Bitmap nicht mehr benötigt, und kann freigegeben werden, sodass man nur noch die Shadow Bitmap hat. Bei Programmen, die die Bilder manipulieren wollen, muss ich die ARGB Bitmap behalten damit ich keine Informationen verliere.
So muss ich eigene Grafikoperationen nur für ARGB implementieren, z.B. Antialiased Lines usw.

Meine einzige Neuerung ist, dass ich meine ARGB Bitmaps als echte OS Bitmaps anlegen will, (statt vorher einfache, selbst-allocierte PixelArrays) damit ich auch OS Zeichenfunktionen darauf benutzen kann. Und hier macht mir das 16Pixel Align einen Strich durch die Rechnung, da guigfx nicht zurecht kommt damit. Guigfx habe ich zum laden und remappen benutzt. Laden habe ich jetzt komplett auf Datatypes umgestellt. PNG lade ich als Ausnahme allerdings selbst, wegen dem Alpha Channel. Remappen muss ich nun auch selbst machen.

@Darius
Ja, mit dem AfA Datatype bekommt man den Alphachannel, aber das RGB Bild ist trotzdem nicht mehr das original, sondern mit dem Alphachannel und der Hintergrundfarbe verrechnet.

@Holger
> Ich verstehe überhaupt nicht, warum Du auf Hi/TrueColor
> Bildschirmen mit palettebasierten Funktionen herumhantieren willst.
Weil AmigaOS (3.x) nun mal Pen basierende Grafikoperationen hat. Mit geht es auch nicht darum, dass sie Pen basierend sind, sondern dass ich eben auf meine Bitmaps malen will, mit welchem Befehl auch immer.
SetRPAttrs() und Penlessmode scheint ja vielversprechend zu sein, geht nur leider nicht richtig ohne friend-bitmap+Screen.
Eigentlich geht es mir hauptsächlich im Text(), da ich das nicht selbst implementieren will, und einfach die uniformität zu normalen OS Bitmaps, damit einem alle Funktionen offen stehen.
Aber so langsam glaube ich doch, ich sollte fast bei meinen PixelArrays bleiben. Die OS Bitmaps bringen zu viele Probleme mit sich.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

01.09.2006, 12:02 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Also es ist so:

Ich schreibe eine Funktionsbibliothek, die 24 bit Bilder verwaltet.
(laden, speichern, blitten, manipulieren (auf ARGB Ebene) usw).

Ich will nicht vorraussetzen, dass der User AfA installiert hat und dazu auch noch ein ganz bestimmtes PNG Datatype, damit mein Program funktioniert. Es soll überall funktionieren.
Und ob das mit AfA+akpngDT funktioniert ist auch fraglich, da die PNG Datatypes das Bild meistens schon vergewaltigen wenn ein Alphachannel da ist, und nicht die Roh-Daten herausgeben. Wie auch immer, ich hab das ja schon alles implementiert, so wild ist das nicht.

Ich greife bisher NICHT auf direkt auf die Bitmaps zu. Alpha blitten funktioniert bei mir so, dass ich den Hintergrund mit WritePixelArray auslese, auf dem PixelArray arbeite (was ein garantiertes Pixelformat hat und im privaten RAM liegt) und dann mit ReadPixelArray wieder auf die Bitmap schreibe.
Das erfordert zwar einen temporären Puffer, ist aber vertretbar von der Geschwindigkeit her, weil man u.U. auch Hardwarebeschleuniung/native OS Funktionen ausnutzen kann. Ein direkten Lesen/Schreiben in die Bitmaps ist auf manchen Systemen sogar langsamer, das hatte ich am Anfang mal. Das wurde mir dann aber zu dumm, weil es doch viele verschiedene Pixelformate da draussen gibt.

Meine zu blittenden Bilder waren bisher auch ARGB PixelArrays im RAM, die ich mit der guigfx.library geladen habe. Und Bilder bearbeiten im RAM geht auf heutigen Rechnern sehr schnell, da nichts duch den Graphic Bus geschickt wird.

Jetzt will ich aber meine Bilder selbst zu Bitmaps machen (inkl. RastPort), damit ich auch alle OS Grafik Funktionen darauf anwenden kann. Dazu lege ich eine ARGB Bitmap mit AllocBitmap an. Ich denke, dass ich darauf auch pixelweise zugreifen darf, weil ich das PixelFormat beim Initialisieren explizit angebe, und ich gebe KEINE Friend Bitmap an und auch kein DISPLAYABLE Tag.
Ich muss eben nur die BytesPerRow berücksichtigen.

Diese Bitmap wird auch immer als ARGB gehalten, damit keine Information verloren geht (ich will ja nicht, dass z.B. mein Grafikprogram mein zu bearbeitendes Bild auf 16bit herunterrechnet, nur weil ich auf einem 16bit Screen arbeite).
Wenn ich jetzt aber auf den Screen blitten will, wird eine Shadow Bitmap angelegt, die im Screen Format ist (1-24bit, u.U. geremapped auf die Screenpalette).
Die Shadow Bitmap muss natürlich nach jeder Bildmanipulation aktualisiert werden.
Bisher habe ich dafür guigfx benutzt. Allerdings muss ich jetzt guigfx komplett rausschmeissen, weil guigfx nur mit kontinuierlichen PixelArrays zurecht kommt, nicht mit Bitmaps die ein Gap haben (also BytesPerRow != PixelWidth * BytesPerPixel).
(oder ich müsste vor dem Remappen ein PixelArray erzeugen, Remappen und es wieder verwerfen, aber dafür brauche ich temporär den doppelten speicher, und das remappen wird noch langsamer als es ohnehin schon ist).

Also ich sehe schon, ich muss entweder guigfx benutzen, oder wirklich alle Pixelformate abdecken.

Oder gibts eine bessere Lösung ?

Deckt wirklich jedes Datatype alle Pixelformate ab?
Das würde ja bedeuten, dass jeder Datatpye Author das Rad neu erfinden muss.

Eine OS Funktion wie CreateDisplayableBitmap(destbitmap, sourcebitmap, viewport) wäre wirklich toll gewesen.

:sleep: ... nach einigem Nachdenken ... :sleep:

Ist folgender Gedanken Gang korrekt:

Ich teste ob der Screen True/Hi color ist. (depth>=16)
Wenn ja, lege ich eine friend Btimap an und benutze ReadPixelArray um von meiner ARGB bitmap auf die friend bitmap zu mappen. ReadPixelArray mapped soweit ich weiss automatisch auf das Zielbitmap Format, solange es True/Hi color ist.

Wenn es ein Farbindizierter Screen ist, frage ich nach der Anzahl der Farben und schreibe EINE remapping Routine, die in ein 8bit PixelArray die entsprechenden Pens einträgt. (Können natürlich auch weniger als 256 Farben sein, das Array ist aber 8bit).
Dann benutze ich ReadPixelArray8 um das auf die Friendbitmap zu bringen, inder Hoffnung, ReadPixelArray8 trägt meine 8bit Pens korrekt in die Bitmap ein, egal wieviele Fabren sie hat (2-256), solange ich keine Pens ausserhalb des zulässigen Bereiches benutze.

Würde das funktionieren ? Dadurch hätte ich zwar nicht die Anzahl der Farben, aber das Pixelformat abstrahiert, und kümmere mich lediglich um die Anzahl der Farben beim Remapping.

Ich möchte noch erwähnen, dass es mir hier nicht darum geht, HAM6, HAM was-weiss-ich und Halfbright zu unterstützen, sondern es geht um High End Amigas die bei einem 40/60er mit 24bit Grafikkarte anfangen, Amithlon, WinUAE, MOS und OS4. Wer auf einem Custom Chip Screen arbeitet, wird mit den angepeilten Applikationen soweiso nichts anfangen können, mangels CPU und GFX power.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 01.09.2006 um 12:15 Uhr geändert. ]
 
bubblebobble   Nutzer

31.08.2006, 23:30 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Was ich meine ist, dass man natürlich mit GetBitmapAttr() den BytesPerRow Wert auslesen sollte. Aber diesen natürlich auf jeden Fall beachten, wenn man selbst in die Bitmap hineinpoked.

Normalerweise interessiert das einen nicht, weil die OS Funktionen das sowieso berücksichtigen, aber z.B. musste ich einen eigenen PNG Loader schreiben um an die ARGB Bitmap des PNG Bildes zu kommen. Die Datatypes liefern 1. den Alpha Kanal nicht und 2. rechnen ihn in das Bild bereits ein, und blenden das gegen die Hintergrundfarbe.

Wenn ich das ganze jetzt in eine Bitmap hinein decodieren will, muss ich eben den BytesPerRow Wert berücksichtigen.
Ich könnte natürlich auch in ein kontinuierliches Pixelarray decodieren, und dann mit WritePixelArray das ganze in die Bitmap kopieren. Allerdings benötige ich dann temporär den doppelten Speicher.
Und ich habe noch jede Menge andere Funktionen wo ich direkt auf die Bitmap zugreife, z.B. zum Blitten mit Alpha channel, additiv, multiplikativ, transparent, texture-blit usw, also Blitmodi, die vom OS nicht geliefert werden.

Das einzige Problem was ich habe ist das Remappen. Wie kann man systemfreundlich eine ARGB Bitmap auf das Screenformat remappen ?


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von bubblebobble am 31.08.2006 um 23:33 Uhr geändert. ]
 
bubblebobble   Nutzer

31.08.2006, 18:46 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Es sieht so aus, als ob AllocBitmap immer einen Speicherbereich allociert, dessen Pixelbreite durch 16 teilbar ist. BytesPerRow ist dann natürlich auch entsprechend gesetzt. Da ich aber immer konsequent von einem kontinuierlichen Speicherbereich ausgegangen bin, ist das nie aufgefallen, weil ich den "Fehler" sowohl lesend als auch schreibend gemacht habe. Bis zu dem Zeitpunkt, als ich OS Funktionen auf die Bitmap angewendet habe wie FillPixelArray. Und das auch erst, nachdem ich eine andere Bitmap genommen habe als meine Testbitmap, bei der alles wunderbar lief, da zufällig durch 16 teilbar.

Zusammenfassung:
Bei OS Bitmaps IMMER den BytesPerRow Eintrag in der Bitmap Struct berücksichtigen, niemals annehmen dass die Pixel alle hintereinander liegen!



--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

31.08.2006, 14:52 Uhr

[ - Direktlink - ] 		Thema: Tonerkennung
Brett: Programmierung

Was für eine Idee ?
Wir haben das Problem hier für dich quasi gelöst und beschrieben, wie man es macht, inkl. Sourcecode und Verweis auf eine externe Library.

Was noch ? Danach käme nur noch das für dich in Maxon Basic zu implementieren. Aber ich denke das musst du schon selbst hinbekommen. Sonst geht es eben nicht.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

31.08.2006, 09:33 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Ich denke ich habe den Fehler gefunden. Mir war das beim Programmieren nie aufgefallen, weil meine Testbitmap zufällig eine 16er Breite hatte.
Jetzt wirds aber unangenehm, ich muss den kompletten Code umschreiben mit seperatem BytesPerRow Parameter.
Mit guigfx.library kann ich dann auch nicht mehr arbeiten, weil dort kein BytesPerRow unterstützt wird, sondern immer von nahtlosen PixelArrays ausgegangen wird. Die Funktionalität muss ich dann auch noch nachproggen. Das hab ich auch schon zum größten Teil, nur Remapping fehlt mir noch.

Gibt es OS Funktionen für Remapping ?

Also z.B. ich habe eine ARGB bitmap, und will sie in das Screenbitmap Format konvertieren, was auch immer der Screen hat.

Kann man evtl. mit datatypes auch von Bitmap zu Bitmap remappen ?


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

30.08.2006, 19:39 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Nein, den Zeichenoperationen ist das nicht egal, weil der BytesPerRow Eintrag frecherweise aufgerundet wird. Funktionen wie WritePixelArray, FillPixelArray etc. funktionieren dann nicht mehr, erzeugen dann ein geschertes Bild und schreiben am Ende sogar über den Speicherbereich.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

30.08.2006, 18:44 Uhr

[ - Direktlink - ] 		Thema: Bitmaps nur durch 16 teilbare Breite?
Brett: Programmierung

Hallo !

Beim Rumspielen mit Bitmaps ist mir aufgefallen, dass man zwar
Bitmaps mit beliebigen Breiten anlegen darf (AllocBitmap()), und viele Operationen funktionieren auch damit, aber wenn man einen RastPort drauflegt funktioniert das nur mit Bitmaps, die eine Breite haben die durch 16 teilbar ist. Auch der Wert in Bitmap->BytesPerRow ist immer auf die nächste 16er Pixelbreite aufgerundet.

Das ist selbst bei 32bit/pixel Bitmaps so. Stimmt das, kann man dan irgnedwie umgehen oder bin ich gezwungen, alles in 16er Breiten anzulegen ?

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

25.08.2006, 19:26 Uhr

[ - Direktlink - ] 		Thema: Ich suche Soundsamples
Brett: Get a Life

Mach dir keine Sorgen, in Deutschland kann man keine Rechte an reinen Natur Sounds haben, auch nicht an deren Aufnahme, da es keine schöpferische Leistung ist.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

25.08.2006, 18:30 Uhr

[ - Direktlink - ] 		Thema: Ich suche Soundsamples
Brett: Get a Life

Micro habe ich, ich bräuchte nur was komfortableres zum aufnehmen als meinen DAT Walkman. (der ist doch recht gross und schwer). Ich dachte ein mp3 player mit mic in wäre perfekt, weil er keine Mechanik hat und leicht ist. Er müsste aber in 44.1kHz aufnehmen, am besten ohne Kompression. Speicher ist ja kein Problem mehr.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

25.08.2006, 13:33 Uhr

[ - Direktlink - ] 		Thema: Ich suche Soundsamples
Brett: Get a Life

Wie wäre es denn, mal hinaus in die Natur zu gehen und was aufzunehmen ?

Ich habe das demnächst vor. Das ist schon interessant, Sound selbst zu sammeln, das ist wie Fotografieren mit den Ohren. Allerdings benötigt man ein gutes Microphon und ein Aufnahmegerät, z.B. einen DAT Recorder. (was ich glücklicherweise beides habe)

Gibt es eigentlich mp3 player, die ein Mic oder Line in haben, mit dem man vernünftig aufnehmen kann ?

Ich hab einen mp3 player mit eingebautem Mic, aber das kann man total vergessen. Und mit total meine ich wirklich total.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

24.08.2006, 11:59 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

@whose:

Alles was durch den ZII oder ZIII Bus muss ist langsam.
AsteroidsTR ist nur deswegen schnell, weil sich alles
auf der Graka abspielt mit Hardwarebeschleunigung.
Da kann man sogar Full-Screen scrollen (was auf der Graka tatsächlich Speicher schieben bedeutet, man kann nicht einfach einen Pointer erhöhen, so wie beim Chipset).

Selbst eine Cybervision hat ja sogar schnelleren Speicher als der Amiga, auch der Blitter dürfte schneller als die CPU sein.

Sobald aber Alpha channels, Transparenz, Beleuchtung etc. ins Spiel kommen, muss man entweder 3D Chips benuzten, oder die CPU.
Da es auf dem Classic Amiga weder das eine noch das andere in ausreichender Power gibt, geht es eben nicht, und wird auch nie gehen.

Man braucht einfach einen größeren Hammer, so simpel ist das.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

23.08.2006, 10:32 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Ich plane damit auch ein Spiel, so ähnlich wie Feary Tale Adventure v(geht das in Richtung Ultima?), aber natürlich wesentlich aufwendiger, z.B. mit transparenten Leucht-Effekten, durchsichtiges Wasser und höherer Auflösung (evtl. 800x600) usw.
Das lässt sich damit auf jeden Fall realisieren, sodass es unter OS4, MOS, Amithlon und WinUAE läuft. Für den Classic wirds aber wohl zu langsam, dafür müsste man eine "Light" Version machen, ohne solche Transparenz Effekte, dann ginge es aber auch.
Das war auf dem Classic vor zehn Jahren nicht möglich, und ist heute auch nicht möglich, da die Hardware nicht durch ein Wunder über Nacht schneller wurde. Das sowas einfach Rechnepower braucht, sieht man an den SDL Games, und die sind sogar oft nur 320x240.
AsteroidsTR dagegen läuft auf einem Classic mit Graka sogar flüssig, obwohl es 640x480 ist und somit 4-fache Blit Power braucht.
(Anm: AsteroidsTR läuft mit den Routinen aus der image.inlcude)

Du wirst ja an den Demos sehen, ab wann Schluss ist. Die Demos in dem AB2 Archive steigern sich, vom simplen Ball-Hüpf Demo, über Scrolling, Alpha Blending bis zum rotierenden, texturierten 3D Cube.

Ich bin auch dabei, eine ISO Tile Engine zu schreiben. Evtl. wäre das was für dich.
--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 19:37 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

@whose

Ja, sollte in der aktuellen distri drin sein.

Aber besser direkt von meiner HP:

http://www.hd-rec.de/Archive/TK_AB2_Sources.lha

Ok, aber für Classic könnte es doch etwas langsam sein.
Ich hatte das bisher nur unter WinUAE und Amithlon probiert.

In der Demos Schublade findest du einige Game-Demos, auch mit Aplha Channel. Aber sowas wie der 3D Cube wird auf jedenfall zu langsam sein.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 18:50 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

In meiner image.inlcude (Amiblitz Befehlsbibliothek) habe ich das alles schon längst implementiert, also z.B. ein .png mit Alphachannel laden und in ein Fenster blitten mit Alpha Channel.

Es ist nur nicht Hardware beschleunigt. Es ist aber schnell genug für ein paar Sprites in Spielen oder für GUI Knöpfe.

Was ich jetzt neu gemacht habe ist, dass ich jedem "image" Objekt
(das sind die 24 bit Bilder aus der image.inlcude) noch ein RastPort und Layer verpasst habe, sodass man mit jeder beliebigen OS funktion hineinmalen kann. So lässt sich z.B. kinderleicht eine doublebuffer Anim machen innerhalb eines Fensers.
Nur leider wird jetzt halt alles in schwart gezeichnet, es sei denn ich mache noch xtra zeichenfunktionen.

BTW, ich habe jetzt guigfx weitestgehend rausgeschmisen
(ich benutze es nur noch zum remappen) und lade via Datatpye. Da kann ich direkt in eine ARGB bitmap laden, die ich dann mit dem Rastport versehen. Ich brauche dann also keinen Speicher mehr doppelt.

Danke nochmal an alle, die mir Tipps gegeben haben!






--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 18:23 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Ich evaluiere nur die Möglichkeiten. Bis jetzt bleibt mir nur das Schlupfloch, dass die Text Operationen grundsätzlich funktionieren, nur eben schwarz. Für meine speziellen zwecke reicht mir schwarz, aber da ich alles in Funktionsbiblitheken packe (Wiederverwertbarkeit!) wäre es schön, wenn alles so funktioniert wie es soll.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 18:03 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

@Holger

Ich schere gerne alles über einen Kamm. Dann muss ich nur eine Funktion Debuggen, Optimieren usw. anstatt von vielen.

Wenn ich Fonts über TTengine mache, bleibt ja nicht mehr viel.
Linien ziehen und Rechtecke malen hat man in 5min implementiert.(ohne AA).

Ich will natürlich nicht direkt in das Bild zeichnen, da ich ja auch den Alpha Channel updaten muss. Es soll ein Programm mit Layern werden.
Ich muss also wissen, welche Pixel wie stark gesetzt werden von der Zeichenoperation. Wenn es einmal ins Bild gemalt ist, kann ich das nichtmehr herausfinden. Ich komme also nicht drumerhum, einmal mit schwarz auf weiss zu Printen/Drawen/Rectfillen etc. Das nehme ich dann um den Alpha channel im Layer zu updaten und färbe das ganze beim Swappen ein (je nach DrawMode, auch abdunkeln, transparent, Effekte etc.)


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 17:43 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Also CGX und Picasso sind die letzen beiden "Lager" die am Ende doch noch (dank einsehen der Macher) zu 99% kompatibel wurden, sodass man
als Progger nicht auch noch diese Suppe auslöffeln musste.

Aber lasst dieses Thema hier bitte. Ich versuche eine Lösung zu erarbeiten, die auf allen System funktioniert, ohne dass ich Extra Würste braten muss.

Das mit dem LUT Array ist gar nicht mal so eine schlechte Idee, nur das ich dan leider AA Fonts verliere, da diese nicht auf LUTs gehen.
Ich werde es vermutlich so machen, dass ich eine weisse Bitmap nehme, dann mit schwarzem Pen zeichne (die Funktionen gehen ja, nur eben immer schwarz), und dann das ganze beim rüberblitten in das eigentliche Bild einfärbe. Da bekomme ich auch gleichzeitig den Alphachannel (invers) gratis geliefert.

Achja, ich will nur 24bit unterstützen, keine farbindizierten Screens oder Bilder.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 17:09 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Das CGFX API bietet aber IIRC keine Funktionen für Linienzeichnen, Text schreiben in 24bit etc.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 16:22 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

@whose

Was schlägst du nun konkret vor ?
Was meinst du mit eigener Palettenverwaltung ?
Ich brauche 24bit Grafik Funktionen auf eine Bitmap, die nicht mit einem Viewport verbunden ist.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

22.08.2006, 08:25 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Ich glaube, ich weiss warum es nicht geht.
Wenn mich nicht alles täuscht, funktioniert Bernds AfA Penless Mode so:
Er merkt sich den RGB Wert irgendwo, den man mit SetRPAttrs() setzt.
Wenn jetzt eine Zeichenfunktion kommt, setzt er flux den Pen #1 auf den RGB Wert, zeichnet, und stellt den ursprünglichen RGB Wert des Pens #1 wieder her.
Bei 24bit Screens kann man diesen Trick machen, da sich eine Paletenänderung nicht auf die bestehenden Pixel auswirkt. Während der ganzen Zeit hält er den RastPort dann gelockt, so kann nichts passieren.

Ich denke das macht er so, weil ich keine andere Möglichkeit sehe. Wie soll AfA das sonst machen ? Für "echte" 24bit Grafikoperationen müsste man Picasso96 geändert werden, das kann man aus AfA heraus nicht machen.

Und weil eigentlich nur mit einem ganz normalen Pen gezeichnet wird, funktioniert das logischerweise auf einer Bitmap ohne Paletteninformation nicht.

Unter AROS, MOS und OS4 könnte es aber funktionieren.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

21.08.2006, 23:21 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

An all eOS4 user:

Könntet ihr mir den Wert von

RPTAG_APenColor
RPTAG_BPenColor

BMB_USERPRIVATE
BMF_USERPRIVATE

verraten ? Dann könnte ich auch OS4 supporten.

Bei den anderen Systemen heisst das

RPTAG_FgColor
RPTAG_BgColor

und das BMF_USERPRIVATE gibts wohl nicht.
Gibt es eine andere Methode/Flag, um eine Bitmap
als unswappable zu deklarieren ?

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

21.08.2006, 23:15 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Ok, es funktioniert NICHT.

Der obige Code funktioniert mit dem RastPort eines Fensters
auf einem 16/24bit screen (was einen Viewport hat).
Es funktioniert aber NICHT mit dem Rastport, den ich aus Thomas seinem Beispiel code erhalte. Hier wird trotzdem alles
in schwarz gezeichnet. Zumindest verhält sich AfA OS unter WinUAE so.

@Darius
das "#" beideutet, dass es eine Konstante ist.
C Progger können sich das einfach wegdenken.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
bubblebobble   Nutzer

21.08.2006, 18:01 Uhr

[ - Direktlink - ] 		Thema: BitMap aus PixelArray erzeugen
Brett: Programmierung

Ok, ich habe mal mit SetRPAttrsA() herumgespielt.
Funktioniert aber nicht (AfA OS), alle Pens bleiben schwarz.

Ich mache folgendes:

code:
SetRPAttrsA_ rp,Tags(#RPTAG_PenMode,False,#RPTAG_BgColor,$FFFFFF,#RPTAG_FgColor,$FFFFFF)
Move_ rp,10,10
Draw_ rp,400,400
RectFill_ rp,20,20,190,190

Hab ich was vergessen ?

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de
 
 
1 2 3 4 -5- 6 7 8 9 10 >> Letzte Ergebnisse der Suche: 707 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.
.