Matrix Games Forums

New screenshots for War in the West!Pike & Shot is now available!Server Maintenance Battle Academy 2 gets updated!Deal of the Week: Advanced Tactics Gold Ask Buzz Aldrin!Pike & Shot gets Release Date and Twitch Session!Deal of the Week Espana 1936War in the West coming in December!Space Program Manager will be launching on Steam
Forums  Register  Login  Photo Gallery  Member List  Search  Calendars  FAQ 

My Profile  Inbox  Address Book  My Subscription  My Forums  Log Out

RE: When?

 
View related threads: (in this forum | in all forums)

Logged in as: Guest
Users viewing this topic: none
  Printable Version
All Forums >> [New Releases from Matrix Games] >> World in Flames >> RE: When? Page: <<   < prev  60 61 [62] 63 64   next >   >>
Login
Message << Older Topic   Newer Topic >>
RE: When? - 3/3/2010 3:53:14 PM   
Josh

 

Posts: 2368
Joined: 5/9/2000
From: Leeuwarden, Netherlands
Status: offline
" I spent virtually all of February replacing assembler routines with equivalent Pascal routines. This is still a work in progress but it has improved the performance of the Delphi 2010 IDE (Interactive Development Environment) when executing MWIF in debug mode. Happily, I am now able to examine internal values of variables while the program is running. Things aren’t 100% what they had been when I was running Delphi 2007, but they are ~80% now. Once I get the rest of assembler code replaced with pure Pascal, I am hopeful of getting my debugging efficiency back to where it was a couple of months ago."

Gosh, sounds like one step forward.. and two back But seriously, that's a *lot* of work.
Thx for the update Steve.

(in reply to yvesp)
Post #: 1831
RE: When? - 3/3/2010 5:10:31 PM   
composer99


Posts: 2307
Joined: 6/6/2005
From: Ottawa, Canada
Status: offline
It looks like it's just as well that this problem happened to Steve (as frustrating as it may have been to correct). Otherwise it might have passed on unnoticed and happened to us.

_____________________________

~ Composer99

(in reply to Josh)
Post #: 1832
RE: When? - 3/3/2010 7:24:16 PM   
Zorachus99


Posts: 949
Joined: 9/15/2000
From: Palo Alto, CA
Status: offline
Glad to hear that debug isn't going crazy any longer. I'm sure there was intense internal pressures on your PC to cough up info for the debugger that most likely either wasn't there or couldn't be checked.

At least you are moving toward hardware, and potentially OS independance with your project.

Good luck, and VOG free sunny days coming to you soon - minus the occasional tidal wave.

Cheers!

_____________________________

Most men can survive adversity, the true test of a man's character is power. -Abraham Lincoln

(in reply to composer99)
Post #: 1833
RE: When? - 3/3/2010 7:27:36 PM   
CarnivalBizarre

 

Posts: 11
Joined: 6/16/2009
Status: offline
Uh...

(in reply to composer99)
Post #: 1834
RE: When? - 3/3/2010 8:42:59 PM   
Shannon V. OKeets

 

Posts: 18397
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: oscar72se

quote:

ORIGINAL: Shannon V. OKeets
When we introduce different CPU chips (e.g., dual core and quad core), there can be more than “1 car on the road”. Threading has a similar effect. The operating systems that you are use to running keep several program executing simultaneously and they do that using complex software that works down at the level of the CPU registers. An application written in assembler relies on the CPU registers and call stack being available according to certain rules. If the operating system vender (i.e, Microsoft) or the compiler vendor (Embarcadero) changes those rules, then the program has to be modified to obey the changed behavior.

I don't have any experience of Delphi 2010, even though I had a brief encounter with Delpi in the late 90s IMHO whilst threading is a powerful tool to make asynchrounous calls "off the main thread" it also is a maaaajor source of what I like to call "occult bugs" The problem is that most debuggers have a hard time attaching themselves to external processes, which means that errors "go unhandled" from the main threads POV. Bugs created this way and that don't cause immediate crashes have a tendency of being super hard to find. I have found that a very good approach is to write separate applications that are only used to test the different routines that are to be executed in its' own thread.

