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).
Quote
Originally posted by SpacePirate: PICTs are uncompressed, a major waste of space.
Not exactly. PICTs can be stored in a ton of different ways, many of which use at least some sort of basic compression. 32-bit PICTs are often compressed with a channel-wise RLE format using an 8-bit flag/counter byte with an 8-bit data item, and 16-bit PICTs are often compressed into a pixel-wise RLE format using an 8-bit flag/counter byte with a 16-bit data item. See (url="http://"http://developer.apple.com/technotes/tn/tn1023.html")http://developer.app.../tn/tn1023.html(/url) for the exact bit-packing routine used by PICTs.
------------------ Get (url="http://"http://www.aznt.com/EVN/EVNEW")EVNEW(/url) - the free, open-source EVN plugin Editor for Windows!
Originally posted by Aprosenf: **Not exactly. PICTs can be stored in a ton of different ways, many of which use at least some sort of basic compression. 32-bit PICTs are often compressed with a channel-wise RLE format using an 8-bit flag/counter byte with an 8-bit data item, and 16-bit PICTs are often compressed into a pixel-wise RLE format using an 8-bit flag/counter byte with a 16-bit data item. Seehttp://developer.app.../tn/tn1023.html for the exact bit-packing routine used by PICTs.
**
Ah, yes... Perhaps I should have said not compressed-nearly-as-well-as-they-could-be. However, the fact is that RLEs are much smaller than having two PICTs (mask+sprite).
~ SP
------------------ Fear the SpacePirate, He made a (url="http://"http://www.evula.org/infernostudios/search.html")plug-in search page(/url)... And he'll board your ship! -mrxak
You'd be surprised. The rle8/rleD format is actually a little wasteful in terms of space to make everything 32-bit aligned, which would supposedly make them faster to process on 32-bit machines, but you still have you look at the individual bytes too often to make it worth much. The RLE format compresses runs of invisible pixels, but pixels that are drawn are left totally raw - runs of the same solid color are not compressed; if they are, Nova can't read them. PICT compression is not 32-bit aligned, and it competes rather well with the RLE format, assuming that you leave the invisible regions a solid color on the original image and you use two solid colors in the mask.
Still coming up with ideas in class...
What about "set all" operators? For example, something like "Bddd" would set all mission bits, "Dddd" would remove all outfits, "Addd" to abort all missions and something like "Xddd" to explore all systems.
Granted it would not be used often, but it would make things a helluva lot easier to do with maps and such that explore systems that aren't linked in the general systems.
It would make for an easier "clearing" of the player's "pallate". I mean, if you start the Fed string, then go into the Polaris string, the Fed's aren't going to let you come back with your cargo of missiles.
It would make it simple to erase all of a player's previous background.
------------------ When viewing a Terrapin for the first time, I realized that anything flies-if you throw it hard enough!
- Second ModVal field. This would require changes to most of the modtypes but would allow for much more versatile outfits. eg. clean legal record could instead be modify legal record by specifying a govt in the first modval and the amount to modify by in the second (you could make a value of 0 "clean" the record). If the way jamming works was rewritten to allow an unlimited number of jamming types then the first modval would be the type of jamming to modify and the second would be the amount to modify by. For "increase maximum" the first would be the outfit ID and the second would be the amount to increase/decrease by - using the negative of the outfit ID in the first field would mean multiply by the number in the second rather than add. With the map you could specify a system which the map would explore around or -1 to explore around the current system. There's a whole range of possibilities this would open up. Other modtypes could be combined into one. eg. a shield modifier where the first modval represents more shield capacity and the second represents faster shield recharge. This would allow you to squash even more mods into one outfit resource without adding more modtype fields.
- Additional flags for cloaking device: visible on screen; targetable
- MaxHangers. This field would allow ships to have a maximum number of hangers - just like MaxGuns and MaxTurrets. There would be a corresponding flag in the outfit resource.
- Flag for ships to make them use weapons even if it might hurt/kill them - specifically to make them use weapons of ammotype -999 (useful for kamikaze ships and stuff).
------------------ "The Macintosh may only have 10% of the market, but it is clearly the top 10%." — Douglas Adams
Originally posted by Guy: **
Ummm, the AI uses ammotype -999. This is already implemented.
I would like a change in how missile jamming is calculated. I would like it changed to %jamvuln*total-jamming%=jamchance (with no 100% capping of jamvuln or total-jamming% - thus a 50% jamvuln missile would be jammed half as offten as a 100% jamvuln missile. (the way it is done now is really wierd, and IMHO really stupid. No chance for a "freak accident" where a well guided missile just happens to get jammed by a 5% jammer, and such, and makes it hard to make missiles that behave like one wants them to). -Az
------------------ It is here. EVNEW Public Beta (url="http://"http://www.aznt.com/EVN/EVNEW")www.aznt.com/EVN/EVNEW(/url) Stuffit is a piece of .sit.