Jump to content

what do you want see in leadwerks 3.0


dreamhead
 Share

Recommended Posts

I would like to see more control over sound entities (including out of the box parent functions, sound duration, utils, etc) and emitters/particles. For instance: I'd like to set individual particle color without having to create multiple emitters.

Since all entities can have a script attached, it is easy to make script functions for particle emitter entities, where you control each particle's properties when it is emitted.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

  • 2 weeks later...

I would like to see the TVec data structures and Vec functions perhaps renamed to include an 'f' on the end.

 

e.g.

TVec2f

TVec3f

 

Vec2f

Vec3f

 

I also think the font load function should accept an image filename as its argument including the '.dds' (or whatever format is chosen)

AMD Athlon 64 X2 Dual Core 6000+ (3.0 GHz)

4 GB DDR2 RAM

2 x NVIDIA GeForce 9500 GT 512 MB (SLI 1.0 GB)

Windows XP Pro

Link to comment
Share on other sites

The ability to reference other objects directly within an script... basically what I would envisage would be 2 new lua variable types. The first would be a "class type", although I guess using a string would work also... but basically the other variable type would provide a pull down that would list all objects in the scene of that specific "class type"... once linked in this way we can then read that key in code and return the reference to the attached entity.

 

For example, this would allow me to have a character model defined within the scene, and link to each slot of that character a weapon object that is in the scene. Another option would be creating waypoints were you can link wapoints and visually see the links, I would guess a simply line connecting them would be ideal, another option here would be creating transporter locations....

 

I would like to add I love the idea of having zones witin the scene, this will be very useful... Day/night cycles would be nice... rivers definitely...

 

How about a new light type that is a point light that we can define the length and width, or even the shape, this would be useful for modelling different light sources...

If it's not Tactical realism then you are just playing..

Link to comment
Share on other sites

  • 5 months later...

Not really a feature but I would like to see all functions neatly encapsulated in a namespace. My function names sometimes collide with LE functions.

How's that possible? Because even LE2 has it's own namespace LE.

Are you sure you put your own functions into your own namespace also?

Ryzen 9 RX 6800M ■ 16GB XF8 Windows 11 ■
Ultra ■ LE 2.53DWS 5.6  Reaper ■ C/C++ C# ■ Fortran 2008 ■ Story ■
■ Homepage: https://canardia.com ■

Link to comment
Share on other sites

How's that possible? Because even LE2 has it's own namespace LE.

Are you sure you put your own functions into your own namespace also?

+1 :)

 

I also think devs need to have their own namesspace and/or way of naming functions/classes.

 

 

I'm sure it's been mentioned before but proper multithreading support.

 

+1

 

Reasoning:

- http calls to server (for example, when fetching online high score)

Intel Dual Core 3GHz / GeForce GTS 450 - 1024 MB / Driver ver 267.59 / 8 GB RAM / Win 7 - 64 bit / LE2.50 / BMAX 1.48

game producer blog - Dead Wake Zombie Game powered by Leadwerks Engine

Twitter - Unfollow me

Link to comment
Share on other sites

By the way, there's more reasons for multithreading:

- fetching online highscore and...

- refreshing master server and..

- joining multiplayer games!

 

It's a pain in the buttocks if game freezes for few seconds when you are "refreshing master server list" or "joining game".

Intel Dual Core 3GHz / GeForce GTS 450 - 1024 MB / Driver ver 267.59 / 8 GB RAM / Win 7 - 64 bit / LE2.50 / BMAX 1.48

game producer blog - Dead Wake Zombie Game powered by Leadwerks Engine

Twitter - Unfollow me

Link to comment
Share on other sites

RakNet ftw :)

 

The way I see it, if you are expecting anything short of buggy network code from LE 3 you are expecting to much. Much like Josh uses a physics library he would be wise to use a tried and proven networking library as well that has all these features in it already, or honestly better yet, we should just use said libraries ourselves :)

Link to comment
Share on other sites

How's that possible? Because even LE2 has it's own namespace LE.

Are you sure you put your own functions into your own namespace also?

 

I do not remember this being the case when I made this feature request, the 8th of november of last year :)

Link to comment
Share on other sites

By the way, there's more reasons for multithreading:

- fetching online highscore and...

- refreshing master server and..

- joining multiplayer games!

 

It's a pain in the buttocks if game freezes for few seconds when you are "refreshing master server list" or "joining game".

 

Multithreading +many. I would love to be able to call on Leadwerks from different threads. Since streaming terrain is on the roadmap I suppose you can't get around it anyway.

Link to comment
Share on other sites

RakNet ftw :)

 

The way I see it, if you are expecting anything short of buggy network code from LE 3 you are expecting to much. Much like Josh uses a physics library he would be wise to use a tried and proven networking library as well that has all these features in it already, or honestly better yet, we should just use said libraries ourselves :)

Hmm, so ... if I use RakNet, I can make http calls without freezing the app? How's that possible? o.O

(bear in mind I use Bmax)

Intel Dual Core 3GHz / GeForce GTS 450 - 1024 MB / Driver ver 267.59 / 8 GB RAM / Win 7 - 64 bit / LE2.50 / BMAX 1.48

game producer blog - Dead Wake Zombie Game powered by Leadwerks Engine

Twitter - Unfollow me

Link to comment
Share on other sites

Hmm, so ... if I use RakNet, I can make http calls without freezing the app? How's that possible? o.O

(bear in mind I use Bmax)

 

RakNet runs on another thread. You basically poll to see if any data is ready in your main loop, but it doesn't freeze your main loop. It's possible because you aren't doing anything LE specific in the RakNet thread. You are just passing data around. Once you have that data in your main LE thread you can then call LE specific functions.

 

bear in mind I use Bmax

 

I don't know if RakNet works with BMax.

Link to comment
Share on other sites

Multithreading +many. I would love to be able to call on Leadwerks from different threads. Since streaming terrain is on the roadmap I suppose you can't get around it anyway.

There is a huge difference between running a single self-contained process on another thread and designing a command set that can just be called in any order at any time. Even if I locked the threads in every single call (which would eliminate any speed gains you might get from multithreading) there's still a ton of errors the user can cause themselves.

My job is to make tools you love, with the features you want, and performance you can't live without.

Link to comment
Share on other sites

maybe callbacks when models are fully loaded from a loading thread and we can copy the data to our main thread which should be faster.

Leadwerks.Net already has events that fire when a model is Activated or Updated physically. This may help.

 

There is a huge difference between running a single self-contained process on another thread and designing a command set that can just be called in any order at any time. Even if I locked the threads in every single call (which would eliminate any speed gains you might get from multithreading) there's still a ton of errors the user can cause themselves.

I agree. Josh should not create a separate environment calling thread-locks every frame. This would cause necessary thread-thrashing within the CPUs. Even then, each method call would have to check whether it is the Marshalling thread (main thread), and invoke a request if otherwise.

 

 

When dealing with multi-threaded environments that use graphics rendering code, you must create a separate buffer for which to call upon. This allows you to reference a particular 'state' of the last rendering cycle represents.

 

http://msdn.microsoft.com/en-us/library/dd287191.aspx

In .Net 4 you can use a thread-safe concurrent dictionary which will solve most of the work for you.

(One more feature that makes it easier to use .Net)

 

It would be an amazing feat if Josh recompiled Leadwerks into an optimized multi-threaded environment with object states internally, but that I think is asking too much.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...