You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(7) |
Dec
(17) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(11) |
Feb
(17) |
Mar
(13) |
Apr
(19) |
May
(10) |
Jun
(8) |
Jul
(13) |
Aug
(16) |
Sep
(4) |
Oct
(3) |
Nov
(12) |
Dec
(3) |
2003 |
Jan
(16) |
Feb
(40) |
Mar
(9) |
Apr
|
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(4) |
Jun
(5) |
Jul
(2) |
Aug
(1) |
Sep
(6) |
Oct
(15) |
Nov
(8) |
Dec
(4) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: kevin f. <kev...@ya...> - 2009-08-17 13:51:10
|
Excuse me, but i have a situation about the ZSNESW program. everything works great and all but i dont not know how to work the controls config. so i can actually play the game. if you could help that would be great. |
From: <arr...@ra...> - 2004-12-30 01:46:37
|
If I want to best approximate the aspect ratio of a real SNES, do I want to use a square pixel mode, or do I want to use a mode where 256x224 fills the screen and the pixels are non-square? Or something else in between? (Such as 256x224 filling the screen more than if the pixels were square, but not completely) Also, I'd like to suggest for the next time, allow a 512x448 Open GL mode. (It was just a few minutes to hack one in myself. Thank heavens for open source.) On my machine, if I want 256x224 filling the screen, 60 hz, and reasonable speed all at the same time, I have to use this mode. |
From: Pieter H. <phu...@xs...> - 2004-12-27 23:13:35
|
On Monday 27 December 2004 09:28, Pieter Hulshoff wrote: > I just downloaded the new 1.40 version, and it looks pretty good overall. > The only issue I've encountered sofar is that the full-screen settings > don't seem to be working properly for me anymore. zsnes 1.40 will take up > the full-screen, but show the game in only the middle section of it. zsnes > 1.36 has no problem with this at all (the game will take up the entire > screen). I'm running zsnes in 256x224 full screen mode. Any thoughts on > what might cause this, and how I could fix it? Ok, figured it out. It was a small fix I'd made for the 1.36 version a long time ago. In linux/sdllink.c, for cvidmode 1, the size in the code is set to 320x240 (Why? I have no idea...Anyone?). When I change it to 256x224 (which is what I think it should be) it works as 1.36 worked for me: fullscreen SNES games. :) Regards, Pieter Hulshoff |
From: Pieter H. <phu...@xs...> - 2004-12-27 08:28:54
|
Hello all, I just downloaded the new 1.40 version, and it looks pretty good overall. The only issue I've encountered sofar is that the full-screen settings don't seem to be working properly for me anymore. zsnes 1.40 will take up the full-screen, but show the game in only the middle section of it. zsnes 1.36 has no problem with this at all (the game will take up the entire screen). I'm running zsnes in 256x224 full screen mode. Any thoughts on what might cause this, and how I could fix it? Regards, Pieter Hulshoff |
From: elsbeth <ou...@ey...> - 2004-11-15 20:02:31
|
text part |
From: gabi l. <sic...@cy...> - 2004-11-12 04:36:13
|
text part |
From: sadella t. <uns...@es...> - 2004-11-10 16:03:52
|
text part |
From: lela c. <tr...@di...> - 2004-11-09 02:33:22
|
text part |
From: karolina <enc...@co...> - 2004-11-08 04:19:50
|
text part |
From: keriann <blu...@kp...> - 2004-11-06 03:14:05
|
text part |
From: elspeth <et...@la...> - 2004-11-02 23:00:44
|
text part |
From: karna <ste...@fa...> - 2004-10-31 15:09:43
|
text part |
From: Shawn <cul...@wa...> - 2004-10-27 23:14:23
|
Ben Ford wrote: > This useage is not correct. If it works, it is due to an undocumented > oddity in the glibc version you are using. It was at the time I wrote it, but it's been years since I wrote it :) And shockingly, this 'undocumented' oddity has worked all those years on several different Linux distributions. But, I digress. :) > From the man page (http://www.frech.ch/man/man3p/optopt.3p.html): > > If /getopt/() encounters an option character that is not > contained in > /optstring/, it shall return the question-mark ( *'?'* ) > character. If it > detects a missing option-argument, it shall return the colon > character > ( *':'* ) if the first character of /optstring/ was a colon, or a > question- > mark character ( *'?'* ) otherwise. In either case, /getopt/() > shall set > the variable /optopt/ to the option character that caused the > error. If > the application has not set the variable /opterr/ to 0 and > the first > character of /optstring/ is not a colon, /getopt/() shall also > print a > diagnostic message to /stderr/ in the format specified for the > /getopts/ > utility. > > This is the only mention of optopt. > > Try this patch: When I get a chance later this week, I'll try it out and let you know what works for me. Hey, if it fixes your problem and still works here, then I say go for it! Thanks for taking the time to further research the issue you were having. As far as the pascal style strings? Well, I just added command line option parsing, and I probably just did what others were doing in the Windows / DOS code :) Or, I was young and needed the money, whichever sounds more believeable :D Thanks, -Shawn |
From: Ben F. <be...@ka...> - 2004-10-27 22:54:35
|
Shawn wrote: >On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > > >>Ben Ford wrote: >> >> >> >>>I gave it a precursory lookover. It doesn't appear that the code to >>>load the rom is ever loaded. If I comment out the if(optopt == '?') >>>condition as shown below, it loads the game fine. It does exit with >>>an invalid pointer warning though. What is the question mark supposed >>>to mean, anyways? Should it be NULL instead? From the limited getopt >>>knowledge I have, I don't this is strictly necessary, as the >>>if(argv[optind] != NULL) should take care of that. >>> >>> >>Shawn, can you comment on this? >> >> > >Yep. Okay, I just finished testing, reading through the code, and >piecing together what I originally did. > >Here's the deal. Everything is working exactly like it's supposed to >here: > >The code checks for the user *explicitly* passing a '-?' option to zsnes >to determine whether or not to display the 'options help text'. If the >user doesn't *explicitly* pass any option, optopt is set to '?' (should >be anyway). Since optopt is set to '?', I know the user didn't pass any >options. > > This useage is not correct. If it works, it is due to an undocumented oddity in the glibc version you are using. From the man page (http://www.frech.ch/man/man3p/optopt.3p.html): If /getopt/() encounters an option character that is not contained in /optstring/, it shall return the question-mark ( *'?'* ) character. If it detects a missing option-argument, it shall return the colon character ( *':'* ) if the first character of /optstring/ was a colon, or a question- mark character ( *'?'* ) otherwise. In either case, /getopt/() shall set the variable /optopt/ to the option character that caused the error. If the application has not set the variable /opterr/ to 0 and the first character of /optstring/ is not a colon, /getopt/() shall also print a diagnostic message to /stderr/ in the format specified for the /getopts/ utility. This is the only mention of optopt. Try this patch: ben@pluto ~/Projects/zsnes/src/linux $ diff zloaderw.c* -u --- zloaderw.c 2003-10-22 20:10:08.000000000 -0700 +++ zloaderw.c.new 2004-10-27 15:32:30.000000000 -0700 @@ -336,15 +336,14 @@ } /* execute rom filename: file.x */ - if (optopt == '?') + /* getopt permutates argv until all non options are at the end of argv. */ + /* since we only expect one non option, it should be the last argument. */ + if ( optind == argc - 1 && argv[optind] != NULL) { - if (argv[optind] != NULL) - { - fvar=&fname; - fvar[0] = strlen(argv[optind]); - strncpy(&fvar[1], argv[optind],127); - makeextension(); - } + fvar=&fname; + fvar[0] = strlen(argv[optind]); + strncpy(&fvar[1], argv[optind],127); + makeextension(); } zstart(); (and off the subject, why use Pascal style strings?) -b |
From: Andrew R. <er...@ho...> - 2004-10-27 21:11:14
|
Hello, I'vew been using ZSNES for several years now. Last year I made the switch to Linux, RedHat 9, then Fedora Core 1. But anyway.... I've recently upgraded to Fedora Core 2 and have been having troulbe with zsnes ever since. By trouble, I mean, my P4 2GHz machine is having a horrible time running at full frame-rate even with sound quality at 22k, so on and so forth. I can't think of any reason as to why this should be a problem- other applications seem to be doing just fine and I have more than enough free resources. The only thing I can think of is the fact that I'm running in 32-bit color mode and ZSNES reports You are running in 32 bpp, but ZSNES is forcing 16 bpp. You may experience poor performance and/or crashing. However, this has never been a problem in the past. I beleive I did try switching to 16-bit color mode, which made Gnome freak out, but it didn't seem to help ZSNES any. If anyone has any suggestions or thoughts I'd be really interesting in hearing them. It may just be something defunct with FC2- I'll probably upgrade to FC3 when it is fully released, maybe that'll fix it. Thanks Andrew Reference info: Processor: Pentium 4: 2GHz Memory: 512MB standard 1GB swap OS: Fedora Core 2 Kernel: Linux 2.6.8-1.521 Graphics card: RIVA TNT2 ZSNES version: 1.36 _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
From: jasmin e. <biv...@df...> - 2004-10-27 15:26:44
|
text part |
From: marcella a. <ne...@gr...> - 2004-10-25 20:33:00
|
text part |
From: vikki e. <bra...@e-...> - 2004-10-18 17:59:42
|
text part |
From: Ben F. <be...@ka...> - 2004-10-12 19:06:54
|
Shawn wrote: >On Mon, 2004-10-11 at 12:27 -0700, Ben Ford wrote: > > >>This is Gentoo with glibc 2.3.4.20040808 >> >>My guess is that the interface has changed slightly. When I commented >>out the ? check, everything worked fine. It would load a ROM and it >>would also display the help text. >> >> > >Well, you'll have to live with doing that I guess for now. Because doing >what you've done breaks on other distributions (at least mine >anyway...), and since showing the help text while loading the ROM isn't >supposed to happen :) > > Err, poor wording on my part. It worked exactly as expected. When you passed a filename, it loaded, when you passed a ?, it displayed the help. >Are you sure freevo is passing legitimate options (i.e. all options are >valid)? > > Ignore the part about Freevo, I'm running it from the command line until the problem is solved. >When I'm feeling suicidal, I'll install Gentoo and try that if you can't >find something else :) > > When I've got a little time for debugging, I'll step thru it and see what the variables are and why that check is failing. -b |
From: Shawn <dr...@wa...> - 2004-10-12 14:32:18
|
On Mon, 2004-10-11 at 12:27 -0700, Ben Ford wrote: > This is Gentoo with glibc 2.3.4.20040808 > > My guess is that the interface has changed slightly. When I commented > out the ? check, everything worked fine. It would load a ROM and it > would also display the help text. Well, you'll have to live with doing that I guess for now. Because doing what you've done breaks on other distributions (at least mine anyway...), and since showing the help text while loading the ROM isn't supposed to happen :) Are you sure freevo is passing legitimate options (i.e. all options are valid)? When I'm feeling suicidal, I'll install Gentoo and try that if you can't find something else :) -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
From: Ben F. <be...@ka...> - 2004-10-11 19:26:46
|
Shawn wrote: >On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > > >>Ben Ford wrote: >> >> >> >>>I gave it a precursory lookover. It doesn't appear that the code to >>>load the rom is ever loaded. If I comment out the if(optopt == '?') >>>condition as shown below, it loads the game fine. It does exit with >>>an invalid pointer warning though. What is the question mark supposed >>>to mean, anyways? Should it be NULL instead? From the limited getopt >>>knowledge I have, I don't this is strictly necessary, as the >>>if(argv[optind] != NULL) should take care of that. >>> >>> >>Shawn, can you comment on this? >> >> > >Yep. Okay, I just finished testing, reading through the code, and >piecing together what I originally did. > >Here's the deal. Everything is working exactly like it's supposed to >here: > >The code checks for the user *explicitly* passing a '-?' option to zsnes >to determine whether or not to display the 'options help text'. If the >user doesn't *explicitly* pass any option, optopt is set to '?' (should >be anyway). Since optopt is set to '?', I know the user didn't pass any >options. > >Now that I know the user didn't pass any options, I attempt to get a >filename from the command line if they passed one in: > >If there is no filename, zsnes starts up normally and displays the file >menu. > >If there is a filename, zsnes starts up and executes the specified ROM >file. > >Now, I just tested this to make sure all of the above happens exactly >like it's supposed to, and it does. > >My guess is that the getopt implementation on your system is somehow >faulty, or is not behaving the same as the one I'm using. > >What Operating System and version of it are you using? > > > This is Gentoo with glibc 2.3.4.20040808 My guess is that the interface has changed slightly. When I commented out the ? check, everything worked fine. It would load a ROM and it would also display the help text. -b |
From: Shawn <dr...@wa...> - 2004-10-08 00:40:53
|
On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > Ben Ford wrote: > > > I gave it a precursory lookover. It doesn't appear that the code to > > load the rom is ever loaded. If I comment out the if(optopt == '?') > > condition as shown below, it loads the game fine. It does exit with > > an invalid pointer warning though. What is the question mark supposed > > to mean, anyways? Should it be NULL instead? From the limited getopt > > knowledge I have, I don't this is strictly necessary, as the > > if(argv[optind] != NULL) should take care of that. > > > Shawn, can you comment on this? Yep. Okay, I just finished testing, reading through the code, and piecing together what I originally did. Here's the deal. Everything is working exactly like it's supposed to here: The code checks for the user *explicitly* passing a '-?' option to zsnes to determine whether or not to display the 'options help text'. If the user doesn't *explicitly* pass any option, optopt is set to '?' (should be anyway). Since optopt is set to '?', I know the user didn't pass any options. Now that I know the user didn't pass any options, I attempt to get a filename from the command line if they passed one in: If there is no filename, zsnes starts up normally and displays the file menu. If there is a filename, zsnes starts up and executes the specified ROM file. Now, I just tested this to make sure all of the above happens exactly like it's supposed to, and it does. My guess is that the getopt implementation on your system is somehow faulty, or is not behaving the same as the one I'm using. What Operating System and version of it are you using? -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
From: Shawn <dr...@wa...> - 2004-10-07 18:32:39
|
On Thu, 2004-10-07 at 10:15 -0700, Ben Ford wrote: > Ben Ford wrote: > > > I gave it a precursory lookover. It doesn't appear that the code to > > load the rom is ever loaded. If I comment out the if(optopt == '?') > > condition as shown below, it loads the game fine. It does exit with > > an invalid pointer warning though. What is the question mark supposed > > to mean, anyways? Should it be NULL instead? From the limited getopt > > knowledge I have, I don't this is strictly necessary, as the > > if(argv[optind] != NULL) should take care of that. > > > Shawn, can you comment on this? When I have a moment later tonight, I'll look into it. Thanks, -- Shawn <dr...@wa...> http://drevil.warpcore.org/ |
From: Jeremy B. <je...@br...> - 2004-10-07 17:33:28
|
Ben Ford wrote: > Ben Ford wrote: > >> I gave it a precursory lookover. It doesn't appear that the code to >> load the rom is ever loaded. If I comment out the if(optopt == '?') >> condition as shown below, it loads the game fine. It does exit with >> an invalid pointer warning though. What is the question mark >> supposed to mean, anyways? Should it be NULL instead? From the >> limited getopt knowledge I have, I don't this is strictly necessary, >> as the if(argv[optind] != NULL) should take care of that. > > Shawn, can you comment on this? I'll go ahead and comment, since I researched this a little bit. The getopt(3) man page says: If getopt() does not recognize an option character, it prints an error message to stderr, stores the character in optopt, and returns `?'. The calling program may prevent the error message by setting opterr to 0. If getopt() finds an option character in argv that was not included in optstring, or if it detects a missing option argument, it returns `?' and sets the external variable optopt to the actual option character. If the first char- acter of optstring is a colon (`:'), then getopt() returns `:' instead of `?' to indicate a missing option argument. If an error was detected, and the first character of opt- string is not a colon, and the external variable opterr is nonzero (which is the default), getopt() prints an error message. The manpage doesn't really specify when optopt will be set to '?' (other than the condition where you actually have an option like "-?"), only when getopt will return '?'. Maybe there's some condition not mentioned in the manpage that the coder was testing for? Either way it does seem like the code should read something more like: case '?': filename = argv[optind]; break; ... if (filename) { ... makeextension(); } zstart(); Maybe Shawn can clarify. Jeremy |
From: Ben F. <be...@ka...> - 2004-10-07 17:14:28
|
Ben Ford wrote: > I gave it a precursory lookover. It doesn't appear that the code to > load the rom is ever loaded. If I comment out the if(optopt == '?') > condition as shown below, it loads the game fine. It does exit with > an invalid pointer warning though. What is the question mark supposed > to mean, anyways? Should it be NULL instead? From the limited getopt > knowledge I have, I don't this is strictly necessary, as the > if(argv[optind] != NULL) should take care of that. Shawn, can you comment on this? -b > > ben@pluto ~/Projects $ diff -u zsnes/src/linux/zloaderw.c.orig > zsnes/src/linux/zloaderw.c > --- zsnes/src/linux/zloaderw.c.orig 2003-10-22 20:10:08.000000000 > -0700 > +++ zsnes/src/linux/zloaderw.c 2004-10-04 02:18:40.744794080 -0700 > @@ -336,8 +336,8 @@ > } > > /* execute rom filename: file.x */ > - if (optopt == '?') > - { > +// if (optopt == '?') > +// { > if (argv[optind] != NULL) > { > fvar=&fname; > @@ -345,7 +345,7 @@ > strncpy(&fvar[1], argv[optind],127); > makeextension(); > } > - } > +// } > > zstart(); > return 0; |