Sprite questions

[ITSTORRASQUE4U]

We are a community modding team, and we have some questions. Please try to use as few technicisms as you can, since not all of us are modders :)

1. How do I extract a SC unit to bitmap?
2. Are palettes global? or do we have one per unit?
3. The unit animations, do they all come in the single bitmap or separate?
4. What color does the see-through part have (you cut a square bitmap, I'm talking about the are around the unit that SC assimilates as transparent)?
5. Is the shadow in the same bitmap as the sprite?

We hope you can help us out :)

[DiscipleOfAdun]

Starcraft graphics are stored as files with a .grp extention. These files can be interpreted to bitmaps by using a program such as RetroGRP(which is buggy) or with Shadowflare's GRP converted. BroodKiller, the coder behind DatEdit, is currently making a GRP handling program that will replace RetroGRP.

The palette used for the unit is the same for all units.

GRP files contain multiple bitmaps which comprise the animation. Units that rotate have 17 direction frames for one part of the animation.

Starcraft interprets the pure black color on the palette as transparent. The palette has several near-black colors that can be used to simulate black.

Shadows are not always the same grp as the unit, but sometimes they are. Most common for shadows to be the same grp are for flying units and stationary buildlings.

That's a basic, basic overview of how it works. Of all modding, graphics is the thing I do the worst in. There are people who can better explain this, but I though I'd try.

[ITSTORRASQUE4U]

And even if it's your worst, thanks for the help :)

Could you tell me who excels at .grp bending?

One more: does SC take the sprite and automatically changes the colors for each faction, or do we have to make a separate sprite for each faction color?

THX again :)

[BroodKiller]

SC deals with this on its own. I am not 100% sure but I think it takes purple as the color to be replaced with team colours.

[TheNomad]

Broody is right. This was discussed in a thread when someone experimented with it and made a team-based cursor (the cursor changed color depending on the player color).

[Aqo]

Wrong wrong wrong T_T

Units have no palettes; They have indexes colors.
Starcraft than extracts data from images.dat that tells it what palette to use per sprite.

Black does not mean transparent. I could make images where light blue is transparent (which is, by the way, very useful when working on GRPs for menus and UI). What does decide it, is the index; in this case, the index for transparency on palette 0 is 0. On the other palettes (1 to 4), there are other indexes for it as well.

I spent months researching GRPs (due to making a lot of them..; I'm talking about tens of GRPs per week when I'm active in the subject), and I concluded several findings that are very useful for various stuff. For example, this archon:
http://img484.imageshack.us/img484/4369/whitearchgc1.png

Took me about 5 minutes to make, and the white area on the sides is partially transparent. I was only able to do it thanks to knowing that in-game colors - the palettes - are decided by Starcraft and not the image.

In other words, normally you'd assume that to do that archon, I will have to find a way to convert the normal archon graphics into something like this:
http://img404.imageshack.us/img404/428/arch1xgd6.png
Which has a long and ineffective way.

However, it's false to believe that the frames themselves have a palette. They don't. That means you can use any palette you want; Thus, I created a specific palette for 1', and than simply recolored the Archon in photoshop into this:
http://img217.imageshack.us/img217/1555/arch2xwk4.png
Same in-game effect, different palette, much less work involved.

[TheNomad]

wow... they look as proffy as the ones made by Blizzard :) very nice work Aqo, as always.

[nirvanajung]

if u look around here
http://www.warboards.org/showthread.php?t=23636
then u could get it about SC graphics especialy grp and palette

[ITSTORRASQUE4U]

Thank you all, your information was very useful. We got the hang of it, and if future questions arise, we'll ask again :)

Now here's more, about tilesets. I wouldn't ask this, but our modders (most important part) haven't been very "in touch" with the rest of our members, so we need to know EXACTLY what we're facing:

