ID:137990
 


i was just wondering if there were any way to decrease pixle and byte size for icons.. im makeing a remake of a clasic game and i need the chars and mobs to be about 6 tiles tall and 3 wide.. so i just want to make the tiles smaller... so you dont have to download a bunch of bulky icons.. so can i do this? i know i can make it look small with view but i want the pixlnum donw also...
On 5/21/01 1:28 pm jobe wrote:
i was just wondering if there were any way to decrease pixle and byte size for icons.. im makeing a remake of a clasic game and i need the chars and mobs to be about 6 tiles tall and 3 wide.. so i just want to make the tiles smaller... so you dont have to download a bunch of bulky icons.. so can i do this? i know i can make it look small with view but i want the pixle num donw also...

just so you know the games are going to be joust(ish) spyhunter(ish) and enhanced maryo sisters(no ish needed) but mainly for joustish i need to make it so you have 6 levels for your movment.. so you can get above you enemy..

its going to be cool but i only need like 6x6 pixles in a tile (im also going to change it so if you hit an enimy from behind you dont die you just bounce off or kill him (depending on how high you are compaired to him..) and alot more dragons and differant types of knights.. along with maps that are huge (so you can travel a long way on a map so a level dose not get to full of players.) and bars where knights can hang out and talk.. along with spells and PK stats. and a money system for killing dragons. (witch is how you will buy spells and beer) after i am done with the game i will post it as a demo so everyone can code play or shnage it to there fassion(but dont name it joust or joustish). well im out... just tell me how to make the tiles 6x6 in pixle size...

In response to jobe
I think you are stuck with the 32x32 tiles, but you could try setting up different tiles with the jouster at varying heights within each tile. Height could be an icon state.
In response to Shadowdarke
On 5/21/01 4:24 pm Shadowdarke wrote:
I think you are stuck with the 32x32 tiles, but you could try setting up different tiles with the jouster at varying heights within each tile. Height could be an icon state.

i wonder if i made the tiles all one color or 2 colors if they would be smaller in byte size...
In response to jobe
i wonder if i made the tiles all one color or 2 colors if they would be smaller in byte size...

Regardless of the size of the tiles, you'd be stuck with the maximum BYOND map size of 21x21.

In response to jobe

i wonder if i made the tiles all one color or 2 colors if they would be smaller in byte size...

The dmi format does indeed compress the icons to take advantage of a smaller number of colors. It also switches to other compression schemes (such as run-length compression) when those are advantageous. When all you have are two colors, each pixel takes up a single bit, so 32x32 pixels requires at most 128 bytes plus a bit of space for the header.

If you use directional icons, it will also notice when the alternate directions are exact rotations of each other.
In response to Dan
On 5/22/01 9:50 am Dan wrote:
If you use directional icons, it will also notice when the alternate directions are exact rotations of each other.

How about if there are only slight differences among the different directional icons? In Dung-Man, the only difference in the various directions for the ghosts is a subtle change in where the eyes are looking. So for each direction, I believe I'm storing a redundant copy of the body/rest of the icon. I've thought about making a directional overlay just for the eyes, perhaps that will work and save some space (although they're small enough that it'll probably only be a few k at most). But if DMI could (in the future, not now obviously!) support a compression where it looks at the differences between directions or movie frames, using that where beneficial, that could be a big win in some cases.
In response to Gughunter
On 5/22/01 9:29 am Gughunter wrote:
i wonder if i made the tiles all one color or 2 colors if they would be smaller in byte size...

Regardless of the size of the tiles, you'd be stuck with the maximum BYOND map size of 21x21.

damn...... thats the max? this is not going to work.. if i do differant highth for each tile there will still me a middle for in between tiles.. so if a mob flys over your head it will still kill you becase of the second tile.. witch will not work.. and i wanted to make money with 1 credit per dime.. (new rider per 10 kills and new credit per 5 pteredactal or dragon kills..)
In response to jobe
Well, if you split the tiles up, you can effectively veiw more of your psuedo tiles in the same 21 x 21 view area. BYOND can't display more than 672 x 672 pixels. That is the real limitation. (Maps can be much larger. I think what he meant was that the maximum viewable area was 21 x 21 tiles.)

If you split the tiles by 2, you would have 4 16 x 16 psuedo tiles per each standard BYOND tile. You would have to build 4 icons for each object, with the icon in a different quadrant for psuedo tile. the map would effectively be 42 x 42, though it doesn't change the display size at all.

BYOND Tile
  <--32 -->

  +---+---+  ^
  |       |  |
  |       |  |
 ^ +...+   +  32
 | |   .   |  |
 16|   .   |  |
 v +---+---+  v
  <16 >


(Splitting it by 4 would make 16 psuedotiles per tile! It can get ridiculous pretty fast, though if you really wanted to, you could theoretically manipulate individual pixels with a system like this. It would require 1024 psuedo tiles per pixel color you used. Talk about inefficient!)

Then you will have to work up a system to convert all the psuedo tiles to full sized display tiles with the use of overlays.

I can give you specific examples if you really want. Don't expect any code for this from me anytime soon. The 32 x 32 icons work fine for my purposes. If it sounds too complex... just forget I mentioned it ;) It probably wouldn't be very efficient anyway.
In response to Shadowdarke
I can give you specific examples if you really want. Don't expect any code for this from me anytime soon. The 32 x 32 icons work fine for my purposes. If it sounds too complex... just forget I mentioned it ;) It probably wouldn't be very efficient anyway.

It actually can work! This is more or less how the motion tracker in SpaceTug operates.

Something along these lines would also be great for providing players with large-scale maps. Technically, you could go all the way up to 1:32 scale, but then you'd need to draw 1024 icon states for each terrain type...
In response to Air Mapster
How about if there are only slight differences among the different directional icons? In Dung-Man, the only difference in the various directions for the ghosts is a subtle change in where the eyes are looking. So for each direction, I believe I'm storing a redundant copy of the body/rest of the icon. I've thought about making a directional overlay just for the eyes, perhaps that will work and save some space (although they're small enough that it'll probably only be a few k at most). But if DMI could (in the future, not now obviously!) support a compression where it looks at the differences between directions or movie frames, using that where beneficial, that could be a big win in some cases.

Another suggestion; allow removal of redundant pixels in animations... that is, if a pixel doesn't change between frames, the .dmi makes a note of it and doesn't store the additional data.

But that's just being anal... it isn't necessary at all. =)
In response to Spuzzum
On 5/22/01 10:05 pm Spuzzum wrote:
How about if there are only slight differences among the different directional icons? In Dung-Man, the only difference in the various directions for the ghosts is a subtle change in where the eyes are looking. So for each direction, I believe I'm storing a redundant copy of the body/rest of the icon. I've thought about making a directional overlay just for the eyes, perhaps that will work and save some space (although they're small enough that it'll probably only be a few k at most). But if DMI could (in the future, not now obviously!) support a compression where it looks at the differences between directions or <font color=red>movie frames</font>, using that where beneficial, that could be a big win in some cases.

