31 replies to this topic

[SebRmv]

Hi everybody,

I am very pleased to announce the immediate availability of the Removers library 1.3.1 (as well as jlibc 0.5.7)
As usual, it is released under the terms of the LGPL license, so that everybody can use & hack it freely.
A source & a binary release are avaliable on http://removers.atar...ts/download.php

I finally rewrote the sound engine, so that now it is able to replay 8 voices at a replay frequency up to 46 kHz.
You can hear the result by testing the binary release of example15 available here: http://removers.atar...s/example15.cof

I am very proud of this new engine. I would like to thank LinkoVitch who, with his work on his own sound engine, gave me enough motivation
to get my hands again on my Jaguar to begin & finish the rewriting of the sound engine, which is a project I planned to do since more than 2 years.

Comments & questions are welcome. Please feel free to ask.

Cheers

Seb

[CyranoJ]

Nice work, seb!

[Jag_Slave]

Awesome!

[LinkoVitch]

Nice one! MOAR stuff for the Jag is all good, things are really kicking off this year!

Gah sound engine competition! Going to have to stop slacking now

[Hyper_Eye]

I installed Belboz's pre-rolled Linux dev environment and replaced jlibc and rmvlib with these new versions. Everything seems to be working and example15 is running just fine. Thanks Seb!

[CyranoJ]

SebRmv, on Sat Jan 21, 2012 10:19 AM, said:

Comments & questions are welcome. Please feel free to ask.

Hi Seb,

How does it perform when the bus is heavily loaded up? What are the latency times like?

[SebRmv]

CyranoJ, on Wed Jan 25, 2012 7:28 PM, said:

SebRmv, on Sat Jan 21, 2012 10:19 AM, said:

Comments & questions are welcome. Please feel free to ask.

Hi Seb,

How does it perform when the bus is heavily loaded up? What are the latency times like?

Hi,

I have not yet really tested. But I have just finished to code an improved version which makes less access to the bus. So I will probably release this new version very soon.
I am now able to reach the next upper frequency which is about 52 kHz with 8 voices. Apparently, there is still some free time, so an upper frequency is still possible (actually 59 kHz seems to work also!)

I would be very pleased if you could benchmark my player with your own code and tell me how it reacts with loads of sprites. To be honnest, I don't really know how to measure what you are asking to me.

[SebRmv]

As promised, version 1.3.2 is now available. Sound engine has been improved.

[Hyper_Eye]

Hey Seb... when I run example15 in Virtual Jaguar built against rmvlib-1.3.1 the music plays perfectly. When I build it against rmvlib-1.3.2 I am getting quite a bit of distortion. In either case it is not using up even close to all of one of my 4 cpu cores. I haven't tried it on the Jag yet but I intend to try both versions later today. I'm just wondering if anyone else is noticing the same behavior.

[Hyper_Eye]

Well I loaded it into a skunk and it sounds fine on the Jag. So it is either the emulator or my computer.

[SebRmv]

I didn't try with VirtualJaguar but with Project Tempest, and on my computer, the sound was distorted. I think it requires a lot of power to emulate what is done by the Jaguar, so maybe it is your computer which is too slow (or the emulator which does not use the full power of your computer).

Please also note that if you use the cof files I gave, example15 uses a higher replay frequency with version 1.3.2 (about 52 kHz) than with version 1.3.1 (about 46 kHz). This might be the difference!

Edited by SebRmv, Fri Jan 27, 2012 1:28 AM.

[Hyper_Eye]

I built example15 myself. I'm not sure if that is what you mean. I didn't re-download it after updating to 1.3.2 either so the frequency requested by example15 is 46k and that is what the console says the freq is. I haven't looked into the lib enough to know that the Protracker replay routine adheres to that same setting. I loaded Project Tempest into wine and gave it a shot. With that I am getting identical results with example15 built against 1.3.1 and 1.3.2. I don't think my CPU is the issue. I'm not seeing any difference in CPU usage between the two versions with Virtual Jaguar and it is pushing one core to just over half. I don't really know what the issue is. It isn't causing any problems with anything I am doing right now and if it was I wouldn't worry too much about it as it works on the Jag and I would likely just use the Jag. I just wanted to share my observation in case there was an issue in the lib (which now that I tested it on the Jag I know isn't likely the case... if it works on the real hardware then it works) or an issue exposed by it in Virtual Jaguar. I certainly think it is valid to think more optimization could be what is needed.

CPU is AMD Phenom II X4 975 @ 3.61GHz (quad core)
GPU is an XFX Geforce 9800GTX+ 512MB
Memory is 4GB G.Skill 1066 5-5-5-15

I made a video (not advertised, link only) demonstrating the issue. I recommend watching it fullscreen in HD to see top running behind the emulator. Top shows CPU usage on a per-core basis so 100% is a whole core and 400% is the whole CPU. You will notice vj pretty much sticks to 65/66 while the example is running in both cases. You might notice some small imperfections when the 1.3.1 build is running. Those don't happen when I'm not capturing the desktop and the difference is pretty accurately captured.



Like I said, I'm making no assumptions about the cause and this is not something that is greatly important to me. I just wanted to make sure I reported what I was seeing in case there is a bug somewhere.

I'm enjoying your library a lot. Thanks for the great work you are doing.

[SebRmv]

Thank you for the video. From what I hear, I can say that it is probably the main resampling loop which takes too much time on VirtualJaguar. You can check this point by changing the value of DSP_BG in the file paula.s and recompile it. This will display in RED the number of lines needed to do resampling, which occurs roughly at every half VBL. (the game is to have as much BLACK as possible between the two RED bars, no BLACK => you lose )
What I can say is that the resampling loop of 1.3.2 is slightly bigger (number of instructions) than the one of 1.3.1 (or 1.3.0), but I think it uses better the pipeline and it performs less access to the main bus. Maybe these two points are not well emulated by VirtualJaguar?

One thing I have not understood in your tests, did it work well with Project Tempest? BTW, I didn't know PT was working with Wine, thanks for the tip!

edit:
1-you will see better the red bars if the VBL is at 60 Hz
2-yes, of course, the replay frequency is the same for Protracker modules!

Edited by SebRmv, Sat Jan 28, 2012 3:40 AM.

[Hyper_Eye]

In Project Tempest there were imperfections with both but they didn't seem to be any different. Neither sounded as bad as what is in that video while 1.3.2 is playing. But they don't sound as good as what I hear in Virtual Jaguar with 1.3.1 which is just about perfect. I will try changing DSP_BG and see what I find out.

[Hyper_Eye]

Well I got back around to messing with this and it appears you were completely right. I made two more videos.

This first one is running in Virtual Jaguar and is pretty much the same thing as the first video I posted except with DSP_BG enabled.



Clearly the red consumes the background when using 1.3.2 exactly when the distortion starts while there is plenty of black while 1.3.1 is running.

This second one is the same thing but using a Jag and Skunkboard. Any noise in the image is an artifact of recording.



The first noticeable thing is that the lines move in a different direction than they do in the emulator. Obviously the important thing is that the Jag hardware exhibits the exact opposite of what the emulator does. When using 1.3.1 the black never runs out but it sure does get close. When running 1.3.2 there is much more black in the background and it obviously plays without any distortion.

SebRmv, on Sat Jan 28, 2012 3:17 AM, said:

2-yes, of course, the replay frequency is the same for Protracker modules!

I figured that was the case but I didn't want to make an assumption without doing the necessary research.

Edited by Hyper_Eye, Sun Jan 29, 2012 7:49 PM.

[SebRmv]

Ah, that's interesting! Thank you for making the experiment.

The fact that the lines go in a different direction means that the replay frequency in VirtualJaguar is probably not the one announced, but is probably a bit higher.
Also, from what I have seen, DSP emulator does not seem to be cycle accurate: this probably explains why 1.3.2 runs slower than 1.3.1

[SebRmv]

Just one final remark regarding the videos: the first red bar sometimes flicks. This is normal because the code that alters BG in file main.c of example15 (function play_module) conflicts with the DSP code. (i.e. the following can happen: the DSP turns it RED, play_module turns it RED then BLACK, and DSP turns it BLACK) But we still see how it behaves, so no matter! This is very instructive. Thank you again for having done the experiment.

Edited by SebRmv, Mon Jan 30, 2012 2:59 AM.

[Hyper_Eye]

No problem. This was pretty interesting for me. Besides I like the tune included with the example so it was a good excuse to listen to it a bunch of times.

[Hyper_Eye]

Alright, I have another experiment I would like to post about. Seb, let me know if this thread is not the right place for this.

So, I have been playing around with sprites and I have not had any issues there so far. Tonight I wanted to check out the screen methods and throw some pixels around. I made a test program with the intention of drawing some lines with the different methods available: put_pixel(), put_pixels(), and vline(). Setting up and working with a screen is pretty easy. I ran into two issues though. I will share my code and then screenshots that show what I am seeing. These results are the same in the emulator and on the Jaguar.

Here is the code:

#include <interrupt.h>
#include <display.h>
#include <sprite.h>
#include <screen.h>

#define RED   0xf800
#define BLUE  0x07c0
#define GREEN 0x003f

#define SCREEN_WIDTH  320
#define SCREEN_HEIGHT 240

#define LINE_WIDTH  8
#define LINE_LENGTH 200
#define LINE_PIXELS (LINE_WIDTH * LINE_LENGTH)

int main(int argc, char* argv[])
{
	int i, j;

	// Initialize
	TOMREGS->vmode = RGB16|CSYNC|BGEN|PWIDTH4|VIDEN;
	init_interrupts();
	init_display_driver();

	// Setup a display
	display* d = new_display(0);
	d->x = 16;
	d->y = 8;

	// A screen to play with
	screen* scr = new_screen();
	alloc_simple_screen(DEPTH16, SCREEN_WIDTH, SCREEN_HEIGHT, scr);
	clear_screen(scr);

	// Attach the screen to the display as a sprite
	sprite* scr_sprite = sprite_of_screen(0, 0, scr);
	attach_sprite_to_display_at_layer(scr_sprite, d, 0);

	// Draw the red vertical lines one pixel at a time
	for(i = 0; i < LINE_WIDTH; i++)
	{
		for(j = 0; j < LINE_LENGTH; j++)
		{
			put_pixel(scr, SCREEN_WIDTH * 0.25 + i, j, RED);
		}
	}

	// Draw the green vertical lines at once with a pixel array
	pixel pl[LINE_PIXELS];

	for(i = 0; i < LINE_WIDTH; i++)
	{
		for(j = 0; j < LINE_LENGTH; j++)
		{
			int ndx = (i * LINE_LENGTH) + j;

			pl[ndx].x = SCREEN_WIDTH * 0.5 + i;
			pl[ndx].y = j;
		}
	}

	put_pixels(scr, GREEN, LINE_PIXELS, pl);

	// Draw the blue vertical lines one line at a time with the builtin
	// vline() method.
	for(i = 0; i < LINE_WIDTH; i++)
	{
		vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH, BLUE);
	}

	// Show the display
	show_display(d);

	for(;;)
	{
		vsync();
	}

	return 0;
}

This is the result when I run that code:

As you can see the only method that works correctly is the vline() method. When I try to set the pixels myself only the odd numbered lines on the x coords show up. The even numbered lines remain black.

The second issue occurs if I change LINE_LENGTH to equal SCREEN_HEIGHT (240). Then vline() exhibits a different issue which looks like this:


So here vline() is not drawing to the bottom of the screen but moves to the right after a certain number of y pixels. I suspect this is not the intended behavior.

Thanks for your interest and assistance!

[SebRmv]

Hyper_Eye, on Tue Jan 31, 2012 1:08 AM, said:

Alright, I have another experiment I would like to post about. Seb, let me know if this thread is not the right place for this.

So, I have been playing around with sprites and I have not had any issues there so far. Tonight I wanted to check out the screen methods and throw some pixels around. I made a test program with the intention of drawing some lines with the different methods available: put_pixel(), put_pixels(), and vline(). Setting up and working with a screen is pretty easy. I ran into two issues though. I will share my code and then screenshots that show what I am seeing. These results are the same in the emulator and on the Jaguar.

Hi,

I'll have a look at it, as soon as I get some time and a Jaguar near myself.
To be honest, these functions are not intended to be really used , but thank you for spotting a bug if any.

Cheers

[SebRmv]

So, sorry, I don't need a Jaguar finally

