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

11

29.11.2012, 21:16

Wenn du so fragst habe ich den Verdacht, dass es der Destruktor sein müsste^^
Das Programm wird dadurch aber nicht wesentlich beschleunigt, wenn ich den Speicher wieder freigebe oder?
Es werden ja unter der Laufzeit keine Destruktoren aufgerufen...
Bilder zu meinem Projekt: ParSim

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

12

29.11.2012, 21:26

Ja, es ist in dem Fall der Destuktor.

Wo kommen wir denn hin, wenn wir nur noch Dinge einprogrammieren, die unser Programm wesentlich beschleunigen?

13

29.11.2012, 21:34

Jetzt bin ich aber gespannt. :D
100k Partikel auf dem Laptop mit 80FpS hatten mich schon umgehauen :D
Bilder zu meinem Projekt: ParSim

Beiträge: 1 223

Wohnort: Deutschland Bayern

Beruf: Schüler

  • Private Nachricht senden

14

29.11.2012, 21:50

Ich weiß nicht wie du das interpretiert hast.
Ich meinte auf jeden Fall, dass es unsinnig ist, bei jedem und allem immer einen Performancevorteil zu erwarten.
Einen Geschwindigkeitsvorteil hast du dadurch nämlich hundertprozentig nicht.

Das Problem ist nur, dass wenn jeder seine Anwendung so programmieren würde wie du (also ohne Speicherfreigabe), dann wäre nach dem Booten wahrscheinlich der RAM aus, bevor die Desktopoberfläche erscheinen kann. :fie:

15

01.12.2012, 17:16

Hi,
ich bin jetzt doch bei VSC++12 gelandet. Mit den Nightly Builds von eXpl0it3r.

Ich kann nicht so viele Partikel rendern wie bei c# :thumbdown:
Momentan lauft die Grafik in der Hauptschleife den Klient-Thread. (Ein weiterer Thread macht die Partikelsimulation.)

C-/C++-Quelltext

1
2
3
4
5
6
7
8
rectangle.setSize(sf::Vector2f(1,1));//immergleiches design
rectangle.setOutlineThickness(0);

for (int i = 0; i<particleMaximum;i++)
{
        rectangle.setPosition(engine.accessor.particleProvider.particle[i].pos);
        window.draw(rectangle);
}


particleMaximum ist 100.000. Soviele Shapes bremsen alles aus :pinch:
Ware es besser statt dem SFML RenderWindow und SFML Shapes auf OpenGL umzusteigen?
Sollte ich alles das an die GPU abgeben? Auch wenn ich die Partikelsimulation später über die GPU machen will?

LG
Bilder zu meinem Projekt: ParSim

TrommlBomml

Community-Fossil

Beiträge: 2 117

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

16

01.12.2012, 17:42

Als performantere Alternative zu SFML kann ich dir Haafs Game Engine empfehlen!

17

02.12.2012, 12:07

Oh nein nicht schon wieder umsteigen, jetzt wo SFML läuft. :D
Ich mach mich mal an SFML- OpenGL...
Oder keine Chance das das was bringt?
Strings kann man mit OpenGL anscheinend nicht so gut zeichnen...

Falls es damit nicht geht dann probier ich mal HGE...

LG
Bilder zu meinem Projekt: ParSim

18

02.12.2012, 17:57

Mit OpenGL geht es richtig schnell :love: Ist eig. auch einfach.

Strings / Texte ist nur auf Umwegen, über eine Große, richtig zurechtgerückte und geschnittene Textur möglich. Da musste ich erst ne Funktion machen^^
Aber es geht! Und die Menüs und Buttons gehen auch.

Und vor allem sind die Partikel smooth und etwas transparent :D

(Zwei Quadrate, eins kommt von oben, eins von unten, beide von klebriger Konsistenz)
Bilder zu meinem Projekt: ParSim

19

07.12.2012, 16:05

Par Sachen sind verbessert:

Der Editor ermöglich verschiedene Materialen und unterschiedlich große Pinsel zu verwenden. Die Materialien unterscheiden sich bisher nur in Farbe und Beschleunigung zu Anfang der Simulation. So kann man alles crashen lassen.

Die Bildschirmauflösung wird ermittelt und das Spiel in vollbild ausgeführt, egal ob breitbild- oder- normaler Monitor.

Bis aus den Partikeln Maschinen angefertigt werden die steuerbar sind und bewaffnet dauert es aber noch bisschen. Unterstützer sind gerne willkommen.

Damit ist etwa der Stand erreicht den ich mit C# hatte, bevor ich auf C++ gewechselt habe. Die C++ Variante schafft 3x soviele Partikel wie die C# in Ectzeit.

Bilder zu meinem Projekt: ParSim

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Horus« (07.12.2012, 16:17)


20

18.12.2012, 13:38

So langsam wird es interessant.

Es gibt jetzt ein Material dass wie Sprengstoff ist XD

Außerdem können Partikel Eigenschaften wie wärme "leiten"

Ich mach par Bilder hier rein :thumbsup:

Das rote ist Feuer, das Gelbe Sprengstoff. Der blaue Block links fliegt gemächlich nach rechts. Er ist aus wärme leitendem Material.


Ist die Simulation gestartet geht der Sprengstoff hoch.


Am Ende der Zündschnur hängt die dicke Bombe :D


Ist die Wärmebildkamera aktiviert sieht man die Erwärmung des blauen Blockes. Das feuer ist kurzlebig, die Partikel verschwinden.


In dem großen Block verteilt sich die Wärme, die abgeplatzten trümmer bleiben heiß. Wenn sie auf Sprengstoff treffen, geht der hoch...



Die schwierigsten Hindernisse auf dem Weg zum fertigen Spiel sind erstmal geschafft :D

Momentan arbeiten wir zu zweit an dem Projekt, mit vc++2010. Wer Lust hat einzusteigen kann sich gerne melden. ;) Wir brauchen mehr materialien, eine Funktion zum Speichern, einen besseren Editor, bessere Partikelverwaltung beim Mutiprocessing. Ist für einsteiger und Fortgeschrittene was dabei.

LG
Bilder zu meinem Projekt: ParSim

Werbeanzeige