8-Bit RLE Bitmap wird nicht richtig geladen.

[D_Key]

@Quiche-Lorraine sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Sorry, wenn ich etwas gefrustet klinge. Aber ich entwickele gerade Firmware für Nordic Chips.

Hi, also habe die Zitate Funktion gefundene
Ja also, ich kenne das Problem nur zu gut, mit dem schlecht Dokumentierten SDK's.
Oder auch mit Fehlern im Chip, die nur unter ganz bestimmt Umständen auftreten.

Ich hatte mich mal vor Jahren mit NXP angelegt bei deren Kinetis IC's.
Da hatte sich das ADC Eingassignal mit der ADC PLL vermischt, aber nur dann wenn man es mit dem Inneren ADC Amp bis ins ins Rechteck verstärkt hat und die Eingangsfrequenz 25kHz betrug.
Also Eingang Sinus -> Verstärkt bis es Rechteckig wird.
Das Rechteck hat dann derartige Oberwellen verursacht, das ein Teil des ADC Eingang Signals zum DAC wider bei 300Hz wider heraus kam, was für derartiges "Gezwitscher "gesorgt hat. Furchtbar war das.
Das Eingangssignal war ein FM Singsang mit 25khz Trägerfrequenz, daher das Gezwitscher.

Im Enddefekt half nur das FM Signal auf eine andere Frequenz zu mischen.

Zurück zum Thema.
Ich habe das Problem gefunden. Ich habe den Code weiter zerstückelt und geschaut, wo entstehen die Nullen.
Vor allem bei einem Bild was überhaupt kein Schwarz enthält.
Problem war hier das return, was ich durch ein continue ersetzt habe :

else if (r==2)
           {
               x=x+getc(in);
               y=y-getc(in);
               continue;//return;
           }

dann habe ich noch das Tauschen der Farben:

unsigned char temp = r;
               r = b;
               b = temp;

durch std::swap(r, b); ersetzt.

PS:
std::shared_ptr oder std::unique_ptr sind bei der Playstation 2 nur bedingt gut.
auch std::vector hat so seine Macken, man kann zwar mit reserve(), verhindern das der Speicher häufig um sortiert wird, aber auch so ist std::vector schon eine Bremse auf der PS2.
Ich hatte zuerst ein std::vector mit std::varaint. Bei nur 100 Charaktern hatte ich schon Frame drop ohne Ende.
Ja und 200 Charaktere gibt es zu spitzen Zeiten auf der Map.

Also dynamische Speicher Verwaltung auf der PS2 sollte man behutsam einsetzen, weil der DRAM einfach Grotten lahm ist, alles auf der PS2 ist lahm.

[Schlangenmensch]

@D_Key Wenn dynamische Speicherverwaltung problematisch ist, könntest du dir pmr Allokatoren anschauen. Damit kannst du einige c++ Container ohne Heap Allokationen verwenden.

[Th69]

Bzgl. dem Vertauschen von r und b, kannst du doch einfach die Variablen tauschen:

get_pixel_rgb_new(pixel_index, &b, &g, &r); // swap r & b

[Quiche Lorraine]

@D_Key sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Ich hatte zuerst ein std::vector mit std::varaint. Bei nur 100 Charaktern hatte ich schon Frame drop ohne Ende.

Zwei kleinen Sachen springen mir diesbezüglich ins Auge.

backgroundPlane* Renderer::addBgPlane(string path, bool transparency)

Der erste Punkt ist die Rückgabe eines allokierten Speichers. Wer gibt diesen frei?

Der zweite Punkt betrifft die Übergabe des Parameters path. Je nach Compiler-Stand, C++ Standard, Aufruf kostet dich dieser Aufruf eine Kopie von path. Warum übergibst du diesen nicht mittels konstanter Referenz?

[DocShoe]

@D_Key sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Also dynamische Speicher Verwaltung auf der PS2 sollte man behutsam einsetzen, weil der DRAM einfach Grotten lahm ist, alles auf der PS2 ist lahm.

Inwiefern macht das Sinn? Liegen Stack und Heap in unterschiedlichen Hardwarespeichern? Also liegen Programmcode und Stack in DRAM und der Heap in Flashspeicher oder Ähnlichem? Kann ich iwie nicht glauben.

[DocShoe]

