Yabause

Originally posted by CyberWarriorX@Tue, 2005-09-13 @ 07:39 AM

I can already dump it with my current tools, I just need the physical cart to dump :)

Cyber Warrior X

[post=139567]Quoted post[/post]​


I know :D , but the person who owns such a cart might not have the tools and/or an AR + CommsLink. So alternatively, this person does not send the cart for dumping to you, but dumps on his own and sends the dump via e-mail.
 
Hey guys,

I just got my linux dev system up and running and I compiled some of the samples. Unfortunately Yabause isn't working...something about glut errors.

So I hit the CVS and downloaded the newest code, which is not compiling. It's hanging in yabause.c, complaining about the function "YabSetError".

I didn't take a look at the code but it looks like something minor. How do I submit patches back to the CVS?

I commented out all references to YabSetError(). Code compiles now, but I still get the following error: freeglut ERROR: Function <glutBitmapCharacter> called without first calling 'glutInit'.

Definitely something to do with OpenGL. :damn:
 
So I hit the CVS and downloaded the newest code, which is not compiling. It's hanging in yabause.c, complaining about the function "YabSetError".

Guill commited a fix for that problem. I imagine it's already on public cvs.

I didn't take a look at the code but it looks like something minor. How do I submit patches back to the CVS?

Normally for non-developers you make a diff file and send it to one of us(Guill, BlueCrab, joostp, myself, etc.) and then we'll commit it. You can use yabause's sourceforge script for doing it as well:

http://sourceforge.net/tracker/?group_id=89991&atid=592128

I commented out all references to YabSetError(). Code compiles now, but I still get the following error: freeglut ERROR: Function <glutBitmapCharacter> called without first calling 'glutInit'.

Hmm.. Have you tried using another version of glut? I seem to recall freeglut was problematic.

Cyber Warrior X
 
What distribution are you using slinga? And what is your glut version?

I got Yabause running on my two linux boxes:

- Fedora Core 4 on Athlon 32 bits with freeglut 2.2.0

- Ubuntu Horay Hedgehog on Athlon 64 bits with freeglut 2.2.0
 
I'm using SUSE 10.0 RC 1. Freeglut version 2.4-04. I think the problem is most likely I don't have openGL support installed properly.
 
Downgrading to freeglut 2.2.0 fixed my problem.

I grabbed the newest source from the CVS and it doesn't compile because of errors in yabause.c. Some regular ascii text is in the code instead of being commented out. I removed it and it works now.

Edit: Submitted updated yabuase.c file to sourceforge, someone take a look when you get a chance, shouldn't take more than 15 seconds.
 
We merged the "yabauserewrite" branch with the main one, so you don't have to specify "-r yabauserewrite" anymore. It may be related to your compilation problem.
 
Off topic, but do you guys plan to implement binary support on Yabause like Satourne had? Not a big deal as converting from binary -> iso is fairly easy. Just curious, thanks in advance.
 
Off topic, but do you guys plan to implement binary support on Yabause like Satourne had? Not a big deal as converting from binary -> iso is fairly easy. Just curious, thanks in advance.

Heh, the funny thing about that is, I was just working on bin/cue support this weekend and I finally commited it last night :) What irony. It's on the main branch of cvs in case you want to check it out. Oh yeah, in order to use it, just use the same command-line option as iso's, but specify a cue file instead.

Cyber Warrior X
 
Thanks CWX, but I guess I wasn't being clear. I mean binaries as in sl.bin, your compiled code. Not a CD cue binary. Satourne had a feature where you could load a binary to a specified address in memory and run it.

Thanks anyway, and again it's not a big deal as converting from sl.bin -> sl.iso is easy enough.
 
Ah ok. That's been actually there for like the last year or so. It's just some of us laz-err busy coders haven't added an interface for it to their respective ports. ;)

Cyber Warrior X
 
I compiled today's CVS and get this error when launching the progam:

Code:
Couldn't set GL mode: Couldn't find matching GLX visual

Cannot initialize VDP1

Error running Yabause

Segmentation fault

I am using :

Ubuntu Hoary

Xorg 6.8.2

Geforce 4 ti4200

NVIDIA 7676 drivers

GLX enabled (with direct rendering)

GTK 2.6

An older cvs used to work but that may have been on my old debian system.I'll try Yabause 0.0.7 and will see if that works.

Edit: 0.0.7 works fine
 
The only difference I can think of between the initialization of 0.0.7 and CVS is the SDL_RESIZABLE flag. Can you try to remove it in the ygl.c file? So the line with the call to SDL_SetVideoMode (line 107) should be:

Code:
if ( SDL_SetVideoMode( 320, 224, 32, SDL_OPENGL ) == NULL ) {

Change that, recompile and test it.
 
Originally posted by ExCyber@Wed, 2005-09-28 @ 11:48 PM

Does it still give you the error message about a GLX visual as well?

[post=140042]Quoted post[/post]​


Yes it does.

EDIT: Just tried compiling the new 0.5.0 release and I get the same problem.

EDIT2: Saw an error relating to aclocal-1.6 being missing, so I installed it.Also saw mention of the --with-gtk option needing to be specified, so I did.Also removed --prefix=/usr ,which shouldn't cause problems but who knows?

It works now :)

I'll post again when I find the exact reason, and maybe some compatibility reports if I get around to it :)

EDIT 3 : hahaha, another edit for you :)

My window manager is Ratpoison and whenever I switch to a different window, it immediatly segaults.

This doesn't happen with any other software so I assume it is not rapoison's fault.
 
As I've got a box with almost the same problem, I've done some tests too. Removing the

Code:
SDL_GL_SetAttribute( SDL_GL_ALPHA_SIZE, 4);

line in ygl.c solved the problem... and I still got transparency ! So I wondered if those SDL_GL_SetAttribute are needed at all and I removed them... and it still works the same (correct colors with transparency and double buffering). Strange...

About the ratpoison problem, I'm almost sure it comes from gtk, some friend got the same bug with gnome (or KDE I can't remember) when using the gtk interface. Btw, that's one of the reason why it's not used by default.
 
Thanks, that fixed it.

Feels a hell of a lot faster too. :thumbs-up:

Running from the commandline is a preference of mine in any case ( and the gui is obviously in its early stages)
 
Back
Top