Biing 1 Tool

[TerminusTechnicus]

Meinst Du eine Schwarzanhebung wenn man maskierte PNG importiert?
Also, dass alle schwarzen Pixel, die nicht transparent sind, um 1 Farbwert aufgehellt werden?

Genau das, du hast doch bisher sonen tollen Bereich wo das Bild direkt eingefasst wird, wäre doch sicher nicht das Problem schwarz um eine Nuance aufzuhellen, damit die Transparenz nicht auf dem Bild greift, oder? Dann braucht man nur mehr die Bildgröße anpassen, nicht mehr umständlich das schwarz ersetzen, hab bisher noch kein Tool gefunden, das einen gescheiten Schwarzersatz praktiziert und auch das Bildformat akzeptiert.

[Devilmarkus]

Das ist kein Problem ansich,
aber man könnte es nicht ohne Weiteres auf transparente Bilder anwenden.

Ich werde die Option "Entferne Schwarze Pixel" zufügen...

Wenn man maskierte PNG dann importiert, ist der Bereich, der nicht maskiert ist, dann halt Tiefschwarz (transparent) und in den maskierten Bereichen werden die schwarzen Pixel entfernt.
So kann man dann auch noch transparente Bilder importieren.

Sollte gehen, ist etwas Umständlich, aber machbar.
Sobald ich die Zeit dazu habe, schau ich mir das mal an...

[TerminusTechnicus]

Naja, du hast doch direkt in deinem Tool Bereichsregler die man anpassen kann... für ebendiese ist das nicht direkt anwendbar? Mit Masken hilft das leider auch nicht viel weiter denke ich.

[Devilmarkus]

Das Lustige ist, dass ich bei den eingebauten Effekten schon eine Schwarzpixel-Entfernungs-Routine eingebaut habe, welche allerdings irgendwie nicht so funktioniert wie sie soll...

Dabei wandle ich VOR dem Filtern alle schwarzen Pixel um in transparente Rote.
Nach dem Filtern wird dann aus allen Pixeln, die nicht transparent und Rot sind, der Schwarzbereich entfernt, welcher beim Filtern entstehen kann.
Anschliessend werden die transparenten roten Pixel wieder in Schwarze umgewandelt.

Warum dies aber nicht richtig funktioniert, weiss ich nicht.
Die Routine ist codetechnisch jedenfalls korrekt!

[TerminusTechnicus]

Funktioniert das bisher nicht bei "maskierten" Bildern oder allgemein auch nciht auf normalen Bildern ohne Maske? Entsprechend liegts vlt an der Maske die darüber gelegt wurde und ggf. wieder, beim importieren durch umwandlung ins pcx einfach seine Maske verliert, oder aber beim Import wieder an transparente schwarz angepasst wird. Arbeitest du nun direkt mit den Masken? Weil die Konvertierung in pcx kennt ja keine Masken... afaik. Solang die ganzen Effekte auf Bild-Masken ablaufen wird das wohl weniger Erfolg haben, denke ich, als wenn das Bild gezielt (Grund-Ebene) verändert wird.

[Devilmarkus]

Kleines Update auf Version 1.5 fertig:
http://cpc-live.com/biing/tool/

Ich habe einige kleinere Fehler behoben, und ab sofort gibt es auf der Seite einen Patch, welcher die DGL20-DGL22 fixed, so, dass man sie mit dem Tool auch bearbeiten kann.

Achtung! Den DGL-Patch bitte nur auf eine unveränderte Biing!2 Installation kopieren!
Er funktioniert nur mit der Version 1.06/1.06a und nur, wenn Ihr auch die Garage installiert habt.
(Bei anderen Versionen keinerlei Garantie, dass es klappt)

Ihr solltet, bevor Ihr den DGL Patch anwendet, eine Sicherung folgender Dateien machen:
DATA\DGL20
DATA\DGL21
DATA\DGL22
DATA\IXY
DATA\OFFS

[Devilmarkus]

Kleines Website-Update:
Ich habe alle offiziellen Patches und Upgrades mit zum Download eingefügt:

http://cpc-live.com/biing/tool/

Teilt mir bitte mit, ob was fehlt / falsch ist.

(Ist echt Mega-Schade, dass es wohl nicht möglich ist, die .EXE so zu patchen, dass auch DGL55 erkannt wird... Dabei liegt es nicht an der Erkennung selber: Wenn man die DGL alle extrahiert und der biing2.dgl mitteilt, dass sie "Files" verwenden soll, werden die entsprechenden Dateien auch nicht gefunden, sonst hätt ich ein Patch Tool geschrieben, was die DGL alle exportiert und die Konfig. anpasst) )

[Devilmarkus]

