Log In  

@zep
A couple of devs are investing into multicart games (like 5 or more data carts).
We are all put back by the artificial loading times (eg minutes)

Would it be possible for the fat client to either ignore load time throttling, or only activat throttling for the published version?
I want the multicart multiverse, not loading screens ;)

P#66040 2019-07-23 06:44 ( Edited 2019-07-23 06:46)

:: Eniko

I'd like to add my voice to this feature request, my Ultima 6 experiment in Pico 8 takes so long to load that it makes developing it super painful, we're taking like 40 seconds on every restart.

It'd be nice if it was something hidden in the config or in a command line switch so regular users don't get confused about performance though.

P#66073 2019-07-24 18:20

I thought multi-cart loading took a couple seconds of simulated swap time, not too long?

That said, I want to do "a multi-cart game" too, and how I theoretically plan to get around that is by making the main cart essentially just a game engine, loading the game content from each cart, and each cart being its own game.

Do you think doing it that way is feasible?

P#66126 2019-07-26 19:29

@Guard13007
Basically like P8 Awards or the 24 in 1 Bootleg Cartridge?

P#66130 2019-07-26 20:47

@Guard13007
Thats essentially how I made Jack of Spades. Have a look at the code if you're interested.

I have a main "hub cart" that runs the title screen and loads to other carts. So when you finish world 1, it loads the title cart, does a cutscene there and then loads the "world 2 cart". You can CTRL+F for "JOS" to find where the relevant loading code is located as all carts have that prefix.

P#66411 2019-08-06 13:47 ( Edited 2019-08-06 13:52)

What @Eniko and i are doing won’t support that workflow.
Essentially we are stuffing ram with data loaded by a master cart.
In my case, 5000 3d points and 3000 faces from 6 carts.

P#66419 2019-08-06 18:01 ( Edited 2019-08-06 18:02)
:: Felice

Are you doing bulk reads, one cart at a time?

Or are you doing partial reads, possibly switching back and forth between carts?

I seem to recall that each time you select a different cart, there's extra overhead. I may be misremembering, but it's something to check on.

Five carts shouldn't be taking the majority of a minute to load, unless you have very complex decompression routines that are pushing the limits of the lua memory heap, causing it to run garbage collection again and again.

Edit: I just wrote a cart that loaded the full 0x4300 bytes from 10 other carts in a row, this is how it looked when I ran it:

P#66662 2019-08-14 00:26 ( Edited 2019-08-14 00:38)
:: Felice

Okay, I wrote a better test app that could do multiple reads and randomize them.

Here's doing a full cart per read:

Here's doing 256-byte pages per read, sequential within each cart:

Here's doing 256-byte pages per read, in a random order within each cart:

Here's doing 256-byte pages per read, in a random order across all carts:

This is pretty much what I expected:

  • There's a bit of overhead per read
  • There's a lot of overhead per cart switch

So try to buffer your reads into larger chunks, preferably of size 0x4300, and don't skip back and forth between carts.


Edit: By the way, the hitches you see there aren't my cart's fault. It's the hardware/OS doing that. It seems to be related to switching carts. If I do that final test, but intercept the request and make them all come from data1.p8, it looks like this:

Notice the cart icon in the corner only comes up and spins once.

P#66665 2019-08-14 03:14 ( Edited 2019-08-14 03:49)

Brillant (as usual).
I am doing sequential byte per byte reads (gives array size/flags...), but my read method could accommodate a full 0x4300 chunk read - I’ll give it a try.

P#66669 2019-08-14 06:57 ( Edited 2019-08-14 06:58)

@freds72 Yeah, I understood what you and eniko are doing (getting cart data via reload(), right?). My response was to Guard13007 who seemed to want a cart swap via load(), if I understood it correctly...

In the reload case I think it would make more sense if the pause only occurred once per "frame", and any subsequent reload call should use the same pause if possible.

P#67112 2019-09-01 22:12

Looks like the loading time will be capped at 2 seconds in 0.1.12d!

P#67793 2019-09-17 09:24

Yup! Pretty cool!

P#67799 2019-09-17 13:17

[Please log in to post a comment]

Follow Lexaloffle:        
Generated 2019-12-08 09:07 | 0.044s | 2097k | Q:37