@Flatfingers and others regarding the beams - thanks! Glad you guys like them. @Employee - I don't think they look great in screenshots, you really do need to see the animation part. The beam basically decoheres and fades out over a second or two after it's fired. The noise effect becomes more obvious over the period. So one gets the impression of a short-lived, coherent beam being projected and then quickly losing stability. I like non-noisy beams too...so maybe we just have the 'noisiness' be a scalable attribute that correlates with some property of the weapon.
Employee 2-4601 wrote:Once you've had time to properly evaluate this situation, it will be interesting to know what the ramifications are for modding. In particular, whether mod developers will simply need to know exactly what they mustn't do in lua if compilation is to remain enabled, or if there might be tools to assist them in avoiding such pitfalls. Maybe the same debug logging you've utilised here will be sufficient. What is the granularity of the compile/no-compile decision? If compilation is aborted, does that affect a single file only? Can it potentially affect other code as well?
That's a good question. I think it will fall more on me, and probably isn't something modders will need to worry about. Most of the places that cause trouble are where Lua and C try to talk to one another (i.e., through my API). So it's on me to build an API that lends itself to LJ optimization.
It is difficult to understand the granularity without understanding tracing JITs, which are difficult to understand in the first place, because they are not like what you might think of as a 'normal' compiler: they don't look at code in terms of how the programmer has written it. They look at code in terms of how it is being
executed, and perform analysis on execution flow to determine if specific 'traces' (paths of code that are frequently-executed, but don't necessarily align with function boundaries or loop bodies, etc. -- both the beauty and the weirdness of a tracing JIT) can be compiled to machine code. So the answer is 'it depends,' sometimes a trace may span multiple functions across multiple files, whereas sometimes it may span only a tiny portion of a single function. Within a trace, any 'bad' operation will cause an abort of the entire trace, if my understanding of LJ is correct. So the decision is all-or-nothing, but at the level of a trace, which, again, is difficult to put a scope on.
At any rate, you guys will have equal access to the LJ debug tools that I have. But again, hopefully it won't be something that modders need worry about.
kostuek wrote: Just out of interest: if you had to identify 3 most basic/urgent features/mechanics to add to the demo next, wich 3 would it be?
Also: nice screenshots
Most basic/urgent:
- An actual HUD (also some better indicators of target distance/velocity, and, most importantly, faction....right now your HUD doesn't tell you whether you're shooting at an enemy or not
)
- Collision detection.
- Sound.
But note that I have answered the question you asked: which are the most basic/urgent. This does not necessarily correspond to what I will be implementing first
(there is no showing coming up so no real urgency other than the usual "finish Limit Theory"!) The HUD though really is a priority.