Log In  

@SunSailor

Follow
Follow

With the ability to record longer GIF videos now, the file size gets pretty big, but I didn't manage to find a suitable GIF optimizer, which removes redundant frames and extends the display time of the frame - all optimizers I found only remove the n-th frame or dither the image... Anyone knowing such a tool, online or offline?

P#24604 2016-07-05 04:21 ( Edited 2016-07-05 08:25)

I wonder - did anyone successfully decode the storage order within the sfx section of a cartridge? I managed to do this with the music section, but the values under sfx seem to behave very strange there, I can't find a practical pattern how the bits are distributed there.
I need to write binary data from within my python script and now I exceeded 0x3200, so this is a real show stopper for me at the moment, any help is appreciated!

Yet I know:

  • each line stores 68 bytes of data
  • each byte is distribute with some of its bits to several locations in this line. Filling all bytes with 255 results in a sequence of 3f77f
  • there is a special "header" to each line, consisting of five bytes, which are the last ones in memory and which are not distributed otherwise

What is yet missing:

  • The distribution pattern of the "regular" bytes
P#19771 2016-04-13 16:16 ( Edited 2016-04-24 16:56)

Hi there,
anyone having an idea how to read fixed point numbers with peek? I managed to get the integer part read and I think I understand as well how the decimal part is designed, but as the decimal part uses the unsigned range of 16 bits, I don't get it read correctly. Currently I have:

function rnum()
 local dlo=peekb()
 local dhi=peekb()
 local ilo=peekb()
 local ihi=peekb()
 local nu=bor(bor(shl(ihi,8),ilo),shr(bor(shl(dhi,8),dlo),16))
 return nu
end

Where peekb simply reads a byte from memory with peek and increments a pointer b.

 local ilo=peekb()
 local ihi=peekb()

These bring me the integer part nicely, but I'm having no success in getting the decimals right. Any help or hint is very appreciated :)

P#19227 2016-03-14 21:09 ( Edited 2016-10-01 19:54)

Cart [#18694#] | Code | 2016-02-07 | No License | Embed
19

A bit of sad, I spent the last three weeks with creating a small rpg game with Pico8, but ran out of memory half the way. I would have been able to come along with the token count with some tricks, but finally, the compressed cartridge size limit hit me and I don't see any chance to finish it with the current limits of Pico8. If the memory limit for the source code would be doubled, there would be a chance, but until then, maybe the wip is of some fun for one or the other. As I'm toying around with a fantasy console like Pico8 myself, maybe it will see the light there eventually ;)

The game picks up elements from the early Ultimas and The Bard's Tale. You can move around the city, enter some buildings and you can enter the first two dungeons. There is already a world with some other buildings and dungeons, but as there's no memory left, I'm not able to fill them with game play.

So far, have some fun with it!

Update: Seems, the cart was that too big, that the export failed - uploaded again.
Update2: I fixed two missing features, where you weren't able to leave the shop and the inventory. Further, I unlocked the wilderness and all the other dungeons.

P#18630 2016-02-03 17:55 ( Edited 2016-07-01 20:25)

Hi,
first off, Pico8 totally blasts me - developing games with it is like a flash back into the 80ies, only with suitable tools. Great work! Too, I like the idea of the strict limitations of the system, but there are some things which may extend them without breaking the idea.

At the moment, the rom in the cartridge supports space for all built in editors. There is sprite space, map space, sound and music space. They are all sufficient for the general "hardware" of Pico8. But the rom lacks of one thing - user space! There is a user space in the ram, following the rom mirrors for all the build in editor data. But why isn't it possible to use the user space in the rom?

This leads to the situation, that one has to initialize all user data in code space. This seems to me a waste of space and tokens. True, from adding the user space to the rom, one problem arises: How to fill it? I spent some thoughts on this with the premise to keep the general idea of Pico8 and its workflow. So, how about this:

1.) Add the user space to the rom. Shouldn't be much work and shouldn't break existing cartidges, although some version tag might be necessary.

2.) Add a general function _build aside to _init, _update and _draw. As you obviously have access to the tokens, I would remove this one from the export versions and wouldn't count the tokens in this function (Including the function itself), but leave the 256kb limit.

This would allow to poke data into the user space without wasting any tokens. One could even preprocess the data, like adding preprocessed line feeds to string data, create lookup tables and such. Further, this would allow us to store an initial titlescreen into the screen ram on boot time... This would be a simple, but great extension of the general build process without touching any of the grounding principels.

A hex editor as an additional tool would be pro, but not required.

Another bigger feature I would love is bank switching. As the "CPU" is definitly an 8 bit one, it could address 64kb of ram. Sure. Virtual ram space is expensive in our imaginary 80ies development world, in which Pico8 exists. But as Pico8 tries to mock up an 8 bit console system, there always was the possibility, that the cartridge-rom was bigger than the system ram. So, how about picking this up by adding a banking space at $8000-$8fff, which is read only and maps to one or more rom banks within the cartridge? They should be limited, up to max 32kb, no doubt, but I think adding bank management would add some extra spice to this retro style development and this wouldn't break anything else either. Initialization would work with the _build function as well. A nice addition to this would be a _switch(a,b) function, which is called, if f1-f4 are pressed and which handles copying editor specific data between the banks, leaving the risk to handle this correctly to the developer him/herself.

Some other features, I would wish for, which are simpler to explain:

a) Add a ceil function, that one is missing painfully.
b) Add some kind of tooltip if you are over a function with the cursor, which shows the token count of that specific function.
c) A simple find with ctrl+f would be great. Currently, I'm using NotePad++ beside Pico8 constantly open for that...
d) Reading the character value as numeric from a strings position. I know, requested several times and there is a workaround, but I don't think this workaround should be needed...
e) Would be nice to be able to set the border color and the background color (e.g. for cls). Could be either background(col) and cls(col) or color(drawcol,clscol,bordercol).
f) Hidden directories are never a good idea to store things, the user shall access or copy by hand. Maybe an extra document directory for cartridges would be nice...
g) Anonymous Functions? Would be great to be able to write code like
h) A modulo function. Needed, writing an own is a waste of space and tokens.
i) The ability to call a function or other code from a string. Maybe something like eval("myfunc(3)")?

startscrolling("Hello World",10,begin cls() end)

Reading, this would trigger a scrolltext with Hello World scrolling over the screen and calling the anonymous function when finished, clearing the screen.
h) A goto line with ctrl+g. Bonus: Accept the name of a function as input.

These are my suggestions so far, maybe they are of some use :)
Keep up the great work!

P#18435 2016-01-24 10:27 ( Edited 2016-01-30 16:49)

About | Contact | Updates | Terms of Use
Follow Lexaloffle:        
Generated 2019-07-16 01:09 | 0.107s | 4194k | Q:26