Due to performance reasons: I made my own vgm-parser/analyser in python. The raw-data replayer is also custom. It's optimized to use the minimum 84 cycles between writings in the inner loop, but due to a bug in openmsx (we need to have it running on openmsx!) I have had to allow 85 cycles (ref: this thread https://www.msx.org/forum/msx-talk/openmsx/ym2413-wait-state...).
Should you release it let me know
I am trying to convert to sdcc the moon sound player but it is very hard. Sdasz80 is crappy and full of quirks
Should you release it let me know
I am trying to convert to sdcc the moon sound player but it is very hard. Sdasz80 is crappy and full of quirks
For norakomi’s project I am working on a MoonSound OPL4 fast replayer converter, taking VGM as input. It’s quite far along, I’ll tune it further when I get more tracks to test with. I’ll publish it sometime in the future but I can do it sooner if you’re interested.
For norakomi’s project I am working on a MoonSound OPL4 fast replayer converter, taking VGM as input. It’s quite far along, I’ll tune it further when I get more tracks to test with. I’ll publish it sometime in the future but I can do it sooner if you’re interested.
It would be great to test it. SDCC has a terrible assembler, are you using Glass for it?
I posted it here, including the source code. Yes it’s using Glass but I tried to use macros etc. sparingly. Let’s discuss further in that thread :).
What "bothers" me though, is that when you stand still and start going to the left or the right, the main character immediately uses the full walking speed. Wouldn't it be more natural if he starts slow and goes faster after a .5 seconds for instance? I think most platform games use this method, it gives a more smoother look to the game.
I've been testing a bit with detaching the viewport's center from the player. This way the scrolling can move smoothly. Even if I haven't added inertia to the player movement, maybe this can alleviate some of your concerns wimpie3? https://www.youtube.com/watch?v=sltpK8R4Fks
I've been planning this solution for a while now. Current setup also allows for seing more area in front of you than behind you. In the video: 2/3 of the screen in front of you, and 1/3 behind. After some testing I lean towards 60% in front and 40% behind, though :)
Also looks pretty good to me. Have you tried interpolating between scroll speeds more gradually, that is, with a fixed point step instead of integer? As demonstrated here.
Looks very good to me!! I like that the camera moves slowly when you turn from left-to-right and viceversa. Lots of games add a very jerky camera movement when you do that, which creates a horrible visual effect when you are playing a part of the game that requires you to change direction constantly. So, this solution works pretty well!
