Show Posts

11761

Support / Level file format - final ?

« on: December 02, 2003, 10:40:49 pm »

Quote from: "rob"

> I'm not quite sure what you mean with "level-format"
We were looking for something that we could design levels with and then just use in the engine (like .map or .wads). From what we could tell 3ds is more of a modeling format, but since I wrote this I found that you can use the Valve Hammer editor export to dxf and then using a program called crossroads we can save it into a 3ds format that seems to work for a level editor. So it was our confusion.

One thing to keep in mind when doing this (i remembered this today while doing some conversion of Quake3-maps to 3DS): 3DS limits the length of the texture names for a material (to 12 or 13 IIRC). This may cause problems, if you named your textures like "my_very_own_texture1.jpg, my_very_own_texture2jpg" etc. The converted file may contains material with textures pointing to "my_very_.jpg" and you don't know what was what after that.
I've described my way to deal with this here:

http://www.jpct.net/forum/viewtopic.php?t=75

11762

German corner / Tutorials

« on: December 01, 2003, 08:24:53 pm »

Ich kenne Jogl, habe es aber bisher nicht weiter betrachtet. Das mit dem Sound verstehe ich nicht...LWJGL hat Sound via OpenAL, Jogl auch (bzw. Joal). Da nehmen sich beide nichts. Der Punkt ist eigentlich, dass LWJGL besser "passt". Es wrappt OpenGL und das war's. Jogl drückt einem seine Interpretation von OpenGL durch sein abstrakteres Objektmodell auf und das passt nicht sooo gut zu den bestehenden Strukturen von jPCT.
Dennoch sollte eine Jogl-Version von jPCT möglich sein. Die Renderer sind ja eigentlich austauschbar...ich habe mich bisher nur nicht damit beschäftigt und sehe auch die Notwendigkeit momentan nicht.
Fast alle benutzen jPCT im Software-Modus. Das es auch Hardware kann, ist manchen gar nicht richtig bewusst.
Eine Wrapperklasse zwischen LWJGL und jPCT wäre sicher hilfreich, aber ich werde sie nicht direkt in die API intergrieren, da sie meiner Ansicht nach dort nichts verloren hat. jPCT verwendet absichtlich keinerlei Listener/Eventhandler/Adapter-Ansätze...wer das haben möchte, soll es sich selber seinen Bedürfnissen entsprechend bauen. Wenn du sowas bauen möchtest, packe ich es natürlich gerne als Option mit dazu.
Irgendwo hatte ich sogar mal eine Aufruf gepostet, dies zu tun...hat bisher nur keiner gemacht... :wink:

11763

German corner / Tutorials

« on: December 01, 2003, 05:58:37 pm »

Eigentlich ist es egal, in welcher Reihenfolge man Software ab- und Hardware anschaltet. Die JavaDOCs klingen so, als ob man erst OpenGL an- und dann Software abschalten muss, aber so war das gar nicht gemeint. Evtl. ist diese Reihenfolge sinniger, um nicht völlig ohne Buffer dazustehen, wenn OpenGL fehlschlägt...aber dann ist sowieso was nicht so, wie es sein sollte.
Die verschiedenen Buffer-Modi gelten nur für Software und werden von der FrameBuffer.optimizeBuf...()-Methode gesetzt. Dabei kann es mal passieren, das in einem Durchlauf die eine und im anderen die andere Methode schneller ist...das liegt im Rahmen er Messtoleranz und macht eigentlich nichts. Der ganze Quark existiert überhaupt nur, weil sich die JVM auf einem P4 u.U. sehr merkwürdig verhält. Es scheint hier ein Problem mit dem Alignment von Arrays zu geben, das aber z.T. erst nach ein paar Sekunden Laufzeit auftritt. Auf meinem Rechner ist das teilweise ziemlich signifikant und man kann es durch diese kleine Messung am Anfang mittels optimize...() etwas abmildern (aber nicht beheben).

11764

German corner / Tutorials

« on: November 30, 2003, 12:34:35 pm »

