Forums

Hi!

Testing Shmup (with many tile redefinitions each frame, as I want to have several parallax and wave animation scrolling effects) I see things going slow... until though to disable WaitForVBLANK!!!

Now the game is running too fast for me. The question is... can I disable the redraw waiter routine? or will have trouble on real sms, instead of emulation. ¿Is there any function to regulate timing alternative to waitforvblank???

Thanks!

The second thing is a new tool.

If I make a laaaaarge shmup stage (vertical, 32x? tiles) memory requirements grow fast, so this tool get the bin tilemap created by bmp2tile and create two files:

One is a binary array of unsigned chars, with only one copy of the diferent rows finded in the tilemap.

Other is an index of chars with the number of the rows.

With this method, reduced a 32x460 tiles testing stage from 29kb to 7kb!!!

Soon will publish a demo, as I am working now.

Thanks!

Sin título-1.jpg (130.46 KB)

There 3 scroll planes here, and a flashing tile. Modify 4 tiles each frame!

Sin título-2.jpg (212.53 KB)

Modifying 4 tiles to archieve a fake wave animation like fire

bintolm.rar (1.86 KB)

I would stick with WaitForVBlank, as it's the way to sync with screen (50 or 60 fps, depending on TV standard / console type).
If you need to speed up something, you could stream tiles using UNSAFE_SMS_load4Tiles() for instance, and UNSAFE_SMS_copySpritestoSAT(), just take care to call these functions right after SMS_waitForVBlank() as they'll work safely only when they run completely during VBlank phase.

As for the tool, you could code a specific BMP2Tile plug-in that prepares the data the way you need them. It's quite easy, but let me know if you need some help with that :)

edit: also consider using palette effects instead of streaming tiles, as it's way faster to redefine a few colors than to load 128 bytes to VRAM.

UNSAFE_SMS_copySpritestoSAT() did the trick, at least on fusion.

But tryed on other emulators (meka, and smsplus)... in SMSPlus don't have any performance problem, even without the unsafe function, while in fusion sometimes the animation seems jerky (I fix it pushing f1, f2 or f3). Have an I7 5500, geforce 920M, 16Gb ram, clean windows, latest drivers, so no hardware fault (and these aren't pcsx4).

So my doubt is about emulators (fusion by example) accuracy, as never had a SMS.

Other question: Sometimes, after compiling, SDCC make a binary which is 100.2%... 100.6% of 32kb. The SMS converted doesn't work, as expected. Fix it deleting some unused bitmaps ¿Would not switch to 48kb rom?

Thanks guy, have a friend here!

I suggest using Emulicious as your emulator of choice. It's the most accurate one I know of, and the only one that faithfully reproduces all the effects of faulty VDP access, plus it comes with all sorts of neat debugging tools.

If something runs flawlessly on emulicious, it will most certainly work on real hardware, too.

eruiz00 wrote

Sometimes, after compiling, SDCC make a binary which is 100.2%... 100.6% of 32kb. The SMS converted doesn't work, as expected.

What's happening there? Which error are you getting?
SDCC output is an IHX file, which isn't a binary file so its size doesn't matter much... and ihx2sms should convert it to ROMs up to 48KB with no problems so I'm quite curious to know what are you getting there...

I have tryed to recreate the problem but does work nicely now. The rom is 48kb. If i find this problem i'll save the workspace and post it here. Things are going good now and hace nice and faster effects with palette :)

Sorry guys but have a problem.

Psgmod attached converts to a vgm and then to 22kb psg file.

If i cut the song got a 15kb psg. Ok. I dispose a bank for the song and switch to it before playing the song. But i have other scroll data which i need to access every frames just like the song....

Is there a way to do this??? Though about bank switch twice every frames but does not seems realistic. I see the psg a bit heavy for what it have inside. Is there some optimization possible?

Dont push too hard on me about the song... in emulicious sounds much better than in psg2mod.

Thanks !!!

stage4.zip (1.15 KB)

Bank switching is cheap, don't worry about doing it several times per frame. If you are composing in Mod2PSG2 then much better to keep it there, it is a more space efficient player and you won't have to trim.

PSG files are very simple but quite BIG files, but there are a few workarounds to overcome the 16 KB limits. First of all you should try compressed PSGs (which I usually call PSGCs) - see psgcomp tool.
Then, if the file is still too big, you could try checking if you've got the needed space in your first 32 KB, as your code may be taking just a small part of it. In that case you just place your tune into the unpaged space, which is up to 32 KB, potentially.
Another workaround is to create two tunes and play them without looping, and checking when one is complete just to fire the other part... that would actually work with many different parts, and you could theoretically write tunes as big as you need them. But it's easier to keep your tunes under 16 KB, really - or use Mod2PSG2 format and library which has better space efficiency.

