Printable View
quize, you might be able to compress a bit more by using the alphabet to represent each compressed number where A=0 B=1 C=2 etc ie;
Normal Map data:
1,0,0,0,0,2,2,0,0,0,0
Crunched Map data:
1,"A",4,"B",2,"A",4
As long as you don't need to represent numbers greater than 26.
me too ;)Quote:
Originally posted by marmotte
nothing :(
k.
Well since Rocketman is finished, im pretty sure my next project may involve DayDream, tomsamson and phreax.. but I will not say anything else =)
Thanks Blink, that's a cool approach.
I'm budgeting a 128 tiles per level for my game and I need to be able to decrunch the level data really quickly 'cause of the free roaming nature of it, so I can't go too mental with compression routines ( It's just cheap and cheerful at the moment ).
A way to go if people if you want to pack map data for a linear game and they have no more than a 128 tile images per level is to store the map data in nybbles ( ie half a byte ).
Basically each byte is a number between 0-255. You can store the first tile value in a byte and it won't be greater than 128. You then use bit shifting to ensure the second tile value is greater than 128 and store it in the same byte. That'll halve the size of your map data before you even perform run length encoding on it.
The trade-off is longer decompression times, which is fine for a typical linear game 'cause you do your decrunching when displaying the "Get Ready - Level x" prompt ( Or whatever ).
Squize.
Well - I'm sure everyone knows i've been working on a secret rpg - I decided to show a tiny snippit out of one of the early prototype levels but this was from my early concepts - As you can see, not your typical RPG!! :D
http://www.mastersystem.org/misc/mocktiles.png
P.S. It's lookin' even better nowadays! :)
RipX
yeah i agree however you may have problems with high-order and control bytes in a text file.Quote:
Basically each byte is a number between 0-255. You can store the first tile value in a byte and it won't be greater than 128. You then use bit shifting to ensure the second tile value is greater than 128 and store it in the same byte. That'll halve the size of your map data before you even perform run length encoding on it.
one question;
you say the maps are loaded on the fly. do you copy a portion of a master map into a smaller array when you hit a new section?
You've got a point actually, ASCII encoding may screw the values up.
I'm not actually loading the maps on the fly, I really need them available quickly. The player should be able to get from level to level as fast as possible to not break the gameplay up.
When you log on to a lift I bring up a terminal screen where you can select the deck you want to go to. Once that's selected I just decrunch the whole map in one hit while the terminal screen zooms down into a white dot.
I'm hoping that a bit of eye candy will distract the player from the fact they are waiting ( Hey, it works for pre-loaders ;) ).
Once a map is decrunched it's stored in it's own array, so the delay will only happen once per level. If I was really cool I'd implement a background decompression routine which would work out the probable next level and start decrunching that while the player is working out which level to go to. But I'm not that cool.
I'll try and post a screeny from the lift screen to try and make it easier to understand.
Squize.
So is your RLE to save memory or bandwidth when you loadVariables()?
Nasty ol' jpeg but you should get the idea
http://www.shoah.co.uk/pages/ionic/lift.jpg
So I just bring this screen up and when a level is selected I run a bit of eye candy whilst decrunching.
I'm using the RLE to try and save bandwidth, you can see how many decks I'm going to have and the "Command Control" deck is a 90x38 map and is going to be far from the largest.
It's not that great a saving when you take into account Flash's excellent compression routines anyway, but if it allows me to improve the bitrate of the sound or add a couple of extra animation frames without the user having to wait longer than I think it's worth the trade off of my time.
Squize.
Just found another pic from when I was conceptionalising (??? spelling ???) that doesn't give much away but it's fun to post :)
http://www.mastersystem.org/misc/mocktiles2.png
RipX
What on earth is that? :p
built that when I was thinking about the game and had no graphix - just made some quick tiles to see what it looked like! lol
RipX
Well, I might as well post might calvin and hobbes game. Here it is:
www.geocities.com/tomandmike1/calvin.html
You guys might have to copy and paste...
Whatever i click on (Start or instructions) i just get another screen with controls and story on, none of the buttons work on that page?? Oh well, nice menu gfx! hehe
Yeah adityadennis I had the same problem.
Now why do people think I've some sort of hang up about doing 100% ports of retro games ?
http://www.shoah.co.uk/pages/ionic/invaders.png
:D
If I ever work out a good way for the invaders to wipe out the barriers at the bottom of the screen it'll see the light of day.
Squize.
PS. I think at this rate the next game will be a punch card simulator.
Wow some great work out there
i'm still working on keiths ring toss game
it is about 90% complete
you can see it at
Ring Toss
Squize: Dynamic mask it... easy way to do it.
just make each of the barriers of of 6 clips each with 2/3 frames, each slightly more degraded!
RipX
Thanks pred & Rip. I'm using a dynamic mask for the baddie bullet explosions hitting the barriers ( You can see it in the screeny ), and it works really well ( Wow, Mr. Bighead ;) ).
The problem is I'm running 55 baddies so they all live in a container clip. There are four barriers which I've broken up into lots of little 8x8 mc's so they can be wiped out correctly.
Checking each of the individual baddies against each of the individual 8x8 mc's and doing it quickly is the hard bit. Remember the invaders may move down the screen in a uniform manner but they may not hit the barriers in a uniform manner, where some have been shot away etc.
It's kinda hard to explain and in theory it seems really easy and that I'm just being a dumbarse ( Perhaps I am ) but have a think about it.
I've got a tile based thing running at the moment but it's far from ideal.
Squize.
i´d so suggest tilebased collision detetcion for this,its just the ideal way to do it.you don´t have a scrolling background,so it´ll work fast and be precise enough.
besides that,i´ve also posted that hittest thingy of pred on some other boards with some suggestions how to improve it,finally we came to the point that using asbroadcaster speeds the collsion detection up by about 35-50% :)