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).
Nova 1.0.9 doesn't dither
I've just noticed that while Nova 1.0.8 and earlier will happily dither your 24-bit pics nicely down to 16-bit, 1.0.9 does not and leaves those nasty colour blotches on nice gradients. It seems we're going to have to make sure all our pics are in exactly 16-bits.
(edit) Well 1.0.10 is out now and this is no longer an issue
This post has been edited by Guy : 09 September 2006 - 09:09 PM
I noticed a problem like this involving PICTs from standard Nova, without plug-ins. I hope it gets fixed.
Do you remember what picts?
On a related note, I found a program that can tell you what compression has been used in picts: JPEGView It's an old classic program and of course requires you to ConText all your picts but after checking out a few from some plugs it seems that any type of QuickTime compression at all (even "None"!) will cause them not to show up in Nova. Common types of QT compression were tiff and png. Transparency/alpha masks cause tinting and picts less than 8-bit appear white. So picts that work are uncompressed in 8, 16 or 24/32-bit. Just keep in mind Nova doesn't dither.
This post has been edited by Guy : 01 April 2006 - 10:37 PM
Many (though not all) outfit PICTs from 6000 to roughly 6070 (in Nova Graphics 1) are 32-bit. I can't see any dithering errors in-game, though. Perhaps they were pre-dithered but somehow the mode didn't get changed... or perhaps I'm being let down by my monitor or my faulty color vision.
I am having problems with this no dithering issue. Although my computer is 32-bit, I can't import anything into the game higher than 24-bit. This causes any Picts I put in the game to become distorted and have lines. :blink: Is there any editor that I can use to put graphics in 16-bit?
@ant-iglias-ii, on Apr 1 2006, 07:01 AM, said in New Observation:
Is there any editor that I can use to put graphics in 16-bit?
Yes. BlitZen by w00tWare will convert graphics to the correct format. Tell it to output 16-bit uncompressed PICTs, and they should work perfectly well.
Now, a couple of questions:
What is the format used for the main screen button masks? I'm almost certain that they are 1-bit, but they don't have the problem with becoming pure white that most 1-bit PICTs have.
What about Windows users? They won't notice this problem, as WinNova doesn't have the PICT bug, but they will still be able to create bugged plugs. Assuming that they find out that their PICTs don't work on MacNova, how should they go about fixing the problem? Will they need to get a Mac user to convert their PICTs for them?
Edwards
oops! I forgot to mention I'm running Windows! :rolleyes: I'm not sure about your questions seeing as I know nothing about Macs but you have me thinking about the Picts I am putting in my plug.
@dr--trowel, on Apr 1 2006, 04:28 AM, said in New Observation:
Yeah, actually there's an awful lot of 32-bit pics in Nova but they all only use thousands of colours, if you get what I mean. Like they've been dithered down to 16-bit and then changed back to 32-bit.
@edwards, on Apr 1 2006, 06:14 AM, said in New Observation:
These are in millions, though the rollover and cursor masks are 1-bit (don't need JPEGView to tell what depth they are though). They are only masks remember, you're not supposed to be able to see them in-game anyway.
Windows users must all import with EVNEW, right? I assume this just creates normal uncompressed picts so there should never be a problem.
This post has been edited by Guy : 01 April 2006 - 05:01 PM
@guy, on Apr 1 2006, 12:59 PM, said in New Observation:
The problem with compressed 1-bit masks is that, even though they are never displayed, they are still treated as if they are entirely white. The problem with that should be obvious. I am rather surprised that those masks are in millions of colors, though. According to all the tests that have been done, shouldn't that cause the buttons to not show up at all?
Didn't you yourself just imply that 32-bit PICTs don't work with MacNova? If Windows users can import 32-bit PICTs into their plugs, as apparently someone has, that will cause problems on MacNova (and WinNova as well, it seems). Are there any Windows users here who would be willing to try taking a Mac plug with known bad graphics, exporting and re-importing the PICTs, and sending it back to be checked for PICT format? Or, just make a plug with a variety of PICTs, and send it to a Mac user to be checked for format.
@Ant'Iglias II: Sorry, I'd been assuming you were on a Mac, as that's the only platform image problems have been reported on so far. For Windows, I only have a couple of suggestions:
Oh, um no, that wasn't what I meant to imply. 24/32-bit, they're pretty much the same thing, right? Images can only have up to 24-bits of colour but seem to be stored in 32-bits. Maybe they're reserved for an alpha mask, even if the pic doesn't actually have one.
Ah. I hadn't known that. However, there's still the question of just how EVNEW imports PICTs. Compressed, uncompressed, or other? Uncompressed is fairly likely, but I'd like to have it confirmed.
@edwards, on Apr 1 2006, 05:14 PM, said in New Observation:
What is the format used for the main screen button masks? I'm almost certain that they are 1-bit, but they don't have the problem with becoming pure white that most 1-bit PICTs have. ... Edwards
I'm pretty sure I heard that the routines that are in charge of the main screen are not the same as those for in-game sprites, and thus do not suffer the same limitations.
@zacha-pedro, on Apr 2 2006, 01:11 AM, said in New Observation:
I've seen a main screen created using PICTs, and I can assure you that it suffers from at least some of the drawing problems as in-game sprites (specifically 1-bit compressed PICTs being read as pure white). I'd wondered about the button mask types because I tested those buttons as in-game sprites, and they worked.
(EDIT) All right, 32-bit masks do work properly. The more interesting question is why the original "New Pilot" button did not turn bright orange when used as a ship sprite. When I ran the New Pilot button's sprites through BlitZen, set to produce uncompressed 32-bit PICTs, it appeared bright orange, both on the main screen and in-game. The resource size was decreased by 66 bytes.
As for the idea of the main screen using a different drawing algorithm, I suspect that you got it confused with the interface buttons, which do use a different drawing method (although the only visible part is that the masks are inverted. This is the same effect that you get if a spďn refers to the same PICT for both sprite and mask, but that's probably a coincidence).
This post has been edited by Edwards : 02 April 2006 - 11:45 PM
@edwards, on Apr 2 2006, 10:49 PM, said in New Observation:
As for the idea of the main screen using a different drawing algorithm, I suspect that you got it confused with the interface buttons, which do use a different drawing method
Nope. Matt has himself said that the main screen uses different drawing routines from those used in-game, which is why it is perfectly accepting of PICT-based sprites.
I am fully aware of this new problem, through my recent plug making. It makes all graphics look terrible, as I can see every one of the pixelated artifacts. Also, BlitZen does not solve the problem n'more. Go ahead and try a bit depth conversion on a resource file with more than one pict resource in it.
I think I may start doing my plug developing /game playing on 1.0.8, purely because of graphical aesthetics-workfulness.
How odd -- all our internal PICTs should be 16 bits, but I guess I'm not that surprised to find that some of them are 32 bit with only 16 bit data.
Nova never offered dithering from 24 to 16, which is why we used BlitZen. It's a byproduct of QuickTime, and, as pe usual, I can only say that I've always and only ever advocated using the approved formats. Using anything else and complaining when support goes away (for whatever reason) is pretty silly.
Dave
@orcaloverbri9, on Apr 3 2006, 04:45 AM, said in New Observation:
Did you actually read the part of my post just before what you quoted?
As far as I can tell, there is no difference between the main screen and the rest of the game in how it handles PICT-based sprites. Red-tinting occurs, 1-bit PICTs turn white, sprites with 16-bit masks don't show up, and if you give me any other PICT bugs, I'll add them to my main screen. The main screen may very well use different drawing algorithms, but that doesn't seem to prevent it from being affected by the various PICT malfunctions:
The top button is 32-bit for both sprite and mask, the middle button has a 16-bit mask, and the bottom button has a 1-bit mask.
@pipeline, on Apr 3 2006, 09:17 PM, said in New Observation:
Well that's almost fair enough, except that prior to 1.0.9 we weren't really aware that there were any "approved" formats. Everything simply worked. Mind you, I'm not really complaining, just pointing out something else we need to be careful of.
@edwards, on Apr 3 2006, 09:26 PM, said in New Observation:
What the? How did you get the red tinting? The existing mask is already 32-bit, which works fine and by the looks of it nothing else does.
This post has been edited by Guy : 04 April 2006 - 04:26 AM
@guy, on Apr 4 2006, 02:26 AM, said in New Observation:
Simple. I ran the sprite through BlitZen (it looks like I skipped the mask), with it set to output 32-bit uncompressed PICTs. Neither JPEGView nor Preview shows any difference between the original and the BlitZen'd versions of the PICT, and there's only a 66-byte difference in size, but the change in format is apparently enough to cause problems. Just to be clear, the mask being 32-bit doesn't affect the color. However, it is important that it be 32-bit because only 32-bit and 8-bit masks work for sprites. 1-bit masks end up masking the entire square of the sprite, and 16-bit masks end up masking nothing.
---------- On a somewhat different note, I may as well mention a few things about 8-bit colors: