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!

Alternative zu Event-System?

Werbeanzeige

.:!Batzer!:.

Alter Hase

  • ».:!Batzer!:.« ist der Autor dieses Themas

Beiträge: 610

  • Private Nachricht senden

1

22.11.2010, 21:52

Alternative zu Event-System?

Hi Leute,

ich wollte mal mein Framework etwas ausbauen und da habe ich daran gedacht das Eventsystem zu ersetzen,
weil in dem dazugehörigen Thread das ein oder andere Geschmunzel deswegen kam.
Ich habe mich damals dafür entschieden, weil die SFML es auch so macht.
Was würdet ihr als "besser" empfinden und was ist daran besser?

btw. Ich habe mich damals für diese Lösung entschieden, weil ich mehr Kontrolle über das Fenster haben wollte.
z.B. Wann es geschlossen wird oder was passiert wenn die Maus das Fenster verlässt/betritt. (eben wie bei der SFML)

greetz Batzer

idontknow

unregistriert

2

22.11.2010, 22:21

Zitat von ».:!Batzer!:.«


Was würdet ihr als "besser" empfinden und was ist daran besser?


Nen Callback basierendes Event-System wäre wohl eine der besten Lößungen (hab ich mal für mein Fenster Input so gemacht. Ist dann leider nicht mehr ganz so simpel mit dem überprüfen einer gedrückten Taste weil du dafür dann 2 Methoden/Funktionen brauchst).

Funktioniert im Prinzip so, dass du jeder Taste einen Liste zuordnest, die Callbacks enthält bzw. in der Regel nen Dellegate also ein Objekt und einen Methoden Zeiger auf die entsprechende Methode des Objekts (der Klasse). Das ganze machst du für Key Pressed und Released und rufst die Methoden der entsprechenden Liste auf, wenn das entsprechende Event vom Fenster kommt!!

Der Vorteil ist einfach, dass es (ohne mich jetzt zu weit aus dem Fenster zu lehnen) die schnellste Lößung ist weil einfach jeder Aufruf nur dann ausgeführt wird, wenn du die entsprechende Taste drückst. Nachteil ist natürlich, dass du etwas mehr "Schreibarbeit" hast.

FalkT

Treue Seele

Beiträge: 125

Wohnort: AC

  • Private Nachricht senden

3

23.11.2010, 16:56

Könntest du mal erläutern, was du primär erreichen willst.
Was sind deine genauen Anforderungen ?

Ich habe ein eigenes EventSystem für unser Projekt entwickelt, da es am gesamten OpenSource-Markt nichts gab, was unseren Anforderungen entspricht.
Dazu zählt beispielsweise boost::signals, boost::asio, sdl-events, QT-Events, wxEvents.
Unsere Killer-Requirements sind meistens "Performant und Threadsafe". Threadsafe heißt in diesem Kontekt mehr als nur "reentrant".

Für die QT-Kenner unter euch sei angemerkt, sowas wie

C-/C++-Quelltext

 
1

emit BlubEvent(myData);

ist dank des MOC-Compilers sehr einfach/angenehm zu verwenden. Meine/unsere Anforderungen verbieten aber jede Art von Präcompiler.

Greetz

xardias

Community-Fossil

Beiträge: 2 731

Wohnort: Santa Clara, CA

Beruf: Software Engineer

  • Private Nachricht senden

4

23.11.2010, 19:44

Boost::Signals2 ist ein sehr schönes (Threadsicheres) Eventsystem, vielleicht behebt das ja deine Probleme mit dem Eventsystem.

http://www.boost.org/doc/libs/1_45_0/doc/html/signals2.html

FalkT

Treue Seele

Beiträge: 125

Wohnort: AC

  • Private Nachricht senden

5

24.11.2010, 17:21

Zitat von »xardias«

Boost::Signals2 ist ein sehr schönes (Threadsicheres) Eventsystem, vielleicht behebt das ja deine Probleme mit dem Eventsystem.

http://www.boost.org/doc/libs/1_45_0/doc/html/signals2.html
Soweit ich weiß werden die Empfänger immer noch synchron beim Emittieren des signals aufgerufen.
Bedeutet zum einen man muss die Empfangsfunktion mindestens reentrant machen. Das verschmutzt auch einen Großteil der Business-Logik mit thread-code.

.:!Batzer!:.

Alter Hase

  • ».:!Batzer!:.« ist der Autor dieses Themas

Beiträge: 610

  • Private Nachricht senden

6

24.11.2010, 20:51

@FalkT
Also meine Anforderungen ist, dass das System vorallem einfach sein sollte.
Es sollte auch schnell sein, aber ohne die Einfachheit zu verletzen.

@idontknow
Hört sich schon mal ganz gut an, aber wäre dann doch etwas zu umständlich das zu benutzen.

qwertzui11

Treue Seele

Beiträge: 340

  • Private Nachricht senden

7

25.11.2010, 10:46

kann

C-/C++-Quelltext

 
1

boost::signals2

schwer empfehlen.
Für Asyncrones Eventhandling

C-/C++-Quelltext

 
1

boost::signals2

in kombination mit

C-/C++-Quelltext

 
1

boost::asio


Qt Signals hab ich anfangs auch gerne verwendet, allerdings schränken diese stark ein:
Multible Klassenvererbung begrenzt möglich
!!!KEINE templates!!!
Generell auch neue Datentypen in qt signals einzupflegen ist zwar möglich aber nicht sehr schön.

was mir bei boost auch recht gut gefällt ist, dass man die Rückgabewerte der aufgerufenen Signals verproben kann.
http://www.boost.org/doc/libs/1_45_0/doc….html#id2538877
Auch gut gefällt mir ist das boost::bind. Wenn man sich mal damit genauer auseinander gesetzt hat ist es in Kombination mit den oberen libs eine mächtige Funktion, die einem vieles erleichtert.

Mein Fazit:
Für GUI-Apllikationen und für Programmierer die in Cpp noch nicht so fest im Sattel sitzen reichen qt signals. Geht schneller von der hand und der Code ist für einen selbst und für andere viel leichter zu lesen.
Bei allem anderem (besonders Spiele) nehm ich boost

Gruss
Markus
http://blub-game.com/logo/blubgame_logo.png

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »qwertzui11« (25.11.2010, 10:56)

Werbeanzeige

Ähnliche Themen