(for devs)If you would recreate Spring again from zero?

[Pendrokar]

Would the engine script change through the experience you've had and would it have better CPU or/and other type of performance than Spring had before?
It is just that adding more and more new graphical features, decreases the performance for the PC, maybe by a bit, but in the long run takes great casualties! Not that I am suggesting to recreate Spring from zero, but I think this will lead of having performance very similar to Supreme Commander! ... Oh wait Spring Project started before anything was known about SupCom. Eh!

[SwiftSpear]

Most of the origional spring devs aren't working on spring any more. Not that the current devs couldn't rebuild the engine if they really wanted too... but that's alot of work. BTW, check out the Command Engine project, it was exactly sort of what you were recommending here. But it fell apart due to lack of time and what not.

[BrainDamage]

this is not a rewrite, but gets pretty close, at least regarding rendering part

viewtopic.php?f=12&t=13772&start=0

[jcnossen]

this is not a rewrite, but gets pretty close, at least regarding rendering part

Yeah, this is similar to how apples are pretty close to penguins.

[Argh]

LOL.

Well, if K-Man ever shows up again, or if somebody else can finally fix the steering code... we might get the whole penguin, someday. Trepan's work has basically delivered the "many games from one engine" premise. Allowing for RK in some way, shape, or form, which looks to be one of the goals of Child's project, would deliver most of the things I was expecting you to deliver with Command Engine's model format, assuming that whatever Child ends up giving us isn't a cure that's worse than the disease.

All we'd need after that is some improvements to the GUI, and I could build Freelancer II

[Pxtl]

From-scratch rewrites are always FAIL. Part-by-part refactorings like Child's work are a great way to move a project forwards. A well-decoupled engine would be nice - wouldn't it be cool if Spring was well-factored enough that modders could choose to use the Lua/FBI+COB/DotNet interchangeably without losing out on functionality (speed, on the other hand, would probably go down the tubes if you used Lua for unit-animation)?

[eriatarka]

From-scratch rewrites are always FAIL.

Truth.

(speed, on the other hand, would probably go down the tubes if you used Lua for unit-animation)

Wouldn't be so sure about that... Lua is pretty much the fastest scripting language around. (See http://shootout.alioth.debian.org/gp4/b ... l&lang=all for a completely non-representative overview ) This would really need some testing to be sure.

[Lupus]

A program written in scripting language won't run faster than compiled program.

[aegis]

not always correct

if the script is written more efficiently than the compiled program, it is possible... also allows for more flexibility

[jK]

A program written in scripting language won't run faster than compiled program.

Since when is COB a compiled program?
The COB compiler only translates the code text in binary, but it still isn't cpu runable code ... Many scripting languages translate the code this way as well as Lua does.

The only advantage of COB >could< be that it is more slight (and limited) than Lua
(->less language overhead).

[lurker]

Cob is very much compiled, just not to x86 code. Would a lua bytecode file really run on a plain, simple, virtual machine?

[KDR_11k]

Of course using Lua for unit animations is a dumb idea. That's what 3d Studio Max (or <insert other 3d package>) is for! Realistic animation is already hard enough to do, no need to complicate matters by forcing the modder to input every rotation by hand.

[eriatarka]

Cob is very much compiled, just not to x86 code. Would a lua bytecode file really run on a plain, simple, virtual machine?

COB is compiled to bytecode, Lua is compiled to bytecode. Yes, there is a Lua VM. I don't see the big difference. Except that a team of very clever guys has spent years optimizing the hell out of Lua; I doubt that amount of effort has gone into COB.

[LathanStanley]

well from what I understand, they ARE rewriting everything under a totally new project and name..

its kinda, hush hush, but yeah, its in the works for "someday"

tards.

[zwzsg]

Except that a team of very clever guys has spent years optimizing the hell out of Lua; I doubt that amount of effort has gone into COB.

COB is very simple and limited, and has been designed exclusively for animating hundred of units on a 1997 computer. You don't need tons of clever guys to optimise it, because there's already about nothing left to optimise in COB. LUA is versatile and has a much broader scope, and is also a much higher level language, so won't ever be as fast as COB.

[eriatarka]

COB is very simple and limited, and has been designed exclusively for animating hundred of units on a 1997 computer. You don't need tons of clever guys to optimise it, because there's already about nothing left to optimise in COB. LUA is versatile and has a much broader scope, and is also a much higher level language, so won't ever be as fast as COB.

You may be right; however, some tests might actually be interesting. And even if Lua isn't faster, I would be surprised if it wasn't at least roughly on par with COB, speed-wise. Plus the expressive power gained by switching from the rather limited COB to a full-blown scripting language also has its advantages.

But it's probably a moot point, short of someone implementing a new unit animation system...

[imbaczek]

Lua has one problem - to implement COB's sleep you need to yield from a coroutine, and that's not elegant in this language. COB has a massive win here IMHO, purely on aesthetic ground.

[Pxtl]

Lua has one problem - to implement COB's sleep you need to yield from a coroutine, and that's not elegant in this language. COB has a massive win here IMHO, purely on aesthetic ground.

A quick google for yielding reveals that Lua does have a statement called "coroutine.yield" for this case. You'd have to convert all the Lua unitscript methods into coroutines using "coroutine.create" before execution, but it would work.

"coroutine.yield(time)" isn't as elegant as "sleep" but it's not bad.

http://lua-users.org/wiki/CoroutinesTutorial

[imbaczek]

exactly what I had in mind. sleep is elegant, coroutine.create+coroutine.yield isn't. I could deal with that, but I doubt modders would like to wrap their heads around this.

[Pxtl]

exactly what I had in mind. sleep is elegant, coroutine.create+coroutine.yield isn't. I could deal with that, but I doubt modders would like to wrap their heads around this.

Couldn't coroutine.create be handled by the Lua-as-unitscript binding system? Just "coroutine.yield" would be fine. Also, I don't know enough about how Lua works, but could the yield statement be wrapped in a "sleep" function? I mean, in most coroutine languages that's a nonsense concept, but Lua might be different.