Gens for linux with opengl support

[wah_wah_69]

I have to plead ignorance, as I'm not sure what the significance of the texture code is. Could I ask for an explanation?

Otherwise, I played with this build pretty extensively over the weekend, and it worked nicely. I didn't see any problems that I haven't seen in the Windows version of Gens, and this runs much faster than the non-OpenGL linux version in full screen. The only suggestion I have is to enable the vsync and screen stretch toggles to work in Open GL mode, if possible.

Check my previous posts , you'll see that I changed the way that the opengl render works.

Vsync and stretch dont't work in the plain SDL renderer , strecth in opengl is easier than in plain SDL , since we just need to expand the quad of the texture a bit , I thought about adding it but realised that the black bars aren't big enough to be considered annoying , also with pal games there's no need to strecth so we'd also have to take check if the rom loaded is pal.

[skunkworx]

I have to plead ignorance, as I'm not sure what the significance of the texture code is. Could I ask for an explanation?

Check my previous posts , you'll see that I changed the way that the opengl render works.

Yes, well, my igorance kind of stretches out to how OpenGL works in general. But that's okay, I'm sure a little web research would work wonders if I actually got my lazy butt in gear to do some of it.

Vsync and stretch dont't work in the plain SDL renderer , strecth in opengl is easier than in plain SDL , since we just need to expand the quad of the texture a bit , I thought about adding it but realised that the black bars aren't big enough to be considered annoying , also with pal games there's no need to strecth so we'd also have to take check if the rom loaded is pal.

That should just be a matter of seeing what mode the emulator itself is in, right? Gens does a good job of autodetecting what TV standard to run at, and if the user sets it to something besides Auto, then it's even easier to find out.

You're right, though, the black bars aren't too big of a distraction. I'm just kind of anal about keeping the right aspect ratio, and MAME has spoiled me on that front.

[wah_wah_69]

