Weber's Rants (tutorials)

[D3thAdd3r]

I cannot get this upgrade soon enough, chomping at the bit here Now I had one idea on the scrolling, probably obvious. As an option for Mode 3 with scrolling, -DHSYNC_SOUND_UPDATE might be accomplished by (dreadful I know) starting rendering a ways from the left of screen horizontally and placing your new magic code before or after the normal scrolling setup stuff. Already the screen is shifted over 8 pixels and ends 8 pixels early? with scrolling. For that kind of extra ability I would live with an offset screen if I were doing say a fighter, beat em up game, platformer. Really they are just not very doable right now but they would be more reasonable with extra ram/time. I wonder if I am understanding this correctly, is this where you are finding cycles for the new code?

call update_sound_buffer ;36 -> 63
ldi ZL,32-9
do_hsync_delay:
dec ZL
brne do_hsync_delay ;135


It's all very interesting to me as I'm actually taking the time to get into and understand the lower level of Mode 3. I see that the scrolling setup takes a fair amount of cycles, and even 16 pixels offset is not many extra cycles.

[uze6666]

In mode 3 with scrolling, if you look at the source you will notice that there pretty much no free cycles left in the horizontal blanking period. The delay cycles and sound update that could be used are only ~80 cycles and I need closer to 200. I'm pretty sure there's way to re-arrange things to get to those 200 cycles. I just want to stabilize this version first.

I wonder if I am understanding this correctly, is this where you are finding cycles for the new code?
call update_sound_buffer ;36 -> 63
ldi ZL,32-9
do_hsync_delay:
dec ZL
brne do_hsync_delay ;135

Yes, you got it. I recovered the delay cycles from hsync_pulse and also most of the ones before call to render_tile_line() in the main loop.

For the upgrade, I'm ripping my hairs off with that distortion issue. I just cannot find what causes it. Note that it's not that terrible, but it wasn't like that before, so got to fix it. Since you are so eager to play with it, here's a beta of the WIP kernel. It's usable right away, and should work without any new switch in your makefile. The only thing you'll notice is a bit less flash usage...and ~500 extra bytes of RAM. Note that in this beta, the 4th channel must be noise and the 5th (PCM) is not yet complete. You'll also note the sync code in uzeboxVideoEngineCore.s is much cleaner now and easier to follow.

Let me know about any bug of funky stuff that happens.

-Uze

[D3thAdd3r]

Wow, yes! My first born son shall be named Uze. This makes all the difference for Lolo, now the more populated levels aren't a flicker fest(well..very noticeably better)! I know exactly what MegaBomber will do with this

[uze6666]

Wow, yes! My first born son shall be named Uze.

Not so sure you really want that! Anyhow, the sound stuff have finally been fixed. One more hour and I was calling the madhouse!! My fault though, I tried to tackle the refactoring of the sync code while rewriting the sound mixer and *that* was a bad idea! Now I got to find a --clean-- way to fit the inline mixer with the existing video modes, with all the existing compile options...so far...code base will be messy from now on I suspect...

-Uze

[D3thAdd3r]

One more hour and I was calling the madhouse!!

The difference between insanity and genius is, of course, success! As far as the code getting a little messy/twisted, sometimes it seems a necessary evil for optimization but then again I'm not the one having to work with it Mode 3 without scrolling has no need to have any option for this, since it's superior all around(ram and speed). If you are going to do this as an option with the scrolling(which I hope!), I think one extra flag isn't going to stump anyone. I'll write up or add any documentation needed or help in any way I can.

[D3thAdd3r]

I'm going to start releasing RamTileLibrary incrementally as it is finalized. It is a collaboration of all my ram tile stuff in my games/demos, and all the mistakes I've learned from. The goal is to enable everyone to easily integrate impressive graphical effects, and in many instances save space doing it. For those who might have seen a sneak peek at my newest Jump n' Bump demo, you likely noticed one thing not normal for an uzebox game. Foregrounds such as trees/bushes to hide your bunny behind!!(or any other sprites) With rtl_Foreground you can do this effortlessly in your game! Without further delay, here is the tutorial on rtl_Foreground. All comments and feature requests are welcome, we can develop this as a community whoever wishes to contribute or brain storm together. Parallax back/foregrounds are hopefully coming at some point! Here's the tutorial and an example attached(press start through menus).

[hpglow]

Very nice.

[D3thAdd3r]

I see I forgot to include the actual RTL source code. I'll remedy that when I get home

Edit: current stable code added(only foreground stuff so far).This will be updated as text, sprites, and other features are finalized.

[D3thAdd3r]

Probably this is a question only Alec can answer...

For some time I have wanted a way to playback songs with different tempos. So I got something working with good results, now I have changed it to not rely on modifying ProcessMusic() in the stock kernel. Basically all it does is keep a pointer oldsongPos around with the last value of the kernel's songPos, when songPos is greater we know a new event has just been read from flash and we need to modify the time until that event plays to change tempo. Then I make oldsongPos=songPos. If songPos < oldsongPos we know that the song has looped. For the 2 songs I have tried increasing tempo with this sounds good even with rounding errors, I just do something like this:

Code: Select all

void UpdateSongTempo(){
	//avoid having to hack kernel's ProcessMusic() directly
	if(oldsongPos < songPos){//kernel just read a new note
		oldsongPos = songPos;
		nextDeltaTime = (nextDeltaTime*10)/(10+musicspeed);//decrease time some, for small values this ends up 0??
	}
	else if(oldsongPos > songPos){//song must have looped, this is causing it to stop playing...
		oldsongPos = songPos;
		//nextDeltaTime = (nextDeltaTime*10)/(10+musicspeed);
	}
}

This works, except that when the song does loop, nextDeltaTime is a very small tick value so using that division I believe it just becomes 0 and does not get played?!? This looped perfectly when I changed ProcessMusic directly and didn't have to rely on a pointer to know when a new event happened, so that is definitely the problem.

I thought of 2 possible solutions. I notice that currDeltaTime and nextDeltaTime are signed 16bit ints, I haven't looked into the asm, but is there a reason that it is signed as opposed to unsigned? Perhaps we could make these values uint32_t, and adjust ProcessMusic accordingly to divide it into real ticks(basically 16:16 fixed point math where we have 16bits of "in between" numbers). 4 extra ram byte in the kernel shouldn't break anyone's game, but now we would be able to very finely change the playback speed of songs! A lot of games do this in overtime, or hectic situations.

Other idea was just to add maybe 2048 empty ticks to the midi song and convert it again, so the first delta time will be large enough for the division not to bring it to 0. Then my lame hack way might work well enough without modifying kernel and I could just be quiet about it Anyone else think this is useful enough to make a good solution as opposed to the hack I will probably do otherwise?

[uze6666]

Hi Lee,

I sort of recall wanting to implement that when I updated the sound/music engine, but could not make it work quickly so I left it out. I don't recall there was any reason why those pointers are signed int. If you think the 16:16 idea will work, I say implement it and lets include it in the stock kernel. We will also want a new simple api function to set the tempo. Just test it well on as many games as possible.