Author Topic: Motherload (Read 9936 times)

Jonius7 · « **Reply #15 on:** August 14, 2013, 11:29:57 pm »

Oh I always loved playing Motherload all those years ago.
20kb for maps could be too much, it depends on whether you have enough space for the other functions of the game (moving, digging etc)

Also on a side note, Super Motherload has been in development in the last few years.
http://supermotherload.com/

Good luck with this! It'll be a great project!

Eiyeron · « **Reply #16 on:** August 15, 2013, 12:02:49 am »

I should suggest RLE encoding for storing maps. It's quite easy, but if your level looks like swiss cheese, you'll risk space loss. You could calculate how much a compressed and a non-compressed map take place, and take the lightest one.

TIfanx1999 · « **Reply #17 on:** August 15, 2013, 12:07:06 am »

I don't think size is a big deal honestly. On another note, nice to see you still lurking builderboy.

You should try to post a bit moar, if you have time that is.

Hayleia · « **Reply #18 on:** August 15, 2013, 04:26:22 am »

Quote from: Eiyeron on August 15, 2013, 12:02:49 am

I should suggest RLE encoding for storing maps. It's quite easy, but if your level looks like swiss cheese, you'll risk space loss. You could calculate how much a compressed and a non-compressed map take place, and take the lightest one.

With the method deeph and chickendude taught me, you don't risk any loss. The problem is that it uses one bit per tile, and if aeTIos uses nibbles and has 12 tiles, it can't apply. So aeTIos, what are the tiles you need ? Maybe you could split them in two parts, above_surface/under_ground and so we could still apply that compression (assuming there are less than 7 above_surface tiles and less than 7 under_ground tiles).

Quote from: Art_of_camelot on August 15, 2013, 12:07:06 am

I don't think size is a big deal honestly.

On a regular 83+ it is. Not only it is hard to fit "big" things in it, but it is also annoying to get "Garbage Collect ?" everytime you quit a single game.

aeTIos · « **Reply #19 on:** August 15, 2013, 05:19:40 am »

I think I'm going with builderboys method. Now I only need to write a map algorithm.
Also Hayleia I will be using separate maps for above and underground.

Hayleia · « **Reply #20 on:** August 15, 2013, 08:40:39 am »

Quote from: aeTIos on August 15, 2013, 05:19:40 am

Also Hayleia I will be using separate maps for above and underground.

Ah, well then maybe you could use the deeph-chickendude method for RLE compression.
Basically, when you have more than one tile, you do that: number_of_tiles,type_of_tile
And when you have one tile, you do that: type_of_tile_with_first_bit_set_at_one
This way, you don't waste space when you have a single tile and you save space when you have more than one.

Builderboy · « **Reply #21 on:** August 16, 2013, 08:53:14 pm »

Quote from: Hayleia on August 15, 2013, 08:40:39 am

And when you have one tile, you do that: type_of_tile_with_first_bit_set_at_one
This way, you don't waste space when you have a single tile and you save space when you have more than one.

I just wanted to point out that you do indeed waste space when you have a single tile. You waste exactly 1 bit of space

That may not seem like a lot, but it can add up depending on your data, you can't every get compression for free.

willrandship · « **Reply #22 on:** August 16, 2013, 09:45:35 pm »

What about instead of storing the ores themselves in the map data, simply storing a 1-bit dirt or no dirt map? Then, you have a function that determines what's there based on a formula. (row * column * seed value, truncated to 256, where 0x10, 0x20, 0x30, 0x40 etc. are ores, and everything else is dirt, for example)

in other words, the map never changes, but you don't need to store 16 tiles for 14 ores, air, dirt.

Runer112 · « **Reply #23 on:** August 16, 2013, 09:49:23 pm »

Quote from: willrandship on August 16, 2013, 09:45:35 pm

What about instead of storing the ores themselves in the map data, simply storing a 1-bit dirt or no dirt map? Then, you have a function that determines what's there based on a formula. (row * column * seed value, truncated to 256, where 0x10, 0x20, 0x30, 0x40 etc. are ores, and everything else is dirt, for example)

in other words, the map never changes, but you don't need to store 16 tiles for 14 ores, air, dirt.

I believe this is quite similar to the method Builderboy suggested. The method sounds like a good way to go.

willrandship · « **Reply #24 on:** August 16, 2013, 10:17:52 pm »

It's similar to the method Pitfall for the Atari 2600 used. End result in that case: 56 bytes for a 256-byte map.

DJ Omnimaga · « **Reply #25 on:** August 17, 2013, 01:38:54 am »

It kinda reminds me one of my early Axe game, where to generate the falling lobsters pattern, all I did was reading through the RAM.

. By the way, for Pitall, is there any doc available online that explains how maps are generated?

willrandship · « **Reply #26 on:** August 17, 2013, 08:23:15 am »

This video is a little scant on the details, but it gives a vague idea on lots of stuff relating to it.

This blog post goes into detail on how the polynomial counter works, including the atari assembly.

http://www.samiam.org/blog/20130606.html

Author Topic: Motherload (Read 9936 times)

Jonius7

Re: Motherload

Eiyeron

Re: Motherload

TIfanx1999

Re: Motherload

Hayleia

Re: Motherload

aeTIos

Re: Motherload

Hayleia

Re: Motherload

Builderboy

Re: Motherload

willrandship

Re: Motherload

Runer112

Re: Motherload

willrandship

Re: Motherload

DJ Omnimaga

Re: Motherload

willrandship

Re: Motherload