So sieht übrigens die Fehlermeldung aus, wenn man es im "Filemode" spielt (Ohne DGL Dateien)

[TerminusTechnicus]

Lässt sich für Block 55+ die exe nicht disassemblen damit man auf den gewünschten Algorithmus kommt der für die Komprimierung zuständig ist?

[Devilmarkus]

Ich habe da leider Null Ahnung von...

Vielleicht kann man ja die Routine ersetzen?
Ich hab sowas ähnliches mal in einem alten CPC-Spiel gemacht.
Das hatte eine falsche Routine zur Palettenauswahl.
(Der Befehl dazu schnitt sich mit einem Befehl, die Ram-Bänke auszuwählen, was zum Absturz führte, bei CPCs mit mehr als 64k Ram.)

Dafür habe ich also im Z80 Assembler an der Stelle eingebaut:
JP <neue adresse mit neuer Routine>
NOP (so oft, bis alte Routine ausgefüllt war)

Und dann munter ausserhalb der eigentlichen Binary die neue Routine eingebaut.

Anschliessend dann die neue Routine mit an die gepatchte Binary rangehängt.

Ich bezweifle allerdings, dass dieses mit X86er Assembler möglich ist?!?

[TerminusTechnicus]

Wichtiger wäre erstmal die Sprache (was beim Dulog sicher nicht ganz so einfach sein sollte), wenn du die kennst weißt du zumindest welchen Disassembler du nutzen kannst/solltest um größtmöglichen Erfolg mit dem RAM zu haben. Aber wie gesagt, da ist denke ich ehr der Herr Dragonling die Koryphäe in dem Bereich. Denke aber dadurch das sie schon am C64 gearbeitet haben durchaus neben dem eigenen Coding/Komprimierungen, wohl doch ehr nen Basic genutzt haben, ist aber nur ne Mutmaßung, für gewöhnlich bleibt man bei dem was man zuerst gelernt/gemacht hat und lernt nicht noch zig andere Sprachen dazu.

[dragonling]

Es gibt nur "einen" Disassembler. Egal in welcher Sprache in Programm geschrieben wurde, am Ende kommt ein Binary raus (wenn es kompiliert wird, also nicht wie bei Java). Und wenn man dies dann Disassembliert, bekommt man Assemblercode.
Ein Programm zu patchen, ist kein Problem. Zur Laufzeit oder in der Exe (wobei das gefährlicher ist, weil man den falschen Breich überschreiben könnte).

Das Dulog wurde in C geschrieben, der Rest der Spiele in Assembler.

[TerminusTechnicus]

Was nutzt du denn aktuell? MASM?

[Devilmarkus]

Es wäre jedenfalls SUPER, wenn hier jemand das Spiel tatsächlich patchen könnte...

Leider kann ich mit einem x86-Debugger nichts anfangen, da ich nicht weiss, wie soetwas arbeitet. (Ich tue mich schon mit einem Z80 Debugger schwer)

Jedenfalls: Wer es patchen kann, den knutsch ich *g

[dragonling]

Was nutzt du denn aktuell? MASM?

Gar nichts. Ich schreibe in Visual C++ und nutze maximal Inline-Assembler.

[Devilmarkus]

Hat eigentlich schon jemand herausgefunden, wie die Dateien "BI2TEX" und "BI2DATA" komprimiert sind?

Ich bin über Biing!2 auf Russisch gestolpert und hab mir das mal angesehen... Da ist definitiv die BI2TEX verändert. (Und die 01.fnt - 13.fnt auch, das werden wohl die Fonts sein)

Russische BI2TEX:
http://cpc-live.com/BI2TEX_rus.zip

[dragonling]

Hat eigentlich schon jemand herausgefunden, wie die Dateien "BI2TEX" und "BI2DATA" komprimiert sind?

Jepp, ich

Russische BI2TEX:

Ich habe die Datei mal decodiert. Es ist die von Biing2, nicht Biing2A. Und sie haben sich die Arbeit gemacht, so gut wie alles zu übersetzen

[Devilmarkus]

Kannst Du mir die Info mal PMmen, wie ich das hinbekomme?
(Mit einem C-Beispiel, oder am besten mit einem Java-Beispiel)

[dragonling]

(Mit einem C-Beispiel, oder am besten mit einem Java-Beispiel):D

Nur in Assembler. Es werden auf den Daten Bit-Operationen durchgeführt, für die es keine Entsprechungen in C gibt! Deswegen habe ich die Routinen zur de~/kodierung mit Inline-Assembler implementiert

[Devilmarkus]

Dann halt in Assembler

Ich möchte halt gern verstehen, wie die Dateien komprimiert sind...