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

1

31.03.2005, 01:13

wieviel interface braucht der mensch?

hey leuts,

sagt mal wie viel interface würdet ihr eurer
engine gönnen?

eher minimalistisch oder eher flexibel?

gruß 23h

2

31.03.2005, 02:46

ps: fenster & windowproc mit in die engine stecken oder außerhalb lassen?

Sicaine

unregistriert

3

31.03.2005, 03:02

Hier stellt sich grundlegend die Frage wie weit deine "Engine" gehen soll.

Soll sie Ingsesamt wirklich alles übernehmen können wie zb. die Unrealengine mit Editor etc. Scriptsprache oder soll sie nur minimalistischst sein also Ressourcenmanagment etc.

Wobei ich mich hier frag obs da irgendwo ne festgelegte bestimmung gibt, was ne Engine min. haben muss und max. haben darf damit es Engine heißt.

weigo

Treue Seele

Beiträge: 234

Wohnort: Deutschland

  • Private Nachricht senden

4

31.03.2005, 08:51

Juhu, endlich mal wieder ein interessantes Thema hier im Forum:

Ich nutze in meiner Engine sehr viele Interfaces, da ich die Engine Plattform unabhängig programmiere.
Es spielt eigentlich keine Rolle, ob du viele oder wenige Interfaces machst.
Das kommt im Endeffekt auf die Engine an.
Bei vielen Abstraktionen, wie in meinem Fall, braucht man viele Interfaces,
aber wie Sicaine schon gesagt hat, braucht man bei einer einfachen Engine wahrscheinlich weniger.

Zitat


fenster & windowproc mit in die engine stecken oder außerhalb lassen?

Darüber habe ich mir auch lange Gedanken gemacht. Da ich meine Engine Benutzerfreundlich machen will, habe ich im Moment eine Version in der Engine, die man aber durch eine XML Datei initialisieren kann ( evtl. mach ich das noch mit Lua ). Man kann natürlich die Methode einfach neu implementieren und seine eigene Version schreiben.

5

31.03.2005, 14:56

mit interfaces meinte ich natürlich nur interfaces
nach außen.

die würde ich halt spontan recht sporadisch halten.
ich frag mich nur ob es eventuell sinnvoll wäre
einiges der funktionen und klassen die so als utilities
innerhalb der engine anfallen auch nach außen
anzubieten, falls sie einigermaßen nützlich wären.
z.b. mathematisches zeugs

die engine die ich grad bau soll nicht sehr allgemein gehalten sein
und wird wahrscheinl. auch niemals von jemand anders
als mir verwendet werden.
daher sieht mein interface im mom nur das nötigste vor:

- laden von geometrie
- laden von texturen
- definieren von entities (geometrie + textur + X)
- laden von schrift
- laden eines levels (besondere geometrie)
- instanzieren/löschen von entities
- platzieren von lichtquellen
- kollisionsabfrage routinen
- positionieren von entities & co.
- platzieren der camera

is halt jetzt auch die frage wie weit man das noch aufbohren muss
um leveleditor funktionalität, damit mein ich vor allem
editieren der level-geometrie,
realisieren zu können.

shader & materials seh ich im mom gar nicht vor, da ich das fest in der engine
verdrahten werde.
natürlich gibts innerhalb eine klasse für shader die shader aus dateien
laden kann oder aus arrays, diese wird aber nicht nach außen
angeboten, noch kann man die engine ohne neucompilieren
mit neuen shadern ergänzen.

ich denke für mein projekt ist das ausreichend und auch ein stück weit
einfacher als eine zu starke generalisierung.

kommentar plz. :=)

6

31.03.2005, 15:02

ps:

wegen window & wproc in der engine oder nicht.
nur mal so spontan ne frage.
wie würdet ihr diese 2 modelle realisieren.?
für window außerhalb der engine fällt mir nur ein,
eine funktion der engine (z.B. render()) einmal pro zyklus
aufzurufen:

C-/C++-Quelltext

1
2
3
4
while(1){
 if (PeekMessage(------));
 engine->render();
}


und für die methode window in engine käme mir nur eine callback
funktion in den sinn:

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
void gamecallback(){
}

engine->setCallBack(&gamecallback);


winmain(){

engine->run();
return 0;
}


hättet ihr ne andere idee wie man das machen könnte?
bzw. weigo kannst du mal deine xml-lösung näher erläutern?

ti äitsh ex ^^

weigo

Treue Seele

Beiträge: 234

Wohnort: Deutschland

  • Private Nachricht senden

7

31.03.2005, 15:21

Ich nehme auch nicht an das meine Engine mal von jemand anderem benutzt wird.

Ich habe eine extra Support DLL, die alle Interfaces exportiert. Damit man Logging usw. auch direkt im Spiel verwenden kann und nicht etwa den gleichen Kram doppelt Implementieren muss.

XML Technik:
Ich habe eine Application Klasse, diese wird als Basisklasse für die Game Application dienen. In der Klasse gibt es eine Init() Methode, die z.B. das Fenster erzeugt. Da man von außen keinen Zugriff mehr auf die Initialisierung hat, außer man überschreibt die Methode und implementiert die Initialisierung neu, habe ich eine ApplicationSerializer Klasse. Diese ist von einer XMLSerializer Klasse abgeleitet und kann XML Dateien parsen.
Eine application.xml würde dann Informationen enthalten wie, Fenster Größe, Position, Vollbild usw.
Die Werte aus der XML Datei werden dann in der Initialisierungsmethode benutzt, dazu muss man ein ApplicationSerializer Objekt der Application übergeben. Zum Parsen von XML Dateien verwende ich libxml2.

Durch dieses Daten Driven Design ist es sehr praktisch verschiede Einstellungsmöglichkeiten zu testen ohne jedes Mal die Anwendung oder gar das Subsystem neu kompilieren zu müssen. Das ganze habe ich dann auch für States, Renderer usw. ( teilweise geplant, da ich erst seit drei Monaten oder so an der Engine arbeite und nur wenig Zeit dafür habe ).

Dave

Alter Hase

Beiträge: 757

Wohnort: Berlin

  • Private Nachricht senden

8

31.03.2005, 20:12

so ähnlich handhabe ich das auch. habe eine application-config-klasse, welche die einstellungen aus einer xml-datei laden kann...

Werbeanzeige