Wenn du den Würfel über die Primitives-Klasse geholt hast, dann hat er erstmal keine Texturkoordinaten, da es ein simpler Drehkörper ist. Du kannst z.B. mit calcTextureWrap() oder -Spherical() eine "draufkleben". Oder den Würfel selber über seine Koordinaten zusammenbauen.
Das mit den Threads ist stellenweise nicht wirklich nötig. Was ich immer tue, ist den Zähler in einem extra Thread laufen zu lassen, um eine Zeitmessung zu realisieren. Der Render-Thread müsste für Applikationen nicht wirklich sein; Du kannst ihn einfach weglassen. Für Applets ist er aber wichtig und um die Portierung zwischen Applet und Applikation zu erleichtern, baue ich es immer gleich so. Hat mit jPCT selber nichts zu tun und ich werde das aus den Beispielen vielleicht auch entfernen, da es wohl mehr verwirrt als hilft.

11765

German corner / Tutorials

« on: November 29, 2003, 06:51:29 pm »

Ok, also in Deutsch:

Stimmt schon, dass die Beispiele uneinheitlich sind. Das liegt primär daran, dass sie zu völlig unterschiedlichen Zeitpunkten entstanden sind und ich jetzt manche Dinge nicht mehr so machen würde, die ich z.B. in Bounce so gemacht habe. Das "fortstrittlichste" ist somit sicher das fps-Beispiel. Es sieht so aus, wie ich jPCT momentan benutze.
C++-Stylisch kann ich nicht nachvollziehen. Ich habe nie viel C++ gemacht, also sollte mich das wirklich wundern. Sie sind sicher nicht sehr OOisch, aber das ist Absicht, damit irgendwelche wilden Objektkonstruktionen nicht vom eigentliichen Inhalt ablenken. Oder was meinst du jetzt genau?

Edit: Wenn du Tutorials schreiben möchtest, fände ich das großartig. Ich kann mich ja leider auch nicht zerteilen, weswegen es eine große Hilfe wäre.

11766

German corner / Tutorials

« on: November 29, 2003, 12:41:31 pm »

Hmmm...the examples in the example-dir of the distribution are there for this. While they are not step by step tutorials, i think they are documented well enough to get you started. I think the terrain-example is best suited for this.
Then there is the "manual" which describes things on a more abstract level. If it's really needed, i may add a small "hello-world"-example to it.

Hope this helps.

11767

News / Version 0.96 has been released!

« on: November 27, 2003, 09:15:52 pm »

Changes are documented here: http://www.jpct.net/changes.html

In addition, i finally replaced the jPCT-demo from the stoneage with a more current version. To be precise, the new jPCT-demo is simply the fps-demo from the examples-dir of the API-distribution bundled with LWJGL 0.7.

Have fun!

11768

Bugs / Bug in 0.92-0.95 in Matrix.scalarMul()

« on: November 27, 2003, 09:12:37 pm »

The fixed version is out.

11769

Support / Level file format - final ?

« on: November 26, 2003, 11:02:32 pm »

Quote from: "rob"

Another method we were thinking about using is loading pre made (serialized) texture objects instead of loading jpg and turning them into textures. Also we were thinking evenuatlly we would like to manipulate the textures on a pixel level.

Anyway, we are just trying to find something that will help us get the game built faster instead of f**king about with the engine - which we seem to suck at and you do not

Serialization is supported by jPCT, but the serialized output can be quite large...at least if you serialize the whole world. Manipulating textures on the pixel level is also possible by implementing the ITextureEffect interface. However, this can't be used to create textures. If it's a showstopper for you that you don`t have a constructor for textures that takes an int[] as parameter, i'll possibly add this.

I like your Doom-engine...what's wrong with it? (Except for the limitations these engines always have).

11770

Bugs / Bug in 0.92-0.95 in Matrix.scalarMul()

« on: November 20, 2003, 10:09:44 pm »

:oops: There's a bug in the scalarMul()-method in Matrix from version 0.92 on. This bug affects Object-scaling too, so this won't work anymore in all versions from 0.92-0.95. I'll release 0.96 to fix this ASAP.

11771