Ambrosia Garden Archive
    • blackhole, on Dec 2 2004, 12:09 PM, said:

      Why is everyone so obsessed with converting to Windows BitMap (.bmp)? It's not going to help anything.

      Actually, it does. I don't know why, or what it was that Lindley was doing before, but several of the systems in his plugin were crashing when you landed on the planet, but they don't now. Thus it evidently is helping something by converting to .bmp, or .tiff.

    • They were jpeg before. WinNova didn't like that.

    • Belthazar, on Dec 2 2004, 01:16 PM, said:

      Actually, it does. I don't know why, or what it was that Lindley was doing before, but several of the systems in his plugin were crashing when you landed on the planet, but they don't now. Thus it evidently is helping something by converting to .bmp, or .tiff.
      View Post

      No, it doesn't. What does matter is how it got in the resource fork. Because PICT (again, like BMP) is a wrapper format it is possible to do odd things. Normal PICTs and BMPs are straight, well, bitmaps. Every single pixel is represented by a discrete value. Optionally these can be compressed. I believe bitmaps support JPEG compression internally - I've seen it around, but it never caught on. PICTs support a basic RLE.

      Now, if you copy to the clipboard you normally get a straight PICT, but you might get a compressed image. If you save directly to the resource fork, who knows what you'll get there. But what ResEdit reads will be a PICT, not a tiff or jpg. The clipboard is a funny thing.

      I would assume that QuickTime on Windows can't handle a peculiar variant of PICT that either Photoshop or ResEdit saves as in certain conditions. That's the problem, not the source image type.

    • Alrighty, here it is, ZP. It should be cross-platform compatible, I think, since I saved it in .rtf format. Those are all the ones I remember at the moment, although there may be another one regarding the s˙st resource, and specifically the pers and dude fields and their respective probabilities, but I'm not certain of that one. If anyone else has spotted one I've missed, point it out to me.

      Attached File(s)

    • blackhole, on Dec 2 2004, 05:38 AM, said:

      No, it doesn't. What does matter is how it got in the resource fork. Because PICT (again, like BMP) is a wrapper format it is possible to do odd things. Normal PICTs and BMPs are straight, well, bitmaps. Every single pixel is represented by a discrete value. Optionally these can be compressed. I believe bitmaps support JPEG compression internally - I've seen it around, but it never caught on. PICTs support a basic RLE.

      Now, if you copy to the clipboard you normally get a straight PICT, but you might get a compressed image. If you save directly to the resource fork, who knows what you'll get there. But what ResEdit reads will be a PICT, not a tiff or jpg. The clipboard is a funny thing.

      I would assume that QuickTime on Windows can't handle a peculiar variant of PICT that either Photoshop or ResEdit saves as in certain conditions. That's the problem, not the source image type.
      View Post

      My understanding is that some convertors are lazy and just put the original image data in PICT wrapping if they can. Thus the importance the original file format can take. I'd suggect everyone (instead of using odd preconverting schemes) to save in whatever format their landscape program/Photoshop if you did posterior tweaking/ allows, open it with Preview, and export it as PICT, making sure the compression settings (in a window you can invoke by clicking a button in the export dialog) is set to "none". Then you have a safe, bimap PICT file. To put it in a resource in the resource fork, the best would be to rename the PICt file to r.128, put the PICT file in a folder named "PICT", put this folder in another folder, and implode this folder with ResPloder (basically doing the converse operation to what's on the website). You then have a resource file with a single PICT resource, that you can then copy to your plug using ResEdit/MC/anything else. I don't know much more about PICT, I'll try to read some Apple dev docs about it.

      Nice list, Belthazar; are you sure the PICT-internal-compression-format problem gives problem only with the planet landscapes? This would suggest that QT on Windows can handle them (since it handles the other PICTs elsewhere the same plug-in developer made), but there is a specific problem there.

    • It would be nice if some type of compression were supported. Using Bitmap-picts rather than jpeg-picts increases the file size dramatically.

    • Zacha Pedro, on Dec 3 2004, 01:21 AM, said:

      Nice list, Belthazar; are you sure the PICT-internal-compression-format problem gives problem only with the planet landscapes? This would suggest that QT on Windows can handle them (since it handles the other PICTs elsewhere the same plug-in developer made), but there is a specific problem there.

      No, I'm not sure of that. I did consider it, yes, but I haven't had a chance to test it with shipyard and outfitter images (and other sorts) yet.

    • Lindley, on Dec 2 2004, 08:00 PM, said:

      It would be nice if some type of compression were supported. Using Bitmap-picts rather than jpeg-picts increases the file size dramatically.
      View Post

      That's for sure, but I don't think we can trust anything else that bitmap PICTs. Besides, EV and EVO live very well with bitmap PICTs (be it the original games and the Nova TCs). Maybe some other compression inside the PICT work on PC, but some more testing needs to be done to be sure. At any rate, people should make sure it is saved in thousands of colors, it will help.

    • Ah! I remembered another crash on PC Nova! If an Mxxx or Nxxx operator is used in an NCB set expression for a mďsn resource while the player is in flight , then the game will crash when the player tries to land, unless they first return to the main menu, and enter their ship again. In fact, not only does it crash, but the pilotfile becomes completely corrupted. That's one of the difficulties that UT was having with the Kobayashi Maru mission in the SFA alpha. (I'm wondering if maybe some of the problem was caused by the fact that the game was also trying to evaluate an Hxxx operator at the same time...)

    • Thank you Contraband, for making Retribution unplayable on PC Nova.

      I love you guys :evil:.

      Is anyone making a list of known PC Nova quirks and issues that cause the game to crash?

    • UE_Research & Development, on Dec 7 2004, 06:06 PM, said:

      Thank you Contraband, for making Retribution unplayable on PC Nova.

      I love you guys :evil:.

      Is anyone making a list of known PC Nova quirks and issues that cause the game to crash?
      View Post

      I think Blethazar had an attachment with a list above.

    • Yah, I am making such a list. I am ignoring bugs which occur regardless of what plugins are running, and only including the ones which plugin makers can actually avoid.

    • I'd be curious about the former catagory as well.....

    • Well, there is one bug where the game would crash if the player did the following sequence of events:

      1. Hit 'esc' to return to the main menu without the pilot dying
      2. Load a new pilot (or re-loading the same)
      3. Enter the ship, and open the map or player info window
      4. Hit "Done"

      Pretty obscure, but quite annoying. Nothing else actually springs to mind at present. Oh, except for the non-scrolling dëscs on planets, anyway. And there was that thing I mentioned to you earlier about "Navigational Deflector" being too long for the space on the Player Info dialogue box.

    • Yeah, scrolling descs would be helpful in a lot of places. Even on the mac there's a planet desc that's cut short. Sirius II or Sirius Prime, I forget which.

    • You are in luck. I'm a PC user and I've got EVNEW. Hit me with the stuff you want and I'll try and bounce back.