Once or twice in my life I have stumbled upon tasks similar to your "migrate-50-year-old-code" to routines that actually makes any sense and that fits into a modern object oriented world. Each time it resulted in me rewriting everything from scratch. I think I have a vague understanding of the scope of your task, so your feat doesn't go entirely unnoticed...

Keep fighting Steve!


Regards,
Oscar

About threading, ...

I am not a fervent fan of threading, but it does have its uses. I see it being useful/essential for monitoring the internet during NetPlay and, to a lesser extent, during PBEM. In both those cases the code executing in a thread separate from the main program's thread will be less than 100 lines.

The more serious use of a second thread will be during AIO play, where the AI Opponent will be figuring out its move while the human player fumbles around with the keyboard, mouse, and his wetware. Your concern about the debugger having trouble tracking down bugs in the second thread is something I'll pay attention to there - now that you have warned about it. Thanks.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to oscar72se)
Post #: 1835
RE: When? - 3/3/2010 8:47:24 PM   
Shannon V. OKeets

 

Posts: 18397
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: yvesp

quote:

ORIGINAL: Shannon V. OKeets
While I was able to replace a lot of the assembler code easily, there were a few places where a one-to-one replacement could not be done. The assembler code more or less took ‘this’ and did ‘that’ to it. Pascal wants all those variables and procedures typed. While the assembler code worked with all variable types and all procedure types, in Pascal separate code fragments are necessary for each variation in the program. There were ~1730 references to one assembler procedure in MWIF. Each of those single line references requires 8-10 lines of new code. Over the course of February I have gotten that count down to 590, while also cleaning up all the other miscellaneous bit of assembler code. I should be able to purge MWIF of the last traces of assembler in the next week. Note that once all the assembler is gone, I will have added ~14,000 lines of new code to the program.


Looks like these assembler procedures were used to do the same thing to different types of data ?
Don't you have genericity in Delphi ?

Yves

Delphi permits some generality for argument passing, but Pascal is stronglytyped. So, when a function is passed, the compiler wants to have information about the argument list so it can check whether the passed function matches. The result is that you need more than one 'universal' function. Here is some of the new code in MWIF:

// ****************************************************************************
// The next 6 routines pass Func or Proc as parameters. In order for the Func
// and Proc to execute correctly, they cannot use any variables that are local.
// All referenced variables have to either be a parameter in the argument list
// of the called Func/Proc or else be global. The module PassedParameters
// defines global variables which are used expressly for this purpose. Care
// must be taken to not use these in recursive calls or nested calls that use
// the same variable.
// ****************************************************************************
function DoesAnyStack(const Func: TStackFunc): Boolean;
function WhichStackDoes(const Func: TStackFunc): TMapStack;
function DoesAnyUnit(const Func: TUnitFunc): Boolean;
procedure ProcessEachUnit(const Proc: TUnitProc);
procedure ProcessEachUnitReverse(const Proc: TUnitProc);
function CountEachUnitReverse(const Func: TUnitFunc): Integer;

...

TUnitProc = procedure(var U);
TUnitFunc = function(var U): Boolean;
TStackFunc = function(var S): Boolean;
THexFunc = function(const Hex): Boolean;
TCoastalProc = procedure(var CD);


_____________________________

Steve

Perfection is an elusive goal.

(in reply to yvesp)
Post #: 1836
RE: When? - 3/3/2010 8:50:47 PM   
SamuraiProgrammer

 

Posts: 338
Joined: 10/17/2004
From: Paducah, Kentucky
Status: offline
If I might be so bold as to add, Delphi Programmers like strict typing. It prevents all kinds of problems from ever being a problem. It does make you have to work a little harder on some things, but you don't have to worry at all about an entire class of bugs.


_____________________________

Bridge is the best wargame going .. Where else can you find a tournament every weekend?

(in reply to Shannon V. OKeets)
Post #: 1837
RE: When? - 3/4/2010 12:56:01 AM   
macgregor


Posts: 968
Joined: 2/10/2004
Status: offline
Thanks for the update Steve. If I'm reading this correctly ...there was a bug that required a reformatting of a lot of the game code, eliminating this 'assembler code' for this new generation of Delphi.

