Is there a way to change color/force removal of single-pixel stars in background?

[L.C.]

^^

 

Via LVZ or something, of course.

Edited November 13, 2009 by L.C.

[CRe]

star03.bmp

[L.C.]

star03.bm2 is a 7x7 star. The 1x1 pixel stars in the background do not have an image, I don't think..

[Samapico]

I think you can change their color with colors.bm2

[L.C.]

Meh, I practically blacked out everything in my colors.bm2 file and still nothing. I know there is 1 row that deals with the black background color.

 

[CRe]

Row 0: Background color

Row 1-3: Menu/radar border colors

Row 4-15: Nothing

Row 16: Radar background

Row 17: Radar grid

Row 18: Radar wall

Row 19: Radar safezone

Row 20: Radar door

Row 21: Radar enemy goal

Row 22: Radar friendly goal

Row 23: Radar prize

Row 24: Radar flag

Row 25: Radar portal

Row 26: Radar powerball

Row 27: Radar self with flag

Row 28: Radar self

Row 29: Radar teammate

Row 30: Radar teammate with flag

Row 31: Radar enemy with flag

Row 32: Radar enemy king of the hill

Row 33: Radar high bounty enemy

Row 34: Radar low bounty enemy

Row 35: Radar mine

Row 36: Radar decoy

Row 37: Radar bomb explosion

 

I don't see a star :/

[L.C.]

We can change the background color, but there's nothing on the pixel stars?

 

/facepalm

 

What has Continuum come to?

Edited November 14, 2009 by L.C.

[Hakaku]

If you really don't want the starfield, lvztile the entire arena with an off-black background (e.g. #000001).

[Samapico]

If you really don't want the starfield, lvztile the entire arena with an off-black background (e.g. #000001).

And prepare for high amounts of fps lag for some people.

Though if the image is pretty large it shouldn't be that much of a problem... might want to find the optimal image size for that. Too small and continuum has to draw a LOT of objects, too large and it might lag because of the amount of memory needed

[LiDDiS]

gradient.bm2

 

Line 1: 1/2-1/1 energy bar animation

Line 2: 1/4-1/2 energy bar animation

Line 3: 0/4-1/4 energy bar animation

Line 4: lvl1 bullet trail anim. (the left most pixel is nearers to bullet, and right most furthest away from bullet)

Line 5: lvl2 bullet trail anim

Line 6: lvl3 bullet/burst trail anim

Line 7: lvl4 bullet trail anim

Line 8: Not used

Top left (0,0) pixel controls the color of narrow 'bar' just above energy bar (separated by transparent/black gap between it them).

 

 

 

 

Nothing about stars in there either

 

They must be hardcoded into the game or something huh?

Edited November 14, 2009 by LiDDiS

[L.C.]

Just found out that the two different pixel star colors (white and gray) are part of the bomb trail. If you totally black out colors.bm2 and gradient.bm2, fire a bomb and follow your bomb, you can observe two pixels (with reasonable spacing between the two) trailing after the bomb.

[Samapico]

Bomb trail is in trail.bm2... (lvl1 to lvl4 and thor)

[»Blocks]

If you really don't want the starfield, lvztile the entire arena with an off-black background (e.g. #000001).

And prepare for high amounts of fps lag for some people.

Though if the image is pretty large it shouldn't be that much of a problem... might want to find the optimal image size for that. Too small and continuum has to draw a LOT of objects, too large and it might lag because of the amount of memory needed

MG's grainy background was a 350x350 .bmp (350 kb) and it worked fine. I separately used a 1000x1000 all-black .png (4.33 kb) which also worked fine and the .lvz of which is attached!

background.lvz

[L.C.]

Bomb trail is in trail.bm2... (lvl1 to lvl4 and thor)

I already have that image fixed as a 1x1 black pixel (which means there is no bomb trail -- YET ).

 

@Blocks Giving your LVZ a try!

 

EDIT: Works. Thanks.

Edited November 14, 2009 by L.C.

[L.C.]

Ok! Block's LVZ works only when I am in windowed mode. Doesn't matter if I have Vsync on or not.

 

EDIT: I figured out what the issue was with the two pixel stars following the bomb (bomb trail). If you use a 1x1 GIF, Continuum will not handle the graphic properly and will lead to animation and graphical glitching. If you use a 1x1 PNG instead, Continuum will handle it correctly without any issues.

 

For some images though, Continuum will handle 1x1 GIFs without issues. For the ones that do have issues, using a 1x1 PNG guarantees resolution. The difference between the two image formats is that GIF provides a significant compression difference for a 1x1 100%-black image than does PNG. This only matters if you're a perfectionist (like me) who tries to save space down to the very byte.

Edited November 15, 2009 by L.C.

[L.C.]

gradient.bm2

(4,0) works like (0,0), but is the alternate color that shows the maximum potential of energy you have left to upgrade to.

[Samapico]

Ok! Block's LVZ works only when I am in windowed mode. Doesn't matter if I have Vsync on or not.

 

EDIT: I figured out what the issue was with the two pixel stars following the bomb (bomb trail). If you use a 1x1 GIF, Continuum will not handle the graphic properly and will lead to animation and graphical glitching. If you use a 1x1 PNG instead, Continuum will handle it correctly without any issues.

 

For some images though, Continuum will handle 1x1 GIFs without issues. For the ones that do have issues, using a 1x1 PNG guarantees resolution. The difference between the two image formats is that GIF provides a significant compression difference for a 1x1 100%-black image than does PNG. This only matters if you're a perfectionist (like me) who tries to save space down to the very byte.