Here is a quick and dirty fix to get full stretch in opengl mode (it'll allways be on)
In g_sdldraw.c line 293 change:

Code: Select all

glTexCoord2f(0.0f, 0.0f);	// Upleft corner of thetexture
	glVertex2f(-1.0f, 1.0f);	// Upleft vertex of the quad


	glTexCoord2f(0.625, 0.0f);	// UpRight corner of the texture 0.625 == 256/320 ,0.625 == 512/640
	glVertex2f( 1, 1.0f);		// UpRight vertex of the quad		


	glTexCoord2f(0.625f, 0.9375f);	// DownRight corner of the texture  0.9375 == 256/240 .  0.9375 == 512/480
	glVertex2f( 1 , -1.0f);		// DownRight vertex of the quad


	glTexCoord2f(0.0f, 0.9375f);	// DownLeft corner of the first texture 
	glVertex2f(-1.0f,  -1.0f);	// DownLeft vertex of the quad

for

Code: Select all

glTexCoord2f(0.0f, (240 - VDP_Num_Vis_Lines)/240.0f/2);	// Upleft corner of thetexture
	glVertex2f(-1.0f, 1.0f);	// Upleft vertex of the quad


	glTexCoord2f(0.625, (240 - VDP_Num_Vis_Lines)/240.0f/2);	// UpRight corner of the texture 0.625 == 256/320 ,0.625 == 512/640
	glVertex2f( 1, 1.0f);		// UpRight vertex of the quad		


	glTexCoord2f(0.625f, 0.9375f-(240 - VDP_Num_Vis_Lines)/240.0f/2);	// DownRight corner of the texture  0.9375 == 256/240 .  0.9375 == 512/480
	glVertex2f( 1 , -1.0f);		// DownRight vertex of the quad


	glTexCoord2f(0.0f, 0.9375f-(240 - VDP_Num_Vis_Lines)/240.0f/2);	// DownLeft corner of the first texture 
	glVertex2f(-1.0f,  -1.0f);	// DownLeft vertex of the quad

Note this is just a quick and dirty way to enable fullstretch , use it until I get to integrate it properly , it will only work in opengl mode , for the sdl mode a soft stretch function will be needed.
I'll take a look about vsync...

[grenouille]

nice! thanks

[skunkworx]

Here is a quick and dirty fix to get full stretch in opengl mode (it'll allways be on)

Got it, and it's working for me too. Sweet! Thanks a bunch, your work is appreciated!

[wah_wah_69]

I've added proper handling of stretch this evening , I were about to roll a new tarball when I found a new bug (not related to the stretch feature ) to reproduce it select the opengl renderer then the sdl one and without changing the filter function go back to opengl again , it will draw in the screen with a wrong offset.

[skunkworx]

to reproduce it select the opengl renderer then the sdl one and without changing the filter function go back to opengl again , it will draw in the screen with a wrong offset.

I haven't been able to reproduce that. Is there a particular game you noticed this with? I've tried a couple of different OpenGL resolutions and SDL filter effects, and each time I switched renderers the screen reappeared the way it was supposed to.

[wah_wah_69]

Forgot to tell that to reproduce the error you need to stay in Normal filter mode.

Anyways shit happens: yesterday 2 consecutives blackouts (about 2 mins each one ,looked like some maintenience stuff, did something funny to my reiserfs partitition). I'm trying to fix it right now.

Fixed the bug , disabling dma allowed me to boot (the reiserfs driver was crashing with dma on , I just booted with an older kernel and then disabled DMA ) , cheked the news it was some power distribuition tower which caused the blackout.

get it here: http://www.telefonica.net/web2/wahwah69 ... ngl.tar.gz

[skunkworx]

Looks good. The stretch function works perfectly.

If you're looking for new features to add, how hard would it be to automatically stretch the screen horizontally when the game switches to the 256 horizontal resolution?

[wah_wah_69]

Here you have a quick & dirty solution again (Same line as before):

Code: Select all

glTexCoord2f(0.0f + (Dep == 64)? 0.0625f:0, stretch_size );	// Upleft corner of thetexture
		glVertex2f(-1.0f, 1.0f);	// Upleft vertex of the quad


		glTexCoord2f(0.625 - ((Dep == 64)? 0.0625f:0), stretch_size );// UpRight corner of the texture 0.625 == 256/320 ,0.625 == 512/640
		glVertex2f( 1, 1.0f);		// UpRight vertex of the quad		


		glTexCoord2f(0.625f - ((Dep == 64)? 0.0625f:0), 0.9375f - stretch_size );// DownRight corner of the texture  0.9375 == 256/240 .  0.9375 == 512/480
		glVertex2f( 1 , -1.0f);		// DownRight vertex of the quad


		glTexCoord2f(0.0f + (Dep == 64)? 0.0625f:0, 0.9375f - stretch_size );	// DownLeft corner of the first texture 
		glVertex2f(-1.0f,  -1.0f);	// DownLeft vertex of the quad

I have my doubts between enabling horizontal stretch by default (so it'll look like any any other game) or enabling it only in stretch mode.

Come to think of it , ¿how many games use this resolution? I just know 2 wonderboy and Megaman the willy wars (the konami intro in most of konami games is in this resolution as well).

By the way both games don't work correctly in gens they seem to use a custom saveram format.

As for Vsync , there's no other way to enable or disable vsync under opengl than using gl extensions the only extension I found seems to be windows only (It starts with the WGL prefix),and it's not supported by my card with linux drivers (haven't cared to check if it's supported in windows or not).

You can allways enable vsync in your driver settings (note it will limit the speed to your monitor vert refresh rate, so the F1->fastfordward will be limited).

Just noticed

Code: Select all

// DownRight corner of the texture  0.9375 == 256/240 .  0.9375 == 512/480  

is wrong it should be:

Code: Select all

// DownRight corner of the texture  0.9375 == 240/256 .  0.9375 == 480/512

[skunkworx]

I have my doubts between enabling horizontal stretch by default (so it'll look like any any other game) or enabling it only in stretch mode.

Come to think of it , ¿how many games use this resolution? I just know 2 wonderboy and Megaman the willy wars (the konami intro in most of konami games is in this resolution as well).

A lot of games go back and forth. Sonic the Hedgehog 2 switches to 256 for its special stages. Mortal Kombat 3 and Ultimate Mortal Kombat 3 use 256 for most of the title and options screens, though they switch back to 320 for the actual game. I believe I noticed that Teenage Mutant Ninja Turtles - Hyperstone Heist (a Konami game) uses 256 for just about everything.

I got the impression from these code patches that it wouldn't be easy to write something that could switch on the fly, at least not without rewriting some other part of Gens. I wanted to ask anyway, though.

As for Vsync , there's no other way to enable or disable vsync under opengl than using gl extensions...

You can allways enable vsync in your driver settings (note it will limit the speed to your monitor vert refresh rate, so the F1->fastfordward will be limited).

You mean in xorg.conf (or XF86Config)? I'll have to play with that.

Thanks again!

[uberpenguin]

Very nice job. A few observations:

In the rc3.2 tarball you forgot to define the function prototype for void vsync() in g_sdldraw.h, so gcc will die when you try to compile it (not that vsync() actually DOES anything right now )

Additionally, do you think there is any way you can eliminate the black line rendering glitch with the old code? I am using gens on a laptop with radeon + DRI + 16 MiB video RAM and I cannot adjust any AGP aperture in the BIOS settings... So obviously I can only use the normal size rendering scheme with the new texture code, but having the different rendering engines is very nice...

-uberpenguin

[wah_wah_69]

I got the impression from these code patches that it wouldn't be easy to write something that could switch on the fly, at least not without rewriting some other part of Gens. I wanted to ask anyway, though.

Not really what's it's difficult is doing it and don't mess the code , the more features you add the harder to mantain clean the code will be.
I post those quickfixes because I prefer to think a bit about what I'm adding to gens rather than include whatever I might think is ok at the moment.

Quickfix:

Code: Select all

glBegin(GL_QUADS);			

		glTexCoord2f(0.0f + Stretch?(Dep * 0.0625f/64.0):0 , stretch_size );	// Upleft corner of thetexture
		glVertex2f(-1.0f, 1.0f);	// Upleft vertex of the quad


		glTexCoord2f(0.625 - (Stretch?(Dep * 0.0625f/64.0):0), stretch_size );// UpRight corner of the texture 0.625 == 256/320 ,0.625 == 512/640
		glVertex2f( 1, 1.0f);		// UpRight vertex of the quad		


		glTexCoord2f(0.625f - (Stretch?(Dep * 0.0625f/64.0):0), 0.9375f - stretch_size );// DownRight corner of the texture  0.9375 == 256/240 .  0.9375 == 512/480
		glVertex2f( 1 , -1.0f);		// DownRight vertex of the quad


		glTexCoord2f(0.0f + Stretch?(Dep * 0.0625f/64.0):0, 0.9375f - stretch_size );	// DownLeft corner of the first texture 
		glVertex2f(-1.0f,  -1.0f);	// DownLeft vertex of the quad
	
	glEnd();

With this code if the *Stretch* option is selected in 256*224 mode(hyperstone heist , wonderboy , megaman) it'll do both V and H stretch , in 320*224(most of the megadrive game library) it'll do V stretch and in games in 320*240(pal version of story of thor) it' ll do nothing because it's not needed.

I have a GeForce2 MX 400 based card , I use nvidia-settings to enable/disable the "Sync to Vblank" option.

In the rc3.2 tarball you forgot to define the function prototype for void vsync() in g_sdldraw.h, so gcc will die when you try to compile it (not that vsync() actually DOES anything right now Smile )

Additionally, do you think there is any way you can eliminate the black line rendering glitch with the old code? I am using gens on a laptop with radeon + DRI + 16 MiB video RAM and I cannot adjust any AGP aperture in the BIOS settings... So obviously I can only use the normal size rendering scheme with the new texture code, but having the different rendering engines is very nice...

About the vsync : I played a bit with it but as I found that there's no way to enable vsync I dropped the idea , forgot to comment the code , my gcc version (3.3.2 20031218 ) just gave me a warning that I failed to see , cflags troubles ,sorry.


About the older ode there's no black line It's just a sligthly darker line between both textures and is noticeable only with filtering on (would you have realized of it existence if I didn't have warned about it? , I thougt about leaving it "as is" but realized that once you know it existance you'll be looking for it and distracting from the game).

Solutions ? : I found 2 , texture compression (if the problem is shortage of video ram , the problem could also be your opengl implementation limitating the max. texture size to 512) it's possible with an opengl extension, and just use non power of two textures via the GL_ARB_TEXTURE_RECTANGLE (the name is wrong a 256 * 16 texture will be rectangle shaped and doesn't need said extension ).

As both solutions need the use of opengl extensions and I don't know much about it'll take some time (I'm checking http://developer.nvidia.com/object/open ... orial.html).

[uberpenguin]

About the older ode there's no black line It's just a sligthly darker line between both textures and is noticeable only with filtering on (would you have realized of it existence if I didn't have warned about it? , I thougt about leaving it "as is" but realized that once you know it existance you'll be looking for it and distracting from the game).

No, it's quite noticible at resolutions at and above 640x480 and full screen... Of course you are right that it cannot be seen at normal resolution, but it's pretty difficult to play any game without filtering on a 1024x768 LCD...

Solutions ? : I found 2 , texture compression (if the problem is shortage of video ram , the problem could also be your opengl implementation limitating the max. texture size to 512)

Hmm... Could be, though if the textures are really the size you said they are with the new code, they would not be able to fit in my 16 MiB video RAM.

-uberpenguin

[skunkworx]

I got the impression from these code patches that it wouldn't be easy to write something that could switch on the fly...

Not really what's it's difficult is doing it and don't mess the code , the more features you add the harder to mantain clean the code will be.
I post those quickfixes because I prefer to think a bit about what I'm adding to gens rather than include whatever I might think is ok at the moment.

I understand. I've worked in software development myself, and I know it's never a good idea to just blindly commit new changes without having a good idea of how they might affect things. I'm happy to use these little fixes in the meantime.

The horizontal stretching works perfectly, as far as I can tell. Now games like Sonic the Hedgehog 2 look exactly they way they do on the Genesis, only without all the annoying ghosting and noise that comes with using a TV connection. Thanks!

[wah_wah_69]

I've added support for non power of two textures reducing the use of video memory grab it in: http://www.telefonica.net/web2/wahwah69 ... ngl.tar.gz

Note: latest nvidia Gl headers (those from 6629) doesnt't include the definition needed for the used gl extension (GL_TEXTURE_RECTANGLE_ARB) for a work around change every appearance of GL_TEXTURE_RECTANGLE_ARB to GL_TEXTURE_RECTANGLE_EXT which is defined in the glext.h header file with the same value as GL_TEXTURE_RECTANGLE_ARB.

I have not ati drivers' glext.h can anyone with said drivers post the output of:

Code: Select all

cat /usr/include/GL/glext.h |grep -i texture_rectangle

?

[uberpenguin]

Code: Select all

$ cat /usr/include/GL/glext.h | grep -i texture_rectangle
#ifndef GL_ARB_texture_rectangle
#define GL_TEXTURE_RECTANGLE_ARB          0x84F5
#define GL_PROXY_TEXTURE_RECTANGLE_ARB    0x84F7
#ifndef GL_NV_texture_rectangle
#define GL_TEXTURE_RECTANGLE_NV           0x84F5
#define GL_PROXY_TEXTURE_RECTANGLE_NV     0x84F7
#define GL_OFFSET_TEXTURE_RECTANGLE_NV    0x864C
#define GL_OFFSET_TEXTURE_RECTANGLE_SCALE_NV 0x864D
#define GL_DOT_PRODUCT_TEXTURE_RECTANGLE_NV 0x864E
#define GL_OFFSET_PROJECTIVE_TEXTURE_RECTANGLE_NV 0x8852
#define GL_OFFSET_PROJECTIVE_TEXTURE_RECTANGLE_SCALE_NV 0x8853
#define GL_OFFSET_HILO_TEXTURE_RECTANGLE_NV 0x8855
#define GL_OFFSET_HILO_PROJECTIVE_TEXTURE_RECTANGLE_NV 0x8857
#ifndef GL_ARB_texture_rectangle
#define GL_ARB_texture_rectangle 1
#ifndef GL_NV_texture_rectangle
#define GL_NV_texture_rectangle 1

Of course, I'm not using ATI's proprietary drivers (no support for radeon mobility M6), just the xorg/DRI ones.

-uberpenguin

[uberpenguin]

Okay, got your rc3.3 tarball and it works perfectly with filters turned on! Thanks a million! Sound seems to be a bit more finnicky than normal (but it always has been)... Maybe while I'm on break I'll look into that issue.

Again, thanks for your work!

-uberpenguin

[spider312]

i'm using ATI proprietary (3.14.6) on my Radeon Mobility M10 (~9600):

Code: Select all

prosper spider # cat /usr/include/GL/glext.h |grep -i texture_rectangle
#ifndef GL_NV_texture_rectangle
#define GL_TEXTURE_RECTANGLE_NV           0x84F5
#define GL_PROXY_TEXTURE_RECTANGLE_NV     0x84F7
#define GL_OFFSET_TEXTURE_RECTANGLE_NV    0x864C
#define GL_OFFSET_TEXTURE_RECTANGLE_SCALE_NV 0x864D
#define GL_DOT_PRODUCT_TEXTURE_RECTANGLE_NV 0x864E
#define GL_OFFSET_PROJECTIVE_TEXTURE_RECTANGLE_NV 0x8852
#define GL_OFFSET_PROJECTIVE_TEXTURE_RECTANGLE_SCALE_NV 0x8853
#define GL_OFFSET_HILO_TEXTURE_RECTANGLE_NV 0x8855
#define GL_OFFSET_HILO_PROJECTIVE_TEXTURE_RECTANGLE_NV 0x8857
#ifndef GL_NV_texture_rectangle
#define GL_NV_texture_rectangle 1

[Matheus Villela]

yabdeo
Gens for Linux maintainer

Didn't noticed, what small world

----

wah_wah_69 i have a problem here, maybe if you have time you can help me?

Two days ago i did an opengl implementation for tupines( http://sourceforge.net/projects/tupines/ ), a NES emulator of a friend, but i'm with problems with the texture size, i've tryied to use the "normal" NES resolution( 256X240 ) for the sdl surface/texture with no luck, only works if i set 256x256 and i don't know why (i'm not an opengl expert). I'm thinking is something with ogl standards for textures but i'm not sure. It looks ugly with 14 pixels more in the window

Well, if you have time to help me to solve this issue please take a look at the source code - look in sdl/graph.c, for reference the "older" SDL software-only code is in sdl/graph.back.c

[mushroom blue]

so, why doesn't the game play in the same window as the toolbar? is it simply just a matter of not knowing how to embed one screen into another?

[wah_wah_69]

so, why doesn't the game play in the same window as the toolbar? is it simply just a matter of not knowing how to embed one screen into another?

It can be done (at least in plain sdl mode) but it's a hack, yabuse ( http://yabause.sourceforge.net/ ) makes use of said hack, it looks nice and all but you won' t be able to use the gui while in fullscreen.

The integration of sdl and gtk it's something that has been discused few times in the sdl mailing list , I don't know exactly if it's a matter of modifying gtk , sdl , or both.

A good solution would be a custom gui a la zsnes.

[Headrush]

In the regular gens-2.12a source I could edit the Makefile to disable the gtk frontend.
Can this be done in the opengl version?
I don't see the same CFLAGS sections for me to make the change in the source.

[FormerSlacker]

For you bios file : you must specify where they are :
Options->Bios/Misc Files->Change
There is also an howto here : http://yabdeo.free.fr/howto.png

lol! That's the *best* howto, ever!

[CrazyTerabyte]

I have three wishes in this message:

1. I feel Gens need a little fixes in GTK dialogs. See these two screenshots:

http://denilsonsa.hn.org/~denilson/Gens_Dialog1.png
http://denilsonsa.hn.org/~denilson/Gens_Dialog2.png

I have no idea about why this happens. My simple suggestion is to make them resizeable.

2. I would like a keyboard shortcut for quit. Maybe Ctrl+Q.

3. Even if Gens for Linux cannot boot real (hardware) CDs, I would like to "enter" in SegaCD/MegaCD bios (IOW, boot it without CD), to allow me initialize the "RAM cartridge". I'm not sure if SegaCD/MegaCD games work in Gens for Linux (loading from a image file on hard disk), but I would like to try.

http://denilsonsa.hn.org/~denilson/Gens_SonicCD.png

P.S.: If someone wanna know what window manager I am using... I'm using fluxbox, with "Windows 3.x" theme.