I'm okay with being back to where we were 2 months ago if it means we can now move forward. I imagine there are parts of this game that were written a long time ago(in computer years). Am I to believe the game has been sufficiently re-written to the current standard to move forward full steam now?

What's seemingly not being mentioned is that the game has been suffering from some kind of a major bug that is halting all progress up to now. Right? I mean, the workload hasn't changed. Am I waiting for a 'eureka' moment? Or did one just occur? Someone besides Steve reply if possible. He's got enough to do.

(in reply to SamuraiProgrammer)
Post #: 1838
RE: When? - 3/4/2010 4:07:19 AM   
paulderynck


Posts: 4397
Joined: 3/24/2007
From: Canada
Status: offline
There is no major bug. There was a major overhaul of the development platform that caused a number of unanticipated side effects that took time away from development over the last two months. There is further development and bug fixing still to be done. Details regarding the further development outstanding are provided in previous monthly updates.

_____________________________

Paul

(in reply to macgregor)
Post #: 1839
RE: When? - 3/4/2010 1:14:53 PM   
Joseignacio


Posts: 988
Joined: 5/8/2009
From: Madrid, Spain
Status: online

quote:

ORIGINAL: paulderynck

There is no major bug. There was a major overhaul of the development platform that caused a number of unanticipated side effects that took time away from development over the last two months. There is further development and bug fixing still to be done. Details regarding the further development outstanding are provided in previous monthly updates.


I understand the same.

Keep up the work, Steve!

(in reply to paulderynck)
Post #: 1840
RE: When? - 3/4/2010 3:48:10 PM   
yvesp


Posts: 1859
Joined: 9/12/2008
Status: offline
quote:

ORIGINAL: Shannon V. OKeets

Delphi permits some generality for argument passing, but Pascal is stronglytyped. So, when a function is passed, the compiler wants to have information about the argument list so it can check whether the passed function matches. The result is that you need more than one 'universal' function. Here is some of the new code in MWIF:

// ****************************************************************************
// The next 6 routines pass Func or Proc as parameters. In order for the Func
// and Proc to execute correctly, they cannot use any variables that are local.
// All referenced variables have to either be a parameter in the argument list
// of the called Func/Proc or else be global. The module PassedParameters
// defines global variables which are used expressly for this purpose. Care
// must be taken to not use these in recursive calls or nested calls that use
// the same variable.
// ****************************************************************************
function DoesAnyStack(const Func: TStackFunc): Boolean;
function WhichStackDoes(const Func: TStackFunc): TMapStack;
function DoesAnyUnit(const Func: TUnitFunc): Boolean;
procedure ProcessEachUnit(const Proc: TUnitProc);
procedure ProcessEachUnitReverse(const Proc: TUnitProc);
function CountEachUnitReverse(const Func: TUnitFunc): Integer;

...

TUnitProc = procedure(var U);
TUnitFunc = function(var U): Boolean;
TStackFunc = function(var S): Boolean;
THexFunc = function(const Hex): Boolean;
TCoastalProc = procedure(var CD);


As I understand this, it really means that there are no generics in Delphi like there are in Java, ADA or C++ templates.

What was the rationale behind the choice of Delphi ?
I know you had no choice ; but did Chris tell you why he chose that framework ?

Yves

(in reply to Shannon V. OKeets)
Post #: 1841
RE: When? - 3/4/2010 6:51:19 PM   
Shannon V. OKeets

 

Posts: 18397
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: yvesp

quote:

ORIGINAL: Shannon V. OKeets

Delphi permits some generality for argument passing, but Pascal is stronglytyped. So, when a function is passed, the compiler wants to have information about the argument list so it can check whether the passed function matches. The result is that you need more than one 'universal' function. Here is some of the new code in MWIF:

// ****************************************************************************
// The next 6 routines pass Func or Proc as parameters. In order for the Func
// and Proc to execute correctly, they cannot use any variables that are local.
// All referenced variables have to either be a parameter in the argument list
// of the called Func/Proc or else be global. The module PassedParameters
// defines global variables which are used expressly for this purpose. Care
// must be taken to not use these in recursive calls or nested calls that use
// the same variable.
// ****************************************************************************
function DoesAnyStack(const Func: TStackFunc): Boolean;
function WhichStackDoes(const Func: TStackFunc): TMapStack;
function DoesAnyUnit(const Func: TUnitFunc): Boolean;
procedure ProcessEachUnit(const Proc: TUnitProc);
procedure ProcessEachUnitReverse(const Proc: TUnitProc);
function CountEachUnitReverse(const Func: TUnitFunc): Integer;