Another suggestion; allow removal of redundant pixels in animations... that is, if a pixel doesn't change between frames, the .dmi makes a note of it and doesn't store the additional data.

I believe I said that. ;-) (or are you being ultra clever by making a redundant suggestion for removing redundant pixels... hmmm)

(oops, violating Guy's rule of trimming quoted reply text)
In response to Gughunter
On 5/22/01 8:52 pm Gughunter wrote:
I can give you specific examples if you really want. Don't expect any code for this from me anytime soon. The 32 x 32 icons work fine for my purposes. If it sounds too complex... just forget I mentioned it ;) It probably wouldn't be very efficient anyway.

It actually can work! This is more or less how the motion tracker in SpaceTug operates.

Something along these lines would also be great for providing players with large-scale maps. Technically, you could go all the way up to 1:32 scale, but then you'd need to draw 1024 icon states for each terrain type...

it would work but the problem is... will it work for joust. i can do it but it would be sorta hard to make sure you dont get killed if one of the mobs just fly over your head.. and joust has ALOT of verry small levels of flying..

so im giveing up for now and im going to work on some of the other games ive been wanting to make... mainly spacetug reserection.. and im probebly still going to make the nintendo style gravity for megaman(a game that will be mostly micos to make it feel like the original... heh)

oh yeah how do you disable a movment but not a direction.. like up.. so you can shoot up but you cant move up.. but the x-buster's fire thing would have to move up... hrrrmmm..


In response to Spuzzum
While we're on the subject of possible DMI enhancements for the future, here's one I'd like to see. Multiple named palettes in a single DMI file. This could be handled very similarly to icon states: each object type could get a new variable called icon_palette which could set the palette just like icon_state sets the icon state (duh). Different icon states within the same icon could be assigned to different palettes - that would be a particular win for some of my animations.

This occurred to me as I watched my rsc file balloon up to 400k for the latest release of Dung-Man. Many of my icons are pretty much the same, just different colors. Having a couple of extra palettes would save a lot of the 15k or more per extra icon (multiple states) for each color.

I've been noticing that a lot of people will connect to the game, start a new game, get killed fairly quickly, and disconnect. I can assume 2 possibilities: either they are completely unimpressed (quite possible), or they are in lag hell from downloading the monstrous resources over a modem and don't realize it will be better when they are finished. Thus I'm looking for any way to trim the size of the resources. This and on-the-fly compression would probably help a great deal, but I realize that these should go on the list for future stuff, nothing soon.

(I do have an idea for using a savefile to track who has ever connected, and thus likely already downloaded the resources, so I can give a nice "please be patient" message to first time players)
In response to Air Mapster

I've been noticing that a lot of people will connect to the game, start a new game, get killed fairly quickly, and disconnect. I can assume 2 possibilities: either they are completely unimpressed (quite possible), or they are in lag hell from downloading the monstrous resources over a modem and don't realize it will be better when they are finished. Thus I'm looking for any way to trim the size of the resources. This and on-the-fly compression would probably help a great deal, but I realize that these should go on the list for future stuff, nothing soon.

well its not that.. its the fact that itis too fast moveing for an online game.. you see... you move in a dir untill you chnge dir or cant move anymore.. but it is hard as hell to get in the right tunnle when your playing.. even after it has downloaded.. it seems to just flash the icons here then al the way over a second latter making it imposible to run away.. and some players have differant expectations when they hear dung...
In response to Air Mapster
Many of my icons are pretty much the same, just different colors.

Yeah, that is an opportunity for greater compression.

they are in lag hell from downloading the monstrous resources over a modem and don't realize it will be better when they are finished.

Have you experimented with different settings of client.preload_rsc? You might want to try turning it off, which will download resources only as needed.

--Dan
In response to jobe
well its not that.. its the fact that itis too fast moveing for an online game..

Air Mapster, have you tried fiddling with world.tick_lag? That might improve the responsiveness, but I can't guarantee anything for network play.

and some players have differant expectations when they hear dung...

It is very unfortunate that we had to change the original name of BYOND! There were many clever puns, that are now all inside jokes. This game is one of them. My Night Soil combat system is another.

The thing that always bothered me about pac-man is that the guy ate all those pellets without ever growing bigger or excreting anything. It violates conservation of matter! Perhaps AM could work that important physical principle into the game somehow, to make it live up to its name!
In response to Dan
On 5/23/01 9:47 am Dan wrote:
Have you experimented with different settings of client.preload_rsc? You might want to try turning it off, which will download resources only as needed.

I don't know if this would be a problem for Dung-Man, but with DragonSnot, this option didn't help. The effect was to hit the new player with a couple of dozen new images when the game started, in addition to all the other traffic related to the game starting, and it would frequently freeze less-beefy computers.

This is why it might be nice (to re-post a previous feature request) to consider having some blocking download process, like Half-Life and other games do. That is, when a new player hooks up (or when an update occurs), you have to wait until the new stuff is downloaded before you can play. This is annoying, but might lead to fewer people leaving after 1 minute of having a partially loaded game (which I also see in my logs with high frequency).
In response to Deadron

This is why it might be nice (to re-post a previous feature request) to consider having some blocking download process

Yeah. We could either make this another boolean option, or we could just expose information (client.downloading) that would allow your game to see if the player is busy downloading files. Then you could handle it however you like.

--Dan
In response to Dan
On 5/23/01 9:58 am Dan wrote:
well its not that.. its the fact that itis too fast moveing for an online game..

Air Mapster, have you tried fiddling with world.tick_lag? That might improve the responsiveness, but I can't guarantee anything for network play.

and some players have differant expectations when they hear dung...

It is very unfortunate that we had to change the original name of BYOND! There were many clever puns, that are now all inside jokes. This game is one of them. My Night Soil combat system is another.

The thing that always bothered me about pac-man is that the guy ate all those pellets without ever growing bigger or excreting anything. It violates conservation of matter! Perhaps AM could work that important physical principle into the game somehow, to make it live up to its name!

actually i have read a paper on pac-man.. you see pac man is hollow.. and the reason he opens his mouth when there are no pellets around is becase he is burping up the invisable gas for of the pellets that he ate.. but the only way to make the gas form is to eat a big pellet (witch turns everything to gas) so if you manage to eat all the little pellets and none of the big ones you will appear verry sluggish.. also another ting not verry meany players know is that is is not a shpear but a cylinder.. a verry tall one.. but you cant see that when the game is going..
Page: 1 2