Author Topic: Motherload  (Read 4826 times)

0 Members and 1 Guest are viewing this topic.

Offline Jonius7

  • python! Lua!
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1918
  • Rating: +82/-18
  • Still bringing new dimensions to the TI-nspire...
    • View Profile
    • TI Stadium
Re: Motherload
« 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!
Programmed some CASIO Basic in the past
DJ Omnimaga Music Discographist ;)
DJ Omnimaga Discography
My Own Music!
My Released Projects (Updated 2015/05/08)
TI-nspire BASIC
TI-nspire Hold 'em
Health Bar
Scissors Paper Rock
TI-nspire Lua
Numstrat
TI-nspire Hold 'em Lua
Transport Chooser
Secret Project (at v0.08.2 - 2015/05/08)
Spoiler For Extra To-Be-Sorted Clutter:

Spoiler For Relegated Projects:
TI-nspire BASIC
Battle of 16s (stalled) | sTIck RPG (stalled) | Monopoly (stalled) | Cosmic Legions (stalled)
Axe Parser
Doodle God (stalled while I go and learn some Axe)

Offline Eiyeron

  • Urist McEiyolobster
  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1430
  • Rating: +130/-10
  • (-_(//));
    • View Profile
    • Rétro-Actif : Rétro/Prog/Blog
Re: Motherload
« 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.

Offline TIfanx1999

  • ಠ_ಠ ( ͡° ͜ʖ ͡°)
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 6173
  • Rating: +191/-9
    • View Profile
Re: Motherload
« 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. :D You should try to post a bit moar, if you have time that is. ;)

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Motherload
« Reply #18 on: August 15, 2013, 04:26:22 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).

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.
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline aeTIos

  • Nonbinary computing specialist
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3913
  • Rating: +184/-32
    • View Profile
    • wank.party
Re: Motherload
« 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.
I'm not a nerd but I pretend:

Offline Hayleia

  • Programming Absol
  • Coder Of Tomorrow
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 3367
  • Rating: +393/-7
    • View Profile
Re: Motherload
« Reply #20 on: August 15, 2013, 08:40:39 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.
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

click here to know where you got your last +1s

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: Motherload
« Reply #21 on: August 16, 2013, 08:53:14 pm »
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 :P That may not seem like a lot, but it can add up depending on your data, you can't every get compression for free. 

Offline willrandship

  • Omnimagus of the Multi-Base.
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2953
  • Rating: +98/-13
  • Insert sugar to begin programming subroutine.
    • View Profile
Re: Motherload
« 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.
« Last Edit: August 16, 2013, 09:52:31 pm by willrandship »

Offline Runer112

  • Moderator
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2289
  • Rating: +639/-31
    • View Profile
Re: Motherload
« Reply #23 on: August 16, 2013, 09:49:23 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.
« Last Edit: August 16, 2013, 09:50:24 pm by Runer112 »

Offline willrandship

  • Omnimagus of the Multi-Base.
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2953
  • Rating: +98/-13
  • Insert sugar to begin programming subroutine.
    • View Profile
Re: Motherload
« 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.

Offline DJ Omnimaga

  • Former TI programmer
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55876
  • Rating: +3151/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • DJ Omnimaga Music
Re: Motherload
« 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. :P. By the way, for Pitall, is there any doc available online that explains how maps are generated?

Offline willrandship

  • Omnimagus of the Multi-Base.
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2953
  • Rating: +98/-13
  • Insert sugar to begin programming subroutine.
    • View Profile
Re: Motherload
« 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