Die Signatur passt wie die Faust aufs Auge... Borland-Verfolgungswahn...

shielding people from their own stupidity is an evolutionary step backwards anyway.

/* God is dead!............Nietzsche */
/* Nietzsche is dead!......God */
/* Nietzsche is God!.......The Dead */

ok...

1. alle die mitmachen wollen müssen mit unserem schon vorhandenen system leben. (is nicht soooo gewöhnungsbedürftig) ;)

ich will aber schwarze schafe ausschiessen wo ich auch gleich zu 2. wechsel:

der sourcecode wird freigegeben wenn sich erweist das derjenige wirklich lust hat mitzumachen und nicht auf einmal keinen bock mehr hat aber die engine schon auf der platte. (währe sehr unfair). zudem wird das spiel nicht mehr opensource nach fertigung sein (wegen cheats) und auch nicht sooo derbst angreifbar sein wie beispielsweise halflife (ports um beispielsweise nen irc-report zu machen) =).

3. keine "ich verbrauch zwar 90% der engineleistung aber sehe dafür geil aus" effekte... =)

4. komplette beteildigung am erfolg (falls irgendwann mal vorhanden *GGG*) ich gehe einfach mal frech davon aus das das projekt fertig wird.

wie ich mich kenne werde ich manche regeln sowieso wieder weglassen und sehe alles nicht so hart wie ich es geschrieben habe. kein programmierer wird als sklave gehandhabt. ich will endlich mal ein spiel was mich nicht endlos annervt weil manche spielerischen features fehlen. ich schrecke nicht davor zurück die engine zu kastrieren um mehr einheiten auf dem bildschirm sehen zu können (LOD ist mitbedacht *fg*)

SPIELSPASS FIRST =)

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Lol!

Jemand der bezweifelt, man könne ein Betriebssystem in C schreiben (wo doch C erfunden wurde, um ein Betriebssystem zu schreiben) hält sich in der Lage, ein Programm cheatsicher zu machen. Gute Nacht.

1. Einmal Opensource, immer Opensource. Wenn sich die Copyrightholder einig sind können sie das Projekt zwar geschlossen weiterführen, aber die ganzen verwendeten Algorithmen in der Engine (u.a. auch für Netzwerkkodierung) liegen offen. Ihr müßtet riesige Teile nach der Schließung neu schreiben, um das Ganze sicher zu gestalten.

2. Die IRC-Reports bei Half-Life sind ein Feature, keine Sicherheitslücke (Valve wissen, was sie tun).

3. Half-Life ist _nicht_ leicht angreifbar. Es ist bloß leider so, daß die halbe Menschheit (naja, nicht ganz ;)) meint, Counter-Strike spielen zu müssen. Und bei so großer Nachfrage ist natürlich auch die Anzahl der Cheatautoren größer.
Die einzige wirklich dünne Stelle bei Half-Life ist das Interface zu den Mod-DLLs - das muß ja leider ziemlich weit offen liegen, und mit Hilfe eines Debuggers und einer selbstprogrammierten DLL ist es leicht zu finden; dann kann man es zur Laufzeit manipulieren, in dem man von außen auf den Speicherbereich von HL zugreift. Und diese Lücke zu schließen ist leider alles andere als einfach.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Ich bin absolut pro open source.

Nur nicht bei Games mit Multiplayer Modi.
Da könnt ihr gleich multiplayer cheats einbauen. Wenn du open source machst, liegt dein netzwerk protokoll offen, und es is nur noch ne frage der zeit...

because our freedom sits at the end of a gun
we're all here getting beat up and held back
we're all here digging knives from our backs

