Pickle
Mega GP Mania
juanvvc said:
I will take a look today. Doesnt the fullscreen/aspect modes use the gp2x hardware scaler?
Last edited by a moderator:
Lemonboy2X Updated
- Thread starter EvilDragon
- Start date
I will take a look today. Doesnt the fullscreen/aspect modes use the gp2x hardware scaler?
NEIL L
Member
juanvvc said:Neil L said:
Color/GBA modes makes sense, since it seems that some games have differences when running on a GBA. For example, Oracle of seasons. SGB is usable in some games (Donkey Kong Land) and even if it cannot be used to play, it is certainly useful to get lots of personalized borders (SGB1 and SGB2 have different border, for example, in Tetris). Furthermore, fixing SGB shouldn't be as painful as fixing soundMost of the code is there, but there is a problem with the sprite palette: I can't understand who creates this palette, and then it is empty at the moment. Anyway, there is a switch in the Makefile to compile Lemonboy without SGB support.
On the subject of palettes & different systems, this got me thinking, could this function be added (as on the original hardware)? (This was sort of copied from Wikipedia!)
When playing an original Game Boy game on a colour system, the user can choose which color palette is used. This is achieved by pressing certain button combinations, namely either A or B (or neither) and a direction key while the Game Boy logo is displayed on the screen.
Key combination / Palette (Could all these palette colours be added to the palettes folder also, so they match the original GBC palettes?)
Up / Brown
Up + A / Red
Up + B / Dark brown
Down / Pastel mix
Down + A / Orange
Down + B / Yellow
Left / Blue
Left + A / Dark blue
Left + B / Grayscale
Right / Green
Right + A / Dark green
Right + B / Inverted
These palettes each contain up to ten colors. In most games, the four shades displayed on the original Game Boy would translate to different subsets of this 10-color palette, such as by displaying movable sprites in one subset and backgrounds, etc. in another. The grayscale (Left + B ) palette produces an appearance essentially identical to that experienced on the original Game Boy.
In addition, most Game Boy games published by Nintendo have a special palette that is enabled when no buttons are pressed. Any game that does not have a special palette will default to the dark green (Right + A) palette. Notable games that do have preset palettes are Metroid II: Return of Samus, Kirby's Dream Land 2, Super Mario Land, Tetris and the Wario Land series.
Super Game Boy titles will work too. Despite compatibility with Super Game Boy titles, the Game Boy Color will not recognize the coloring header for Super Game Boy titles which have a color graphics system of its own.
At the moment all the B&W games start in B&W when set to the 'Gameboy Colour' option. (Instead of the 'special palette' as mentioned above)
If this could be done (even if it's with a pretend 'Game Boy logo' screen at the start of the games when you can enter the button presses to change the palette)
If this can be fixed could the B&W Gameboy be added to the options? So B&W games stay B&W on the GB setting, but colour on the GBC setting. (If colour palettes are supported by the game!)
Seperate settings for GB/GBC/GBA/SGB/SGB2 would also be nice. (eg. So different frames/screen sizes etc. can be used for different emulated hardware, hopefully SGB & SGB2 will be fixed soon)
A confirmation on the load option would be good also. (As it's only on the save option at the moment)
Cheers, Neil
Last edited by a moderator:
Pickle
Mega GP Mania
I put up my test version for interpolation. I know the double mode is slow, it can still be faster by removing some wasted lines in the scaler, its just taking me some time to learn enough ARM to get it to work. Im more looking for opinions on how it looks. Basically the screen is 2nd pass of the scaling code by notaz. It just about fits except for an extra 12 lines. What ive done is removed 2 lines at the top and 2 at the bottom. Then removed 8 lines (4 each) from the top and the bottom.
pickle.gp2x.de\lemonboy-wiz.zip
pickle.gp2x.de\lemonboy-wiz.zip
chickendung
TO THE TRENTON TAR PITS!
Pickle said:
Hmm...when I copy that link into my address bar, it says the page could not be found. When I manually type it in, I get a zip with the .gpe alone. I loaded it up, but it does not feature double interpolation, and the tearing is not fixed. Old version?
Last edited by a moderator:
Pickle
Mega GP Mania
chickendung said:
opps try pickle.gp2x.de/lemonboy2x-wiz.zip
Last edited by a moderator:
Rivroner
Well-Known Member
- Joined
- Jun 4, 2006
- Messages
- 1,106
I have tried the double interpolation option and at 750 mhz every game plays fullspeed, audio now is not as good as you previous release but is good enough.
I have tried fulscrreen aspect ratio option in Juanvcc Lemonboy and is very good as well, may be you two could make an only lemonboy launcher.
Pickle, do you think is posible to rotate screen?
Tearing is now almost hidden at all but it is still there.
Thansk for the good job and sorry for my bad english.
I have tried fulscrreen aspect ratio option in Juanvcc Lemonboy and is very good as well, may be you two could make an only lemonboy launcher.
Pickle, do you think is posible to rotate screen?
Tearing is now almost hidden at all but it is still there.
Thansk for the good job and sorry for my bad english.
Pickle
Mega GP Mania
Rivroner said:I have tried the double interpolation option and at 750 mhz every game plays fullspeed, audio now is not as good as you previous release but is good enough.
I have tried fulscrreen aspect ratio option in Juanvcc Lemonboy and is very good as well, may be you two could make an only lemonboy launcher.
Pickle, do you think is posible to rotate screen?
Tearing is now almost hidden at all but it is still there.
Thansk for the good job and sorry for my bad english.
Yeah audio is worse in the interpolation mode since it takes more process time, theres still saving that can be made in the interpolation routine. Just have had time to try it.
Is fulscrreen aspect ratio by Juanvcc scaling?
What do you mean by an only lemonboy launcher?
I set a flag in wizlib to set the screen to 240x320, but it doesnt seem to change anything. I think theres more to "rotate the screen" than just rotate the screen.
Last edited by a moderator:
crow_riot said:
I personally find this solution very interesting. Everybody talks about using OpenGL to get rid of the tearing and you're AFAIK the first one who has a working proof of concept:
http://www.gp32x.de/board/index.php?/topic/50478-opengl-es-engine/
I presume that an implementation in an existing emulator is not that easy?
Last edited by a moderator:
Pickle said:
Yup. The last version that I posted (http://www.gp32spain.com/foros/showpost.php?p=1002939&postcount=96, it includes source code) has a video mode that is pretty similar to hardware fullscreen on Gp2x.
Code: the main idea is multiplying the original size by 5/3 by grouping items in groups of three (abc) and then doubling the first and second item (aabbc) In "full screen aspect ratio" mode, items are both pixels and lines. In "real fullscreen", items are only lines and pixels are just doubled (aabbcc). I was not worried about speed since it was only a "prove of concept". Fortunately, users say that this mode works at 400MHz pretty well, but I'm sure that it can be faster.
Code:
/* new function just after scaleline2x */
void scaleline53x(void *dst, void *src, int width, int offset){
byte *t=tmpline+offset*fb.pelsize;
int tmpx, pixel1, pixel2;
tmpx=width+3;
while((tmpx-=3)>0){
MEMCPY(t, src, fb.pelsize);
MEMCPY(t+fb.pelsize, src, fb.pelsize);
t+=2*fb.pelsize;
src+=fb.pelsize;
MEMCPY(t, src, fb.pelsize);
MEMCPY(t+fb.pelsize, src, fb.pelsize);
t+=2*fb.pelsize;
src+=fb.pelsize;
MEMCPY(t, src, fb.pelsize);
t+=fb.pelsize;
src+=fb.pelsize;
}
//MEMCPY(dst, tmpline, 320*fb.pelsize);
MEMCPY(dst+offset*fb.pelsize, tmpline+offset*fb.pelsize, width*fb.pelsize*5/3+1);
}
/* switch() inside vid_init */
case vmode_fsasp://fullscreen, aspect ratio
fb.offset=0; fps_x=14; fps_y=0;
break;
case vmode_fs: // fullscreen
fb.offset=0; fps_x=fps_y=0;
break;
/* switch() inside vid_begin */
case vmode_fsasp:
tempy=144+3;
fs=fakescreen;
s=(void *)fb1_16bit;
while(tempy-=3){
scaleline53x(s, fs, 160, 27);
s+=320*fb.pelsize;
MEMCPY(s, s-320*fb.pelsize, 320*fb.pelsize);
s+=320*fb.pelsize;
fs+=fb.pitch;
scaleline53x(s, fs, 160, 27);
s+=320*fb.pelsize;
MEMCPY(s, s-320*fb.pelsize, 320*fb.pelsize);
s+=320*fb.pelsize;
fs+=fb.pitch;
scaleline53x(s, fs, 160, 27);
s+=320*fb.pelsize;
fs+=fb.pitch;
}
break;
case vmode_fs:
tempy=144+3;
fs=fakescreen;
s=(void *)fb1_16bit;
while(tempy-=3){
scaleline2x(s, fs);
s+=320*fb.pelsize;
MEMCPY(s, s-320*fb.pelsize, 320*fb.pelsize);
s+=320*fb.pelsize;
fs+=fb.pitch;
scaleline2x(s, fs);
s+=320*fb.pelsize;
MEMCPY(s, s-320*fb.pelsize, 320*fb.pelsize);
s+=320*fb.pelsize;
fs+=fb.pitch;
scaleline2x(s, fs);
s+=320*fb.pelsize;
fs+=fb.pitch;
}
break;
Last edited by a moderator:
sbock said:
i dont know what the emulators are using, what they use for drawing. if they use SDL or just directly draw into the framebuffer. i think i could hack a little utility to provide a virtual framebuffer that is actually an opengl texture buffer and this texture is then drawn the correct way. i don't have a clue about performance impact by 'uploading' a texture every frame, but it could be significant... but if there is someone interested in coop, i'd be in
Last edited by a moderator:
crow_riot said:
In the particular case of lemonboy (and I'm sure that it is the same in other emulators), it uses direct access to the framebuffer. Anyway, it should be really easy to use a virtual framebuffer and then apply your idea. Since performance is not really an issue for a gameboy emulator, it seems that it shouldn't be that difficult to introduce OpenGL rendering.
But I honestly have no idea on where to start and I don't have a Wiz to perform tests. If you can show us some code that given a 320x240 RGB-16bits texture, it is rotated and shown on a 240x320 screen using OpenGL, we can try your way
Last edited by a moderator:
Pickle
Mega GP Mania
juanvvc said:crow_riot said:
In the particular case of lemonboy (and I'm sure that it is the same in other emulators), it uses direct access to the framebuffer. Anyway, it should be really easy to use a virtual framebuffer and then apply your idea. Since performance is not really an issue for a gameboy emulator, it seems that it shouldn't be that difficult to introduce OpenGL rendering.
But I honestly have no idea on where to start and I don't have a Wiz to perform tests. If you can show us some code that given a 320x240 RGB-16bits texture, it is rotated and shown on a 240x320 screen using OpenGL, we can try your way
I can do tests on the wiz.
I have a good annoucement, lemonboy source is now hosted on sourceforge. No longer should there be multiple versions of source. Contact me for write access.
http://sourceforge.net/projects/lemonboy/
Its currently using svn for source control. Developers can contact me for write access.
Last edited by a moderator:
Pickle said:juanvvc said:crow_riot said:
In the particular case of lemonboy (and I'm sure that it is the same in other emulators), it uses direct access to the framebuffer. Anyway, it should be really easy to use a virtual framebuffer and then apply your idea. Since performance is not really an issue for a gameboy emulator, it seems that it shouldn't be that difficult to introduce OpenGL rendering.
But I honestly have no idea on where to start and I don't have a Wiz to perform tests. If you can show us some code that given a 320x240 RGB-16bits texture, it is rotated and shown on a 240x320 screen using OpenGL, we can try your way
I can do tests on the wiz.
I have a good annoucement, lemonboy source is now hosted on sourceforge. No longer should there be multiple versions of source. Contact me for write access.
http://sourceforge.net/projects/lemonboy/
Its currently using svn for source control. Developers can contact me for write access.
i just downloaded source from the archive and looked at it for a few minutes. i'll think the easiest way for me is to hack something together like libcastor with sample code how to use. it's not a big thing, so it should be done in the next few days. the idea is: create a 320x240x16bit pixelbuffer as virtual framebuffer, draw into that. then use glTexSubImage2D to update an 512x256-sized opengl texture. and use either a fullscreen quad (2 triangles) or the glDrawTex extension with correct texcoords to display the subpart only. no magic about that, straight forward.
Last edited by a moderator:
Pickle
Mega GP Mania
crow_riot said:i just downloaded source from the archive and looked at it for a few minutes. i'll think the easiest way for me is to hack something together like libcastor with sample code how to use. it's not a big thing, so it should be done in the next few days. the idea is: create a 320x240x16bit pixelbuffer as virtual framebuffer, draw into that. then use glTexSubImage2D to update an 512x256-sized opengl texture. and use either a fullscreen quad (2 triangles) or the glDrawTex extension with correct texcoords to display the subpart only. no magic about that, straight forward.
sounds good
New beta version pickle.gp2x.de/lemonboy2x-wiz.zip
I merged in juanvvc fullscreen/aspect video modes. They look good and are decently fast.
Last edited by a moderator:
TitanUranus
Active Member
That looks really good, and the speed is great too. Can (and will)this be applied to other emulators?
chickendung
TO THE TRENTON TAR PITS!
Fullscreen implementation is nice, but I still believe Scale2x deformed is the best option, which is perfect as it is. However, may I dare to mention the sound delay again? It seems to be mocking me...
It seems to be mocking me...
Pickle
Mega GP Mania
chickendung said:Fullscreen implementation is nice, but I still believe Scale2x deformed is the best option, which is perfect as it is. However, may I dare to mention the sound delay again?
well there a video mode for everyone, i also like the scale2x deformed.
And everyone knows about the delay you can keep mentioning it but it doesnt make anything happen any faster.
Its quite simple if I make the sample size 2048 theres a bit of static, if i make 4096 no static with a delay. Personally im happy with where the sound is at the moment since previously it sucked so bad it was painful to play the emu at all.
Last edited by a moderator:
chickendung
TO THE TRENTON TAR PITS!
I'm not going to spill ALL the beans, but I do know that we will be seeing a completely separate Game Boy emulator with no tearing whatsoever, and no sound delay. Think of it as a holiday present from a certain developer...Expect something to appear before Christmas.
