50 replies to this topic

[RX Shorty]

Nice release Pickle.
Though as noticed before, the sound is really loud and crackling..

[Pickle]

Im not sure why the sound is like this. I think it was better with the 16 bit SDL, but that introduced instabilities. Maybe I can convert to 16 bit sound with the OSS code and get something better sounding. I think SDL is using OSS anyway, so it kind of makes sense it sounds tha same with no changes.

Edited by Pickle, 18 June 2009 - 05:15 PM.

[vEGA-rJ]

There's no scaling option working in it or i'm wrong?

At the beginning pickle told that there isn't scaling working, but now the situation has changed or not?

[Pickle]

There's no scaling option working in it or i'm wrong?

At the beginning pickle told that there isn't scaling working, but now the situation has changed or not?

No i havnt added a good solution yet. Like Dave mentioned I would also like to take a look at the method used in gpsp and see it can be used.
To be honest there is a double scaling, but its only in the vertical direction. The gp2x hw scaler was supposed to used to do the horizontal scaling. But i removed that line, so you only get the vertical.

Also I dont think anyone has noticed, but theres an overlay text option that itsnt working with wiz_lib. I saw it work with the SDL video. Its not a big piority i think. It would display various message like fps, saving states, volume?

Overclock does work if anyone wants to play around with it. You can underclock if you want. If anyone thinks we really need to go below 200 Mhz let me know.

[juanvvc]

No i havnt added a good solution yet. Like Dave mentioned I would also like to take a look at the method used in gpsp and see it can be used. To be honest there is a double scaling, but its only in the vertical direction. The gp2x hw scaler was supposed to used to do the horizontal scaling. But i removed that line, so you only get the vertical.

Actually, that "vertical scaling" was the "deformed video mode". In this mode, vertical scaling was in software and horizontal scaling in hardware, as Pickle says It should be NOT difficult to add horizontal scaling in software. In file gp2x.c, wiz.c, whatever you called, add this function at the beginning:

CODE

static byte tmpline[160*2*4]; // up to pelsize=4 systems
void scaleline2x(void *dst, void *src){
    byte *t=tmpline;
    int tmpx=160;
    while(tmpx--){
        MEMCPY(t, src, fb.pelsize);
        MEMCPY(t+fb.pelsize, src, fb.pelsize);
        t+=fb.pelsize*2;
        src+=fb.pelsize;
    }
    MEMCPY(dst, t, 320*fb.pelsize);
}

And change the MEMCPY lines inside cases 4 and 3 of the switch(options.scaling) in function vid_begin (lines 178, 182, 185 and 197 in my original gp2x.c) for:

CODE

scaleline2x(s, fs);

For example, case 3 (double size) is now:

CODE

        case 3: //DOUBLE SIZE
            tempy=120;
            fs=fakescreen+options.voffset*fb.pitch; //+fb.offset(==0);
            s=(void *)gp2x_video_RGB[0].screen16;
            while(tempy--){
                scaleline2x(s, fs);
                MEMCPY(s+320*fb.pelsize, s, 320*fb.pelsize);
                s+=2*320*fb.pelsize;
                fs+=fb.pitch;
            }
            break;

There we are: deformed and double modes in Wiz! Sure, they are not the most popular modes and this solution will cost some megahertzs. But it is just a matter or minutes to code!

Also I dont think anyone has noticed, but theres an overlay text option that itsnt working with wiz_lib. I saw it work with the SDL video.

To print texts on screen, the Gp2x used the text functions from the original minimal library and maybe they are not compatible with wiz_lib. In the SDL version that functions are directly taken from wiz_lib, so you can just copy fontdata8x8 and print_text() from sdl.c, and they should work.

Most messages are not important: volume and so. But sometimes there is a question to the user ("Are you sure that you want to save the game?") and I think that you must show these questions on the screen.

Overclock does work if anyone wants to play around with it. You can underclock if you want. If anyone thinks we really need to go below 200 Mhz let me know.

If we add software scaling or solve the diagonal issue, we will need more freq for sure Besides, there are some games that need more CPU even in Gp2x (Alone in the Dark, Shantae...) Setting freq to 300MHz is not a bad idea, and the Wiz does not run out of batteries as fast as the Gp2x

Edited by juanvvc, 19 June 2009 - 01:36 PM.

[Pickle]

If we add software scaling or solve the diagonal issue, we will need more freq for sure Besides, there are some games that need more CPU even in Gp2x (Alone in the Dark, Shantae...) Setting freq to 300MHz is not a bad idea, and the Wiz does not run out of batteries as fast as the Gp2x

Thanks a bunch for the code and tips!
The cpu speed is selectable from 200 to 550 in 50 Mhz increments.

[juanvvc]

The cpu speed is selectable from 200 to 550 in 50 Mhz increments.

My fault My reading comprehension is so low that I thought that you won't allow freqs higher than 200MHz

BTW, the actual code for the double mode must be (case 3)

CODE

        case 3: //DOUBLE SIZE
            tempy=120;
            fs=fakescreen+options.voffset*fb.pitch; //+fb.offset(==0);
            s=(void *)gp2x_video_RGB[0].screen16;
            while(tempy--){
                scaleline2x(s, fs);
                MEMCPY(s+320*fb.pelsize, s, 320*fb.pelsize);
                s+=2*320*fb.pelsize;
                fs+=fb.pitch;
            }
            break;

(changed in the last post, as well)