...

TUnitProc = procedure(var U);
TUnitFunc = function(var U): Boolean;
TStackFunc = function(var S): Boolean;
THexFunc = function(const Hex): Boolean;
TCoastalProc = procedure(var CD);


As I understand this, it really means that there are no generics in Delphi like there are in Java, ADA or C++ templates.

What was the rationale behind the choice of Delphi ?
I know you had no choice ; but did Chris tell you why he chose that framework ?

Yves

I don't know.

However, I believe that Delphi was a good choice (maybe the right choice).
---
I've written major applications in C++ (> 100,000 lines of code) and one of its weaknesses is it strength: the ability to do whatever you like as far as variable typing is concerned. Often that is done by inserting C code down at a lower level.

There is a substantial amount of code in MWIF that uses pointers, with the variable type being 'cast' onto the abstract pointer. I am not real happy with that code since it is vulnerable to errors that the compiler can not detect. To give you some insight into how I prefer things, I use AU, NU, and LU as variable names for air, naval, and land units. I restrict using U for a unit to those cases where I do not know the branch of service. In comparison, CWIF used U almost exclusively, which provided less information to me (the programmer) when I was reading the code. I also use Bmbr and Fgtr for bombers and fighters if the code fragment has narrowed down the unit type to that degree.

My point here is that by choosing good names for variables and functions/procedures the code is much easily to proof read. If I never see another Void Pointer in my life, I will not shed hot, wet tears. Being able to override the principle purpose of a language (e.g., Pascal: strong typing) is not a good thing in my opinion. It opens the door for creating code that can go flying off into the weeds without any warning. In essence, I deploy "tricky code" since being able to recognize it and remember what it does is difficult 6 months after you have written it.

Most of the 'tricks' are in legacy code (or taught in computer science courses as "neato stuff"), which were written when available memory was at a premium and CPU speed was a driving concern in order to get a program to function at all. Neither of those should be a factor in 99% of the applications written today. [Of course real-time software is an exception.]

Just my highly biased viewpoint.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to yvesp)
Post #: 1842
RE: When? - 3/5/2010 1:58:22 AM   
macgregor


Posts: 968
Joined: 2/10/2004
Status: offline

quote:

ORIGINAL: paulderynck

There is no major bug. There was a major overhaul of the development platform that caused a number of unanticipated side effects that took time away from development over the last two months. There is further development and bug fixing still to be done. Details regarding the further development outstanding are provided in previous monthly updates.

Thank you so much Paul. You gave me just the answer I was looking for. Hopefully this new development platform will prove itself worthy of so much work, and of course that these unanticipated side effects are as minimal as possible. I also hope all this translates to 'We're now able to push forward.' Godspeed Steve!

(in reply to paulderynck)
Post #: 1843
RE: When? - 3/5/2010 9:10:08 AM   
yvesp


Posts: 1859
Joined: 9/12/2008
Status: offline
quote:


I don't know
However, I believe that Delphi was a good choice (maybe the right choice).


Since I have only written once in pascal object, I cannot really tell.

quote:


I've written major applications in C++ (> 100,000 lines of code) and one of its weaknesses is it strength: the ability to do whatever you like as far as variable typing is concerned. Often that is done by inserting C code down at a lower level.
...
My point here is that by choosing good names for variables and functions/procedures the code is much easily to proof read. If I never see another Void Pointer in my life, I will not shed hot, wet tears. Being able to override the principle purpose of a language (e.g., Pascal: strong typing) is not a good thing in my opinion. It opens the door for creating code that can go flying off into the weeds without any warning.


I too hate those void* (which sometimes are even void** or worse!)
You're right, they are holes through which many bugs slip in.

quote:


Just my highly biased viewpoint.