deswegen... und die zahlen (polycount) für fullscreen (bisher gemessen an einer sphere...

BISHER: 10000 @ 12 FPS (1050MHz, Gef2 GTS, ((512 MB)))

hmmm... ich denke das ist schonmal ein guter schnitt bisher... aber mal ne frage: wieviele polygone können spiele heutzutage eigentlich darstellen bai 30 FPS ? ich weiss bei Halflife sind das echt nicht viele... die texturen machen schon ne menge aus und die BSP verhindert das polygone die man nicht sehen kann weggelassen werden. (dafür habe ich noch nicht die technik raus.)

was schaffen eure engines oder tests bisher ?

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

10000 Polygone @ 12 fps ist schwach. Half-Life kann so 1500 wpolys + 10000+ epolys @ min. 25 fps auf 550Mhz, TNT2.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Hmm, seien wir ehrlich...
die alpha von u2 schafft auf nem halb so schnellen rechner, bei 9x so viel doppelt so viele frames.

und sogar mein towers of hanoi toppt das...

because our freedom sits at the end of a gun
we're all here getting beat up and held back
we're all here digging knives from our backs

@Prefect ich sprach von visual C++ und nicht von c

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

danke.. ich habe bereits erwähnt das wir noch viel zu optimieren haben. mipmapping ist nicht drin. jedes frame wird für alle polygone das licht berechnet und noch viel mehr

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Zitat:

CY4N1D3 postete
@Prefect ich sprach von visual C++ und nicht von c

Öhm... ich mag dich auch...

anyway

Visual C++ is nur ne IDE für nen C/C++ Compiler (auch wenn der verm$t wurde), genauso wie Delphi nur ne IDE für Object Pascal ist.

Du kannst (zumindest theorethisch) mit VC++ das selbe machen wie mit jedem ANSI C compiler...

because our freedom sits at the end of a gun
we're all here getting beat up and held back
we're all here digging knives from our backs

hmmm... ein bissl optimiert.

ergebniss 140000 Polygone pro sekunde... das suckt... ich brauche mind. ne mio. polys pro sekunde *grrr*...

ka ob mipmapping was bringen würde... habe landscape und 512x512 texturen... aber selbst bei niedrigeren texturen hab ich nicht mehr frames *hmpf*

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

hmm na na ich bin nicht wirklich davon überzeugt das Delphi nur ein wenig langsamer sein soll als C++ ... hmm naja wenn ihr das unbeding mit Delphi machen wollt was solls. Noch ein Tip Schau dir mal die Unreal2 Engine an :D, sind zum Teil 300.000 Ploygone in manchen Spielzenen und das soll mit Effekten .... dann auch noch flüssig laufen :D
Naja dass wurde hier bestimmt aber schon irgendwo genannt, also dann mal viel spaß mit eurem Spiel :D

Being in john Malkovich
.....

bei einer spielscene mit 300.000 poly's und einer framerate von 24FPS müssten das 7,2 mio. poly's pro sekunde sein..................

klingt wirklich etwas unreal aber ich glaube mal nicht wirklich das diese scene 300.000 polygone pro frame darstellt. das die scene im eigentlichen sinne soviele poly's hat mag ja stimmen aber da wurde sicher noch sehr stark mit LOD und co gearbeitet. aber 7,2 moi poly's / sek. währe ne reizvolle sache :)

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

kann dir nich folgen.

LOD hat an sich nix mit der polygonenanzahl zu tun. es wird die polygonenanzahl NACH dem lod'en, partikel hinzufügen etc gemessen. da verändert der LOD an sich auch nix mehr.

und viele polygone sind gerade für außenlandschaften und gegner wichtig, denn dort fallen sie auf.

because our freedom sits at the end of a gun
we're all here getting beat up and held back
we're all here digging knives from our backs

Man ich bin selber umgefallen als ich das gelsen habe, da sie dazu noch einen Vergleich gezeigt haben -> in der Unreal 1 engine sollen irgendwie durschnittlich 700 - 1000 Polies oder so ka wie viele genau(habe das Heft net hier) :
und in der Unreal 2 engine sollen durchschnittlich 100x so viele Polies sichtbar sein :D ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh :D
Wahrscheinlich haben die ne 1+1 Matrix entwickelt :D also GAME = 1+1 END;
ka was die da gemacht haben, aber die scheinen echt krank zu sein :D

Being in john Malkovich
.....

Hm....ich glaub da braucht sich Doom3 auch nicht verstecken...

BattleTech-MOD:
http://bthl.unitedgaming.net/

@blair, das ist richtig... war mein denkfehler.ich frag mich nur immer wie man das schaffen kann. ein wenig LOD spielereinen sind aber sicher noch mit drin... schau mal:

1. polygone die nahe dran sind haben ein hohes detail. weiter weg (alleine durch mipmaping) ein niedrigeres, sonst würde es pixelgeriesel geben. und: für polygone, die so weit weg sind, dass man texturen darauf nicht mal mehr sehen könnte, könnt man eigentlich doch auch die textur weglassen (einfarbige texturen, farbe geht aus durchschnitt von texturfarben)... :-/

2. z-buffer-sperre für sehr weit entfernte objekte ? wenn sie weit genug wegsind dann dürfte das nicht auffallen wenn ein object, das hinter einem anderen object steht, es trotzdem verdeckt :)