1. Is it possible to generate fully new tilesets (for example, an inside-protoss building tileset) without having to overlap one of the present ones in SC?
2. Can you describe an easy process, without too many technicisms, of how to make a new tileset?
3. Do .grp's for tilesets work in the same way as unit .grp's?
4. Do any of you gurus out there volunteer to advice us (if you don't have the time to get involved further in this project, I'll just send you PMs with our questions) about what can be done an what can't?
5. Can any of you give me a copy of winscript 5.x to start learning modding? my comp doesn't download it from it's official page :D

Thanks again, and hope you have some spare time! ;)

[TheNomad]

1. Is it possible to generate fully new tilesets (for example, an inside-protoss building tileset) without having to overlap one of the present ones in SC?
2. Can you describe an easy process, without too many technicisms, of how to make a new tileset?
3. Do .grp's for tilesets work in the same way as unit .grp's?
4. Do any of you gurus out there volunteer to advice us (if you don't have the time to get involved further in this project, I'll just send you PMs with our questions) about what can be done an what can't?
5. Can any of you give me a copy of winscript 5.x to start learning modding? my comp doesn't download it from it's official page :D

Well, I'll start simple by saying that StarCraft is not WarCraft 3. StarCraft isn't really moddable, except that certain tools provide access to certain parts of the game which we can change (but aren't supposed to). That having been said, I'll close this discussion by saying that there are A LOT of limitations to SC.

So, let's start with the questions :)

1. Yes, but it's hard as hell. Creating the GFX and assigning them to the GRP and the doodads and terrain groups is intensive work.
2. There is no easy process to modify a game that isn't supposed to be modifiable ;) Moving on, you can't add new tilesets, you can modify existing ones. Well you can add a new terrain, just like you can add a new race or a new resource, but the amount of exe restructuring is so huge that it won't pay off on the long run (imo), especially with a new (possible ?) patch.
3. Of course, they are GRPs. The terrain info (walkable, buildable, accessible etc.) is described in the terrain info and read and interpreted by the exe
4. you can make walkable surfaces (or non walkable), buildable (or non-buildable) and change terrain height. That is about it. As for the way to do it, it's not very easy if you want NEW tilesets. If you want to fool around with existing tilesets, it won't be too hard. You can't make UMS games for the Installation in multiplayer though, I believe it's hardcoded.
5. WinScript ? What's that ?

Anyway, although it'd be good to be able to properly modify terrain, SC doesn't quite like it too much. Unfortunately this is one area I'd LOVE to mod, but will stay out of, due to the fact we don't know too much about the terrain format and cos it's very difficult to mod it.

Hope this helps!

[ITSTORRASQUE4U]

It both helps and leaves more questions :):

1. I don't quite get it. You're saying it's TOTALLY IMPOSSIBLE to make new tilesets, or just damn hard?
2. What do you refer to when you say "hard work"? Is it full knowledge of the code, or intensive work that a noob can also do? or both? or perhaps getting a full group of designers, mappers, modders, etc. to do the job?
3. Can you post a link to a terrain or tileset editing tutorial? any of you?

Winscript 5.x is a program I believe require for modding. I have all the basic stuff to start, but it doesn't let me convert because I don't have winscript 5.x.

[Aqo]

I'm afraid the information TheNomad gave you is entirely wrong.
Tilesets are not GRP files, they use five different formats that are editable with TileEdit. There are GRPs used for terrain sprites, like the sides of a creep area, and tree-tops, but other than those it's all other file formats. To use TileEdit, open it; In it you'll see all the megatiles. Select one, click export. This created a bmp. Open it, edit it, than in TileEdit click Import, select it and save.
That's it.

I have to say, TileEdit is the easiest modding program to use (other than TBLPad...).
It never bugs, and it works perfectly. I could show you screenshots of a few attempts where I turned creep into smilies.

And yet, as for creating new tilesets, forget it. You can't. Why? Because you don't have the patience to do it. I'm not making an assumtion, it's a fact.
Editing one megatile takes about a minute or so; there are about 1400 megatiles per tileset; assuming you work on this intensively for three-four hours a day, it will take you about two weeks to finish that one tileset.
Unless you can magically force yourself to spend two weeks of your life working intensively on a terrain, in reality, it will take you a year or so to finish that terrain. Chances are, you'll give up in the very beggining of it.

