CompuServe Messages

for PC Imagine 3.2 feedback report ————————— First off, I want to make sure you guys understand that I am a great fan of Imagine (for both Amiga and PC), and do my best to promote the program whenever I get the chance. I take pride in the fact that a program such as Imagine had its roots in the Amiga universe. However, It has always been a bit of an embarrassment to have to admit that upon each subsequent update of the program, some key feature or portion of the program has been 'broken'. Worse yet, the problems introduced were so obvious that beta-testing, or final Software QA testing could not have been performed on the version shipped to customers. (remember the stuck starfield in 3.0? I personally know of two professional users who switched to another product when you refused to correct this problem in a timely manner. I really felt bad when this happened). Having said that, and with the hope that you are still reading this, I again request that I be allowed to be an active beta- tester of Imagine (both Amiga / PC versions). I am a professional C++ systems developer with almost 20 years experience in high and low level programming. I have been writing protected-mode programs on the PC for over 5 years, and understand 'what it takes'. Please take this offer seriously- My goal is to help ensure that when Imagine is shipped to customers in the future, that it is a fully (as possible) tested and characterized product. At the end of this letter are several suggestions which you should also take very seriously. Bug Reports ———– These problems were verified to occur on 3 different systems, all different manufactures, some of them pentiums. 1. Upon execution of Imagine 3.2, I am presented with a very large requester: "Requested screen mode is not supported through VESA interface" Funny thing is, I was running the config file shipped with 3.2, and VESA drivers were not loaded. The error message still appears with VESA drivers loaded. (this did not occur on the Pentium running VESA drivers). 2. The default colors for Imagine editors (detail/stage etc.) were set to a blinding bright blue instead of the normal subdued gray. upon accessing the prefs screen, the grid color was shown to be 66d (close to the 666 of 3.1). I suspect a developers personal prefs file got shipped instead of the 'customer' file. also: QPTH = c:\imagine should be c:\im32 or d:\im32 QUIK = PC 480 should be PC Lores QURM = Trace should be Scanline GRID = 66d should be 666 I recommend not making radical changes to such defaults from release to release. Especially in the case of QURM, which caused that first quickrender to take all day….. The prefs editor could possible be written such that fields with a finite number of 'mode' selections would present a multiple-choice requester, instead of forcing the user to guess what valid choices might be. This is especially true on the Qrender display mode (PC Lores, PC 400, PC 480 etc.). 3. While in the staging editor, primitive spheres from 3.0/3,1 projects are no longer visible in the perspective window. As such, projects created with 3.0/ 3.1 cannot be dealt with by the 3.2 stage editor. This seems similar to the problems we had when 2.9 came out where parts of 2.0 projects and objects just 'disappeared'. Trivialities ———— 1. Prefs editor. The SCRL field has a typo. 'precantage' should be 'percentage' (very old typo). 2. In keeping with MSDos programming convention, Entry of "IMAGINE /?" on the command-line should present the user with a short list of valid command-line arguments. The only arg I know of is '/noxms', which I have to use. 3. In the detail/stage editor- if the map/texture file for an object cannot be found, the render is aborted. It would be VERY helpful it the requester would indicate which object or group contained the missing map/attrib. 4. There are always an awful lot of typos in the readme and doc files shipped with imagine. Summary ——- The bugs as listed above make Imagine 3.2 unusable. I really hate to see this happen, especially when it could so easily be avoided. The last 3 releases have had similar problems, but not as bad as this one. If you want to remain a software supplier in today's market, you must take QA seriously- I wish I could be there to help (really!). Several easy steps to reduce 'bugs' as seen by the customer: ———————————————————— 1. Install and operate a BBS system or internet FTP site that has a COMPLETE image of the beta version of Imagine, including all subdirectories. 2. Make this .zipfile (.lha for Amiga) available to all beta testers (with signed non-disclosure agreements) so that more testing than you can do in-house can be performed. 3. When you arrive at what you feel to be a stable version ship the uncompressed contents of the .zipfile your beta testers have been using. * This prevent surprises that result from last-minute tweeks by the developers (which ALWAYS have unexpected side-effects). * Since the end-users are installing the exact same code the beta-testers have been pounding on, you ensure that no files are missing in the release, and no silly clerical errors have crept into the distribution process. (remember the missing icon on Amiga Imagine 3.1 ?). 4. Provide a mechanism where users can submit bug-reports. There is currently no way for users to report problems to the Imagine developers. The phone support folks cannot and should not be required to do this, and should inform customers how to submit a bug report via email. The current method of writing a letter is a black-hole. I have reported the same bugs via mail for several releases now… I have tried to report bugs via Compuserve- but was instructed to never do this again. The readme.now sent with 3.2 is a move in the right direction in that you should ALWAYS tell the user which problems have been addressed in the current version. Please continue the tradition. Closing ——- Again, I request that I be added to your beta test program. I hate to see a fantastic program like imagine crippled by easily prevented problems that are so trivial in cause, yet so utterly fatal in effect. Thanks. Ron Flory Senior Avionics Software Engineer IFR Systems, Inc. Wichita KS 67215 355 Cherokee drive Kechi KS 67067-0278 Imagine User # 9810, 9617