Zukunft um BB?!?

Übersicht Sonstiges Smalltalk

Gehe zu Seite Zurück  1, 2

Neue Antwort erstellen

hamZta

Administrator

BeitragSa, Apr 05, 2008 0:19
Antworten mit Zitat
Benutzer-Profile anzeigen
Xaron hat Folgendes geschrieben:
Außerdem ist OOP für Spiele nicht unbedingt der geeignetste Ansatz.


Ich kann mir irgendwie nicht ganz erklären wieso OOP für Spiele nicht sehr geeignet sein soll? Bring doch mal ein Beispiel, wo du ein anderes Konzept OOP vorziehen würdest.

hamZta
Blog.

ProfJake

ehemals "DTC" / "Fabian Niemann"

BeitragDo, Apr 10, 2008 17:17
Antworten mit Zitat
Benutzer-Profile anzeigen
Schade, dass du nicht antwortest Xaron, mich interessiert wirklich was für eine Technik besser geeignet wäre,
obwohl ich OOP total super finde.

Abrexxes

BeitragFr, Apr 11, 2008 14:10
Antworten mit Zitat
Benutzer-Profile anzeigen
Xaron hat Folgendes geschrieben:
Außerdem ist OOP für Spiele nicht unbedingt der geeignetste Ansatz.


Quatsch. OOP ist keine Erfindung Gottes und auch keine Zauberei. Es ist lediglich eine HILFE die sich aus der Entwicklung von C zu Cpp als sehr effektiv zeigte. Aus diesem Grund bieten viele aktuellen Sprachen OOP was das arbeiten an komplexen Code erleichtert, jedoch nicht zwingend nötig ist.

ABER : OOP kostet Zeit, was auf einem XGhz PC keine Rolle spielen muss kann kleinen Systemen das Genick brechen. Um also Basiscode (Engines) zu entwickeln wird oft kein OOP benutzt um nicht schon beim Unterbau eines Programms Zeit zu verschwenden. Wer zb eine NDS Engine mit vielen Objekten und Klassen mit OOP aufbaut kann sich sicher sein das die Engine nichts taugt da schon ein Tetris den DS kaltstellen wird. Ist eine Engine hingegen in C geschrieben und weitestgehend optimiert (kein OOP/ ASM an relevanten Stellen) dann wäre es für den Anwender der Engine Selbstmord grössere Projekte ohne OOP anzugehen.

Also bitte Informieren was OOP eigentlich ist und bewirkt. Das da ist eine Aussage wie "Keine Ahnung was eine Apfel oder eine Birne ist, aber eines muss schlechter sein".

cu
 

Dreamora

BeitragFr, Apr 11, 2008 23:46
Antworten mit Zitat
Benutzer-Profile anzeigen
bei den heutigen compilern ist super optimierter C Code noch einige wenige Prozent schneller als C++ code.
der mythos das OO viel langsamer oder überhaupt langsamer sein soll als prozedural entstammt der tatsache das viele ganz einfach mit C++ nicht effizient programmieren können und das programm vorsätzlich verlangsamen indem sie argumente falsch übergeben (objekte so übergeben das sie kopiert werden und solche spässe) und so zb

Eiffel zb ist high end OO und ist mindestens so schnell wie jedes C. warum? es hat keinen eigenen compiler, der precompiler generiert C code draus welcher dann von den plattform eigenen highend compilern zu programmen gemacht werden.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Abrexxes

BeitragSa, Apr 12, 2008 0:45
Antworten mit Zitat
Benutzer-Profile anzeigen
Schenk mir einen Stern *

* = löschen

TheShadow

Moderator

BeitragSa, Apr 12, 2008 10:24
Antworten mit Zitat
Benutzer-Profile anzeigen
Zitat:
der mythos das OO viel langsamer oder überhaupt langsamer sein soll als prozedural entstammt der tatsache das viele ganz einfach mit C++ nicht effizient programmieren können und das programm vorsätzlich verlangsamen indem sie argumente falsch übergeben (objekte so übergeben das sie kopiert werden und solche spässe)


Na hallo - in C++ ist oft nix anderes möglich

void foo(const rect& r)
Also dort wo const mit Referenz steht wird ein Objekt kopiert...

Der Aufruf würde dann etwa so aussehen
foo(rect(100,200));

Sag mir eine c++ Library wo das nicht der Fall ist

Nahezu alle großen Libs machen es so: wxWidgets, Irrlicht... und sag blos nicht die Coder von Irrlicht haben nicht effizient Programmiert - sowas wäre bei 3D-Engine ziemlich schwachsinnig

Code: [AUSKLAPPEN]
virtual void    draw2DImage (const video::ITexture *texture, const core::position2d< s32 > &pos, const core::array< core::rect< s32 > > &sourceRects, const core::array< s32 > &indices, s32 kerningWidth=0, const core::rect< s32 > *clipRect=0, SColor color=SColor(255, 255, 255, 255), bool useAlphaChannelOfTexture=false)=0


