I've started integrating your new graphics into the game, but ran into a couple of minor problems. The scale and angle of the images isn't quite right, and when I resize and rotate them so that they are in appropriate proportions I lose too much graphical quality. Perhaps you'd be willing to take some new images for me?
Armory: Just right Arms: Just right CC: Just right Collector: 25% larger Obs: Just right Phase: 25% larger IP: 25% smaller Proto: 25% larger Seige: Just right, facing north TF: Just right Sentry: 25% smaller, facing north
The angle of facing for most structures is unimportant, but the guns have to face the right way when firing. Slot the graphics into your own copy of the game to check that they look right!
If you could fix me up with these adjusted assets I would be most appreciative :) Perhaps you'll find time to do the unit animations as well at some point in the future. You are helping to make Starstrike a far better looking game!
Heres the skulk and gorge animations and the sentry tower which I forgot to put in the last rar. <a href="http://www.2shared.com/file/7248829/d64aa513/SkulkGorge.html" target="_blank">http://www.2shared.com/file/7248829/d64aa513/SkulkGorge.html</a>
Just a quick question, currently it looks like all the images are just color-key transparancy. Is there any chance of having either alpha transparancy (and swtiching from .bmp to .tga or something similar), or at least addative blending (would be usefull for stuff like spores and spit)?
It's possible to change formats for specific assets, but I'm handling transparency at code-level. It's easier for me as a programmer to keep a universal format across the board using color-key transparency, and then if the image requires alpha transparency (such as with spore clouds or explosions, structure placement blueprints, etc) I am applying that at code-level, which is a very simple matter and allows me to dynamically adjust image transparency on the fly at run-time. Unless you have particular need of partial transparency within sections of each image, it makes more sense to retain the existing structure.
Having said that, I am always open to making changes if you have particular need. Is there some sort of advantage in using fixed transparency at asset-creation time rather than at code-level runtime?
Currently the only things I'm having transparncy problems with is the gorge spit and explosions. They need to be addatively blended and currently there color keyed as well, it looks very wrong. If you could change it at a code level that would be fine.
Actually you are right; the explosions don't look right at all at the moment. I'm using transparency on them at the moment which I'm not sure is implemented in the current downloadable build (which is a solid year old now). Perhaps for visual effects like that we should make an exception and handle transparency at asset-time. Do you have a better looking explosion asset with transparency already mapped in? Or, are you able to produce one? If it looks better your way, we'll do it that way!
As for spit, it's just a circle at the moment :) That little green blob is going to replaced at some point.
The effects like explosions, spit and spores need addative blending.
Final pixel color = background pixel + texture pixel;
So if the texture pixel is black the framebuffer isn't changed. Notice that half-life sprites always have a black background so that they can be addativly blended.
Yes. That's how I've been handling transparency at code level, except that I'm using 255,255,255 (white) as the transparent color. The problem with the explosions is that the borders of the explosion itself are near-white as they blend from orange explosion flame to the background color, and near-white is displayed as-is rather than partial transparency. This is why I agree that the explosion asset might be better off with asset-transparency rather than code transparency. I will look into this.
Let me know when you have the other aliens and marines ready to go :)
I think I may be confusing things here. As I see it currently the engine is using color-key transparancy with white as the color key. What I'm suggesting is instead we use addative blending for the effects like explosions etc.
To see the differnce look at this picture I mocked up in photoshop. The top explosion is color-keyed with black (0,0,0) as the color key. The bottom one is addatively blended. They are both the same explosion picture.
Yes, I understand the difference. I'm not sure how we can implement additive transparency, though.
Color-key transparency is a simple matter at code-level; my rendering routine just needs to be told what the transparent color is, and the global alpha level of the entire image and it will happily draw the image correctly, with the color-key color not drawn at all and the whole image at the specified transparency. Also at code-level I am able to read image formats TGA, DDS and PNG, and retain their alpha-channel transparency information when rendering them to the screen. Perhaps using a combination of these techniques would do the trick; what I need is an explosion asset that has alpha-channel full transparency at the boundary of the orange explosion flame, extending outward to the square canvas border, and gradated near-transparency just within the border of the flame. Then I can use code-level transparency to determine the general transparency of the flame at run-time.
I did a little search I think I've found the command. Try using "Ghost object on id" on special effects, where id is the object id of the object to turn ghosting on. This is how dark basic does addative blending. Then you just need to use black background sprites.
I'm familiar with the ghost object command set. They operate on 3D model objects only and don't apply to 2D sprites, but they have the same effect as the code I'm using to manipulate sprites.
SET SPRITE ALPHA is the key command I'm working with. It takes the transparent color-key into account and applies a global additive transparency to the remainder of the image.
Just for the record, the background doesn't have to be black for any sort of transparency to work. I deliberately selected white for the color-key instead of black, because it was easier to create assets that way.
Now that I think about it, I'm fairly sure all we need is a decent explosion animation that doesn't have white smokey edges around the orange flame. I generated this one quickly a long time ago, but if we can put our hands on a decent explosion animation asset I think we could run it through the existing, unchanged transparency code and it would look just fine.
I'd just like to announce that I finally got around to repairing the damage the hacker did to Starstrike's official website and forum system. Now that production on the game is back in full swing, I clean swept the site files from the host and rebuilt everything from scratch, replacing all the old data with duplicate information so that everything is back the way it was!
Anybody interested in continuing to follow production of the game is encouraged to head on over to <a href="http://www.starstrike.ausleague.com" target="_blank">http://www.starstrike.ausleague.com</a> and sign up on our official forums to contribute!
In the coming weeks I hope to release a new Alpha build containing all the tweaks and updates I've done unannounced over the last year in idle downtime for you all to play and enjoy.
Thanks again for everyone's support. See you soon :)
Work on the graphics has been slow as I've been working on a better way to do the animations and working out a way to get marines weapons in. Have a solution but it's gonna take a while to put together. But once it's done I should have all the animations out in a few days.
I've been looking into drawing some tilesets and have come to the conclussion that their only really going to look good if we change the way the map is rendered slightly. I would need two layers, a floor layer which is drawn first. And then a wall layer that is drawn ontop of the floor layer and can support transparent parts. Is this possible?
Here's an example, the top shows the floor layer, and the bottom shows the floor layer with the wall layer ontop of it.
It's possible but from a strictly programming standpoint less desirable; the fewer rendering steps per iteration, the better on account of processing speed.
As you know, at the moment the walls and floors are combined into composites and pasted as one prerendered tile to the map. Over the multi-stage render method the advantage is uncompromised mainloop cycle speed of the game (and features, as far as I can tell, identical graphical quality). It does result in (a little) more work for the artist (as he has to manually rotate each wall for NSEW-facing walls and paste it to each floor type) and a higher physical number of tiles, but that's a better tradeoff than cycle speed or graphical quality.
Why would only look good if we use a multi-stage render? I would have thought the final screen output would look identical to prerendered composites.
I think I may of misunderstood how the engine worked. Would you be able to release the map editor so I can see how it works. Or give a good description of the map making process. I think that it may work out all fine after all.
Next time I see you on MSN I'll send the editor your way, if you like. It's a simple one-layer tilebased affair. If you take a look at the tiles in the GFX folder, you'll see that the tiles are numbered. All files in this folder are loaded into the game engine and assigned a unique identifying tag that equates to the filename number. Any tile with a tag > 500 is impassible, all other tiles are walkable, and it's as simple as that. Special tiles such as resource nodes and hive hardpoints are treated, for the most part, the same way, except that there are special behaviours hardcoded for them in the game code itself for the relevant tag numbers.
If you need any information more specific than that, hit me up here or on MSN.
Ok I'll have a look at the tiles again, that info helps. I'm moving to university over the weekend so could you email the map editor instead (Same address as my MSN) thanks.
Comments
I've started integrating your new graphics into the game, but ran into a couple of minor problems. The scale and angle of the images isn't quite right, and when I resize and rotate them so that they are in appropriate proportions I lose too much graphical quality. Perhaps you'd be willing to take some new images for me?
Armory: Just right
Arms: Just right
CC: Just right
Collector: 25% larger
Obs: Just right
Phase: 25% larger
IP: 25% smaller
Proto: 25% larger
Seige: Just right, facing north
TF: Just right
Sentry: 25% smaller, facing north
The angle of facing for most structures is unimportant, but the guns have to face the right way when firing. Slot the graphics into your own copy of the game to check that they look right!
If you could fix me up with these adjusted assets I would be most appreciative :) Perhaps you'll find time to do the unit animations as well at some point in the future. You are helping to make Starstrike a far better looking game!
Thanks for the updated structures!
The sentries seem to be missing though - they need to be made 25% smaller and rotated to face north.
See how you go with the unit animations too :) Thanks!
Although the sentry is now facing the correct direction it still seems a little too big. Could you reduce it a further 25% in size?
Thanks for your continued efforts, the game is looking better already :)
It's possible to change formats for specific assets, but I'm handling transparency at code-level. It's easier for me as a programmer to keep a universal format across the board using color-key transparency, and then if the image requires alpha transparency (such as with spore clouds or explosions, structure placement blueprints, etc) I am applying that at code-level, which is a very simple matter and allows me to dynamically adjust image transparency on the fly at run-time. Unless you have particular need of partial transparency within sections of each image, it makes more sense to retain the existing structure.
Having said that, I am always open to making changes if you have particular need. Is there some sort of advantage in using fixed transparency at asset-creation time rather than at code-level runtime?
As for spit, it's just a circle at the moment :) That little green blob is going to replaced at some point.
Final pixel color = background pixel + texture pixel;
So if the texture pixel is black the framebuffer isn't changed. Notice that half-life sprites always have a black background so that they can be addativly blended.
Let me know when you have the other aliens and marines ready to go :)
As I see it currently the engine is using color-key transparancy with white as the color key.
What I'm suggesting is instead we use addative blending for the effects like explosions etc.
To see the differnce look at this picture I mocked up in photoshop. The top explosion is color-keyed with black (0,0,0) as the color key. The bottom one is addatively blended. They are both the same explosion picture.
<img src="http://i37.photobucket.com/albums/e78/Frassle/Blending.jpg" border="0" class="linked-image" />
Color-key transparency is a simple matter at code-level; my rendering routine just needs to be told what the transparent color is, and the global alpha level of the entire image and it will happily draw the image correctly, with the color-key color not drawn at all and the whole image at the specified transparency. Also at code-level I am able to read image formats TGA, DDS and PNG, and retain their alpha-channel transparency information when rendering them to the screen. Perhaps using a combination of these techniques would do the trick; what I need is an explosion asset that has alpha-channel full transparency at the boundary of the orange explosion flame, extending outward to the square canvas border, and gradated near-transparency just within the border of the flame. Then I can use code-level transparency to determine the general transparency of the flame at run-time.
That should do the trick, no?
Try using "Ghost object on id" on special effects, where id is the object id of the object to turn ghosting on. This is how dark basic does addative blending. Then you just need to use black background sprites.
I'm familiar with the ghost object command set. They operate on 3D model objects only and don't apply to 2D sprites, but they have the same effect as the code I'm using to manipulate sprites.
SET SPRITE ALPHA is the key command I'm working with. It takes the transparent color-key into account and applies a global additive transparency to the remainder of the image.
Just for the record, the background doesn't have to be black for any sort of transparency to work. I deliberately selected white for the color-key instead of black, because it was easier to create assets that way.
Now that I think about it, I'm fairly sure all we need is a decent explosion animation that doesn't have white smokey edges around the orange flame. I generated this one quickly a long time ago, but if we can put our hands on a decent explosion animation asset I think we could run it through the existing, unchanged transparency code and it would look just fine.
If anyone else has played, do let us know how you go with it and what you think!
Any 2D tileset artists out there?
I'd just like to announce that I finally got around to repairing the damage the hacker did to Starstrike's official website and forum system. Now that production on the game is back in full swing, I clean swept the site files from the host and rebuilt everything from scratch, replacing all the old data with duplicate information so that everything is back the way it was!
Anybody interested in continuing to follow production of the game is encouraged to head on over to <a href="http://www.starstrike.ausleague.com" target="_blank">http://www.starstrike.ausleague.com</a> and sign up on our official forums to contribute!
In the coming weeks I hope to release a new Alpha build containing all the tweaks and updates I've done unannounced over the last year in idle downtime for you all to play and enjoy.
Thanks again for everyone's support. See you soon :)
Any progress? :)
I've been looking into drawing some tilesets and have come to the conclussion that their only really going to look good if we change the way the map is rendered slightly.
I would need two layers, a floor layer which is drawn first. And then a wall layer that is drawn ontop of the floor layer and can support transparent parts. Is this possible?
Here's an example, the top shows the floor layer, and the bottom shows the floor layer with the wall layer ontop of it.
<img src="http://i37.photobucket.com/albums/e78/Frassle/Tileset.jpg" border="0" class="linked-image" />
As you know, at the moment the walls and floors are combined into composites and pasted as one prerendered tile to the map. Over the multi-stage render method the advantage is uncompromised mainloop cycle speed of the game (and features, as far as I can tell, identical graphical quality). It does result in (a little) more work for the artist (as he has to manually rotate each wall for NSEW-facing walls and paste it to each floor type) and a higher physical number of tiles, but that's a better tradeoff than cycle speed or graphical quality.
Why would only look good if we use a multi-stage render? I would have thought the final screen output would look identical to prerendered composites.
If you need any information more specific than that, hit me up here or on MSN.