Zitat: Zitat von Ikon (Beitrag 7904083) Ich habe nur wenig Erfahrung mit Kollisionserkennung, aber meines Wissens nach arbeitet man Quadern und Kugeln, die um die betreffenden Modelle herumgelegt werden. Normal ist eine Dreieckssuppe (also ein normales Mesh) für statische Levelgeometrie. Für bewegliche Objekte nimmt man Compounds aus konvexen Polyhedra, Kugeln, ..., also eine Kombination aus simpleren Formen, die jeweils einfach zu berechnen sind.

Bei beweglichen Objekten ist das Kollisions-Compound fast immer nur approximativ, außer bei simplen Objekten wie einer quaderförmigen Kiste natürlich. Bei der statischen Levelgeometrie kann man die zur Darstellung benutzte Dreieckssuppe benutzen, oft wird aber auch hier nur eine Approximation benutzt. Der Grund ist nicht zwangsweise die Rechenzeit, sondern oft auch der Spielfluß. Man will ja nicht an jeder kleinen Ecke gleich hängenbleiben.

Zitat: Zitat von Gast (Beitrag 7904035) fmod ist seit OpenAL ein alter Hut. OpenAL ist eine Sound-API, fmod eine Soundengine. Also bitte erstmal selbst informieren, bevor du so einen Kappes postest.

Zitat: Zitat von G.A.S.T. (Beitrag 7903173) Du vergisst die Cam. Das System kann durchaus erkennen, wenn der Spieler seinen linken Arm bewegt...auch wenn es im Fall von Move keine 3D-Cam ist (richtig?) Nein kann es nicht. Wozu sollte man sonst eine große leuchtende Kugel + Bewegungssensoren benötigen, wenn man die Bewegung auch so erkennen könnte? ;)

Wie gesagt, mit einem Kugelcontroller und einem Nunchuck kann man gerade mal einen Bruchteil der Wii-Spiele portieren, da diese meist beide Bewegungssensoren nutzen. Du kannst nicht mal Pfeil+Bogen damit simulieren, dazu bräuchtest du schon 2 Kugelcontroller (so wie in der Demo von Sony). Und wie man mit so einer dicken Kugel einen genauen Pointer hinbekommt, frage ich mich immer noch. Denn statt einfach nur die Infos von der Kamera auszulesen (wie bei der Wii) muss hier ja Position der Kugel + Neigung des Controllers ermittelt werden.

Oder sieh dir mal Rayman an, die Rhythmus oder Laufspiele. Die würden mit einem Controller auch nicht funktionieren.

Der Nunchuck ist demnach total sinnlos dabei. Fast alle größeren Spiele auf der Wii nutzen auch beim Nunchuck den Sensor. Hierfür brauchst du dann bei der Playstation eben 2 Hauptcontroller. Keine Ahnung ob das so gut ankommt.

Zitat: Zitat von Coda (Beitrag 7903878) Soviel zu Charlies Verschwörungstheorien. Ach Quatsch, in nichtmal nem Jahr ist Lucid Pleite und dann kommt die große "Nvidia hat Lucid platt gemacht"-News und schwupps ist Charlie wieder der große Messiahs. Wäre nicht das erste Mal, das er "Recht" nur deswegen hat, weil er eigentlich Unrecht hatte ;)

So wirklich neu ist die Idee ja nicht. Gab doch sogar mal ein Spiel, dass nicht Voxel sondern Kugeln benutze, was ja diesem PointClouds schon recht ähnlich ist. Da noch eine ordentliche hierarchische instanzierende Datenstruktur, die man clever durchsuchen kann und fertig ist das ganze teil.
Das Problem bei Punkten/Voxeln gegenüber Polygonen ist nur, dass die keine Oberfläche, bzw keinen Oberflächenvektor haben. Damit kann man dann auch keine SChöne Echtzeitbeleuchtung machen. Und das ist heute schon ein ziemliches Problem.

Gruss,
Steffen Bendel