For case 4 (deformed), I think that you only have to change the three calls to MEMCPY for scaleline2x. Be aware that I didn't test this code!

Edited by juanvvc, 19 June 2009 - 01:40 PM.

[Pickle]

Ive been messing with the new scaling code but all im getting is black. Im going to keep looking.

Update: Ive got it pretty much working now :-)
Update2: Its working :-)

I did the scanline slightly different. I think the original version was black since t address was never reset to the beginning of the array. So in my solution I offset t, but never change it directly. So at the last memcpy its pointing where it should be at the first byte in the array.

CODE

static byte tmpline[160*2*4]; // up to pelsize=4 systems
void scaleline2x(void *dst, void *src){
    byte *t=tmpline;
    int tmpx, pixel1, pixel2;

    for( tmpx=0; tmpx<160; tmpx++ )
    {
    pixel1 = tmpx*2*fb.pelsize;
    pixel2 = (tmpx*2+1)*fb.pelsize;
    MEMCPY(t+pixel1, src, fb.pelsize);
    MEMCPY(t+pixel2, src, fb.pelsize);
    src+=fb.pelsize;
    }
    MEMCPY(dst, t, 320*fb.pelsize);
}

I updated the zip at pickle.gp2x.de/lemonboy-wiz.zip

Edited by Pickle, 20 June 2009 - 01:53 AM.

[DaveC]

Thanks for the update.

I noticed though when you set the settings for scaling options in the menu it doesn't save them or display the changes.

It doesn't do a regular fullscreen mode when you hit the game buttons to change, just gives the deformed at top/bottom type and the 2:1 cropped option. Also is there a smooth option like GPsP? The other scale modes are quite blocky.

The sound is still distorted. Is there a way to fix or is it too much ingrained in the code?

Thanks for the great work.

[juanvvc]

Thanks, Pickle. I cannot see where my code is wrong, it should do the same thing that yours. Anyway, if your code is working that's enough

Are the system messages (volume, saves) displayed on the screen now?

I noticed though when you set the settings for scaling options in the menu it doesn't save them or display the changes. (...)It doesn't do a regular fullscreen mode when you hit the game buttons to change

I couldn't understand the first bug report, sorry. Do you mean that you change the options and they are not applied, or that they are not saved in the configuration file?

About the true fullscreen mode... Give us a break! Cropped and deformed fullscreen modes were really easy and quick to simulate in software. In a few weeks, I'll have time enough to check the Notaz fullscreen algorithm and I think that the Wiz is powerful enough to manage 2xsai for Gameboy emulation.

Of course, Pickle can work on this emulator at his own if he likes. He is doing a wonderful work.

Edited by juanvvc, 20 June 2009 - 01:34 PM.

[Pickle]

Thanks, Pickle. I cannot see where my code is wrong, it should do the same thing that yours. Anyway, if your code is working that's enough

theres one problem at least, in your final memcpy the address in 't' is at 320*pelsize, not at the beginning, so the copy is coying the unused data.

Are the system messages (volume, saves) displayed on the screen now?

I havnt fully debugged them yet, I did a quick look and I dont see whats wrong.

I have taken a look at the notaz method. Its an arm asm routine, it should be usable to create a larger screen but keeping the correct aspect ratio. I just need some time to try it out.

Im trying to figure out the noisy sound too, which I think is the biggest problem at the moment

Edited by Pickle, 20 June 2009 - 03:31 PM.

[juanvvc]

theres one problem at least, in your final memcpy the address in 't' is at 320*pelsize, not at the beginning, so the copy is coying the unused data.

Right, I see. The last MEMCPY shouldn't be with t but tmpline. MEMCPY(dst, tmpline, 320*fb.pelsize);

Anyway, if your code works, it's fine. Your version is a little slower because you have a couple additional operations, but not really that much

I cannot help with the sound. I confirm that is really buggy in the SDL version for PC, but it is ok in the minimal lib for Gp2x. Or at least, nobody complained You're using the wiz_lib for sound, aren't you?

I removed lots of lines in the main loop of emu.c (emu_run() function) to improve speed for the Gp2x. I'm pretty sure that some of them were related to sound syncronization. Maybe you should check the original version of emu.c in gnuboy.

[Exophase]

Too bad the MLC video layer only supports YUV 4:2:0, since it has a hardware scaler. You could output a 320x288 Y and 160x144 Cb and Cr images, but that'd probably take more time than doing a notaz like scaler on 160x144. Although, for normal (non color) GB there's really little or no changing non luminance data, so you could probably get away with only outputting 160x144 grayscale with a fixed Cb/Cr offset to get the palette you want, then have the hardware scaler scale that (comes with bilinear filtering). Probably not worth the effort though.

[Pickle]

I cannot help with the sound. I confirm that is really buggy in the SDL version for PC, but it is ok in the minimal lib for Gp2x. Or at least, nobody complained You're using the wiz_lib for sound, aren't you?

I removed lots of lines in the main loop of emu.c (emu_run() function) to improve speed for the Gp2x. I'm pretty sure that some of them were related to sound synchronization. Maybe you should check the original version of emu.c in gnuboy.

The sound is perfect for synchronization, it just there a static noise that is in it and it only some tones. Some are fine.
To just make sure for each sample are the bits shared between left and right, or is a full sample given for each channel?
For example do the left and right samples need to be in one 16 bit sample or two 16 bit samples?

[Pickle]

The gpsp interpolation is working now.

juanvvc: where in the source is the A button cycling the scaling?