Level streaming demo

Use this forum to share and discuss Uzebox games and demos.
User avatar
jhhoward
Posts: 76
Joined: Fri Feb 07, 2014 8:11 pm

Level streaming demo

Post by jhhoward »

I made a simple demo that uses petitfatfs to stream a level as you smoothly pan the camera around. You will need to download the attachment and put both files in the root of your SD card for it to work. I couldn't get it to work with the uzem emulator. (If anyone figures out how to, please let me know!)

Some extra details about the demo:
- Artwork is from the free Dawnlike tileset that you can find here:
http://opengameart.org/content/dawnlike ... ileset-v18
- The demo level was created in Tiled and I then made a custom program to convert from the .tmx format to a simple format for the demo to parse
- I arranged the format of the map to have the contents twice: column-major and row-major. This was so that the demo can easily read a 'strip' of the map in both horizontal and vertical orientations in a single read. As you pan the camera, it loads the new strip of data at the edge of the screen.
- For some strange reason, petitfatfs would cause all sorts of wild problems if my read buffer was a local array rather than a global one, i.e:

Code: Select all

// Bad, ends up overwriting bits of memory
void MyReadFn()
{
	uint8_t buffer[BUFFER_SIZE];
	WORD bytesRead;
	pf_read(buffer, BUFFER_SIZE, &bytesRead);
}

// Good!
uint8_t buffer[BUFFER_SIZE];
void MyReadFn()
{
	WORD bytesRead;
	pf_read(buffer, BUFFER_SIZE, &bytesRead);
}
I think this technique would be really useful for an RPG type game or a platformer. Not so useful for something like an RTS which needs the whole map to be persistently in memory.
Attachments
StreamingDemo.zip
(13.3 KiB) Downloaded 573 times
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Level streaming demo

Post by nicksen782 »

jhhoward wrote: - For some strange reason, petitfatfs would cause all sorts of wild problems if my read buffer was a local array rather than a global one, i.e:
Yes, I noticed this too! The array being local messed things up. Perhaps all the allocating and de-allocating of memory is to blame. Global worked better but I use a different method. Actually, D3thAddr came up with it. He would stream data from the SD card into the ramtile buffers, do something with it and then it would be overwritten automatically. Basically, provision your game for plenty of ramtiles and then sneak your data right under the blitter's nose. Kinda like a RAM time-share.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Level streaming demo

Post by D3thAdd3r »

jhhoward wrote:I arranged the format of the map to have the contents twice: column-major and row-major.
There was some conversation on storing maps like you did in the Gauntlet thread and I think it's a requirement for any performance. It seems there should be some performance gains to be had by wasting some bytes to align with sectors/clusters. My understanding is that PetitFS has to read through the entire sector from the start and also finish reading through even if it's just a few bytes in the middle that are needed. If that's correct then padding things out should help out so at least you would never have to suffer a delay crossing some boundary. Might not be practical space wise for big games(SD card is only "virtually" unlimited after all), but something to consider.

jhhoward wrote:I couldn't get it to work with the uzem emulator.
It works on my end using the latest emulator v1.3 found here. I don't think it's my PC, but it's not impossible either; there seems to be very short, probably 1 frame, stutters in the scrolling if you hold a direction for a bit(or 2 directions more so?). It's not too bad and would probably be fixed by a shorter screen. I think the padding idea might alleviate that as well. I haven't tried it in hardware yet, but Uzem seems to perform slightly worse on SD than the card I use. Uzem emulates at the speed of the slowest card someone is likely to use I believe.

Anyway excellent demo and great work here, this is so cool to see working in reality. Loads of possibilities!
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Level streaming demo

Post by CunningFellow »

You could alleviate the problem of having to buffer to a global variable AND the reading a whole sector thing by using the read_block_multi SD command.

You still need to read all the bytes BEFORE the data you want (SD can't seek to the middle of a 512 byte block) but you can end the read any time you like, and if the read spans more than one block you can just keep going.

You should be able to just

calculate the the start address of where you want to read from
divide that by 512 and use the answer to seek a sector
use the remainder from above division to skip n bytes without storing them
read m bytes you need straight into the VRAM

The read byte function will have to keep track of byte in sector (so it knows when it hits 512) and it will also need to know the "span" of where to write too

For the row major reads span would be 0. For the column major reads span would be 32.

That would save RAM and double handling of data.

You can look in T2K source for my version of this (mmc.s and mmc_extra.c), I will try "push" this to the kernel but we want to be careful we don't break anyone elses SD card access.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Level streaming demo

Post by D3thAdd3r »

I'm very much a proponent for having your SD methods wrapped up in a nice package. Personally I'd prefer to have it a totally separate entity from PetitFS, kind of like a MiniSD. Seems like the footprint would be smaller, the speed faster, and the flexibility very high for the stuff I've needed to ever do.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Level streaming demo

Post by CunningFellow »

So I should make another version of mmc.s with my versions instead of trying to integrate it into the other ?
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Level streaming demo

Post by D3thAdd3r »

Alec would know better how that should be organized as I had overlooked that PetitFS and FatFS both use the same mmc.s file. Plus I am not sure exactly what would need to be reconciled or remain different between the current kernel and your work. Probably some in depth discussion to be had there that warrants it's own thread?

This demo makes me want to try a beat-em-up style arcade game for some reason though Super Mario Bros. would make more sense at first. As it currently works with PetitFS do you have any idea how much gameplay you are able to run each frame over the top of this?
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Level streaming demo

Post by uze6666 »

I'll open another topic for discussion on the SD stuff.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Level streaming demo

Post by CunningFellow »

jhhoward - There is new SD card reading stuff that is quicker now.

http://uzebox.org/forums/viewtopic.php? ... 130#p16605

Could help you out here.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Level streaming demo

Post by D3thAdd3r »

I don't see this demo on the wiki anywhere, do you have any source code for this? As is, this is a pretty good basis for a lot of games.
Post Reply