---

For the latter, I'm a modder and I never heard of winscript 5.x, so I doubt it's needed.

[ULTRAZEALOT]

thanks A LOT to AqoTrooper and theNomad. :D
we're thirsty of knowledge :)
btw
i think that point 4 of torraskes's post implies "do you wanna join us"???
that would be cool coz we're lackin of commited modders :)
please ask torraske for further information
and thanks again.

[TheNomad]

I'm afraid the information TheNomad gave you is entirely wrong.
Tilesets are not GRP files, they use five different formats that are editable with TileEdit.

I never said terrain is GRP. I said that the terrain GRPs are the same as normal GRPs since that was his question and I said the terrain info is stored in the terrain files (the ones you enumerated).

The reason I said it is hard is cos of the unknowns present (which I find disturbing since I dunno either the full capabilities of the program, the format or what happens if I change something ASSUMING I add new terrain), therefore not very noob-friendly.

As for creating a new tileset, it's impossible since you'd have to restructure the exe, add new dat entries and so on... not only on sprites.dat but also on images.dat. It's not just about making BMPs and GRPs.

Anyway, I see nothing wrong with what I said ;)

[ShadowFlare]

...

Black does not mean transparent. I could make images where light blue is transparent (which is, by the way, very useful when working on GRPs for menus and UI). What does decide it, is the index; in this case, the index for transparency on palette 0 is 0. On the other palettes (1 to 4), there are other indexes for it as well.

...
Technically there is no transparency color in the GRP format; that is only something that has been put into the converters to make things easier, since common image formats used by the converters do not have direct support for transparency. In the GRP format, transparency is actually defined by a special code, which has nothing to do with any certain color. All 256 colors are actually usable in the GRP format, not just 255 of them.

[HyperDemonic]

Wrong wrong wrong T_T

Units have no palettes; They have indexes colors.
Starcraft than extracts data from images.dat that tells it what palette to use per sprite.

Black does not mean transparent. I could make images where light blue is transparent (which is, by the way, very useful when working on GRPs for menus and UI). What does decide it, is the index; in this case, the index for transparency on palette 0 is 0. On the other palettes (1 to 4), there are other indexes for it as well.

I spent months researching GRPs (due to making a lot of them..; I'm talking about tens of GRPs per week when I'm active in the subject), and I concluded several findings that are very useful for various stuff. For example, this archon:
http://img484.imageshack.us/img484/4369/whitearchgc1.png

Took me about 5 minutes to make, and the white area on the sides is partially transparent. I was only able to do it thanks to knowing that in-game colors - the palettes - are decided by Starcraft and not the image.

In other words, normally you'd assume that to do that archon, I will have to find a way to convert the normal archon graphics into something like this:
http://img404.imageshack.us/img404/428/arch1xgd6.png
Which has a long and ineffective way.

However, it's false to believe that the frames themselves have a palette. They don't. That means you can use any palette you want; Thus, I created a specific palette for 1', and than simply recolored the Archon in photoshop into this:
http://img217.imageshack.us/img217/1555/arch2xwk4.png
Same in-game effect, different palette, much less work involved.
this is of topic but i got to say thx your just told me something not about GRP

[nirvanajung]

Technically there is no transparency color in the GRP format; that is only something that has been put into the converters to make things easier, since common image formats used by the converters do not have direct support for transparency. In the GRP format, transparency is actually defined by a special code, which has nothing to do with any certain color. All 256 colors are actually usable in the GRP format, not just 255 of them.
yea... technically the access subject is just SC-code itself
it's not any index-colour propertieces of Bitmap and GRP format

so i know if there is chance to discovering access colour code in SC
we could make own custom palette settings to define that for sprite

anyways he wasn't talking about actual technical issue
he just analogize with general point of view

AqoTrooper : i think Nomad was correct
in above of his reply, i have understood his talking is the terrain GRPs are the same as normal GRPs
and terrain info is stored in the terrain files
he told as for concerning with mechanism of editing image for tileset not about usage of tools
and his wasn't focus to file types for editing them
anyways i took mean of his elucidation like that even though i'm not english person

