It's not if you have really high resolution or are sitting very far from screen. You might notice during actual loading, though, when the image is scaled to full screen size.
I made it 1600x1200, so it will look better on higher resolutions. Despite the size, it's only 684 kb (compressed), which is far less than the previous one. Worked out pretty good, I think.
I will attach a screenshot of how the loading screen looks for me in game, for anyone who is curious.
Can definitely recommend Aorta to anyone else who needs to make large textures!
Thanks, that Aorta program was much better than the Photoshop plugin! It still caused some issues with the outline around the logo, but I increased it in size by 1 pixel, so it's pretty much not noticable now.
Looks much better:
The size of Aorta's output file is even half the size of the plugin's!
Maybe I can even make a higher res version now, can certainly afford the space...
I tried some different formats, with the following results:
DXT5 was just as bad, same artifacts.
4.4.4.4 had insufficient color depth.
5.5.5 and 5.6.5 are not supported, the texture is completely messed up.
8.8.8 provides quality equal to TGA, but the file size is 75% of TGA, which is still pretty damn large.
I'll just use 8.8.8 unless someone else has a better alternative. It's 1.61 MB when compressed inside map. I understand that more compression means lower quality, but the rest of the image looked fine in DXT3. It's just annoying that there's one spot where quality is just too damn bad to tolerate (and removing the map logo is not an option).
I have a loading screen of size 1024x768, which I compressed according to the sticky guide by Otixa (DXT3, no mips), but I am getting some really ugly compression artifacts. The loading screen contains a lot of different shades, so indexed color TGA as was suggested in some other thread is not an option, and regular TGA is about 4.5 times the size.
This is how the problematic area looks, compared to the TGA:
As you can see, it's really not passable quality.
Is there a better option which will avoid this issue, but allows good compression ratio and works with SC2?
May be worth noting that the image has no alpha channel, so an option with no alpha is fine.
I have a ModelAddition actor that attaches a bubble (TimeBomb model) to heroes that are incapacitated. It works for every hero, except the one based on Karass. I am using SOpAttachCenter, which the High Templar model does have, and host _Selectable. See actor events for ModelAddition in attachment.
I noticed Karass actor has a non-default Animation Blend Time, not sure if this would matter.
Saw it on Kotaku, looks great, not a huge MMO fan after quitting WoW, but I'll definitely check this out. Hopefully it won't feel like work since you won't have 40 man raids and thus the obligation to show up and not disappoint your guild.
I just hope there will be SOME players left for other maps :P
One is a puzzle map I started making, which was intended as a cooperative project that other people could add to, but I began another project and thus didn't have time for it.
I also made a rather unique, at least to my knowledge, map in StarCraft 1. The idea is that you have one of every unit in the game available to select, but you can only pick each unit once, and you must use every unit. After picking you are sent into an arena and last player (or last team) left alive gets a point for that round.
When all units have been used, the player, or team, with the most points wins.
I also had a timer that, when it expired, gave the round point to the player/team with highest kill score, to avoid people just running around indefinitely to avoid losing.
It's partially microing a specific unit well, using terrain well, and also if you play as a team you can complement each others' units, or if someone uses a very powerful unit one round you can use a bad unit that round and save better ones for later.
If you picked a worker unit you got lots of minerals and gas for that round, so you could build some or repair an ally.
I might have used things like pickups if they had been available in SC1.
This post outlines a process for how cooperative development can be handled. This process is used for the hero survival project Frontline, and may be of benefit to anyone who is planning a project where terrain and preplaced units are done by one person while data and triggers are done by another.
The purpose is to create a single map file containing everything, no mod creation required, but to be able to develop terrain and placement portion separately from data and trigger portion. Two people can then work on these parts seperately, on their own, at their own pace, and without having to send files back and forth or worry about version conflicts.
First, let's look at the pros and cons of using this development approach.
Pros:
No version conflicts.
No need to send files back and forth.
No time lost waiting for other person to be done with file.
Easy to merge work later.
Map load faster for testing.
Cons:
Terrainer can't do data editing to use imported models for custom doodads or such.
New units created in data cannot be placed until merge.
May use more global variables than normal.
The idea here is to have two separate map files. One is maintained by the terrain developer, the other by the data/trigger developer. They both can just start a new map from scratch and begin work, no special setup required. The two maps will be developed separately and then merged at the end of the project, with minor work required to merge.
Terrain developer:
Your map will contain the terrain, preplaced units, doodads and anything else that you work with using the editor's main view.
Restrictions:
It cannot contain any (with some exceptions) data editing, since this will be overwritten during merge. If you need to place something that will be made by data editing, use an obvious placeholder like a rainbow or such instead. Then replace your placeholders after merge.
You can still accompish a lot by tweaking doodads, like applying tints or rescaling using the object properties. If you do need to create something however, use placeholders and do it after merge.
The exception to the rule is that you may change things under the Terrain data type, such as tileset and water, this will make changes in data but it is assumed the data/trigger developer will not need to change these, while you most likely will.
You can create triggers as long as they are for purely debug purposes, since they will be overwritten later.
Data/Trigger developer:
Your map should contain the data editing and triggers. This map will also contain imported files, as you will need to refer to them in data or triggers, e.g. layout files, icons, models and so forth.
Restrictions:
You may create terrain for testing purposes only. I suggest you keep it simple, as it will be overwritten by the real terrain. You can edit tileset or water for this testing terrain, but these changes will be overwritten later. If you need to change anything in any of the terrain data types which needs to be in the final map, save this for after the merge.
Furthermore, it is important that you do not refer to anything preplaced (units, regions, points, etc) in your triggers. If you need to refer to something that will be preplaced in the map, create a global variable for it, then use that variable wherever you would use the preplaced object.
For testing, you can place things and then initialize those global variables to your placed objects on map initialization. Put all your variable initalizations in one trigger, or inside an action definition. This will save a lot of work and reduce errors later.
After merge, your references to preplaced objects will be completely wrong, a point may refer to a doodad or such. But since you are using variables, you need only change the initialization of your variables, and if you followed the advice above, you only have to do it once and just in one place.
Merging the maps:
To merge the maps, save both maps as Editor Component Lists. That will give you a folder for each map. To merge them, you will need to copy files from one of the folders to the other. I suggest you copy from terrain map to data/trigger map.
The following files should be copied from terrain map to data/trigger map: Base.SC2Data\GameData\TerrainData.xml
Base.SC2Data\GameData\WaterData.xml
MapInfo
MapInfo.version
Objects
Objects.version
PaintedPathingLayer
t3CellFlags
t3FluffDoodad
t3HardTile
t3HeightMap
t3SyncCliffLevel
t3SyncHeightMap
t3Terrain.version
t3Terrain.xml
t3TextureMasks
t3VertCol
t3Water
The following files will need to be merged together from both maps' versions:
ComponentList.SC2Components - copy over any entries from the terrain map's version that is not in the data map's. Preload.xml - copy over the terrain map's entries to the data map's.
Note: This list may not apply fully to your project, it is how things look for Frontline.
After you've merged, open the resulting folder and save as Editor Map File. You now have a single map file. Replace placeholder objects and change initialization of variables, as well as any other things which need doing after merge. Also ensure the settings in the Map menu are correct, such as player properties and game variants (they were not for me).
Note: This last part cannot be done in parallel, but since map is mostly complete you will likely be able to just take turns with the map file fixing the post-merge details without losing a great deal of time.
Minerals are gained by random drops in arenas, with an expected value of 2.4 minerals per arena, +1 for defeating boss.
You can buy more Medkits, Batteries, as well as +2 boosts to an attribute for 10 minutes. You can also buy a level, but it costs 50 minerals, so you would have to play about 15 arenas without spending any minerals on anything else to afford it.
I added a new option to the arena creation. You can now choose if you want the waves to be a mix of units generated randomly or if each wave should contain only one type of unit chosen at random.
0
It's not if you have really high resolution or are sitting very far from screen. You might notice during actual loading, though, when the image is scaled to full screen size.
0
I made it 1600x1200, so it will look better on higher resolutions. Despite the size, it's only 684 kb (compressed), which is far less than the previous one. Worked out pretty good, I think.
I will attach a screenshot of how the loading screen looks for me in game, for anyone who is curious.
Can definitely recommend Aorta to anyone else who needs to make large textures!
0
Thanks, that Aorta program was much better than the Photoshop plugin! It still caused some issues with the outline around the logo, but I increased it in size by 1 pixel, so it's pretty much not noticable now.
Looks much better:
The size of Aorta's output file is even half the size of the plugin's! Maybe I can even make a higher res version now, can certainly afford the space...
0
Well, a progress report...
I tried some different formats, with the following results:
I'll just use 8.8.8 unless someone else has a better alternative. It's 1.61 MB when compressed inside map. I understand that more compression means lower quality, but the rest of the image looked fine in DXT3. It's just annoying that there's one spot where quality is just too damn bad to tolerate (and removing the map logo is not an option).
0
I have a loading screen of size 1024x768, which I compressed according to the sticky guide by Otixa (DXT3, no mips), but I am getting some really ugly compression artifacts. The loading screen contains a lot of different shades, so indexed color TGA as was suggested in some other thread is not an option, and regular TGA is about 4.5 times the size.
This is how the problematic area looks, compared to the TGA:
As you can see, it's really not passable quality.
Is there a better option which will avoid this issue, but allows good compression ratio and works with SC2? May be worth noting that the image has no alpha channel, so an option with no alpha is fine.
0
I have a ModelAddition actor that attaches a bubble (TimeBomb model) to heroes that are incapacitated. It works for every hero, except the one based on Karass. I am using SOpAttachCenter, which the High Templar model does have, and host _Selectable. See actor events for ModelAddition in attachment.
I noticed Karass actor has a non-default Animation Blend Time, not sure if this would matter.
Any ideas?
0
@Nebuli2: Go
But not 40 man raids...
0
Saw it on Kotaku, looks great, not a huge MMO fan after quitting WoW, but I'll definitely check this out. Hopefully it won't feel like work since you won't have 40 man raids and thus the obligation to show up and not disappoint your guild.
I just hope there will be SOME players left for other maps :P
0
I linked to it as an example of things I gave up rather than getting stuck with a detail and never finishing the map.
0
You do realize this thread is almost a year old...?
0
Well, I can offer two ideas.
One is a puzzle map I started making, which was intended as a cooperative project that other people could add to, but I began another project and thus didn't have time for it.
You can find that map and details here: http://www.sc2mapster.com/forums/resources/project-workplace/21100-puzzle-rooms-working-title-a-cooperative-project/
I also made a rather unique, at least to my knowledge, map in StarCraft 1. The idea is that you have one of every unit in the game available to select, but you can only pick each unit once, and you must use every unit. After picking you are sent into an arena and last player (or last team) left alive gets a point for that round.
When all units have been used, the player, or team, with the most points wins.
I also had a timer that, when it expired, gave the round point to the player/team with highest kill score, to avoid people just running around indefinitely to avoid losing.
It's partially microing a specific unit well, using terrain well, and also if you play as a team you can complement each others' units, or if someone uses a very powerful unit one round you can use a bad unit that round and save better ones for later.
If you picked a worker unit you got lots of minerals and gas for that round, so you could build some or repair an ally.
I might have used things like pickups if they had been available in SC1.
0
Cooperative Project Management
Separate Terraining and Data/Triggers
This post outlines a process for how cooperative development can be handled. This process is used for the hero survival project Frontline, and may be of benefit to anyone who is planning a project where terrain and preplaced units are done by one person while data and triggers are done by another.
The purpose is to create a single map file containing everything, no mod creation required, but to be able to develop terrain and placement portion separately from data and trigger portion. Two people can then work on these parts seperately, on their own, at their own pace, and without having to send files back and forth or worry about version conflicts.
First, let's look at the pros and cons of using this development approach.
Pros:
Cons:
The idea here is to have two separate map files. One is maintained by the terrain developer, the other by the data/trigger developer. They both can just start a new map from scratch and begin work, no special setup required. The two maps will be developed separately and then merged at the end of the project, with minor work required to merge.
Terrain developer:
Your map will contain the terrain, preplaced units, doodads and anything else that you work with using the editor's main view.
Restrictions:
It cannot contain any (with some exceptions) data editing, since this will be overwritten during merge. If you need to place something that will be made by data editing, use an obvious placeholder like a rainbow or such instead. Then replace your placeholders after merge.
You can still accompish a lot by tweaking doodads, like applying tints or rescaling using the object properties. If you do need to create something however, use placeholders and do it after merge.
The exception to the rule is that you may change things under the Terrain data type, such as tileset and water, this will make changes in data but it is assumed the data/trigger developer will not need to change these, while you most likely will.
You can create triggers as long as they are for purely debug purposes, since they will be overwritten later.
Data/Trigger developer:
Your map should contain the data editing and triggers. This map will also contain imported files, as you will need to refer to them in data or triggers, e.g. layout files, icons, models and so forth.
Restrictions:
You may create terrain for testing purposes only. I suggest you keep it simple, as it will be overwritten by the real terrain. You can edit tileset or water for this testing terrain, but these changes will be overwritten later. If you need to change anything in any of the terrain data types which needs to be in the final map, save this for after the merge.
Furthermore, it is important that you do not refer to anything preplaced (units, regions, points, etc) in your triggers. If you need to refer to something that will be preplaced in the map, create a global variable for it, then use that variable wherever you would use the preplaced object.
For testing, you can place things and then initialize those global variables to your placed objects on map initialization. Put all your variable initalizations in one trigger, or inside an action definition. This will save a lot of work and reduce errors later.
After merge, your references to preplaced objects will be completely wrong, a point may refer to a doodad or such. But since you are using variables, you need only change the initialization of your variables, and if you followed the advice above, you only have to do it once and just in one place.
Merging the maps:
To merge the maps, save both maps as Editor Component Lists. That will give you a folder for each map. To merge them, you will need to copy files from one of the folders to the other. I suggest you copy from terrain map to data/trigger map.
The following files should be copied from terrain map to data/trigger map:
Base.SC2Data\GameData\TerrainData.xml
Base.SC2Data\GameData\WaterData.xml
MapInfo
MapInfo.version
Objects
Objects.version
PaintedPathingLayer
t3CellFlags
t3FluffDoodad
t3HardTile
t3HeightMap
t3SyncCliffLevel
t3SyncHeightMap
t3Terrain.version
t3Terrain.xml
t3TextureMasks
t3VertCol
t3Water
The following files will need to be merged together from both maps' versions: ComponentList.SC2Components - copy over any entries from the terrain map's version that is not in the data map's.
Preload.xml - copy over the terrain map's entries to the data map's.
Note: This list may not apply fully to your project, it is how things look for Frontline.
After you've merged, open the resulting folder and save as Editor Map File. You now have a single map file. Replace placeholder objects and change initialization of variables, as well as any other things which need doing after merge. Also ensure the settings in the Map menu are correct, such as player properties and game variants (they were not for me).
Note: This last part cannot be done in parallel, but since map is mostly complete you will likely be able to just take turns with the map file fixing the post-merge details without losing a great deal of time.
0
I've finished the store.
Minerals are gained by random drops in arenas, with an expected value of 2.4 minerals per arena, +1 for defeating boss.
You can buy more Medkits, Batteries, as well as +2 boosts to an attribute for 10 minutes. You can also buy a level, but it costs 50 minerals, so you would have to play about 15 arenas without spending any minerals on anything else to afford it.
0
After a lot of mucking about with dialogs, I have produced a graphical hero selection!
0
I added a new option to the arena creation. You can now choose if you want the waves to be a mix of units generated randomly or if each wave should contain only one type of unit chosen at random.