pipeline, on Jan 1 2006, 11:28 PM, said:

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.

Dave @ ATMOS
View Post

You mean, it's like deprecated Carbon API like the Classic Event Manager and QuickDraw? Then it might be worth to indicate this in the Bible.

Yep, paying attention to doing 1-bit masks is not a problem if one converts them to rlës (that stores the mask another way, and accepts everything thanks to QT). None of these problems exist with rlë, being a whole format in and on itself, while PICT is only a wrapper format that can concievably contain data in many ways.

Edwards, on Jan 2 2006, 05:59 PM, said:

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.)

Main screen buttons don't draw using the same routines as ship sprites (last I heard), and is the cursor not a series of cicn resources?

Regards the collision handling of RLEs, that's a major bug. Why wasn't it reported?

Dave @ ATMOS

pipeline, on Jan 2 2006, 03:38 PM, said:

Main screen buttons don't draw using the same routines as ship sprites (last I heard), and is the cursor not a series of cicn resources?
View Post

Actually, the cursor is also a PICT based sprite. But it and the main menu graphics do seem to be handled differently since our modified graphics worked fine in 1.0.9 without requiring BlitZenning.

Edwards, on Dec 31 2005, 05:01 PM, said:

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.
View Post

Unfortunatly, it doesn't look like I'll be able to make said app, since I've been unable to determine exactly what format BlitZen exports as. It's not a standard uncompressed 16 bit PICT resource, so I'm at a bit of a loss as to where to procede.

This post has been edited by Andcarne : 02 January 2006 - 06:54 PM

pipeline, on Jan 2 2006, 05:38 PM, said:

Regards the collision handling of RLEs, that's a major bug. Why wasn't it reported?

Dave @ ATMOS
View Post

Another good example of bad collision handling can be demonstrated by attacking an Auroran Cruiser with FPCs head on. A lot of the time your FPs go straight through the Cruiser and appear out the other side. I'm trying to make a video to demonstrate this.

oh my god, i never thought i would ever not murder someone for saying this (much less say it myself), but i am for once profoundly gratefull that i am running this on windows.....

feel free to murder me now, if you can beat me to it.

Ragashingo, on Jan 2 2006, 07:54 PM, said:

Another good example of bad collision handling can be demonstrated by attacking an Auroran Cruiser with FPCs head on. A lot of the time your FPs go straight through the Cruiser and appear out the other side. I'm trying to make a video to demonstrate this.
View Post

http://homepage.mac.com/ragashingo/.Movies...aCollisions.mov

Note that for a few moments all my FPs pass through the Cruiser until it accelerates and changes its relative position to my ship.

Noted on the beta list -- we're looking at it.

Dave @ ATMOS

pipeline, on Jan 2 2006, 02:38 PM, said:

Main screen buttons don't draw using the same routines as ship sprites (last I heard), and is the cursor not a series of cicn resources?View Post

The main screen buttons, in my limited tests, are subject to at least one of the problems that normal sprites are. The standard buttons (mission dialog "okay", etc.) are drawn using an entirely different algorithm, and their masks are not affected by the PICT problems.

pipeline, on Jan 2 2006, 02:38 PM, said:

Regards the collision handling of RLEs, that's a major bug. Why wasn't it reported?

Because I, at least, only became aware of it two days ago, when I needed to convert a PICT-based puzzle into rle because the PICTs no longer worked? The "shots-pass-through-Auroran-Carriers" aspect was mentioned, I think, but that was probably not enough information either for it to be tracked down, or to be picked up to send to Matt.

Anyway, I'm not quite as annoyed about my inability to create working 1-bit PICTs now, as converting my pet plug-in to rle and 16-bit PICTs only tripled its size.

Edwards

it would appear that i spoke too soon, my ship has decided to turn red......
oops.JPG (37.87K)
Number of downloads: 48

ooh, painful-to-look-at dart
dart1.JPG (29.3K)
Number of downloads: 38

the dart of pain in motion
dart2.JPG (26.85K)
Number of downloads: 45

This post has been edited by Edwin_again : 03 January 2006 - 07:51 PM

Edwards, on Jan 3 2006, 05:42 PM, said:

Anyway, I'm not quite as annoyed about my inability to create working 1-bit PICTs now, as converting my pet plug-in to rle and 16-bit PICTs only tripled its size.

It's never been noted anywhere that Nova was designed to use anything other than 16 bit PICTs or RLEs, with the exception of the RLE8 resource. I would never have expected 1bit PICTs to work right, ever.

That said, we're still working on the PICT bug so that people can use 16 bit PICTs should they so wish. However, I don't expect there to be any official support for anything other than the following:

• 16 or 8 bit RLEs

• 16 or 8 bit PICTs with 1 bit masks.

With regards to PICTs, any form of QuickTime compression you choose, as long as it's 8 or 16 bit, should be fine, which is why we're trying to fix the bug. 1 bit PICTs for masks should not be compressed.

Dave @ ATMOS

Edwards, on Jan 2 2006, 08:42 PM, said:

converting my pet plug-in to rle and 16-bit PICTs only tripled its size.
View Post

But is the zipped version also 3 times the size?

pipeline, on Jan 3 2006, 05:30 PM, said:

I would never have expected 1bit PICTs to work right, ever.

pipeline, on Jan 3 2006, 05:30 PM, said:

16 or 8 bit PICTs with 1 bit masks.

Cocked eyebrow.

Oh well, except that I won't be able to test sprites without rleing them, this shouldn't be too much of a hassle.

Guy, on Jan 3 2006, 08:09 PM, said:

But is the zipped version also 3 times the size?View Post

No, that only grew by 4K, probably as a result of rles not compressing as nicely. However, it's just fun to say "my fully self-sufficient total conversion has a total size of one hundred and twenty-eight kilobytes ".

Edwards, who has needed to settle for "my fully self-sufficient total conversion has a total size of three hundred and fifty kilobytes".

Never mind, that's also great to say.

Edwards the happy-once-again

Edwards, on Jan 4 2006, 05:54 PM, said:

Cocked eyebrow.

You know what I meant; the sprite picture (not the mask) should never be 1 bit.

Don't play silly-buggers.

Dave @ ATMOS

Edwards, on Jan 4 2006, 01:54 AM, said:

No, that only grew by 4K, probably as a result of rles not compressing as nicely. However, it's just fun to say "my fully self-sufficient total conversion has a total size of one hundred and twenty-eight kilobytes ".
View Post

Man, would I loved to have had you around during the ill-fated days of my EV clone for Commodore 64...