Log In  

35

Update 15.03.2017:

Update 12.03.2017:

  • added one more level
  • added new sound effects(thx to nico gueguen)

Cart [#38190#] | Copy | Code | 2017-03-12 | Link
35

Is probably more a demake than a remake.

So far:

  • 5 Levels
  • all powerups
  • 7 different enemy types
  • moving platforms
  • pipes
  • simplified physics, due to token limit
  • removed 'running across narrow pits', due to token limit

Do not know if cartridges is the correct category, but since I reached the token limit, this is almost finished.
Compressed code size is ~12kb, so I will probably add 4 more levels and hopefully some missing sound effects.

token limit is annoying, because the whole map memory is free and could be used for intro screens or more levels.

Here is the uncompessed source code:
https://mega.nz/#!fAkDnaYS!R6mrADTTTBr1_0QiZ7Uzg32CG4DnPwwVZhBMs4_fXa0
Can not be stored in pico-8, because it brokes the strings

platformer
P#38102 2017-03-08 14:17

::

Congrats! Looks great! I lol'd when I got stuck in the 1-2 warp zone because those levels aren't implemented. :)

P#38105 2017-03-08 17:11

::

Thanks. Yes, need to add targets for previous pipes there...world 2 pipe will work in the next update ;)

P#38106 2017-03-08 17:59

::

Really cool demake, but still needs work...
the physics and controls feel really off, as Mario falls at a steady pace immediately after releasing the jump button, and his jump is much higher (for example, getting to the top of 1-2 is much harder because I keep on hitting the bricks.)... I'm curious as to what's taking up all the tokens, as it's clearly not levels, and the code could probably be shortened even more...

P#38107 2017-03-08 18:50

::

>> Really cool demake, but still needs work...
Thanks. You're right... it's a litle frustrating, cause the token limit prevents me from polishing

>> I'm curious as to what's taking up all the tokens, as it's clearly not levels
I wonder too... uncompressed source is linked. Any tips are welcome. I spent a lot of time reducing the token count... but hey, it's idiotically anyways... there are around ~1000 SELF. calls ;)
I am relatively proud of how I have solved this with the levels.. currently ~ 11kb uncompressed map data, and probably enough room for antother 3-4 levels

Jump height is basically controlled in that way:

--controlling jump height:
    --stop upward movement in jump
    --when "a" was released
    elseif  was_jump and not jump and mp.vy < 0 then 
        mp.vy = -0.0001
    end 

In principle the controls in the original are probably delayed. But I think the controls in the original are a lot more diffucult , especially without gamepad... At least my girlfriend found this easier.

Did you use a gamepad?

P#38108 2017-03-08 18:59

::

I love how you move faster while shooting fireballs.

P#38113 2017-03-09 01:21

::

Nice work! I love how you used the pallete. Also I am not feeling the jump is a big issue.
There is a concern about Nintendo bringing this down. They are known to take out assets using their IP so be careful on publising it in the open.

P#38118 2017-03-09 03:34

::

Well done. This is amazing!

P#38123 2017-03-09 14:54

::

I got a 'file expired' with the link https://dropfile.to/kKzzgMk

Could you reupload it please ?

P#38127 2017-03-10 01:55

::

What is the map data being used for? I see that you define maps in code, but the top half of map editor is still filled with data. Are those just maps you were building prior to taking the code approach?

P#38177 2017-03-12 00:23

::

Title screen is using map data. (the first 16x16 blocks).
More ist not used anymore... I created a custom level editor, which exports strings. But if I had known, that there is only enough memory for a few levels, I had not taken the trouble...

I have just added beanstalks and this as the fifth level and the compressed code size increased to ~14kb.

P#38183 2017-03-12 04:07

::

Wow very cool. You know about using multi-carts for data? You could store all your level data in a seperate cart, I think. It won't work in browser though :(

Since its a demake, perhaps you could take some liberties with the level design, and shrink them drastically, and only do 2 or 3 levels per world.

