Quote from: "rolz"I see the thread is way too old, but can you please add support for these features, at least for hardware renderer  ?

Hardware only support for multi texturing? I'll see if it fits somehow into jPCT...

Quote from: "rolz"
-improved performance for precise Z coordinate calculation on ground.
( adjustable by game.disable.fast.placement parameter in techno properties)

Changed

Code Select Expand

object3d.calcMinDistance(v1, v2) (2000ms)
to

Code Select Expand

object3d.calcMinDistance(v1, v2, n) (500ms)

still it is not as efficient as accessing avg heights data (<10ms)

Are you using an octree on the terrain?  calcMinDistance may benefit from it (apart from the rendering itself).

Your progress is astonishing... :shock: But what about gameplay? I think it's looking very nice now as it is and it seems to be time to add some more gameplay. What do you have in mind gameplay wise?

Quote from: "General is back"wenn das der gute Huuck noch mitbekommen würde....  :wink:

Tja, der ist nun im Ruhestand: http://englischlehrer.de/about/impressum.php...actually...

You get the id when adding the light to the World by using addLight() as a return value. Again: I agree that it would be better to handle lights as instances of their own, but just write yourself a Light-class that takes a World in the constructor and internally adds a new light to this world and holds the id. Manipulate the light by mapping the methods of your class to the corresponding ones in World. For example: Currently, there is no way to remove a light from the World, so just add a method disable() to your Light class and let it call World.setLightVisibility(myID, false). Got the idea?

Edit: rolz owned me...  :lol:

Quote from: "Melssj5"Why wont you change that feature on jpct?

Because it will break all existing code and doesn't really gain you anything except for giving you the gut feeling that it's somehow "better" that way. One thing i really hate about non-commercial software (may it be open source or not) is when the API constantly changes without adding new functionality, i.e. when the only reason for a change is to make the developers of the API feel better.
But i may add such Wrapper as an option and put it into the util-package. I haven't done this until now, because nobody ever complained about it and because such a wrapper is drop dead simple to write by yourself if needed.

Quote from: "the unbeatable"...vielleicht solltest du lieber bisserl Act of War üben, statt deine ganze HP ins Englische zu übersetzen ;-)

Bleibt zu klären, was auf lange Sicht erfolgversprechender ist...

Quote from: "manumoi"I suppose there is a way to redefine this limit but I wasn t able to find it.
How to do that?

Set Config.maxLights to a higher value before instantiating a World.

Quote from: "Melssj 5"maybe the lights should have its own methods to do their stuff, I dont know.

Yes, i agree. The current implementation for the lights turned out to be rather unintuitive. The basic idea was to keep Lights as lightweight as possible but that isn't really an issue when looking back at them now. Anyway, i won't change this in jPCT. But it's very easy to write your own wrapper class for the lights. That's what i did in Paradroidz too. All you have to do is to store the World and a light's id in each instance of this "MyLights"-class and map methods like MyLights.setPosition() to the corresponding World-methods. Not an ideal solution but at least more OOish as the current implementation.

Glad to see you back in business... :wink: Your planned approach sounds reasonable to me. Just make sure to keep things as complex as needed but as simple as possible. Things will grow in complexity anyway...(for example, Paradroidz proof of concept version started with 4 classes, now i'm at 163 and counting...).

Quote from: "rolz"Happy birthday to me  :!:

Well...then...: HAPPY BIRTHDAY TO YOU! :mrgreen:

Quote from: "Anonymous"it would be nice though if you could create an applet using the software-based renderer, but have an optional download to plugin a hardware-based renderer, so the the same software runs in either way.

I don't quite understand...you can already do that!

Quote from: "rolz"- Transparent objets were flickering (grass, trees) , like on one frame object A was in front of object B, and on the other - object B was in front of A.

It appears that it is possible to control which object had to be displayed in the front by manually setting Object3d.setSortOffset() for such objects.

Basically, the inconsistent overlapping is impossible to avoid when using painters algorithm based on z-sorting...and that's what jPCT has to do to ensure an (almost) correct order. setSortOffset() may help if used right. But for overlapping trees, it will get quite difficult, i think. The method is in because i needed it for Paradroidz to avoid an overlapping problem between the fog of war and the energy pods.
I don't think that the sorting flaws are a big problem in Technopolies. I hardly ever notice them and i usually notice every subtle rendering artifact... :wink:

Sorry to hear that Personally, i don't spend days or even weeks drawing UML diagrams and designing stuff to the death. I usually know the goal that i want to achieve and i have a rough idea of how to do it before i start coding.  When i'm thinking too much about design, i usually complicate things more than needed.  For example, Paradroidz first design was overcomplicated. It made sense on paper and it would have done so even in code, if the code would have been used in the way it was planned to...but it wasn't.
Designing too much leads to too much "what if"-thinking IMHO: "What if i want to do this or that in the future or what if my game objects should start cleaning the kitchen or cooking some coffee one day...i should take care of that too...or maybe i want to render them on a line printer one day, so i should introduce another rendering abstraction layer...". That's BS. I like the part of the "Extreme Programming"-philosophy where it says: "Code what's needed, not more. Refactor if needed." That's basically what i'm doing with Paradroidz. That's NOT what i'm doing with jPCT. jPCT's design is years old. It should be refactored for some parts and i would do that, if i were the only person using it. But i'm not and i really don't want to break other people's code (because i HATE it, when this happens to me) justto  make me feel better. In the end, it doesn't matter at all.
However, what works for me doesn't have to work for everybody else and these things lead to very emotional discussions (even more than the great question: "Where to put the brackets?"... :wink: ) most of the time. Do what works for you. If you do and if you finish at least something, you already did a lot better than people who are just talking about things...
About the art department: I'm not very good at art, i.e. drawing textures, making models...i could do better than i'm currently doing with Paradroidz, but i don't want to spend the time needed. A skilled artist would be multiple times faster than me (and with better results) That's why i'm currently looking for an artist to improve the look of the models at least. And to make sure that he delivers, i'll pay him for his work. Not much of course, because Paradroidz is freeware, but anyway...
What else can i say...don't give up just because it isn't fun all the time. There are soooo many abandoned projects on the net...too many if you ask me. The people who are actually getting things done are very very few... :cry:

Tested the new version on a Linux box (Debian) and it worked just fine. I got some exceptions, but that may be the case in Windows too... :?:

java.lang.ArrayIndexOutOfBoundsException: 1517
       at aS.a_(Unknown Source)
       at bk.b(Unknown Source)
       at bk.d(Unknown Source)
       at techno.client.world3d.Client3D.run(Unknown Source)
       at techno.client.world3d.Client3D.main(Unknown Source)
java.lang.NullPointerException
       at O.a_(Unknown Source)
       at bk.b(Unknown Source)
       at bk.d(Unknown Source)
       at techno.client.world3d.Client3D.run(Unknown Source)
       at techno.client.world3d.Client3D.main(Unknown Source)

It ran quite slow, but that's not much surprising because the system is a Pentium II 400Mhz with a TNT2-32MB graphics card. But it was still playable...