Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

21

04.12.2013, 21:51

Mehr Aufwand in wie fern? Mehr CPU-Leistung wohl kaum.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

22

04.12.2013, 21:51

Wenn deine Formen relativ "regulär" sind, empfiehlt es sich sie mit Hilfe von Polygonen zu modellieren. Dann kannst du eine Physik-Engine wie Box2D benutzen, um die Kollisionen zu erkennen und darauf zu reagieren.

Mehr Aufwand in wie fern? Mehr CPU-Leistung wohl kaum.

Na doch. Es sei denn du berechnest die Maps im Voraus für "jede" Kombination aus Skalierung und Rotationswinkel. Das würde aber wiederum auf den Speicher gehen.

23

04.12.2013, 22:01

Mit Aufwand meinte ich eigentlich den zeitlichen und intellektuellen aufwand des Programmierers, um das ganze selbst umzusetzen.

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

24

04.12.2013, 22:09

Es wäre aber auch mehr Arbeit für die CPU.
Dadurch braucht man für jedes Pixel einige Fließkommaoperationen.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

25

04.12.2013, 22:12

Na doch. Es sei denn du berechnest die Maps im Voraus für "jede" Kombination aus Skalierung und Rotationswinkel. Das würde aber wiederum auf den Speicher gehen.
Bitte? Ob nun SDL einen Rotozoom auf ein 32-Bit-Surface macht oder man selbst auf eine 8-Bit-Maske dürfte schon einem Unterschied machen. Aber keinen positiven für SDL. Es wird eh beides auf der CPU gemacht!
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

26

04.12.2013, 22:23

Wenn man SDL_gfx benutzt, ja, dann macht es keinen Unterschied.
Aber wer macht sowas heute schon noch? Die meisten Leute benutzen SDL doch nur, um Bilder zu laden, ein Fenster zu erzeugen, Input abzufragen usw. und rendern dann mit OpenGL.

27

04.12.2013, 22:44

Also ich benutze das immer noch -parallel zu OpenGL- eben für die Pixelgenaue Kollisionsprüfung. SDL_gfx ist zwar nicht superduperschnell, aber man braucht die Surface ja nicht ständig neu berechnen, sondern nur für den kurzen Moment einer potentiell möglichen Kollision. Und da fällt das performancemäßig so gut wie garnicht auf. Aber stimmt schon, damit ich bin womöglich der einzige, der noch SDL_gfx benutzt. :)

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

28

05.12.2013, 06:41

Aber wer macht sowas heute schon noch?
Genau darum ging es doch aber.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Volker_Neff

Treue Seele

  • »Volker_Neff« ist der Autor dieses Themas

Beiträge: 249

Wohnort: Hamburg

  • Private Nachricht senden

29

05.12.2013, 11:59

Danke erst einmal!

Ich werde erst einmal auf jeden fall keine gedrehten Modelle verwenden.

Trotzdem komme ich noch nicht ganz so weiter. :( Und zwar fehlen mir zwei Sachen. Zum ersten was genau ist ein Bitarray und vor allem wie kann ich es erstellen? Entweder suche ich nach dem Falschen oder ich mir fehlt der Anhaltspunkt. Die zweite Sache ist, was genau ist ein Void* bzw. wie sagt der mir welches Pixel welchen Alpha wert hat?
Ich stehe grade total auf dem Schlauch.

Noch einmal vielen, vielen Dank

Architekt

Community-Fossil

Beiträge: 2 481

Wohnort: Hamburg

Beruf: Student

  • Private Nachricht senden

30

05.12.2013, 12:33

Ein void Zeiger ist ein typloser Zeiger. Jeder Zeiger kann implizit zu einem void* werden. Was du machen musst, ist diesen zu einem uint* zu casten und dann jeweils die R, G, B und A Werte auszulesen.

Kleines Beispiel, auch wenn ich es besorgniserregend finde, dass du mit einem void* überfordert bist. Eventuell fehlen da noch einige Grundlagen.

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
int getPixelAt(SDL_Surface* srfc, short x, short y) {
    uint* pixels = static_cast<uint*>(srfc->pixels);

    return pixels[(y * srfc->w) + x];
}

/// ...

int pixel = getPixelAt(your_surface, x, y);

ubyte r, g, b, a;
SDL_GetRGBA(pixel, your_surface->format, &r, &g, &b, &a);


Nur als Beispiel, ist kein 100% valider C++ Code da ich mich seit Ewigkeiten nicht wirklich mit C++ beschäftigt habe.
Der einfachste Weg eine Kopie zu entfernen ist sie zu löschen.
- Stephan Schmidt -

Werbeanzeige