ausserdem noch fogendes. man sieht doch imemr bei 3D Mark 2001 den lichttest wo es bei 8 lichtern schon wie sau hakt (waren es 8 ?). warum läuft sowas in spielen immer viel flüssiger auch wenn mehr als 16 bewegliche lichter zu sehen sind. (weniger polygone ????). und licht hardware zu berechnen dürfte eigentlich mit dem Z-Buffer viel schneller gehen als zu fuss.

position des lichtes -> die entfernungen im z-buffer -> farbwerte addieren... *hmmm*

egal... viel mehr fällt mir dazu einfach nicht ein... sagt doch mal bitte etwas... bin so scheisse unkreativ in dem bereich :(

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Hei...

Kennt von euch einer PL1? Wohl kaum =)
Hm ich lern das mit 17 Jahren... habs schon fest im griff =)

Ihr dürft mich auch auslachen :D aber mein Geschäft (Credit Suisse) benutzt das immernoch :P hat doch style oder?

-=[ Aigu.ch ]=-

hm ich mag delphi auch absolut nicht... und naja ich finde eher nicht das pascal mit c mithalten kann da der syntax in c viel einfacher/ bzw. in pascal der umständlicher ist...

naja ok ich will halt nun im info unterricht nicht die ganze zeit dumm rumsitzen und im internet surfen...

deshalb will ich nun wissen wo es tut's über engine/3D in delphi gibt, bzw. welche CY4N1D3 benutzt hat... wenn möglich deutsch und sag jetzt nicht google suche... *G*

Nun ist deine Zeit gekommen sprach der Tod, stolperte und brach sich das Genick. :o

Zitat:
da der syntax in c viel einfacher/ bzw. in pascal der umständlicher ist...

-no comment-

btw: google suchen... wir haben im übrigen ber nicht tutorials nachgearmt... (das bringt einen nicht weiter) wir haben uns den scheiss selber rausgefummelt bzw. c übersetzt... gestestet, umgeschrieben, getestet usw. das hat immerhin einen lerneffekt *fg*

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

ja ich habs halt nicht mit der gramatik meno... *G*

Nun ist deine Zeit gekommen sprach der Tod, stolperte und brach sich das Genick. :o

ich auch nicht *fg*

nen kumpel sagt immer ich kann besser c/delphi als deutsch... also mich als programmierer stört es nicht weiter *fg*

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Hm, was klingt einfacher?

C/C++:
Quellcode:int x = 500;
int y[10];
Pascal:
Quellcode:VAR x : integer = 500;
VAR y : ARRAY [1..10] OF integer;
Also momentan würde ich auf C/C++ tippen, aber das wundert mich nicht. Pascal wurde als Lernsprache entwickelt, der Schüler soll also durch Pascal prozedurales Programmieren lernen, um dann mit einer Profisprache wie C/C++ weiterarbeitern zu können.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

oder warum?

Pascal:
Quellcode:
a:=2;
if NOT a = b;

anstatt
Quellcode:
a=2;
if (a != b)

oder warum immer END ist nicht } viel schöner?

aber das hilft mir bei meinem problem auch nicht umbedingt weiter... und so ne diskusion bringt eh nix da niemand von c/pacal zum anderen wechseln will...

also wo tut's?

Nun ist deine Zeit gekommen sprach der Tod, stolperte und brach sich das Genick. :o

zum einen kann ich beides. aber borland delphi macht mir die arbeit einfach leichter und ich komme damit irgendwe schneller ans ziel. wobei mit c kann ich mehr performance aus meinen aplikationen rausholen. (mich nervt der c syntax etwas mehr als andere *fg*)

Zitat:
VAR x : integer = 500;
VAR y : ARRAY [1..10] OF integer;

*reusper*

var x: dword = 500; y: array[1..10] of dword; *tze*
int x = 500; Int y[10];

*fg*

was mich an delphi etwas nervt (und was ich auch ganz gerna mal vergesse nachdem ich c gecodet habe):

IF (yes = willig) THEN Begin sex := true; End;

IF (willig = yes) { sex = true; }

ich finde auch cool das man variablen in c schon mit ner funktion definieren kann

int leckmich = sex(param);

sind aber sachen die einen nciht weiter stören.

for (i=0;i<10000;i++) { bla bla; }
for i = 0 to 9999 do begin bla bla; end;

fazit: is etwas länger... und c auch etwas schneller... *fg* aber verzichten kann ich auf delphi nicht. wenn ich mal schnell nen programm programmieren will bin ich bei C einfach an der falschen adresse. delphi kann ausserdem mehr als die meisten hier glauben. ich habe bei delphi noch kene grenzen gehabt. *hmmm* -> asm -> dll's

tjo... wer beides kann hat halt nen vorteil *fg*

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.