(for devs)If you would recreate Spring again from zero?
Moderator: Moderators
(for devs)If you would recreate Spring again from zero?
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!
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
- Classic Community Lead
- Posts: 7287
- Joined: 12 Aug 2005, 09:29
Re: (for devs)If you would recreate Spring again from zero?
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
- Lobby Developer
- Posts: 1164
- Joined: 25 Sep 2006, 13:56
Re: (for devs)If you would recreate Spring again from zero?
this is not a rewrite, but gets pretty close, at least regarding rendering part
viewtopic.php?f=12&t=13772&start=0
viewtopic.php?f=12&t=13772&start=0
Re: (for devs)If you would recreate Spring again from zero?
Yeah, this is similar to how apples are pretty close to penguins.this is not a rewrite, but gets pretty close, at least regarding rendering part
Re: (for devs)If you would recreate Spring again from zero?
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
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
Re: (for devs)If you would recreate Spring again from zero?
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)?
Re: (for devs)If you would recreate Spring again from zero?
Truth.Pxtl wrote:From-scratch rewrites are always FAIL.
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.(speed, on the other hand, would probably go down the tubes if you used Lua for unit-animation)
Re: (for devs)If you would recreate Spring again from zero?
A program written in scripting language won't run faster than compiled program.
Re: (for devs)If you would recreate Spring again from zero?
not always correct
if the script is written more efficiently than the compiled program, it is possible... also allows for more flexibility
if the script is written more efficiently than the compiled program, it is possible... also allows for more flexibility
Re: (for devs)If you would recreate Spring again from zero?
Since when is COB a compiled program?Lupus wrote:A program written in scripting language won't run faster than 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).
Re: (for devs)If you would recreate Spring again from zero?
Cob is very much compiled, just not to x86 code. Would a lua bytecode file really run on a plain, simple, virtual machine?
Re: (for devs)If you would recreate Spring again from zero?
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.
Re: (for devs)If you would recreate Spring again from zero?
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.lurker wrote:Cob is very much compiled, just not to x86 code. Would a lua bytecode file really run on a plain, simple, virtual machine?
- LathanStanley
- Posts: 1429
- Joined: 20 Jun 2005, 05:16
Re: (for devs)If you would recreate Spring again from zero?
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.
its kinda, hush hush, but yeah, its in the works for "someday"
tards.
Re: (for devs)If you would recreate Spring again from zero?
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 wrote: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.
Re: (for devs)If you would recreate Spring again from zero?
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.zwzsg wrote: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.
But it's probably a moot point, short of someone implementing a new unit animation system...
Re: (for devs)If you would recreate Spring again from zero?
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.
Re: (for devs)If you would recreate Spring again from zero?
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.imbaczek wrote: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.
"coroutine.yield(time)" isn't as elegant as "sleep" but it's not bad.
http://lua-users.org/wiki/CoroutinesTutorial
Re: (for devs)If you would recreate Spring again from zero?
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.
Re: (for devs)If you would recreate Spring again from zero?
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.imbaczek wrote: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.