Waaaaaaay too big!

Rui 'Trovatore' Pires · Thu 14/04/2005 15:53:16

Ok, picture it. 5 GUIs, the most complex of which has about 20 buttons/labes and the least of which has no buttons at all. 2 rooms, one of them 3200x480. Resolution is 640x480, and high colour mode (16bit). 164 sprites.

Compiled size: 94mbs.

I found out this is because most of the sprites were 640x480. Now, I know this sounds like a foolish thing to do, but I still found it preferable to making an AVI. I guess I'll have to make one anyway, but I'd like to ask... any chance of making it better? I don't know, better sprite compression? I KNOW this is an issue which has been around already, I'm just bringing my 2 cents from my own issue...

Ishmael · Thu 14/04/2005 15:56:52

You can ofcource zip it down for easy distribution... The sprite data zips up pretty well. Rars down even better.

Rui 'Trovatore' Pires · Fri 15/04/2005 01:10:13

Yeah, but even so, the 94mbs rar down to 13mbs. And the game is still that small... and I am already experiencing slower saving, and I save/test a LOT. Heh. I wouldn't want to end up with a Gb-big game. Sure, I can use AVI... but I'd simply rather not, and if this can be in any way optimized, it'd be wonderful. I feel that using AGS instead of AVI gives me some more control over stuff...

Gilbert · Fri 15/04/2005 02:23:26

Actually the sprites are not compressed for speed issue.
However, as I had suggested before, it might be doable to make the sprites RLE-compressed, since RLE is so ~~crappy~~ simple, it shouldn't consume much CPU power to decompress anyway (actually smaller file size makes the stuff faster to load from file, but if we use a too-complicated compression algorithm the decompressing process may affect the game's smoothness), since in general sprites would contain large blocks of repetitive colours (e.g. the "transparent" parts) it seems that RLE should help in paking the sprite data a bit tighter in general.

simulacra · Sat 16/04/2005 15:31:30

Perhaps compression could be optional, as a game setting when compiling.

Orieac · Mon 18/04/2005 18:19:10

Quote from: simulacra on Sat 16/04/2005 15:31:30
Perhaps compression could be optional, as a game setting when compiling.

I agree. I had already made that sugestion some time ago for hi-res games (640x... or 800x...). Since hi-res games require faster computers i don't think anyone will notice big slowdowns.

Pumaman · Mon 18/04/2005 20:16:24

Yes, simple sprite compression is under consideration for a future version.

edmundito · Mon 18/04/2005 21:14:01

That's a big game! It better be damn good or you better start selling it

Rui 'Trovatore' Pires · Mon 18/04/2005 22:52:55

THAT's the irony. It's a simple "zoom in" effect that I couldn't achieve anyway else.

Like, a screen with a small hole - zoom in the hole and go to the other screen behind. 164 sprites for that (there's some little things that preceed the zooming) and wham. After I removed the "things that preceded it"... it's still 55mbs.

edmundito · Mon 18/04/2005 22:54:16

can your backgrounds be reduced in colors? or are they ultra high quality with lots of prerendered detail? if so, I may have a technique that could help you out....

strazer · Mon 18/04/2005 23:09:57

QuoteLike, a screen with a small hole - zoom in the hole and go to the other screen behind.

Sounds like this could be achieved using the RawDrawImageResized function (but probably wouldn't look so nice since it's not smoothed).

edmundito · Mon 18/04/2005 23:30:07

or, unfortunately, a video.

strazer · Mon 18/04/2005 23:35:58

Yeah, or an FLC file or making a wide room background consisting of all frames side-by-side, then setting the viewport with a while loop:

Code: ags


// room script file

int bgframe;


function room_a() {
  // script for room: Repeatedly execute

  //...

  SetViewport(system.viewport_width*(bgframe/3), 0); // the /3 is just to slow it down
  bgframe++;
//if (bgframe > 30) bgframe = 0; // loop video

  //...

}

Rui 'Trovatore' Pires · Tue 19/04/2005 06:42:23

Netmonkey 1 - I'm using 16bit, and I'm not going back to 256. I hate fiddling with that palette.

Strazer 1 - ...I had not thought of that at all, actually. It sounds like a darn good idea. I just wonder about the qualiity of the scaling.

Netmonkey 2 - Yeah, I arrived at that conclusion too... thing is, aparently the resutling file is just as big.

Strazer 2 - FLC: That would mean 256 colors, right? And at any rate, I don't know how to convert to FLC. Not that I'm VERY worried about graphical quality yet - I'm only making "placeholder" graphics so I can coax some artist with the rest. I'd just like to present it as best I could. Wide room: Eek. There's about 100 frames in this animation (or 80, or something like that). (80*640)x480 is one hell of a size for a room.

edmundito · Tue 19/04/2005 07:49:27

You don't have to go to 256 colors, just your backgrounds (239 with my method, to be exact). If your backgrounds are not too photo-realistic, then photoshop can do some very good color reductions.

This is what you need to do:
http://netmonkey.cellosoft.com/tutorials/tut2.html

strazer · Tue 19/04/2005 07:55:22

Neat! Thanks for the tip!