Can I just point out that, as far as I am aware, all the graphics in the Nova data files are 16 bit dithered? There are none that are millions of colours.

I should know, I Blitzened them before I put them all in...

Dave @ ATMOS

pipeline, on Mar 1 2005, 06:26 PM, said:

Can I just point out that, as far as I am aware, all the graphics in the Nova data files are 16 bit dithered? There are none that are millions of colours.

I should know, I Blitzened them before I put them all in...
View Post

I had thought everything was 16-bit, but decided to double-check before writing my previous post. I used ResEdit to copy a few of the outfit pics in Graphics 1, and then used GraphicConverter's "New Image Using Clipboard" command. It looks like you missed a few, Dave.

At least these images are all 32-bit:

• light laser (ID 6000)
• Fixed Railgun (100mm) (ID 6043)
• Nuclear Torpedo (ID 6048)

It may be that everything from 6000 to 6048 is 32-bit, and all the files with higher numbers are 16-bit. I wasn't thorough about checking out this idea (and didn't look at the graphics in other files at all), but at least these 4 images are indeed 16-bit:

• Fusion Reactor (ID 6049)
• Fed Cloaking Device (ID 6083)
• Wraith Graviton Beam (Adult) (ID 6103)
• Radar Missile (ID 6202)

I'm all for 16-bit, for what it's worth -- regardless of whether or not Nova can show millions of colors, thousands is plenty. No sense using larger files when ATMOS has already shown the quality of the graphics you can make with "just" thousands of colors.

(Dang. Just checked my own work, and I released Cold Fusion for Nova with a bunch of 32-bit landing scenes. :blink: Well, if I ever do manage to release a new version, I may be able to reduce the archive size a fair bit....)

Ah, I see! I muist not have Blitzened those ancient graphics when we swapped to RLE graphics from PICT during Nova's development.

Quote

I'm all for 16-bit, for what it's worth -- regardless of whether or not Nova can show millions of colors, thousands is plenty. No sense using larger files when ATMOS has already shown the quality of the graphics you can make with "just" thousands of colors.

Meh, RAM and HD space is cheap, and we live in 2005, not 1995, thus I'm all for millions of colors. That and I'm always a bit worried as to how my sunsets will come out once several million color shades are removed from them...

Sorry I been a way for a while, college stuff. I've been looking in to REALbasics capabilities, and it can only save to 2 file formats, JPG and Pict. Which one would you want?

It can open them all by the way ;), though some of them come out a bit weird.t.

Please bear with a potentially stupid question: is the REALbasic this uses the same REALbasic you are using? I ask because the software at that site seems to compile to linux and windows as well as mac.

If it isn't, how similar is it?

PICT for sure, and I speak for everyone here well, mostly everyone. When it comes to JPEG versus PICT, I'll take a lossless format every time, particularly for sprite graphics where pixel-perfection is essential.

Dave @ ATMOS

Artanis, on Mar 2 2005, 03:15 AM, said:

Please bear with a potentially stupid question: is the REALbasic this uses the same REALbasic you are using? I ask because the software at that site seems to compile to linux and windows as well as mac.

If it isn't, how similar is it?
View Post

Yes its the same version, 5.5.4.

@Pipeline: OK, i will change the formats to PICT. Like i say i was only testing out with JPG, as it is slightly quicker to use and code.

The resources are already stored as pict so if you use that then there'll be no conversion and you'll be guaranteed no loss.

This post has been edited by Guy : 02 March 2005 - 04:14 AM

I'm still wondering how iNova handles already-encoded RLE resources.

At the moment it can't, I got hold of the format guide to RLE resources, but the images always come out distored and blured.

I will let you know when i fix it.

DaGekkoMan, on Mar 2 2005, 05:01 AM, said:

At the moment it can't, I got hold of the format guide to RLE resources, but the images always come out distored and blured.

I will let you know when i fix it.
View Post

So, what, at the moment does it just do a raw data dump of them? That's good enough for now...as long as it can extract/insert them from/into ResEdit files and hold them in a package if they've already been created, even if it can't display them.

Ok, I have a feature request, and I can help you with this if you need it.

I want a high level scripting mode built into the editor, so you can do things like fancy programming with crons and stuff in one step. I'll puzzle over the implementation, and might even be able to give you a sort of module to stick into the existing application.

Ah, and a small but important feature is for there to be an option of somewhere for, if you paste, for it to chose the lowest available id, the highest available id, or the highest taken ID+1. This would make certain things much easier.

This post has been edited by NebuchadnezzaR : 02 March 2005 - 09:51 AM

@Weepul: Thats what its doing at the moment, as with everything it gets unless it has a template resource in the data files for it.

@NebuchadnezzaR: <no comment on first request> second request however is interesting, could you please expand as i was a little confused by the post. Do you mean for the user to be able to select how to allocate a new ID a new resource?

DaGekkoMan, on Mar 2 2005, 09:26 AM, said:

@NebuchadnezzaR: <no comment on first request> second request however is interesting, could you please expand as i was a little confused by the post. Do you mean for the user to be able to select how to allocate a new ID a new resource?
View Post

I think that's what he means, ideally by a modifyer and a command key- not a menu item only!

Example of what I mean:

Ok, you have a plugin containing spob ID 200 and spob ID 400. You copy spob ID 200 and paste it back. Does it chose ID 128, 201, 401, or 2000(whatever the max would be)? In different circumstances, different ones would be preffered, and they are all simple enough to implement by themselves. Either a check box somewhere, or shift-cmd-z for one and cmd-z for another, in any case, it would be a good feature to have.

probably, cmd-z would chose 128 and shif-cmd-z would be 401, but this depends on what seems most appropriate. I think checkboxes make sense, because you probably want it to do the same thing several times in a row.

(and by checkbox i probably mean radio buttons)

This post has been edited by NebuchadnezzaR : 02 March 2005 - 09:39 PM

Some program (I think ResFool) has a setting to let you choose the starting ID for resources. This means that if you create a new resource it will start numbering at that ID and presumably it would work for pasting too. Just an alternative way of doing it, although I think NebuchadnezzaR's idea is better.

Hmm, yea that sounds like it could be useful, and it shouldn't be more then an hours work to do, maybe less.

Thanks

Artanis, on Mar 2 2005, 04:15 AM, said:

Please bear with a potentially stupid question: is the REALbasic this uses the same REALbasic you are using? I ask because the software at that site seems to compile to linux and windows as well as mac.

If it isn't, how similar is it?
View Post

However, just because it can compile in Windows and Linux doesn't mean the application will function properly... All of the resource handling still only works on a Mac, as I recall it, those commands are simply ignored while compiling for linux/win.

~ SP

(edit: ubb)

This post has been edited by SpacePirate : 04 March 2005 - 02:10 AM

SpacePirate, on Mar 4 2005, 02:00 AM, said:

However, just because it can compile in Windows and Linux doesn't mean the application will function properly... All of the resource handling still only works on a Mac, as I recall it, those commands are simply ignored while compiling for linux/win.

~ SP

(edit: ubb)
View Post

No, they just completly error the compiler, which is kind of annoying, the only way to avoid that is by using pragmas, but in doing that you get a pointless shell <_<