PS:
Ich hatte vor 10 Jahren mal einen Raytracer mit rekursiver Geometrie geschrieben (gerade getestet, läuft mittlerweile auf Multicore echt flott). Da hatten die Objekte potentiell auch unendlich viele Grundobjekte. Muss man aber beschränken, sonst bleibt das Program hängen, wenn man dorthin guckt, wo die Rekursion nicht abbricht wird (ähnlich wie beim Apfelmänchen an den Stellen, an denen der Algorithmus nicht endet)

Geil, Beitrach ist n paar Wochen weg gewesen vom Fenster und nu holtne jemand hoch und was macht er? Kommt hier rin und ledert gleich mal los, wasn das für Kack hier drin. Jaja, DX11=scheiße? Geht doch nach Hause, ihr ewiggestrigen Hinterwäldler. :biggrin:

Ja Gott sei Dank haben sie keinen Voodoo2/3-Verschnitt verbaut. Der NEC war die richtige Wahl, bis auf die Lieferengpässe die man hatte.

@Schlammsau

Hier mal die Frames anhand von DIRT 2.

Spoiler zu: 2520x1418 4xMSAA/16xAF @1680x945 max. Details DX9











Wie gesagt - Konsolenports lassen sich selbst mit einer GTX260 und DS noch sehr gut spielen.

Hier mal weitere Frames:

Spoiler zu: 3360x1890 2xMSAA/16xAF @1680x945 max. Details DX9




Zweites Setting empfinde ich allerdings mit 32-40fps nicht mehr als flüssig. Die Framerate wird hier nicht mehr angezeigt weil Fraps damit überfordert ist. Die Bilder sind mit EVGA-Precision ohne Framecounter entstanden.

Und hier mal zwei Bilder in Originalgröße und PNG als Beweis. :)

Tja, ging wohl doch etwas schneller mit Mount Evans als ich selbst dachte... ;D
Das Nächste mal verabschiede ich mich mit einen festen Datum.

http://www.heise.de/newsticker/meldu...-0-953414.html

Es darf nun also weitergewütet werden.

Nein, kein Fake. Aber in etwa mit dem gleichen Status wie Raytracing momentan. Technisch interessant, aber weitab von realer Umsetzung...

http://www.unlimiteddetailtechnology.com/

Bei deinem Youtube-Video hat der Poster rechts im Info-Fenster auch noch eine Mail von einem der Macher gepostet.

D&D auf nem Touchscreen-Tisch:
http://www.heise.de/newsticker/meldu...ch-953254.html

Zitat: Zitat von jayk (Beitrag 7860576) Ich besitze ein Iphone 3G, also noch die ältere Version mit dem (noch) schlechteren Akku, als das neue 3GS, und wenn ich es jeden Tag über die Nacht auflade, habe ich eigentlich keine Probleme damit. Dir ist klar, das das 3GS einen kleineren Akku hat wie das 3G? :freak:

... das 3GS hällt trotzdem länger ;)

Gruß,
Chris

Zitat: Zitat von dildo4u (Beitrag 7893410) http://images.eurogamer.net/assets/a...g_Demo.jpg.jpg

http://images.eurogamer.net/assets/a..._Final.jpg.jpg In der Final deutlich besser!

Ob nun MLAA echtes AA ist oder nicht, besser wie in der Demo siehts aus, die Kanten sind glatter. In der Demo wurde 2xMSAA benutzt?

Bei GTA IV auf der PS3 wars definitiv so dass es in 576p weniger geruckelt hat als in 720p und, jetzt kommt der Hammer, es sah auch noch besser aus (kein Matsch in der Ferne wie bei 720p sondern ein klares Bild)

Sachen gibts... :ulol:

Zitat: Zitat von hardtech (Beitrag 7886093) ergo bräuchte man einen beamer mit großer diagonale, damit das gefühl hat mittendrin zu sein, was ja 3d einem vermitteln will. 120Hz-Beamer gibts z.B. von Acer in 720p und "Geforce 3D Vision Ready" für gerade mal ca. 600 Euronen. Noch ein paar Monate, dann dürften auch 120Hz-1080p-Beamer in der Region ankommen, hoffentlich für ein paar Euronen mehr auch mit LED-Lichtquelle :usweet:

Wobei der GC sogar leistungsfähiger als die PS2 ist!

Das Problem für Google ist einfach, dass sie in dem Bereich selbst so gut wie keine Patente haben, während Palm und MS ausreichend viele vorweisen können, dass sie jene von Apple getrost ignorieren können.

Nicht unbedingt

Zitat: Zitat von aths (Beitrag 7874382) Man kann die häufigsten Zeichen auf kurze Bitlängen umkodieren und somit Platz sparen (Huffman, arithmetische Komprimierung.) Oder man kann sich bei sich wiederholenden Zeicheketten nur doch Verweise auf diese Wörter speichern (Wörterbuchverfahren mit diversen unterschiedlichen Implementierungen. Die Index-Liste ist zudem Huffman-komprimierbar.) ja das ist eine Möglichkeit der Kompression. Zusätzlich musst du aber bedenken, das Huffman-Kodierung nur optimal ist, wenn die Wahrscheinlichkeit der Zeichen einer Potenz 2^n entspricht. Statische Huffman-Bäume höhere Ordnung sind dagegen nicht praktikabel, und dynamische zu langsam. Vergiss Huffmann einfach wenn es um moderne Verfahren geht. Worauf ziehlte der Teil jetzt eigentlich ab? Habe das nicht ganz verstanden?

Zitat: Wenn ich das kontestabhängige Verfahren richtig verstehe, versucht er, das nächste Zeichen zu erraten. Geringe Abweichungen (nächsthäufigere Zeichen) nehmen nur kurze Bitlängen ein. Größere Abweichungen (sehr unwahrscheinliche Zeichen) brauchen lange Bitlängen. Während des Entpackens muss es also irgendwie eine Tabelle gebe, welche diese Zeichen speichert, diese Tabelle muss laufend geändert werden. die "Tabelle" ist dynamisch. Kodierer und Dekodierer haben zu jedem Zeitpunkt das selbe Modell.

Zitat: Von wie vielen der letzten Zeichen sollte diese Tabelle aber abhängig sein? kommt drauf an, wie man die Verbundwahrscheinlichkeit berechnet. So wie ich das mit den Escape-Codes demonstriert habe sind ca. 4-8 praktikabel.

Zitat: Letztenendes ist es doch vom Ansatz her ein Wörterbuchverfahren, jedenfalls wenn viele der bisher dekodierten Zeichen zum Aufbau der Tabelle genutzt werden, welches Zeichen jetzt wahrscheinlich kommt bzw. welche Zeichen möglich, aber unwahrscheinlich sind. nein, ein Wörterbuchverfahren ist ein Substitutionsverfahren. D.h. eine Zeichenkette wird mit einem Index/Verweis oder Ähnlichem ersetzt!
Ein Kontextmodellierer macht eine Aussage über die Wahrscheinlichkeitsverteilung der Zeichen in Abhängigkeit von der Vergangenheit. Natürlich sind gewisse Datenstrukturen äquivalent aber die Philosophie dahinter eine andere.

Vergiss aber nicht, das innerhalb einer modernen Implementierung beides ineinader fließt.

also Wörterbuchverfahren+Kontextmodellierung für die Verweise
oder Kontextmodellering mit Wörterbuch-Präprozessor.

Hier könnte wohl das Problem relevant werden, dass die Farben bei OLEDs unregelmäßig altern.

Zitat: Zitat von Tomi (Beitrag 7873482) Die ersten 1,30m Plasmas kamen damals auch 30.000 DM (~15.000 Euro). Wobei so ein flacher 1,30m Plasma für die meisten sicherlich um einiges beeindruckender wirkte als dieser 37cm Bildschirm von LG. Der niedrige Stromverbrauch ist beim einem stationären Gerät auch eher irrelevant, insofern stellt sich wirklich die Frage wer für 2000€ hierzu greifen soll.