Beeing myself a veteran developper, I fully agree with you (I am also highly biased).
I hope you enjoy yourself on this daunting task!

Keep up the good work, Steve!

Yves

(in reply to Shannon V. OKeets)
Post #: 1844
RE: When? - 3/8/2010 3:00:59 AM   
wif_o_matic

 

Posts: 4
Joined: 1/14/2010
Status: offline
Hey Steve,

How complex is this programming task (doing wif) than the others you have done in your life?

Cheers
Ben

(in reply to yvesp)
Post #: 1845
RE: When? - 3/8/2010 4:56:22 AM   
Shannon V. OKeets

 

Posts: 18397
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: wif_o_matic

Hey Steve,

How complex is this programming task (doing wif) than the others you have done in your life?

Cheers
Ben

Complexity is not really the problem. It is the sheer magnitude of, ..., well, just about everything. If I need to make even a small change, then there are often a 100+ places where that change needs to be made.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to wif_o_matic)
Post #: 1846
RE: When? - 3/9/2010 3:00:51 PM   
wfzimmerman


Posts: 649
Joined: 10/22/2003
Status: offline

quote:

ORIGINAL: Shannon V. OKeets


quote:

ORIGINAL: wif_o_matic

Hey Steve,

How complex is this programming task (doing wif) than the others you have done in your life?

Cheers
Ben

Complexity is not really the problem. It is the sheer magnitude of, ..., well, just about everything. If I need to make even a small change, then there are often a 100+ places where that change needs to be made.


Strictly as a matter of technical interest (not back-seat driving), this sounds like a good argument that more FTEs on the project would have been more effective.

_____________________________

Contribute to the Steve H. thank you book! http://www.nimblebooks.com/wordpress/2009/04/contribute-to-the-wargamers-wwii-quiz-book/

(in reply to Shannon V. OKeets)
Post #: 1847
RE: When? - 3/9/2010 3:42:19 PM   
SamuraiProgrammer

 

Posts: 338
Joined: 10/17/2004
From: Paducah, Kentucky
Status: offline
Speaking from experience, I can tell you that the more people you have on a project, the more time is wasted in 'meetings'.

It is like this... two programmers get the job done in 65% to 75% of the time taken by one - at twice the cost.

Three programmer might get the job done in 40% of the time - at three times the cost.

We have a saying in the business... There are three qualifiers - Fast, Inexpensive, Quality. Pick any 2. You are not allowed to have all 3. EVER!

_____________________________

Bridge is the best wargame going .. Where else can you find a tournament every weekend?

(in reply to wfzimmerman)
Post #: 1848
RE: When? - 3/9/2010 8:28:04 PM   
wfzimmerman


Posts: 649
Joined: 10/22/2003
Status: offline
The flip side of this, of course, is reducing scope. Here we have a contractual and business commitment to a truly ginormous scope.


quote:

ORIGINAL: SamuraiProgrammer

Speaking from experience, I can tell you that the more people you have on a project, the more time is wasted in 'meetings'.

It is like this... two programmers get the job done in 65% to 75% of the time taken by one - at twice the cost.

Three programmer might get the job done in 40% of the time - at three times the cost.

We have a saying in the business... There are three qualifiers - Fast, Inexpensive, Quality. Pick any 2. You are not allowed to have all 3. EVER!


_____________________________

Contribute to the Steve H. thank you book! http://www.nimblebooks.com/wordpress/2009/04/contribute-to-the-wargamers-wwii-quiz-book/

(in reply to SamuraiProgrammer)
Post #: 1849
RE: When? - 3/9/2010 11:55:46 PM   
SewerStarFish


Posts: 304
Joined: 5/7/2007
From: Reading, Pa. USA
Status: offline
I think the only drawback to being so well informed about the progress of MWif is that we see the results of months like February; where little game development is accomplished. The nuts and bolts work is not glorious or satisfing except that its absence can ruin a product. All those "nothing new's" are dishearting to the impatient but what was done will silence some of those inevitable post-release " this game is broke" whiners. Sadly no matter how bug free a product it is, there'll be someone who owns a computer that won't run it -- and they'll post a dozen times complaining (take a look at the Guns of August forum).

Thanks Steve for the updates, and the effort.