[Aqo]

I never said terrain is GRP. I said that the terrain GRPs are the same as normal GRPs since that was his question and I said the terrain info is stored in the terrain files (the ones you enumerated).
My mistake, sorry. I got confused by those lines:
"1. Is it possible to generate fully new tilesets (for example, an inside-protoss building tileset) without having to overlap one of the present ones in SC?"
"1. Yes, but it's hard as hell. Creating the GFX and assigning them to the GRP and the doodads and terrain groups is intensive work."


The reason I said it is hard is cos of the unknowns present (which I find disturbing since I dunno either the full capabilities of the program, the format or what happens if I change something ASSUMING I add new terrain), therefore not very noob-friendly.
TileEdit only opens the formats you need, so it's not really hard to find them...

As for creating a new tileset, it's impossible since you'd have to restructure the exe, add new dat entries and so on... not only on sprites.dat but also on images.dat. It's not just about making BMPs and GRPs.
True. But this is the same for everything, since modding is basically replacing things, which creates a problem for cases when you want to add things. However, he could still add a new tileset into an existing one; aka: All tilesets are full of black null tiles. You could put your new tiles into them, and in SCMDraft manually place them in the iso view. In this case, it simply comes down to graphic editing, dat editing, and a massive amount of patience.

Technically there is no transparency color in the GRP format; that is only something that has been put into the converters to make things easier, since common image formats used by the converters do not have direct support for transparency. In the GRP format, transparency is actually defined by a special code, which has nothing to do with any certain color. All 256 colors are actually usable in the GRP format, not just 255 of them.
You've made several mistakes here. First, there are 256 colors, not 255. Second, true that there is no "transparency" like the 24-bit one, but there is an 8-bit transperacy which is defined by a dat entry which is called "images.dat", where a special attribute loads a palette from SC; each palette has specific 8-bit transperacy indexes. As for convertors, RetroGRP, they do nothing to make things easier. They do all and just what you need, convert indexes of any 8-bit image into an 8-bit pack of images called GRP. The colors of those images do not matter at all, just the indexes.

yea... technically the access subject is just SC-code itself it's not any index-colour propertieces of Bitmap and GRP format
You don't know what you're talking about are you :rolleyes:

I'll try to make things clearer, since it looks like everyone here don't understand how graphics in SC work:

There are 4 things that matter:
1. The SC code
2. The palette files
3. images.dat
4. The indexes inside each frame of a GRP

When it needs to draw a frame of a GRP, the starcraft code opens images.dat and looks for the entry of that GRP. It than detects data telling it what colorfile to use for that GRP. It applies colors from that file into the indexes of that frame.

When we create an 8-bit picture to be compiled into a GRP, it doesn't matter what colors it has. What does matter, is what index each color has, because that tells Starcraft what color to paint that part as, in the game.


so i know if there is chance to discovering access colour code in SC we could make own custom palette settings to define that for sprite
There's no need to discover, I already know where it is.
tileset\x

x = a name of a tileset.

