Weber's Rants (tutorials)

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Weber's Rants (tutorials)

Post by Jubatian »

D3thAdd3r wrote: Tue Apr 03, 2018 4:44 am(...) I would be interested to see how well the new SPI Ram stuff in M74 can cooperate with other things, as I do plan on vsync mixer. Probably what I want to do will not work out that well, but we will see how cycles play out.
Using the VSync mixer with a blitting video mode may not be a very good idea if you want many sprites. Both for RAM and CPU overhead (Approx. 512 bytes of RAM and some 10 - 15K cycles less of VBlank).

If you absolutely something special what demands the VSync mixer as of now, I would say, Mode 72 could be the best solution (and your bg. seems to be simple enough to compress well). In that mode no RAM and CPU is taken for sprites, although of course it has its own limitations.

By the way Mode 74 can also use the SPI RAM as sprite source.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

I would like to have 36+ ram tiles, but that would eliminate the vsync mixer option for M3. I may be too limited even without that, and M13 will not work for this as I am aiming for ~16 global colors. Previous experiments showed the blitting performance is far below 36 for the 15 color mode, so M74 does seem inevitable in a good way. I just want to exhaust my options first before making the horizontal resolution trade off a final decision.

SPI Ram sourced sprites would allow custom painted cars, which would be pretty nice. SPI Ram as a requirement is already decided, but in particular I want to try and hit something new in sound for this one where the vsync mixer becomes interesting. About 80% sure this is going M74 for many reasons.
User avatar
Jubatian
Posts: 1560
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Weber's Rants (tutorials)

Post by Jubatian »

