PPointer ist denk ich mal nen Pointer aufem Pointer

also so dann:

type
PPointer = ^Pointer;

@Fiji-Figther :
Die Extensions GL_ARB_vertex_shader und GL_ARB_fragment_shader stehen für die neue HLSL von OpenGL (glSlang), wärend die alten Extensions GL_ARB_Vertex_program und GL_ARB_Fragment_program für die Lowlevel VPs und FPs stehen.Die Extensions unterscheiden sich also, und der Begriff Shader wurde hier wohl gewählt weil program entweder schon vergeben war, oder weil das ARB der Meinung war, man sollte soch D3D (*igitt*) von der Terminologie her annähern.

@DCW_Mr_t :
Leider muss ich dich enttäuschen (und Phob auch ).Die von mir beschriebenen Features gehören ja wie du bemerkt hast mit OpenGL1.5 zum Kern.Wenn eine Grafikkarte nun nicht in der Lage ist diese Extensions zu unterstützen (viele davon kann man aus Geschwindigkeitsgründen auch nicht per Software emulieren, z.B. die Occulisionquery wäre in Software unbrauchbar langsam), dann wirds dafür halt ganz einfach keine OpenGL1.5-Funktionalität geben.Deshalb werden Gl1.5-Treiber auch nur für volle DX9-Karten wie die R9500-9800 (und bald 9900) und die GeForcreFX-Reihe erscheinen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Schade hatte so sehr gehoft, einige neue Dinge nun nutzen zu können... so gesehen bringen den meisten Leuten dieses neue "Opengl 1.5" ja gar nichts, weil alle neuen Feats für die Leute, die ne gute Graka haben eh schon längst akls Extention verfügbar sind und alle anderen mit diesen Dingen nichts anfangen können
(fällt meines Erachtens nach schon fast unter "Schwachsinn"... sorry, dass ich das so ausdrücke...)

Ich habe mal eine Frage: wie schwer fällt bei solchen Units die Portierung nach Kylix? (Hätte mal Lust auf sowas.... bzw. sowas selber zu machen....)

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

Im Großen und Ganzen sind das meiste immer nur neue Technologien. Allerdings gibt es auch die ARB extension texture_non_power_of_two. Diese ermöglicht es offiziell Texturen zu verwenden die keine 2er potenz als Höhe oder breite zu besitzen. Diese Extension sollte dann allerdings auch auf TNT2 Karten verfügbar sein. Genau wie das mit ARB_vertex_buffer_object der Fall ist. Allerdings isr auf einer TNT2 der Geschwindigkeitsvorteil von VBO's gegenüber DL's oder iterativer Modus gleich 0. VBO's werden bei der nur Softwareseitig emuliert. Aber es ist ja klar. Wenn der Chip auf der Karte (oder Speicher auf der Karte) so etwas nicht unterstützt bzw zu klein ist. Wo soll das sonst herkommen. Und die gesamt funktionalität einer Karte noch mal in den Treiber zu packen würde viel zu viel kosten und wäre richtig langsam. Siehe 3D TExturen auf einer TNT2.

Zum Thema Header übersetzen nach Linux. Du musst das Laden der Methoden anders gestalten. Du musst die WGL Extension mit den GLX austauschen und wenn du bei der Functionsdeklaration darauf geachtet hast windows und linux calls zu implementieren ist das kein Ding. Als sehr gutes Beispiel schau die mal den OpenGL 1.2 Header von Lischke an. Der macht genau das.

@sos: Aber... *lufthol* NV hat durchaus bei Treibern Softwareemulationen integriert die über der eigentlichen Funktionalität einer Graka heraus ging. Und wenn mich nicht alles täuscht wollten die auch dabei bleiben und das nicht nur für Shader...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Das mag sein das die Sachen wie VPs per Software im Treiber emulieren, allerdings ist dies auch nur bei Features sinnvoll die dann auch mit brauchbarer Geschwindigkeit zu emulieren sind.
Occlusionqueries lassen sich z.B. nur sehr aufwendig und sehr langsam emulieren, weshalb ich hier kaum an eine generelle Treiberemulation dieses Features für ältere Grakas glaube.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ja, versteht sich von selbst, dass es bei den meisten Emulationen in dieser Richtung wie "einfach nicht da ist" ... ne PixelShader auf meiner alten GeForce2MX war so sinnvoll wie 1 FPS, vermutlich nichtmal für Standbilder sinnvoll... aber gut der Thread gerät Off_Topic

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Um mal wieder OnTopic zu kommen:
Ihr habt tatsächlich die CUBE_AMP_ARB mehr oder weniger vergessen.
Ihr habt zwar diese mit dem entsprechenden Parameter definiert, aber prüft diese nie mit CheckExtension und habt auch nicht die Variable GL_ARB_texture_cube_map drin, in der das Ergebnis von CheckExtension ja stehen müsste.
Also: vergessen, oder hab ich was übersehen?

Außer dem Bug mit gluBuild2DMipmaps habe ich sonst bisher aber nichts gefunden. Bin wirklich zufrieden mit der Unit, gefällt mir

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Also 64kb demo fähig sind die Header ja nicht. *ggg*
Die exe war bei mir prompt über 40 kb groß, nur die Initalisierung.
hmm, ich glaub ich schreib mir mal so ne Art "Minimalheader"...


mfg las

a) Keiner hat behauptet das die Header 64k fähig wären...
b) Gibts ja immernoch Exe-Packer wie UPX
c) Wenn schon 64k, dann schon Assembler...

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi,

dafür würde ich einfach die OpenGL.pas benutzen die bei Delphi dabei ist.


mh.. Ich bastle ab und zu mal wenn mir langweilig ist an meiner 64k Demo.. falls man das so nennen kann *g*
Und ich finde das geht auch ohne Assembler recht gut...

Aber irgendwie is mir immer zu langweilig da weiterzumachen, bzw mir is TLoF wichtiger *g*

Au'revoir,
Aya~

Laber nicht so nen Blödsinn!
Kennst du Jan Horn?!? Und ich glaub kaum das die von Farbrausch etc. nur asm coden...



Joa, da komm ich auf so ca. 20 kb, mit UPX ca. 12 kb das ist ganz ok.

Achte auf deinen Umgangston...es gibt hier im Forum immer noch sowas wie Verhaltensregeln, und ganz nebenbei ists unabstreitbar das man die kleinsten Programme mit Assembler schreiben kann...auf http://www.cfxweb.net gibts ein komplettes Assembler-OpenGL-Programm das nur 4KB groß ist...das machst du mit keiner Hochsprache...

Edit : Und davon mal abgesehen gerät diese Diskussion hier stark OT.Bisher gabs kaum Kommentare zum Header an sich!

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Entschuldigung, das sollte kein personlicher Angriff sein.
Klar sind die kleinsten Programme in Assembler, das stimmt wohl ( z.b. www.256b.com ). Aber nichts spricht dagegen bei einer 64kb Demo eine Hochsprache zu verwenden, wir reden von 64kb ( und das ist eigentlich ne ganze Menge! ) nicht von 4kb.
Damit bin ich jetzt genug vom Thema abgewichen, sorry.

mfg las

Gibt's jetzt eigentlich noch eine korrigierte Version der Header mit ARB_CUBE_MAP, oder soll sich das jeder selbst schreiben?

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?