You might also be interested in Pixel Vision 8 (https://pixelvision8.itch.io/game-creator). Similar to Pico-8 but console limitations are configurable.

P#38192 2017-03-12 13:29

::

Thanks.
Multi-carts work in browser, but not on BBS, that's why I decided to make it as single cart game.I did not cosider the compressed code size limit at the beginning :(

>> and only do 2 or 3 levels per world.
Yes, I thought about the same, but since there is only 1kb memory left, I will probably add just on more level - that are around 100 screens all in all.

>> You might also be interested in Pixel Vision 8
Cool, just saw the SDK sow far.


But this 8k token limit makes no sense at all. You can make a limit, but at least 16k+16kb user memory whould make sense.
Currently it is simple impossible to create games like mario, turrican or other 8bit titles. Which is sad..

P#38193 2017-03-12 14:54

::

Really great remake. The backward scrolling is a welcome addition to the original game as well. Other additions such as starting the game as Super Mario and the lenient fire-flower-counts-as-a-hurt-buffer are also fun tweaks, for starters.

I'll keep my eye on this!

EDIT: I was stuck in the Warp Zone area, so I was trying to see if I could wall jump and then this happened -

P#38194 2017-03-12 15:45

::

Nice one! .. but I can't reproduce it. how did you do that
? Does the gravitation work again, if you press 'jump' again?

P#38195 2017-03-12 16:17

::

did you consider "vectorizing" the levels?
('i',n,x,y) item n @ x,y
('h',n,x,y,w) block n filling a line from x,y to x+w,y
('v',n,x,y,w) block n filling a line from x,y to x,y+h
('r',n,x,y,w,h) block n filling a rect from x,y to x+w,y+h
plus clouds and bushes could be generated pseudo-randomly

P#38272 2017-03-15 07:11

::

this is basically done. Level strings have the following format, items and enemies, for example:

900401014B => 
id: 9
subid: 0
x: 040
y: 101
w: 4
h: B

Map data is RLE compressed and saved in strings without overhead. This matches with " block n filling a line from x,y to x+w,y"

>> block n filling a rect from x,y to x+w,y+h
Yes, I thought about it.. some kind of 2d-RLE. But the token limit was reached anyway.

P#38274 2017-03-15 07:41

::

It would be pretty easy to use that 4k of MAP that isn't used to store levels, but unless you could squeeze all the levels down to 4k may not be worth it since then you'd need different routines to load from string vs map.

The big advantage would be you'd get back the space you're spending now by storing a lot of data in twice the required space. (0xFF (1 byte) vs "FF" (2 bytes)).

The compressed version (of the uncompressed source) is a LOT closer to fitting inside the limit with those level strings removed though.

P#39977 2017-04-27 08:54

::

Also you can declare multiple locals on a single line to save on the "local" repetition.

local id, subid ,x, y, startdir

id = read_number(lev,1)
subid = read_number(lev,1)
...

Thought I guess now you're repeating the name, grrrr. Nevermind.

Of course there is also multiple assignment:

local id, subid, x, y, startdir = read_number(lev,1),
  read_number(lev,1),
  read_number(lev,3),
  read_number(lev,3)+8,
  read_number(lev,1)
P#39978 2017-04-27 09:36

::

Hi dreamer3! Thank you...

>> The big advantage would be you'd get back the space you're spending now by storing a lot of
>> data in twice the required space. (0xFF (1 >> byte) vs "FF" (2 bytes)).

I am not using classic hex encoding for the tilemaps. So I am just spending 1 Byte per tile using custom encoding with the 94 printable ASCII characters ;)

P#40169 2017-05-04 05:42

::

I read the code. It sure looks like the first segment of letters are stored in hexadecimal... I do see where after that you switch to a different encoding. But there is quite a bit of data stored in ASCII HEX from where I sit.

P#40183 2017-05-04 10:08

::

Yes, entity location and data is stored in hexadecimal. But most of the space is used by the tilemaps... anyway, in the end it was the tokenlimit...

P#40214 2017-05-05 09:50

::

Loved it!

P#40249 2017-05-06 19:57

::

As a note, it sounds like you're using a very inefficient representation of the levels in your strings. Are you storing literal tile layouts, or using a much more efficient 'sparse' layout like the original Super Mario Bros game did?

This document explains the format originally used, it might be helpful.

SMB1 defined the global sky/ground/background for the entire level in two bytes, then describes individual 'screens' (16-tile sections of the map, key look that matches PICO8) in two bytes per overlay, with a single overlay able to place multiple objects.

As a result, level 1? 131 bytes total for the entire level. 101 bytes for the terrain and another scant 30 bytes for the enemy list in this case.

So really I think the main issue is your level format is overly huge because it's storing raw tile layouts instead of using such a 'sparse' structure. So yes you'd need to do more work to update your editor to do such a format, but that kind of 'indirect' map layout is really the key to fitting stuff into tiny systems like the PICO8 limitations.

Old games almost never stored the entire map in 'ready to render' format back in the day; they would commonly store a 'palette' of objects, and the map would define where those objects went and in what order, sorted so that the game only had to examine a few dozen bytes to update the screen.

This is why so many early games didn't let you scroll back: They didn't have structures that could be 'scrubbed' both directions cheaply, only in one direction, and the CPUs at the time couldn't brute-force-scan the entire level data to scroll backwards.

And storing raw data into the map/tile regions and then copying that out using peek() in your _init can be a LOT more efficient than packing data into strings. It avoids the cost of the byte->whatever encoding (which at a minimum will expand the data by 20% for ASCII85, or as much as 50% for hexadecimal) and then the cost of that in the 'compressed string' size limit.

P#40274 2017-05-07 10:56

::

Hallo WolfWings,

Thank you. This is really helpful... I will try to change the level format. :)
Looks like a way to pack all levels into 4kb map memory.

Edit:
I am still hesitating because I have no idea how to deal with the token limit. using the map memory istead of strings, will propably bring some free tokens. But there are still some missing enemies/gameplay elements, that are necessary in the later levels

P#40313 2017-05-08 05:08

::

Read over the original Mario source code; while it's assembly it's well documented at this point.

Also I'm seeing a LOT of your code where you're assigning a series of variables at once instead of using the..

x,y,z = 1,2,3

...format, which saves tokes. There's a lot of token optimizations that can be done, not one silver bullet, but this first step gets you well back under the compressed-string limit which was what you'd ran into first by far. :)

Sadly a lot of game design for the PICO8 can be "design a basic idea... then redesign it to actually fit the constraints of the system" at times as you learn more and more about structures and the like to use.

P#40327 2017-05-08 14:31

::

Thanks, I will give it a try...

x,y,z = 1,2,3

Yay, more code obfuscation ;)

P#40333 2017-05-08 16:18

Log in to post a comment

user:
password:

New User | Account Help
:: New User
X
About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2017-11-23 18:41 | 0.237s | 1835k | Q:44