(in reply to wfzimmerman)
Post #: 1850
RE: When? - 3/10/2010 8:39:18 AM   
oscar72se

 

Posts: 100
Joined: 8/28/2006
From: Gothenburg Sweden
Status: offline

quote:

ORIGINAL: SamuraiProgrammer

Speaking from experience, I can tell you that the more people you have on a project, the more time is wasted in 'meetings'.

It is like this... two programmers get the job done in 65% to 75% of the time taken by one - at twice the cost.

Three programmer might get the job done in 40% of the time - at three times the cost.

We have a saying in the business... There are three qualifiers - Fast, Inexpensive, Quality. Pick any 2. You are not allowed to have all 3. EVER!


I have a favourite quote (translated from swedish): "-I hate all people that generalize." While there is some truth in what you are saying(in particular the last sentence), I believe that for most projects the optimal work conditions are created in a harmonized group. The irony is that programmers aren't exactly famous for their social skills

Regards,
Oscar

(in reply to SamuraiProgrammer)
Post #: 1851
RE: When? - 3/11/2010 1:46:04 PM   
WIF_Killzone

 

Posts: 224
Joined: 4/30/2009
Status: offline
Using my own PERT analysis to estimate when the game will finally be released using the following assumptions:

Optimistic: 8 Months
Most Likely: 16 Months
Pessimistic: 30 Months

PERT Calculation: (8+(4*16)+30) / 6 = 17 Months

Using a three point calculation (instead of PERT) with same Optimistic, Most Likely, and Pessimistic assumptions:
(8+16+30) / 3 = 18 Months

Feel free to plug in your own numbers :)

Next up, some qualitative risk analysis. What is the likelyhood that using old programming code as the starting point for development will result in a complete or partial re-write of code and hence negatively impact the schedule):

Likelyhood: (1=Low, 5=High) = 5
Impact: (1=Low, 5=High) = 5

5*5=25

Congratuations you made top score. (hehe)

But wait, lets subtract the benefits of using the old programming code as starting point, hmmmm.

Keep plugging away Steve, a bump in the road is all.


(in reply to warspite1)
Post #: 1852
RE: When? - 3/11/2010 2:28:39 PM   
WIF_Killzone

 

Posts: 224
Joined: 4/30/2009
Status: offline
My only real concern from a risk point of view is the "Hit by Bus" risk. What is the risk response to that one besides sending flowers? What a subject, (brrrrr), but it does have the highest impact of all risks (followed closely by Matrix going tits up). It is also one of the least likely to occur (thankfully). From a risk response point of view Steve, I hope the code has been placed in Escrow for your Wife (or family) or some other agreement is in place. This is a huge investment you have made in terms of time and therefor $$ if an act of god were to occur.