D3thAdd3r wrote: Wed Apr 04, 2018 12:50 amI just want to exhaust my options first before making the horizontal resolution trade off a final decision.
Still there is an alternative, I sent you a mode draft earlier which could possibly work with this game (2bpp background and 4bpp sprites, 5.5 cycles / pixel possible, so you could have the same resolution like Mode 3, while it would use Mode 74's sprite blitter). Problem is that it seems like I won't have time to do it.
D3thAdd3r wrote: Wed Apr 04, 2018 12:50 amSPI Ram sourced sprites would allow custom painted cars, which would be pretty nice. SPI Ram as a requirement is already decided, but in particular I want to try and hit something new in sound for this one where the vsync mixer becomes interesting. About 80% sure this is going M74 for many reasons.
You may also consider Mode 748 then instead. It is easier to use, and you can do other SPI intensive stuff with it for enriching further the game (check these).

I don't know what are your exact goals with the VSync mixer, however if it is just playing back samples from the SPI RAM, then I have an idea which could work well for you.

Take the inline mixer, and modify its PCM channel so it reads from RAM instead of ROM, optionally discarding its frequency (so it always increments the sample pointer by 1).

Then you can use the PCM channel as an audio buffer (288 bytes for example) which you may fill in VBlank, even from the SPI RAM, even from within Mode 748. This would both require less RAM and less VBlank time (as it is still an inline mixer). Mode 748 by the way has 234 cycles for the mixer, Mode 74 only 215.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

I am trying to come up with a solution, but I have a hard time imagining how it can be reliable. I have music tracks that are ~2 minutes long full PCM, and I want to play these during the title screen, intermission, and gameplay. I believe this adds presentation value that is far above the sum of parts if one only considers how impressive an implementation is on paper. This would not use Streaming Music, it would be an attempt at Streaming PCM or a compressed variant.

It seems a lot harder that I initially imagined. Vram data will get filled from level data in the SPI Ram, which takes some complexities to implement, but there is nothing inherently stopping that part. 128K is not enough to store the level, and also a "real" full length music track, so that runs to the nasty beast of intermittent SD card access(something I am checking into on Artcfox's SD scrolling implementation, non-blocking stuff). I feel no qualms about having some test at boot, which tells the user if their card is not fast enough and stops there, after which I can make some necessary assumptions about read latency.

I see some workarounds to make these things cooperate. Some frames, it will not be required to add new values into vram on the '644 so I could use the SPI bus for other purposes. If I am to randomly stream PCM from SPI ram for sound effects, that is not going to work because it will create horrible sound drops if I access the SD card which must be done to the sum of at least 15,700 bytes per second on average(averaged over say, 8 seconds where 96K of SPI Ram is a buffer for PCM music). I think I have to choose: PCM music or PCM sound effects from the SPI Ram, and not both. Because this game only requires a few short sound effects, I might try to squeeze them in flash as PCM(where you can use ~8khz PCM, and play it back double speed like Columns sounding well enough), where I can fall back to wave based sounds if I run out of space. If I do that, I believe it is possible on fast cards, to keep up with music and scrolling..maybe.

Graphics are coming along pretty close to done for the tracks. I suck at isometric art, I give up on that, oh well it is straight top down..what can I do :roll: I am trying for some spiffy menus, title screen, race intros, conclusion, intermission where you can buy parts at the RC shop, etc. That is pretty hard, I struggle to find a good way to make some semi-photo-realistic RC parts with the ridiculously small resolution I have to use. Upgrades will be different types of tires(need to fit in a ram tile frame of ~6x6/48x48 pixels), different motors(brushless, higher RPMs, etc.), different batteries(NiMh, Li-ion, LiPo, and Lithium-Air as a mythical top end). Every individual item has to fit in ram tiles, as it has to come from SD/SPI Ram. I will post some graphics for that once I get somewhere, right now I have to increase my art ability just to make something presentable for this...looks terrible :roll:

Random update there, I am having some Uzebox fun today!
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

Also just to be clear, by Streaming PCM I don't mean something related to Streaming Music at all. With SM, it was practical to make a reasonable universal solution only because the buffer requirements were so small. In this way, it does not force the developers hand or limit their use of SPI Ram for other things(in reality the buffer could be easily eliminated for direct SPI Ram reads, but that removes it's flexibility by introducing arbitrary control systems on the SPI Ram versus what the user might want, for ~12 byte of ram saved).

I don't see any such generic possibility for PCM, because you simply can't buffer it usefully on the '644. So what I am talking about is no kernel construct, but rather a technique entirely in user space(using VSync mixer). Just wanted to say that as the Streaming Music stuff(and the way I talked about it, worded it, and changed it :roll: ) probably is difficult to wrap one's head around, even though(once understood) it is not overly complicated. Pretty sure Streaming PCM will be a bit more nasty.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

I put aside a chunk of SPI Ram for a circular buffer and full PCM song streaming works fine in the right situations. The SPI Ram can only hold a few seconds of audio, so in a custom WaitVsync() SD sectors are loaded every other frame or so, to fill in for what is eaten by the mix buffer each frame. I did some more testing on 4 bit ADPCM compression and I am surprised that in many cases there is very little quality loss, but it depends a lot on the music. Either way, the most that should be done in a frame is a single SD sector load, and it would make no sense to do less than that having to skip bytes next time. So I have dropped the 4 bit idea entirely, since it does not improve the worst case scenario at all...even if you can wait an extra frame before needing to load a sector due to half data size. For the frames where you must inevitably do those loads in either solution, it is more optimal not to have to also decompress and run a prediction engine beforehand. With the raw buffer you simply can't miss a frame or it sounds terrible. It works great for the Title screen and in game menus so far, and the sound quality is everything I could hope for. A few sprites can be blit and input processed without any hiccups, so planning on music for menus and things, and in game there is only sound effects.

I am thinking on what the best way to approach a different mixer is. I don't want to pay the huge cost(and Jubatian did a smaller option recently) for the mixer buffer, since it has really hurt my ram tiles count. With PCM sound effects that I am mixing in user code, there is no need for any of the data structures of the wave channels, no noise channel stuff, no MIDI player, etc, which adds up to some considerable gains. I am seeing how far it can be pushed, with some tightly controlled SPI Ram access, to do it all in SPI Ram.

I want to make this work because I have grown accustomed to this full PCM sound now. Something like a single seek and ~65 SPI reads can happen per scanline, so at a minimum it would take roughly 5 scanlines out of each frame just outputting the audio for that frame. Then that data has to be there before it can output, which takes even more. For sound effects, a few seconds of them can be pre-loaded so long as they don't need different pitch playbacks which requires skipping. In that case, there is no need for in gameplay SD loads. For the places like the title screen where the song is 2 minutes long, then the problem becomes that you must grab the SPI bus to read from the SD card, put that to local ram, then write that to SPI ram...all before the end of the scanline when it needs the audio byte stored in SPI Ram, impossible! So giving in to only have music on non-intensive sections like the user interface, I think it can be made to work by having the option to play from a pointer in '644 ram or the SPI Ram. Naturally, increase the ram tiles and use those as a temp audio buffer for full song playback(where SD access is required), and during gameplay when you are not loading extra data(pre-baked 1 pitch sound effects loaded prior), all the ram tiles that would have been lost by the mixer buffer are available for sprite use. I think this actually works even if a little convoluted. Sacrificing a few scanlines to make Uzebox sound better than SNES! At least in theory it should work and no single part in particular seems anything too complex.

EDIT-attached a hacked together demonstration
Attachments
rcf1.zip
(1.51 MiB) Downloaded 582 times
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Weber's Rants (tutorials)

Post by L4rry »

That is a pretty epic demo sound track :)