@D_Key sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

...
C++ brauch ich nicht zu lehren ich Programmiere seit 17 Jahren c / c++ im aber im Bereich der Signalverarbeitung,, Mikrocontroller usw.
...

Ich glaube, du meinst "lernen" statt "lehren", oder? Wenn das der Fall ist, hast du ein massives Problem. In dem Moment, wo man aufhört, sich moderne Techniken aneignen oder generell dazulernen zu wollen, weil man glaubt, dass man eh schon alles kann, wird man schlechter.
Dein Code ist ein wilder Mix aus C und C++, du solltest dich für eins von beiden entscheiden. Wenn du fit in C bist, dann mach C, wenn du C++ lernen willst, dann mach C++. Aber nicht das, was du hier zeigst.

Statt alles selbst zu programmieren solltest du mal einen Blick auf fertige Bibliotheken werfen, z.B. CImg.

Ansonsten stimme ich @Quiche-Lorraine in all seinen Kritipunkten zu.

[DocShoe]

@D_Key sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Ich hatte zuerst ein std::vector mit std::varaint. Bei nur 100 Charaktern hatte ich schon Frame drop ohne Ende.
Ja und 200 Charaktere gibt es zu spitzen Zeiten auf der Map.

Wenn du Vektoren genauso in Funktionsaufrufen benutzt, wie du std::string benutzt, dann wundert mich das nicht.
Bitte lies dich in die verschiedenen Möglichkeiten ein, wie Parameter an Funktionen übergeben werden (call-by-value und call-by-(const-)reference).

[D_Key]

Uii, das ist sind auf einmal viele Leute aufgewacht.

@Th69 sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Bzgl. dem Vertauschen von r und b, kannst du doch einfach die Variablen tauschen:

Jo, stimmt^^ das ist natürlich noch kürzer.

@Quiche-Lorraine sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Der erste Punkt ist die Rückgabe eines allokierten Speichers. Wer gibt diesen frei?
Der zweite Punkt betrifft die Übergabe des Parameters path.

Für die Speicherfreigabe habe eine separate Funktion. Der Hintergrund wird nur gelöscht bei verlassen des Levels oder beim verlassen des Spiels.
Den String über habe ich am Sonntag Abend schon auf eine Zeiger geändert.
Ich musste weitere Parameter an die adBgPlane Funktion übergeben, da habe ich das gleich geändert.

@Schlangenmensch sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

@D_Key Wenn dynamische Speicherverwaltung problematisch ist, könntest du dir pmr Allokatoren anschauen. Damit kannst du einige c++ Container ohne Heap Allokationen verwenden.

Das klingt nach eine prima Idee, wenn das mit dem PS2 SDK funktioniert mache ich das.

@DocShoe sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Wenn das der Fall ist, hast du ein massives Problem. In dem Moment, wo man aufhört, sich moderne Techniken aneignen oder generell dazulernen zu wollen, weil man glaubt, dass man eh schon alles kann, wird man schlechter.
Dein Code ist ein wilder Mix aus C und C++,

Der wilde Mix ist jetzt daher geschuldet, das ich mich eigentlich ich gar nicht mit dem bmp Dateiformat auseinander setzen wollte. Für mich hat cbmp von github funktioniert. Bis ich bemerke habe das die Originalen Textur Altlas'se 8Bit RLE Komprimiert sind.

Klassisches C mag ich überhaupt nicht mehr, weil keine Objektorientierung.
Immer nur neuen Standards zu folgen halte ich für Überreiben. Nicht Immer ist das neuste auch immer gut.

@DocShoe sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Liegen Stack und Heap in unterschiedlichen Hardwarespeichern? Also liegen Programmcode und Stack in DRAM und der Heap in Flashspeicher oder Ähnlichem? Kann ich iwie nicht glauben.

Das ist eine sehr interessante Frage. Also Heap und Stack liegen Im DRAM.
Programmcode hat einen eignen Speicher auf der CPU. Zudem hat die EE zwei Vector Einheiten, die einen eignen Speicherbereich haben (MicroMemory,) wo der VU Assembler landet.
Ich weiß auch Atok nicht wo Konstanten hin gespeichert werden. Flash Speicher gab es bei der Playstation 2 nicht.
Es gibt noch eine "Section .data" für große arrays, da es aber kein Flash Speicher gibt vermute ich, das jedes mal das CD Laufwerk bei einem Zugriff auf ein solches Array loslegen muss. Für den IOP also den PS1 Prozessor gibt es noch einen 2 MB EDO-RAM.
Zudem gibt es noch einen schnellen 16kB scratchpad RAM.