Geez, why am I thinking like this--do not respond Steve. (just wanted to make sure your aware which I'm sure you are).

(in reply to WIF_Killzone)
Post #: 1853
RE: When? - 3/11/2010 2:30:13 PM   
Triboga


Posts: 18
Joined: 11/4/2009
From: Alicante
Status: offline
Don't waste your time reading that Steve and keep working! , I'm eager to beat my friend pinkpanther again, after few years. Scared he even moved out from our city (well, probably his girlfriend has somthing to be) without resolve the question who’s better playing WiF after some games and different scenarios. Well, is obviously for me but not for him and this is our chance to put this on trial

_____________________________

"Prefiero arrasar un país que dejarlo en manos de Herejes"

http://elgrancapitan91.blogspot.com/

(in reply to WIF_Killzone)
Post #: 1854
RE: When? - 3/11/2010 2:36:00 PM   
WIF_Killzone

 

Posts: 224
Joined: 4/30/2009
Status: offline
Yes, and don't leave the house or eat any strange spicy foods. And work dammit-work!!

< Message edited by WIF_Killzone -- 3/11/2010 2:37:12 PM >

(in reply to Triboga)
Post #: 1855
RE: When? - 3/11/2010 5:11:43 PM   
WIF_Killzone

 

Posts: 224
Joined: 4/30/2009
Status: offline
So given Parkinsons law that work will shrink or expand to fit the time available, can we now set an aggresive date with say two months contingency to account for the unexpected, and work towards that.

Say T + 12 Months.

I'm such a brat.

(in reply to WIF_Killzone)
Post #: 1856
RE: When? - 3/11/2010 6:55:12 PM   
macgregor


Posts: 968
Joined: 2/10/2004
Status: offline
I guess right now we're waiting for the assembler code to be re-written into this Pasqual. Until that is accomplished, we can expect no progress. Am I to believe this is not finished yet? If not I hope Steve lets us know when it's finished so we can finally, hopefully, have some idea of how long this thing may take.

Am I also to believe that the AI will still present many intangible delays that are impossible to predict, only to the effect that it still may take several years? All I can say to that is ...BUMMER.

But alas, I make one request as I delete this bookmark. Steve please let me know when this project is making tangible progress again. While discussing computer programming may be entertaining to those in the field, the pace of progress is going to drive me crazy.

I have got to take a break from visiting this forum, which translates to forgetting about MWiF. If I'm still at the same email, the most I can hope for is the pleasant surprise that I may still be alive to see the release.

(in reply to WIF_Killzone)
Post #: 1857
RE: When? - 3/15/2010 9:42:33 PM   
CarnivalBizarre

 

Posts: 11
Joined: 6/16/2009
Status: offline
I work in a team of five on a software project, and we have a meeting per alpha release, which is around 6 weeks apart.

Though when taking on a new team member people have a bit of a hard time to contribute 100% I would say that working on a team is rather more productive per hour than working alone, if the team has the right members. But if you work with 20 or so people or more I guess it would be hard to keep such a team productive...

Also, Steve, if you need to change on 100 places to make one change, something needs to be done, Is the inherited code really that bad? Code Refactoring is your friend...

(in reply to macgregor)
Post #: 1858
RE: When? - 3/16/2010 4:44:23 AM   
Shannon V. OKeets

 

Posts: 18397
Joined: 5/19/2005
From: Honolulu, Hawaii
Status: offline

quote:

ORIGINAL: CarnivalBizarre

I work in a team of five on a software project, and we have a meeting per alpha release, which is around 6 weeks apart.

Though when taking on a new team member people have a bit of a hard time to contribute 100% I would say that working on a team is rather more productive per hour than working alone, if the team has the right members. But if you work with 20 or so people or more I guess it would be hard to keep such a team productive...

Also, Steve, if you need to change on 100 places to make one change, something needs to be done, Is the inherited code really that bad? Code Refactoring is your friend...

The assembler code used one routine to call 1700+ different functions (a generic 'loop' capability). To replace all those calls with loops required unique control variables for the loops - since they can be nested. Not all the variables have to be unique, but many do. In any event, replacing a single line of code with 8-12 lines of code is not something refactoring handles. In Pascal, the variable are defined in one location and then the loop occurs later.

In some cases I was able to do a one-to-one replacement, and in those cases refactoring would have worked. However, the functions that were called needed to use 'global' variables, since the 'new' calling function was unable to access local variables. So, I needed to examine each of the functions that was called to make sure none of the variables it used were local.

_____________________________

Steve

Perfection is an elusive goal.

(in reply to CarnivalBizarre)
Post #: 1859
RE: When? - 3/20/2010 5:06:41 PM   
gilderan

 

Posts: 3
Joined: 3/3/2004
Status: offline
Steve,

To say this is a monumental piece of work is understating it somewhat

Thanks for the regular updates - it has been a while but I will read through the 60 plus odd pages and do some catching up.

The screenies look really good mate.

Cheers
-Gil

(in reply to hbrsvl)
Post #: 1860
Page:   <<   < prev  60 61 [62] 63 64   next >   >>
All Forums >> [New Releases from Matrix Games] >> World in Flames >> RE: When? Page: <<   < prev  60 61 [62] 63 64   next >   >>
Jump to:





New Messages No New Messages
Hot Topic w/ New Messages Hot Topic w/o New Messages
Locked w/ New Messages Locked w/o New Messages
 Post New Thread
 Reply to Message
 Post New Poll
 Submit Vote
 Delete My Own Post
 Delete My Own Thread
 Rate Posts


Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI

0.152