A safer way to black out animation graphics would be to use a M x N black image instead of 1x1, where (M,N) is the number of frames in the original animation, this way it uses a 1x1 pixel for each animation frame, instead of potentially screwing up. It's probably coded to handle this properly, but it's hard to tell (plus, a 10x4 png or whatever is not much larger )

[L.C.]

I think the reason why 1x1 PNGs work while 1x1 GIFs do not is related to the compression.

* If I run the 1x1 PNGs through PNG Monster, the PNGs will then behave like the 1x1 GIFs.

* If I do not run 1x1 PNGs through PNG Monster, the PNGs will behave correctly and it will work (but they are like 2 KB more than if I passed it through PNG Monster)

* 1x1 GIFs have better compression than PNGs (even if passed through PNG Monster)

* GIFs still have better compression than PNGs if I use a dimension like 10x1 instead of 1x1

 

Anyway, besides this, I have encountered one problem with Block's LVZ. It only worked in Windowed mode or if vsync is disabled. I have tried everything to get it working, but have no success (even with GIFs).

 

 

 

For Continuum graphics that have two or more rows of animations, a single row is enough if you want to black it out using GIFs. Therefore a height of 1px would work, but I think you have to compensate either a minimum number of x axis frames or the number of x axis frames in the image you are replacing. (A 1x2 px will not work for an image with 10 frames per row.)

Edited November 20, 2009 by L.C.

[Samapico]

You can't compare compression for such small images... they use color palettes, each in their own way... so the filesize for 1 or 10 pixels doesn't mean anything, really.

[L.C.]

Yes it does if you are a perfectionist and are trying to squeeze everything down the the smallest possible filesize. Here is a comparison:

 

For any GIF that has dimensions 1x1 through 10x1 (just changing width) and is pure black, filesize will be 35 or 36 bytes.

For any PNG processed through PNG Monster that has dimensions 1x1 through 10x1 and is pure black, filesize will range from 66 bytes to 88 bytes.

 

Big difference. Compression does matter, and the compression algorithms used for PNGs versus GIFs are very different. I have found that overall, PNGs offer the best compression when dealing with Continuum graphics. In extremely few cases does GIF win over PNG for regular images, but when it comes down to smaller images with a palette of one to a few colors, GIF easily wins over PNG.

 

JPG is perfect for photographs because its compression algorithms are more suited to the the kinds of shapes and variations that normally occur in photographs.

PNG is not overall good for photographs because of the kind of color variations that generally occur.

GIF is not good for photographs either (unless they are really small) because of its small palette limitations and compression (although if you are willing to accept color loss due to its palette and face compression artifacts, huge photographs could be of smaller filesizes than PNGs).

 

JPG is okay for digital images, though significantly better than using GIFs.

PNG is excellent for digital screenshots and some digital art, providing artifact-free images but scales in filesize as image complexity and resolution increase. It is also typically the king when taking desktop screenshots and pictures of GUIs and interfaces (as they are relatively "simple").

GIF is only good for animations and monotransparency in few occasions when it comes to website design images (usually PNG reigns, especially due to PNGs ability to have transparency for any color); small images may work better than PNG/JPG in rare scenarios (assuming you do not want the ugly palette limit stripping your image of colors).

 

Shall I go on?

 

 

 

EDIT: My normal routine when saving any image is to save them as a GIF, JPG, and PNG. Then I run PNG through PNG Monster and then compare the filesizes on all three formats, and then I compare the visual differences.

Edited November 21, 2009 by L.C.

[Samapico]

35 bytes or 88, it all fits in one single packet... you don't save anything

Plus, it will take one cluster of memory (whatever they are called) on your hard drive anyway, so there as well, you don't save anything.

 

I'm not arguing about compression or file types or whatever... I'm saying you can't compare the quality of compression of 2 different file types by comparing how they perform on 1 to 10 pixels.

[L.C.]

Point taken, but still.

[»Blocks]

Hmm, I'm at a loss over the LVZ I posted not working. Seems like it could be a hardware-specific thing, but why? I never had any problems with it.

 

I think there are better things to spend your efforts on than crunching down the filesize of a 1x1 image. In this case, I think it's appropriate to say "Good enough" and move on.

 

It's important to note that GIF and PNG employ lossless compression methods, while JPEG is typically lossy. You should never save anything in the JPG format if you're going to convert it to a PNG.

[Dr Brain]

If you're serious, you should try and trim down the messages that your bots send. Don't forget to remove periodic messages, and the greet message too! They consume far more bandwidth than 50 bytes. Don't even think about doing what this crazy guy wanted to do, either: http://www.ssforum.net/index.php?showtopic=24002 (lol).

[L.C.]

If you're serious, you should try and trim down the messages that your bots send. Don't forget to remove periodic messages, and the greet message too! They consume far more bandwidth than 50 bytes. Don't even think about doing what this crazy guy wanted to do, either: http://www.ssforum.net/index.php?showtopic=24002 (lol).

Aha, good tips and advice though. Do you have any other bandwidth-optimizing tips in mind?

 

As far as that crazy idea goes, I think that guy wasn't intending his gameplay/gamemode for dialup players.

 

EDIT: Question! In Subgame2's settings, there are a lot of "Reliable" settings, such as "MessageReliable" and one for greening. If "Reliable" is enabled, does it make sure that 'whatever it is' gets delivered?

Edited November 21, 2009 by L.C.