Author	Message
eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Wait to vblank and performance, and a new tool Posted: Sat Feb 04, 2017 5:12 pm
	Hi! Testing Shmup (with many tile redefinitions each frame, as I want to have several parallax and wave animation scrolling effects) I see things going slow... until though to disable WaitForVBLANK!!! Now the game is running too fast for me. The question is... can I disable the redraw waiter routine? or will have trouble on real sms, instead of emulation. ¿Is there any function to regulate timing alternative to waitforvblank??? Thanks! The second thing is a new tool. If I make a laaaaarge shmup stage (vertical, 32x? tiles) memory requirements grow fast, so this tool get the bin tilemap created by bmp2tile and create two files: One is a binary array of unsigned chars, with only one copy of the diferent rows finded in the tilemap. Other is an index of chars with the number of the rows. With this method, reduced a 32x460 tiles testing stage from 29kb to 7kb!!! Soon will publish a demo, as I am working now. Thanks! Sin título-1.jpg (130.46 KB) There 3 scroll planes here, and a flashing tile. Modify 4 tiles each frame! Sin título-2.jpg (212.53 KB) Modifying 4 tiles to archieve a fake wave animation like fire bintolm.rar (1.86 KB)

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sat Feb 04, 2017 6:51 pm
	I would stick with WaitForVBlank, as it's the way to sync with screen (50 or 60 fps, depending on TV standard / console type). If you need to speed up something, you could stream tiles using UNSAFE_SMS_load4Tiles() for instance, and UNSAFE_SMS_copySpritestoSAT(), just take care to call these functions right after SMS_waitForVBlank() as they'll work safely only when they run completely during VBlank phase. As for the tool, you could code a specific BMP2Tile plug-in that prepares the data the way you need them. It's quite easy, but let me know if you need some help with that :) edit: also consider using palette effects instead of streaming tiles, as it's way faster to redefine a few colors than to load 128 bytes to VRAM.

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sun Feb 05, 2017 2:40 pm
	UNSAFE_SMS_copySpritestoSAT() did the trick, at least on fusion. But tryed on other emulators (meka, and smsplus)... in SMSPlus don't have any performance problem, even without the unsafe function, while in fusion sometimes the animation seems jerky (I fix it pushing f1, f2 or f3). Have an I7 5500, geforce 920M, 16Gb ram, clean windows, latest drivers, so no hardware fault (and these aren't pcsx4). So my doubt is about emulators (fusion by example) accuracy, as never had a SMS. Other question: Sometimes, after compiling, SDCC make a binary which is 100.2%... 100.6% of 32kb. The SMS converted doesn't work, as expected. Fix it deleting some unused bitmaps ¿Would not switch to 48kb rom? Thanks guy, have a friend here!

Kagesan Joined: 01 Feb 2014 Posts: 878	Posted: Sun Feb 05, 2017 5:19 pm
Kagesan Joined: 01 Feb 2014 Posts: 878	I suggest using Emulicious as your emulator of choice. It's the most accurate one I know of, and the only one that faithfully reproduces all the effects of faulty VDP access, plus it comes with all sorts of neat debugging tools. If something runs flawlessly on emulicious, it will most certainly work on real hardware, too.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Sun Feb 05, 2017 6:24 pm
	eruiz00 wrote Sometimes, after compiling, SDCC make a binary which is 100.2%... 100.6% of 32kb. The SMS converted doesn't work, as expected. What's happening there? Which error are you getting? SDCC output is an IHX file, which isn't a binary file so its size doesn't matter much... and ihx2sms should convert it to ROMs up to 48KB with no problems so I'm quite curious to know what are you getting there...

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sun Feb 05, 2017 10:46 pm
	I have tryed to recreate the problem but does work nicely now. The rom is 48kb. If i find this problem i'll save the workspace and post it here. Things are going good now and hace nice and faster effects with palette :)

eruiz00 Joined: 28 Jan 2017 Posts: 556 Location: Málaga, Spain	Posted: Sun Feb 12, 2017 8:57 pm
	Sorry guys but have a problem. Psgmod attached converts to a vgm and then to 22kb psg file. If i cut the song got a 15kb psg. Ok. I dispose a bank for the song and switch to it before playing the song. But i have other scroll data which i need to access every frames just like the song.... Is there a way to do this??? Though about bank switch twice every frames but does not seems realistic. I see the psg a bit heavy for what it have inside. Is there some optimization possible? Dont push too hard on me about the song... in emulicious sounds much better than in psg2mod. Thanks !!! stage4.zip (1.15 KB)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Sun Feb 12, 2017 10:01 pm
	Bank switching is cheap, don't worry about doing it several times per frame. If you are composing in Mod2PSG2 then much better to keep it there, it is a more space efficient player and you won't have to trim.

sverx Joined: 05 Sep 2013 Posts: 3828 Location: Stockholm, Sweden	Posted: Mon Feb 13, 2017 9:49 am
	PSG files are very simple but quite BIG files, but there are a few workarounds to overcome the 16 KB limits. First of all you should try compressed PSGs (which I usually call PSGCs) - see psgcomp tool. Then, if the file is still too big, you could try checking if you've got the needed space in your first 32 KB, as your code may be taking just a small part of it. In that case you just place your tune into the unpaged space, which is up to 32 KB, potentially. Another workaround is to create two tunes and play them without looping, and checking when one is complete just to fire the other part... that would actually work with many different parts, and you could theoretically write tunes as big as you need them. But it's easier to keep your tunes under 16 KB, really - or use Mod2PSG2 format and library which has better space efficiency.

Forums

View topic - Wait to vblank and performance, and a new tool