Each of these folders has a *.pcx inside it (PCX is SC's true graphic format) that is basically Starcraft's colorfile for that terrain. Note that Starcraft doesn't support true transperacy, it just replaces colors according to how much copies of an index are on top of each other. Those files cover all cases by being two dimensional.


---


If you don't believe that everything I just said is true, download the mod I attached, open a jungle map that has guardians in it and tell them to attack. Than open the *.mpq and look at what files are in there.
'nuff said.

[matefkr]

About completly new tilesets: may have a "not too" dificult way to deal with this problem. If you have luck, you needn't modify the starcraft.exe.
Can you define me the engine team (what they shall do with the engine, end how?) If you intrested about this little chance, as me later -now i have to learn...

[nirvanajung]

You don't know what you're talking about are you :rolleyes:
I'll try to make things clearer, since it looks like everyone here don't understand how graphics in SC work:

ur blah blah blah....

lol i know what u did talk about that
lol... u really missed my point and SF's point of view either
we are already know about , probably SF agreed with me
for ur saying about :
1.The SC code
2. The palette files
3. images.dat
4. The indexes inside each frame of a GRP

u don't need to tell about them for us (SF either) lol

my saying was about StarCrft engine code
(whatever it's primally source code or just hex information)
for example, if we r discover Starcraft's colouring handle of game engine
then we can make palette setting as we mind
then we can change the routine of rendering colours
if so, we can set tranceparent,special colours as different way
such as define from something different file like *.ini file

so basicly i wasnt say for present rule of colouring
my point is the changing SC engine to derestrict use the colour
now u got it my point ? lol

u seems looks underestimate other person basicly,
so u couldn't see other person's point of view
anyways.. i don't think that is all of ur missing
u don't know actualy me and other persons's quantity of knowledge
so that made u like that i think so, it's not offence u
if u try to appreciate other person's trace of modding
then u could see right point of other person's saying in mostly


i believe that its not dependent on english-language capability
its dependent on opening mind for other person
i believe like that ;)

There's no need to discover, I already know where it is.
tileset\x
x = a name of a tileset.
Each of these folders has a *.pcx inside it (PCX is SC's true graphic format) that is basically Starcraft's colorfile for that terrain. Note that Starcraft doesn't support true transperacy, it just replaces colors according to how much copies of an index are on top of each other. Those files cover all cases by being two dimensional.

lol as i said above, u dont have to explicate that
i know that already dont waste of time lol
i wasnt saying about tileset and terrain mainly
the main issue was GRP palette settings for units/buildings and thingy graphics lol
hmmm.... why have u change focus like that?

and as i said right above, it's not about making define from specific file
SF and my point was Starcraft's colouring handle of game engine
so we need to discover


If you don't believe that everything I just said is true, download the mod I attached, open a jungle map that has guardians in it and tell them to attack. Than open the *.mpq and look at what files are in there.
'nuff said.
anyways thanks for you taking time even though i dont need that at all
All right! That's all for today its a waste of time
however Thank you thogh lol

[Aqo]

Haha. You say it's me who underestimates other people's knowledge, but you completely fail to listen to what I was saying. Hypocrit xD

If you at least bothered to try the mod I posted you might've understood what I was saying, but appearently you're too arrogant to even do that. I won't waste any more time on you; Hopefully the others are more clever than that.

[matefkr]

PCX- Zsoft Paintbrush (i think). Anyway, Aqo speak right, You can do with that method.

Aqo: what is lo? files? They contains subunit placement and tileset datas, right?

[nirvanajung]

PCX- Zsoft Paintbrush (i think). Anyway, Aqo speak right, You can do with that method.

yea PCX file uses for graphics but as i said above i wasnt talking about tileset
or other format
the main issue was GRP for unit/buildings and fingy
so that can't change their colours baicly that file apply to terrain and UI

[Aqo]

PCX- Zsoft Paintbrush (i think). Anyway, Aqo speak right, You can do with that method.

Aqo: what is lo? files? They contains subunit placement and tileset datas, right?
I'm afraid LO? files are the only one aspect of Starcraft modding I have never got into, so I can't help you on this :(

[matefkr]

nirvana: don't forget SC ai bug's, you can find a lot.. what ever, can you offer me a good disassembler? i've found a crappy one, but this one recompile the whole file, even those bytes, wich won't be executed (variables, .exe header, and may be free spaces). Please send me a link if you know one.

Sorry about grammatical mistakes.

[nirvanajung]

i dont have good disassembler cause i'm not programer i'm just CG artist mainly

[matefkr]

Do you know someone, who has?

["Aqo speak right" - i meant about unused tile indexes]

[Aqo]

Well, did you ever open a Starcraft map editor like SCMDraft, matekr? If you did (if not do it now), you'll see that the tiles in every tileset are made of a list of megatiles, each in the size of 1 grid. There are many black unused megatiles; them you could replace.

This is what I'm talking about:
http://img232.imageshack.us/img232/3964/unusedtileskg4.png
See the area sorrounded with red? The black inside it, are unused megatiles, that you could use :)

---

btw why am i Hypocrit ? that really conjecture u didn't saying with any logical describe about why i am Hypocrit
You're a hypocrit because you're complaining that other people don't listen to what you have to say, while you don't listen to what they have to say at the same time.
The mod I posted shows how the colorlist Starcraft uses to convert all graphics is used, and how it can be modified. However, you didn't download it, you just saw that it's inside the "tileset" folder and assumed it only modified tilesets, when it actually modifies units and flingys. This proves two things:

1. You don't listen to what other people have to say.
2. You don't understand how Starcraft graphics really work.

[matefkr]

I said that you have right about unused tiles. I haven't use scmdraft yet, but i verified your posting with a my hack of an scm file (not scm, but chk). Blizzard hadn't make it hard for me, the tileset informaitions started after a normal ASCII string "TILE". I saw 00 byte then a number byte, 00 byte ...i changed a number byte to ff, then i see what you said.

[nirvanajung]

am i need to listen what they have to say indispensably ?
there was no time to listen they say
indispensably, should i just wait till they saying about their oppinions?
if u think so, ok forget about it if u though should i wait to listen they saying
then i can't explain what i wasnt complaining
and as for the "tileset" folder if actually that changes all colours
for units and flingys GRP as want anything
then yeah... i accept that i'm misstake

but what i was right to do,
back to first my reply for SF
i said that the main issue is Starcraft's colouring handle of SC engine code
that my kernel of point
anyhow the master of access subject is colouring handle inthe Starcraft engine
that's top of controler so i wasnt saying for present rule of colouring
which is Starcraft graphics really work now
my point is the changing SC engine to derestrict use way of the colour
so i said that we need to discover for Starcraft graphics working
but u did reply as "the present rule of Starcraft graphics working" for my post

so i tried 2 say that i know already what u said about the present rule
but u tried again explain with the present rule
that's the reason what i was felt u underestimates other people's knowledge

now u got it my point ?

[nirvanajung]

matefkr : if u wanna get know about lo*
try look around this link page
http://www.staredit.net/index.php?showtopic=37762
there are discussion for Lo* files

BTW, AqoTrooper, I won't waste of time any more
i don't want hear that u saying "the present rule of Starcraft graphics working" whatever i said for rendering handle to colouring by SC engine code not about requirement setting file in the present format

however i don't underestimate u
i believe that u know as well as solve modding by ur self without trouble

Back to main issue of first post person and take care ur project
i don't want waste of time for my mod project now

then i'm going to 3d graphic work to get rendering as FLC file for GRP

[matefkr]

Thanks!

[ITSTORRASQUE4U]

Ok, back to subject....

What you're saying there Aqo, is that we can just overlap those black tiles with our own, and then just use those for our tileset, right? Then, more questions arise:

1. Are those empty squares enough to produce a fairly decent tileset?
2. Will future mapmakers have to use the index tile display?
3. What about doodads?

Thanks again :)

[TheNomad]

Regarding generic questions:

I'm afraid LO? files are the only one aspect of Starcraft modding I have never got into, so I can't help you on this :(

One of the things we agree on. LO? files are overlays (responsible for dust on burrowing/liftoff/unburrowing/land, flames/shield damage etc.). BK is currently doing some research on them and I got into them (but on a very basic level atm). They also control offsets (like where turrets should be placed etc.).

nirvana: don't forget SC ai bug's, you can find a lot.. what ever, can you offer me a good disassembler? i've found a crappy one, but this one recompile the whole file, even those bytes, wich won't be executed (variables, .exe header, and may be free spaces). Please send me a link if you know one.

Sorry about grammatical mistakes.

Olly Debugger. It's the one I use. I tried a few, my second favorite is PE Explorer, but olly will also let you modify the exe. I looked around for tuts, but didn't find any. I just learned as I moved along (plus DoA showed me a few things to get me started).

---

As for on topic:

I had an idea of using 2 methods of making tilesets (apart from EXE restructuring): replacing current tilesets OR using unused tileset spaces...
I saw the second was also suggested by Aqo. The reason I didn't bring it in is because I am not 100% sure if it'd work OK (although it should in theory). However, it won't be possible to add new doodads due to the images.dat limit.

---

As for off topic:

I've known both modders for some time, both nirvana and Aqo, and I have to say both of you are very good. I see you have different points of view, but I know both of you can do quite a lot of amazing things due to your intensive knowledge of GRPs :) That having been said, the off topic discussion can be ended :)

---

As for what I said, sorry if I wrote things in a weird way and made them sound differently than intended, but I'm glad to see that now as they're all cleared up we reached a common point of view :) (I'm also glad I didn't write completely wrong stuff :P). I consider myself a very good modder on the coding part, the GRP is something I am ok at, but only at theoretical stuff, still got lots to learn.

Torrasque, I suggest you focus the project on the units, music, sounds and storyline and leave the tilesets at the end, but it is your decision :)