I love PCM audio. It's great fun to create low bit rate PCM sound affects using everyday household items apart from the epic music you can produce. I think this is an ideal use case for SD->SPI RAM streaming. I've been wanting to do PCM sound effects again ever since I used them in Tank Fu, but they are really just too 'sizy' to fit into flash. I'd certainly be tempted to to use a solution like this.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Weber's Rants (tutorials)

Post by Artcfox »

Wow! Sounds amazing!

I guess I'm going to have to build one of those newfangled Uzeboxes that has an SPI RAM chip on it now. (I wonder if it is possible to retrofit SPI RAM onto one of the Uzebox DTVs, since I have many of them.)
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Weber's Rants (tutorials)

Post by nicksen782 »

All that in only two megabytes?! How long is the song itself in seconds? I think it went on for at least two minutes before it stopped.

Also, what is the name of the song? Crunchy!

How much SPIRAM buffer did you need? I'm curious as to the actual data rate too.
User avatar
D3thAdd3r
Posts: 3175
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Weber's Rants (tutorials)

Post by D3thAdd3r »

L4rry wrote: Thu Apr 26, 2018 6:38 am I love PCM audio. It's great fun to create low bit rate PCM sound affects using everyday household items apart from the epic music you can produce. I think this is an ideal use case for SD->SPI RAM streaming. I've been wanting to do PCM sound effects again ever since I used them in Tank Fu, but they are really just too 'sizy' to fit into flash.
Indeed PCM is very cool in my book, and it being so "sizey" :) I barely could use it in a real game except for a few small cases. I am hoping there is some general solution that is not too horrible or limiting, so we can have more PCM in games going forward! Making them on your own(and I thought the sound was very good on Tank Fu) is quite cool. I am thinking to try some announcer stuff like saying the name at the title screen and maybe some "3 2 1 Go!" thing..we will see if I actually do that though.
Artcfox wrote: Thu Apr 26, 2018 12:07 pm I guess I'm going to have to build one of those newfangled Uzeboxes that has an SPI RAM chip on it now. (I wonder if it is possible to retrofit SPI RAM onto one of the Uzebox DTVs, since I have many of them.)
All the cool kids are doing it, you should definitely jump on the expansion band wagon :) Even though UzeAmp can of course do such a thing as this, I think the SPI Ram could allow some more flex for slower cards or doing more things simultaneously(where some lag frames are acceptable). I think it will shine more when/if it turns out that it works well for sound effects as well, which there is really no prayer to have multiple sfx streamed from SD. On the UDTVs I looked at it but didn't get to far. My guess is it is possible, but I didn't see a real clean way past super/glue epoxy and running small wires.
nicksen782 wrote: Thu Apr 26, 2018 1:53 pm All that in only two megabytes?! How long is the song itself in seconds? I think it went on for at least two minutes before it stopped.

Also, what is the name of the song? Crunchy!

How much SPIRAM buffer did you need? I'm curious as to the actual data rate too.
The actual data rate in the original file(down converted from 44khz) is 16,000 bytes per second which is the closest to NTSC line rate that Audacity lets me export as 8 bit RAW. On the Uzebox it comes out at 15734/second like UzeAmp, so ~262 per frame. Playback on Uzebox is theoretically slightly slower(so "down-tuned" notes and slightly longer) than the original WAV because of that 16->15.7 rate, but listening back to back between them it is not noticeable. The original song is 124.5 seconds long and on Uzebox probably 126 seconds.The song is called "Roaring"(not the underscore version), and I am also liking "Underground Alley" for something like end of race statistics. The licensing for those is maybe not really precise for a video game, but it should work. I didn't experiment extensively with different sizes, but I see no reason 1K of SPI Ram wouldn't work just as well, only increasing if the max frames between reads increases.
Post Reply