Gnuboy 1.0.3


I think the original problem may be that the existing code might be clipping the sound data at 8 bits.
Unfortunately, at the moment I'm preparing the next teaching season and I've literally no time for this :(

Anyway, keep in mind that Color and Old gameboy use different frequency tables in sound.c, so be sure of testing the sound in both systems. Besides, if you included the preliminary SuperGB support maybe you noticed an "#ifndef DEBUG" in supergb.c that MUST be "#ifdef DEBUG" (lines 407 and 435 of supergb.c) . That section saves the current palette in a file for debugging, and the final version SHOULDN'T do this. Anyway, since SuperGB palettes are not working right for most games, I still advice against including SuperGB support as is :(

One additional thing: you can change the about image to put your name instead of mine, of course. Please, keep the name of the graphs artist Madcore. Add your name to the CREDITS file, also. Use this clean about image to add names: http://lewis.upc.es/~juanvi/about-clean.png
 
Last edited by a moderator:
Some good news, SDL sound was creating some instability but I just got the wiz_lib to stream the data like minimal lib. The sound is still a little noisy, so I will do some checks to see I setup it all up right.
At least no stupid crashes.
 
OK time to have at it!

pickle.gp2x.de/lemonboy-wiz.zip

Let me know what you think, ive been pluggin at this thing for while and like to know from you following this what you think of it.
Of cource we would like to add scaling and maybe I will. Other than that fire away. (Opinions on the sound?)
 
Thanks for the great work.

If you are going to add the scaling you may want to look at or ask Notaz for the routeen in GPSP. It has some kind of smoothing and for Gameboy it would need it or it would look pretty ugly.

The sound? Noise comes out and corresponds to the game but it is extremely staticy and distorted, almost like the speakers are blown. I think that could use some improvement.
 
Last edited by a moderator:
Thanks for your work, Pickle. Is it possible to get the source code or your modifications to introduce your improvements in my version?

Thanks again. I notice that you do not claim recognition for your work in the about box. And you obviously deserves that recognition :)
 
Thanks for your work, Pickle. Is it possible to get the source code or your modifications to introduce your improvements in my version?
Thanks again. I notice that you do not claim recognition for your work in the about box. And you obviously deserves that recognition :)


Sure, i want to get the changes into your version so they dont get lost and also when you finish other changes you make the wiz version will be ready to go.
I may need to go through everything again and cleanup the changes I really need from those I dont.
 
Last edited by a moderator:
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.
 
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?
 
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.
 
Last edited by a moderator:
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!

QUOTE
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.

QUOTE
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 :)
 
Last edited by a moderator:
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 :D

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!
 
Last edited by a moderator:
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
 
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.
 
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?

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.
 
Last edited by a moderator:
Back
Top