@DocShoe sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Wenn du Vektoren genauso in Funktionsaufrufen benutzt, wie du std::string benutzt, dann wundert mich das nicht.

Nein, ich habe Zeiger im Variant abgelegt. Ich bin aber allgemein nicht zufrieden mit dem Variant, weil ich eine strikte Reihenfolge einhalten muss wie meine Gameobjekte von der gameloop durchlaufen werden müssen. Zuerst Charakter, dann Waffen, dann Zauber-angriffe usw. Wahrscheinlich muss Reihenfolge nicht einhalten aber für mich zum debuggen ist es erst mal das einfachste.
Ich habe jetzt verschiedene Vectoren also mit verscheiden Klassen.

Neben bei ist mir aufgefallen unter Windoof 11 lassen sich die BMP Dateien auch nicht öffnen im Standard Bildbetrachter.
Da kommt auch nur Matsch heraus. In Ubuntu klappt das.
Da die BMP Dateien auch 20 Jahre alt sind macht es den anschien als hat sich der RLE Algorithmus mal geändert.

[Quiche Lorraine]

@D_Key sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Nein, ich habe Zeiger im Variant abgelegt.

Warum das denn?

Mich würde da mal den Code interresieren.

[D_Key]

@Quiche-Lorraine sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Warum das denn?

Das weiß ich nicht mehre genau, weshalb ich das gemacht habe.
Ich komme ja nicht aus der Spielteewicklung das ist eine andere Abstraktionsebene als DSP.
Anfangs bin ich ich ziemlich im Dunkeln getappt, weil ich die Objektorientierung bzw Vererbung nicht hin bekomme habe.
Z.b gibt es Charaktere , Freeze, Firen, Bandit usw.. Da dachte ich, klar machst alt genauso so die einzelnen Klassen.
Bin dann aber dahinter gekommen, dass wird Murks, weil jeder Freeze, Firen, Bandit ist ein Charakter.
Class Charakter erbt von class LivingObject. Wobei LivingObject die Volumenbereiche bereitstellt und auch die Positionen im Textur-atlas angibt. LivingObject ist die Basis Klasse für alle GameObjecte.

Das zumindest was die C++ Problematik an geht. Die PS2 hat mich dann noch mal ganz anders gef***...
Das Makefile für den ganze code schreiben ..eine Geburt
Der Vektor Assembler war anfangs furchtbar.
Die Alpha blending Einstellung um das Schwarz heraus zu rechen, bin bald ausgerastet.

Und neben bei, ich habe ich mal Serversteiges Programmierern gelernt ... PHP, Perl, Java und JavaScript.
Durch ein Hobby Bastler-Treffen bin ich eher unfreiwillig in die Mikrocontroller Programmierung gerutscht.
Die DSP Kenntnisse hat ich schon von anfang an, weil ich sehr viel mit Audio Streaming und Resampling bzw Audio Kompression zu tun hatte. Durch die DSP Vorkenntnisse bin ich erst mit den Jungs da in Verbindung getreten.

@Quiche-Lorraine sagte in 8-Bit RLE Bitmap wird nicht richtig geladen.:

Mich würde da mal den Code interresieren.

Sorry aber nee, ich habe den Variant jetzt verbannt. Zudem Starte ich meinn Programmier PC heute nicht mehr.

Mich würde viele mehr interessiere ob hardwarespezifische Frage zum Rendern auf der PS2 stellen kann?
z.B beeinflusst das Z-Bufferign mein Alpha Blending, Ich kann mich hinter Transparenten Flächen verstecken (wozu ist die Fläche den transparent).
Oder aber hätte ich gerne einen Framebuffer von 800x600 groß ist und ein Screen Config von 1280 zu 720 sprich 720p.
Wenn ich das mache ist das Bild nach unten Rechts verschoben es muss aber Technisch möglich sein, da der kleinerer Framebuffer auf das ganzen Fernseher "gezogen" wird.