[ITSTORRASQUE4U]

Oh well, all those aspects are being developed at the moment: the modding one is the slowest and is currently isolated from the rest of the project. Therefore, all our questions about the capabilities of the project have not been answered as we would like to. All other areas are progressing smoothly, except this one. Thanks again for the help :)

BTW, would any of you modding gurus in here, despite probably having godly issues to attend, like to be actively in this project? Your help and/or periodic advice is most needed.

The off topic:

" MPQ Compactor
Author: BSTRhino
Required files: WinMPQ | Windows Script Host for Windows 98, NT 4.0 and ME or Windows Script Host for Windows 2000 and XP
Mirrors: None
Downloads: 5128
This program is designed to save you time when making your MPQ customs. Take a folder, drag and drop it onto this program, and within a few seconds the MPQ Compactor will have finished compiling all the contents of that folder into an MPQ for you. It will even run MPQDraft and execute your patch if you have MPQDraft.exe in the same folder. With this program, making customs is effortless. Requires WinMPQ and Windows Script Host 5.6. To download this, choose the operating system you use: Windows 98, NT 4.0 and ME or Windows 2000 and XP."

THAT'S the thing I can't dl. Does anybody have a copy? :(

[WonkierBubble]

http://www.microsoft.com/downloads/details.aspx?FamilyID=C717D943-7E4B-4622-86EB-95A22B832CAA&displaylang=en&Hash=Eh%2bmpFxJeSn8bfJONiFX4p%2bpJR8gNQW9qkG6nkP6d lgi5RmnX9uNcseZ1w8MktIfaC8J0KiB4nUJaomDvinQxw%3d%3 d

Bam!

If that doesn't work just search for the thing on Google; that's what I did.

If that doesn't work, I uploaded it to Filefront for you.
http://files.filefront.com//;6534526;;/

[ShadowFlare]

You've made several mistakes here. First, there are 256 colors, not 255. Second, true that there is no "transparency" like the 24-bit one, but there is an 8-bit transperacy which is defined by a dat entry which is called "images.dat", where a special attribute loads a palette from SC; each palette has specific 8-bit transperacy indexes. As for convertors, RetroGRP, they do nothing to make things easier. They do all and just what you need, convert indexes of any 8-bit image into an 8-bit pack of images called GRP. The colors of those images do not matter at all, just the indexes.
lol, I wasn't trying to start a discussion about this. BTW, I did say there are 256 colors available to use and not just 255. It is when using a converter like RetroGRP or my own that only 255 are available. Anyway, I know exactly how it all works. As I said, there is a special code for complete transparency (0% opacity) in the actual format, which doesn't use up one of those 256 colors in the palette. For an example of this, try using my converter to make an image using color 0 and set the transparency color as something else when you convert it back to a GRP. On most tilesets this will just be black, but on space, it will show the stars wherever you have color 0. =)