ich zähle mal wieviele Objekte hier kopiert oder on the fly generiert werden:
1:const core::position2d< s32 > &pos
2:const core::array< core::rect< s32 > > &sourceRects
3:const core::array< s32 > &indices
4:SColor color=SColor(255, 255, 255, 255)
AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

Xaron

BeitragSo, Apr 13, 2008 9:26
Antworten mit Zitat
Benutzer-Profile anzeigen
Du liebe Güte, da hab ich ja was losgetreten. Ich muss immer wieder schmunzeln, wenn ich lese, wie wenig Ahnung ich hab. *gg*

Mir ging's nicht um die Geschwindigkeit. Die Unterschiede sind nicht mehr erwähnenswert.

Mir ging's um das Konzept an sich. OOP ist halt der letzte Schrei (seit ein paar Jahren). Das heisst aber nicht, dass es auch optimal für alle Anwendungszwecke ist. Auch prozedural kann man durchaus schön programmieren, für Spiele ist das vom Aufbau durchaus sinnvoll. Wink Natürlich hat auch OOP für Spiele Vorteile, da muss man halt abwägen.

Ich wollte nur mal zum Nachdenken anregen, mal über den Tellerrand zu schauen.

Im übrigen, Abrexxes, weiß ich was OOP ist, glaub mir.

Gruß - Xaron
Cerberus X - Monkey X Reloaded!

FreetimeCoder

BeitragSo, Apr 13, 2008 10:54
Antworten mit Zitat
Benutzer-Profile anzeigen
Also, um mal wieder zum Thema zurückzukommen: Ich empfehle dir Bmax + MiniB3D.
Für mich ist das inzwischen ein besseres B3D geworden.

Das C++ dir zu schwer vorkommt kann ich gut nachvollziehen, bei mir wars genau so. Als erstes hab ich mir B3D gekauft. Ich finde es nach wie vor für Einsteiger ganz schön, aber inzwischen empfehle ich doch Bmax, einfach wegen der Plattformunabhängigkeit, den Modulen, weil man selbst bestimmen kann wie "strict" man programmieren will und natürlich OOP Wink

Inzwischen bin ich auch auf dem weg zu C++, aber dir als blutiger Anfänger rate ich dir davon ab, nimm Bmax Wink
Allerdings, ein kleinen Vorteil hat BB: Die Demo ist zeitlich unbegrenzt. Eventuell sollteste dir die erstmal anschauen und gucken ob Programmieren was für dich ist. Wenn du dich entscheidest dabei zu bleiben sollteste dir gleich Bmax kaufen. Das ist zwar eine Umgewöhnung, aber es lohnt sich.

MfG
FTC
"Wir haben keine Chance, aber wir werden sie nutzen!"
Projekte:
Dexterity Ball (100%)
Aquatic Atmosfear (22 % ca 4700 Zeilen) eingefrohren mangels OOP Fähigkeiten von Blitz
(ehemals Uboot)
PC: Intel D 3 GHz | NVidiaGforce 6700 256 Mb | 1024 Mb DDR RAM 400 Mhz | 2x160 GB S-ATA

Tankbuster

BeitragSo, Apr 13, 2008 11:18
Antworten mit Zitat
Benutzer-Profile anzeigen
Da hätte ich jetzt mal ne persönliche Frage:

Ich fange gerade mit einem neuen Projekt an (B3D)
Aber wenn Blitzmax+Mini B3D so toll sein sollen, würde es nicht vielmehr Sinn machen, dass ich mir BMAX zulege und alles darin mache?

Ich will mal eure Meinung hören. Das dumme wäre nur, dass ich sicherlich ein bisschen brauch, um mit Max zurechtzukommen. Und sicherlich würde B3D auch reichen, da ich noch ziemlich lang brauchen werde um wirklich alle Möglichkeiten auszuschöpfen.

ABER:
Wenn B3D irgendwann total veraltet ist (und Grakas DX7 garnichtmehr unterstützen x) ), müsste ich den kompletten Code des Projekts in eine andere Sprache (z.b. Bmax) umschreiben. Das würde sicher lang dauern und ziemlich viele Probleme mit sich bringen. Außerdem ist die Plattform-Unabhängigkeit sicherlich auch was schönes.

Also:
Eure Meinung sei gefragt ^.^
Twitter
Download Jewel Snake!
Windows|Android

BladeRunner

Moderator

BeitragSo, Apr 13, 2008 12:16
Antworten mit Zitat
Benutzer-Profile anzeigen
Ich mab Bmax sehr, auch wenn ich nicht mit 3D arbeite. Aber was man hört ist kleptos minib3d schon recht weit fortgeschritten und dennoch easy-to-use.
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI

Stolzer Gewinner des BAC#48, #52 & #92

Gehe zu Seite Zurück  1, 2

Neue Antwort erstellen


Übersicht Sonstiges Smalltalk

Gehe zu:

Powered by phpBB © 2001 - 2006, phpBB Group