I just had a look at some of my example codes and just realized that I have badly documented these functions.
Indeed, the color parameter has to be on 32 bits: the high half and the low half are both used to set the color.
In your case, simply change your code to:

put_pixel(scr, SCREEN_WIDTH * 0.25 + i, j, RED<<16 | RED);

vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH, BLUE<<16 | BLUE);

put_pixels(scr, GREEN<<16 | GREEN, LINE_PIXELS, pl);

Regarding the problem with vline, I need to think a bit about it.

Cheers

Edited by SebRmv, Tue Jan 31, 2012 2:58 AM.

[SebRmv]

Hi again,

for the problem with vline, I think the higher value you can give is SCREEN_HEIGHT-1, because the parameter is not the height, but the Y-coordinate of the last point (which should be >= Y-coordinate of the first point).
But, I still don't understand why something is put to the right. The intended behaviour is that the Y-coordinate is clipped.

[Hyper_Eye]

SebRmv, on Tue Jan 31, 2012 2:49 AM, said:

To be honest, these functions are not intended to be really used , but thank you for spotting a bug if any.

I am glad they are there and documented (I ran doxygen on the source because the online doc is outdated.) I would like to put these methods to use for a particular purpose and I was pretty happy when I found them.

SebRmv, on Tue Jan 31, 2012 2:55 AM, said:

So, sorry, I don't need a Jaguar finally

I just had a look at some of my example codes and just realized that I have badly documented these functions.
Indeed, the color parameter has to be on 32 bits: the high half and the low half are both used to set the color.
In your case, simply change your code to:

put_pixel(scr, SCREEN_WIDTH * 0.25 + i, j, RED<<16 | RED);

vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH, BLUE<<16 | BLUE);

put_pixels(scr, GREEN<<16 | GREEN, LINE_PIXELS, pl);

This resolved the issue perfectly! Thanks!

SebRmv, on Tue Jan 31, 2012 3:07 AM, said:

Hi again,

for the problem with vline, I think the higher value you can give is SCREEN_HEIGHT-1, because the parameter is not the height, but the Y-coordinate of the last point (which should be >= Y-coordinate of the first point).
But, I still don't understand why something is put to the right. The intended behaviour is that the Y-coordinate is clipped.

I would expect clipping but not where the line is clipped and I didn't expect to see it on the right. I thought it would end where the other lines end.

Thanks for looking at the issue and responding so quickly. As you can tell I meant it when I said I was having fun with your lib!

[Hyper_Eye]

By the way, I realize you were implying that there could be a clipping issue due to me going one over the screen size. I know you were just pointing out possibilities without the convenience of being able to run the code at the moment. I want to clear it up a bit. It doesn't matter what ymax I specify. If it is beyond the last visible point in that screenshot it will begin coming down on the right. The length of the line coming out on the right is determined by how much ymax goes beyond that point. I think the highest value before this happens, in this example, is 200.

As for the ymax used in the code I posted, the value used is indeed incorrect. The corrected code, accounting for 0, would be:

vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH-1, BLUE<<16 | BLUE);

Thanks.

[SebRmv]

Hyper_Eye, on Tue Jan 31, 2012 3:03 PM, said:

By the way, I realize you were implying that there could be a clipping issue due to me going one over the screen size. I know you were just pointing out possibilities without the convenience of being able to run the code at the moment. I want to clear it up a bit. It doesn't matter what ymax I specify. If it is beyond the last visible point in that screenshot it will begin coming down on the right. The length of the line coming out on the right is determined by how much ymax goes beyond that point. I think the highest value before this happens, in this example, is 200.

As for the ymax used in the code I posted, the value used is indeed incorrect. The corrected code, accounting for 0, would be:

vline(scr, SCREEN_WIDTH * 0.75 + i, 0, LINE_LENGTH-1, BLUE<<16 | BLUE);

Thanks.

Clearly, there is a bug somewhere.
I tried to understand what goes wrong yesterday evening, but haven't succeeded yet.
Just one question: does the problem also happen when using VirtualJaguar?