As for when I was saying something about "making it easier" I was referring to the fact that without just designating some arbitrary color as a "transparency color" you need a separate mask image to determine what parts of the image to show and what parts not to show. I seem to remember the converter from StarDraft doing this.

As for the other transparency/translucency colors, I know all about those as well. Each "palette" in images.dat has its own table in .pcx format for blending colors together for those translucency effects. One useful thing about knowing this is that you can expand the sizes of those tables so that SC doesn't crash when you use higher color numbers with them.

It is very likely the order in which SC does its processing to determine the colors goes something like this:

1) While decoding rows in the GRP, if it is a transparent pixel, do not draw anything, if it is an actual color then continue processing.
2) Look up which color translation table to use (from images.dat).
3) Read the color of the pixel that will be drawn over.
4) Look up the new color in the table, based on the color from the GRP and the color that it is being drawn over.
5) Write the pixel on-screen.

The .wpe palette of course doesn't fit directly into this processing, since SC doesn't need to check the palette; the palette is basically an automatic thing once it is loaded. Also, the above steps would be a bit different for the EMP Shockwave "palette" in images.dat. As far as I know, the translation table for that one instead determines the X displacement of the pixel to read from and then display; therefore not determining any actual color based on the GRP's colors, just a displacement value.

[TheNomad]

