Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
investigators and programmers needed!
Im praying that future developments will make what Im about to say irrelevent, but perhaps we should start preparing ourselves....
As is being discussed over here, it looks like the Mac version of EVN 1.0.9 is much pickier than previous versions about the PICTs it will display properly. Since this doesnt affect the stock Nova scenario, pipeline is saying that this isnt going to be changed. Thats not totally unreasonable -- ASWs primary interest is in the playability of the game as shipped.
But a bunch of plugs are negatively impacted. So far, developers have discovered problems with PlugPack V16, Starfleet Adventures, rEVisited, and Aftermath -- and thats just in the first few hours since 1.0.9 was released. My expectation is that in the next year were going to be hearing about this problem over and over on the webboards. Why are my graphics all turning red? is going to be up with requests for Multiplayer and 3D EV4 as one of the annoying questions we all get sick of repeatedly answering.
So its up to us to head this off! pipeline has described the process that ATMOS used to create its unaffected PICT resources. Its a great help to know that, but it strikes me as rather a lot of work for large projects.
I bet theres a better way. Its going to take some work on our part, though.
First, we need to thoroughly investigate the problem -- on what systems does it occur, what programs and methods cause it, etc. Does anyone have a way to peer at PICT resources that lets you directly identify their type of content (encoding or whatever)?
Then (unless ASW decides to fix the bug after all) we need to figure out automation routines that will let us churn through piles of resources in reasonable amounts of time. ATMOS used Photoshop -- if someone can make a batch processor for that program it would be useful to many of us but, for others, Photoshop is financially out of reach.
Ultimately, Id like to see a free utility app and/or script that will let even players drag and drop their downloaded or self-built plugs to automatically rejigger all the faulty PICTs in em.
Thats what I think, anyway. Go team go!
This post has been edited by Dr. Trowel : 21 December 2005 - 03:08 PM
I'd volunteer to test it. I'm running an iBook with 10.4.3.
Thanks, Mac -- nothing to test yet, tho!
OK -- I'm low on time, but I just tried BlitZen, looked at the results in-game, and then opened the plug in GraphicConverter (just drop the plug on the GC app -- it gives you a list of PICT resources). I think what I see is that the red graphics are ones that have millions of colors (24/32 bit); Blitzen fixes these by converting them to 16 bit (thousandes of colors). MISSING graphics still occur after using BlitZen; my guess is that that is because 1.0.9 no longer tolerates 24/32 OR 16-bit MASKS -- your masks now have to be just black and white (1 bit). I haven't tested that yet, though.
Can anyone replicate or extend my tests? I'm going to have to leave off investigating for a while -- holiday duties call!
Here's what I did to fix the rEV graphics issues for the PC version, which now also appear on mac 1.0.9 and the same fix works for it too: ConText -> Batch convert with GC -> ResStore -> Done!
This post has been edited by Guy : 21 December 2005 - 06:11 PM
Or perhaps we can move into a new version.
The bug will be fixed, so sayth pipeline!
Will the bug be in the windows version as well??
This post has been edited by darth_vader : 22 December 2005 - 06:44 PM
Guy, on Dec 21 2005, 03:56 PM, said:
Here's what I did to fix the rEV graphics issues for the PC version, which now also appear on mac 1.0.9 and the same fix works for it too: ConText -> Batch convert with GC -> ResStore -> Done! View Post
Batch convert with what parameters?
darth_vader, on Dec 22 2005, 05:44 PM, said:
Will the bug be in the windows version as well?? View Post
No, but WinNova 1.0.9 seems to have its very own horrendous bug -- check Slouch's post in the "(ANN) -- Ambrosia releases EV Nova 1.0.9" topic.
This post has been edited by Dr. Trowel : 22 December 2005 - 07:30 PM
Dr. Trowel, on Dec 22 2005, 01:30 PM, said:
Batch convert with what parameters? View Post
Convert to same folder and format. Other settings don't matter. Might not expect that to work but it did for me.
This post has been edited by Guy : 22 December 2005 - 08:39 PM
Just out of curiousity, has anyone tried using, say, Mission Computer to save their plugs as .rez files, and then convert them back to a Mac plugin, to see if that fixes things?
I ask because it's also related to a possible problem with Mac users having trouble with Windows files. As the author of a Windows plugin, I am highly interested in whether or not it works properly on Macs. This is the kind of problem that could give me (and all Windows users) headaches, as my plugin works fine on my own Windows computer.
I've mentioned the same in this post on the Nova board, but no responses as of yet:
http://www.ambrosiasw.com/forums/index.php...dpost&p;=1508945
GutlessWonder, on Dec 22 2005, 10:22 PM, said:
Just out of curiousity, has anyone tried using, say, Mission Computer to save their plugs as .rez files, and then convert them back to a Mac plugin, to see if that fixes things?View Post
That would be highly unlikely, I'm afraid - despite the difference in the format of the container file, the actual resources are identical bit-for-bit between Npďf and .rez plug-ins.
Dr. Trowel, on Dec 21 2005, 08:21 PM, said:
1.0.9 no longer tolerates 24/32 OR 16-bit MASKS -- your masks now have to be just black and white (1 bit). View Post
My Noir shield graphics problem just got 860% worse. :mad:
Hamster, on Dec 23 2005, 04:01 PM, said:
My Noir shield graphics problem just got 860% worse. :mad: View Post
Actually, I haven't systematically confirmed that non-1-bit masks are causing the disappearances -- that was a guess, as I tried to indicate when I wrote that. I doubt I'm going to have time to test the theory in the next few days, though.... Perhaps someone else will do / has done it? (If anyone tries on a Mac, you'll want to work with ResEdit instead of MissionComputer, which tends to bump graphics up to 32-bit. You can use GraphicConverter's "Information" palette to see the bit depth of your images.)
Come to think of it, there may be a different (or additional?) cause of disappearing graphics -- sidebar target graphics have vanished from UncleTwitchy's Starfleet Adventures, and those don't use masks.
Hamster, you also have the option of waiting for ASW to fix the bug.... but of course there's no guarantee as to when they will succeed and release... do you suppose they'll call it 1.0.10? 1.1? 1.0.9.1? And will they delay releasing until the beam bug is also fixed? Time will tell.
This post has been edited by Dr. Trowel : 23 December 2005 - 05:53 PM
I would have loved to be able to investigate and fix this. Unfortunately, while it is the holidays it doesn't mean more free time to me - quite the contrary: I have familial obligations and stuff. Plus, see Mackilroy's avatar. Yes. Not only that, but I'm addicted.
However, I know of one or two ways to put a PICT from a PICT file to a PICT resource. One involves ResStore, but it might be a bit complicated to build the file necessry for the resource to be made by hand, since it does not come from ConText'ing of a resource file. The other way involves ResPloder (look for it at VersionTracker), and it's quite simpler.
Therefore, you can export your creations as PICT using just about anything that uses QuickTime for export (say, Preview). In the PICT options, make sure to specify the bit depth you need (especially, 1-bit for masks, plus it makes them lighter), though for colors you need 16-bit but QT might not do an ideal dithering (the operation that generates patterns of the closest colors in order to best match a color that doesn't exist in 16-bit), better let BlitZen do its job. Also, make sure to set compression to none - better all around, I think.
Zacha Pedro, on Dec 24 2005, 11:09 AM, said:
Also, make sure to set compression to none - better all around, I think. View Post
You nailed it there. 1.0.9 doesn't like compressed PICT's, whereas the previous versions were fine with any that Quicktime could understand.
It's actually quite a simple process (for dev's at least) to just process all your files with BlitZen (just drag-and drop all plugin files containing PICT's onto BlitZen, and select 16-bit, dither on, no compression), then take the PICT resources from the resulting files and copy them back into your standard plug files. Once I figured out what was necessary, it only took me 15 minutes or so to do all of Aftermath.
With that in mind, it also shouldn't be particularly difficult to write a simple app that will take a file as input, and convert all PICT resources to the uncompressed format inside the same file. I'll get working on it.
Andcarne, on Dec 30 2005, 11:38 PM, said:
You nailed it there. 1.0.9 doesn't like compressed PICT's, whereas the previous versions were fine with any that Quicktime could understand.View Post
Yes, that fits with what I've been running into. For that program of yours, do be sure to have it convert 1-bit compressed to 1-bit uncompressed, rather than any other bit depth, so that sprites will work properly.
Edwards
Sprites, provided they're rle'd, aren't affected by this bug. I assume this is because the necessary conversions are done when using enRLE. And if you're using PICT based sprites, it's probably a good idea to change them all into rle8's/rleD's.
With luck, the PICT bug has now been sorted so that any QuickTime compression can be used.
A new development build of the engine has been released to test this, and a number of other bugs.
Please note that while it will restore compressed PICT functionality, I still heartily recommend against using compression in Nova PICTs, for a variety of technical reasons that I've listed previously.
Dave @ ATMOS
Andcarne, on Jan 2 2006, 07:16 AM, said:
And if you're using PICT based sprites, it's probably a good idea to change them all into rle8's/rleD's. View Post
Abso-fraggin'-lutely. The PICT sprites option was only ever kept in to allow an easy transition for developers who were still on EV/EVO time, as it were. It was also there so that Nova would continue to boot while ATMOS was part-way through the transition from PICT sprites to RLE sprites.
Andcarne, on Jan 1 2006, 12:16 PM, said:
Sprites, provided they're rle'd, aren't affected by this bug. I assume this is because the necessary conversions are done when using enRLE. And if you're using PICT based sprites, it's probably a good idea to change them all into rle8's/rleD's.View Post
There is one specialized purpose where PICT-based sprites are important: If you are trying to do any sort of maze or other manuvering challenge with deadly spobs, the game is very bad at calculating collisions when you use rles. PICTs cause ships to be destroyed when you touch the mask, while rles cause the ship to be destroyed at some point well away from the mask.
Also, pipeline, if you want to tout the importance of rle-based sprites, it might be a good idea to convert the rest of your PICT-based sprites into rles... (The main screen buttons and the cursor are still PICT-based.)