| |
Debugging VERGE 1 Displaying 1-8 of 8 total.
1
LordGalbalan
|
Hi, um I've taken it upon myself to debug VERGE 1. I'm undertaken this responsibility now because my Simulation Framework is completed. The JS version of the Simulation Framework can be seen here.
www.livejournal.com/users/lordgalbalan
The VERGE versions, among others, are forthcoming.
Any who desire may help by either posting bug reports here or emailing them to me at lordgalbalan@email.com . Please provide the conditions, to the best of your ability, under which the bugs do occur. Also provide the consequences of the bug's activity, whether the screen is garbled or the program is closed, or worse. I would be grateful if the VERGE development team would send me their bug report records, sufficient that I can identify as many bugs in the software as possible. I am debugging the latest version of VERGE 1 DOS. I am aware that some bugs may not be proper to VERGE 1 itself, but are inherited from the software libraries native to VERGE's sound output system. I will not undertake the analysis of libraries external to VERGE at this time.
I am undertaking these tasks in the spirit of developing optimal bug analysis formulae, to better diagnose operational deviations in systems of any design. Furthermore, in its current state VERGE is not stable enough to warrant the implementation of the Simulation Framework by myself as a special case of the VERGE C coding convention. The implementation thereof is a goal of mine. My research will be released to the Public Domain.
Posted on 2003-09-16 14:38:47
|
veclitna
|
Yay for useless goals.
Posted on 2003-09-16 16:21:28
|
grenideer
|
I didn't know verge1 had too many bugs. Off the top of my head I can't really think of any, but it's been a while.
If you want to REALLY test your bug analysis formulae, try your system on the latest version of WinVerge. And let me have the fixed version :).
Posted on 2003-09-16 17:18:07
|
andy
|
You really should get the newest WinV1 or neoVERGE and use that instead. The code in both is much improved. (neoVERGE is based on WinV1, so... yeah)
That aside, there are a thousand thousand little issues that you will not be able to fix without breaking games. There are countless internal and interface inconsistencies.
One that comes to mind is that PartyIndex(n) was sometimes expected to be zero-based, and other times one-based. I even made a macro for PartyIndex(n)-1, since it was necessary so frequently.
This isn't really a bug, but the menu code could be condensed to less than a third of its present size by factoring the commonality out and OOPifying the whole shebang.
A lot of the internal data structures could be replaced with STL containers. Extra bounds checking is most likely necessary in more than a few places as well.
If you have any problems, you can email me. I know my way around the V1 source fairly well.
Good luck. You'll need it. ^_~
SOULBAIN WHY IS MY USER INFORMATION NOT ABOUT ME ANYMORE WHY IS IT ABOUT YOUR WONDERFUL PHP SKILLS MAN I DON'T GET IT WHAT IS WRONG WITH YOU
Posted on 2003-09-17 11:09:50
|
LordGalbalan
|
Well I've been looking over the source. There are no syntax errors. Not a one. As for the problem you presented, there is only one solution of prime effectiveness. The function PartyIndex must be instructed to examine the VC source itself and to identify which of the array bound cases is being applied. Accordingly, the source of the function must be duplicated for each case. That's the best answer I can give, and I've given the situation a lot of thought. Either way the problem is solved, a vice must be accepted.
Object orientization may make the code more difficult for inexperienced programmers to make sense of. Bounds checks are probably not an issue because this code is quite rigorous, like that of a mathematician's. ENTP or INTP is probably the personality type of the author.
Posted on 2003-09-23 21:48:41
|
andy
|
Getting VC to guess what the coder had intended is doomed to failure. You're either going to have to fix it, or you're going to have to leave it broken.
Which source are you looking at? O_o There's all kinds of stuff like
switch (var)
{
case 0: flags[arg1]=value; return;
floating around in there. Note that arg1 is an integer provided from VC; providing a negative or too-large value will almost certainly cause the engine to explode.
SOULBAIN WHY IS MY USER INFORMATION NOT ABOUT ME ANYMORE WHY IS IT ABOUT YOUR WONDERFUL PHP SKILLS MAN I DON'T GET IT WHAT IS WRONG WITH YOU
Posted on 2003-09-25 09:09:09
|
LordGalbalan
|
My strategy is to have VC look at the value supplied by the user at each iteration of the program. If the base is 1, then the code for the program will be executed with 1 as base. Else if the provided base is 0, then the code will be executed with 0 as base. The code effecting the PartyIndex function itself will be within this conditional block. It'll be slightly slower than before, but workable.
We may not be using the same source version. The source version I am using is the Verge 1 DOS source available from VergeSource.
Posted on 2003-09-25 18:15:28
|
andy
|
You can't just guess whether a value is 0 or 1 based by looking at it. (except when it's 0) The call may or may not be in a conditional block; and you won't know anyway, unless you want to rewrite the VC engine to make such deep introspection possible. Further, the base isn't 0 or 1 for a given span of VC, it's 0 or 1 depending on which builtin function you're using, so such introspection is useless.
If anything, winV1 and neoVERGE have *more* error checking than DOS v1 does. (by far) Anything gaping holes that are still in those builds is also in DOS v1.
SOULBAIN WHY IS MY USER INFORMATION NOT ABOUT ME ANYMORE WHY IS IT ABOUT YOUR WONDERFUL PHP SKILLS MAN I DON'T GET IT WHAT IS WRONG WITH YOU
Posted on 2003-09-26 22:35:23
|
Displaying 1-8 of 8 total.
1
|
|