The off topic:

" MPQ Compactor THAT'S the thing I can't dl. Does anybody have a copy? :(

Stick to the WinMPQ + MPQDraft combo for now :)

[Aqo]

1. Are those empty squares enough to produce a fairly decent tileset?
More than enough; most tilesets have more empty squares in them than used squares. Those "squares" are called megatiles, by the way :P

2. Will future mapmakers have to use the index tile display?
Yes.

3. What about doodads?
Doodads are just normal terrain, that is up to you to be placed rather than be randomized by the original editor; some of them also have a sprite sticking on them (to cover stuff below it; i.e. treetops) - you can manually place those sprites if needed with SCMDraft on top of the doodad's terrain of your new doodads.

(space 0% transperacy): true that.

("making it easier") Ok...

(translucency effects) Yup.

It is very likely the order in which SC does its processing to determine the colors goes something like this:

1) While decoding rows in the GRP, if it is a transparent pixel, do not draw anything, if it is an actual color then continue processing.
2) Look up which color translation table to use (from images.dat).
3) Read the color of the pixel that will be drawn over.
4) Look up the new color in the table, based on the color from the GRP and the color that it is being drawn over.
5) Write the pixel on-screen.

The .wpe palette of course doesn't fit directly into this processing, since SC doesn't need to check the palette; the palette is basically an automatic thing once it is loaded. Also, the above steps would be a bit different for the EMP Shockwave "palette" in images.dat. As far as I know, the translation table for that one instead determines the X displacement of the pixel to read from and then display; therefore not determining any actual color based on the GRP's colors, just a displacement value.
Looking at this, I think we're saying the same thing in different wording.

---

nirvanajung, I think I got your point, you say that if we could change the SC engine we'd be able to make Starcraft handle colors differently in an entire new way. However, if we could change the SC engine, we could as well just create our own new engine and recreate a new 24-bit 3D engine. Since none of us can do it, I'm discussing practical possibilities to use the Starcraft engine with how it handles graphics now to create top-quality images.

[BroodKiller]

I gotta bookmark this thread, so that I really know what I'll be doing with GRPEd :)

[ShadowFlare]

I gotta bookmark this thread, so that I really know what I'll be doing with GRPEd :)
Heh, referring to my lengthy descriptions? :)

[ITSTORRASQUE4U]

Stick to the WinMPQ + MPQDraft combo for now :)

No, I had no problems downloading MPQCompactor. THE PROBLEM IS Script Host 5.6.

On topic:

Now, I think I should start tileset learning by modifying an existing one, right? More questions arise:

1. When loaded via tileset editor, the terrain splits into megatile groups, and when you export them via .bmp you only see a "stripe" containing all the megatiles. Therefore, you modify the complete stripe and all megatiles there should "interlock" just like in-game megatiles do, right?
2. Does each tileset have it's own palette (this was probably a stupid question, they do right? :rolleyes: ).
3. Lets say I export the "stripe" to photoshop, paste a photo on it, turn it into .bmp (using the tileset palette of course) and give it back, will it work?
4. Are doodads edited in the same way?

Thanks again :)